Épigraphe

I
ÉPIGRAPHE
‘Une communication efficace est indispensable pour réussir

professionnellement, que ce soit au niveau interpersonnel, interne,
organisationnel ou externe.’
Mike Myatt
II
DÉDICACE
À mon papa Kalubi Mulamba Jean – Pierre et à ma maman

Mpunga Mukeba Marie – Thérèse. Mes faibles mots ne sauraient
exprimer tout l’amour et la considération que j’ai pour vous, mes
modèles.
Ndaya K.
III
REMERCIEMENTS
Mes plus vifs remerciements s’adressent :
À l’Éternel Dieu tout puissant qui m’a donné force, courage et détermination pour que ce qui
était un rêve plusieurs mois plutôt devienne aujourd’hui une réalité ;
Au professeur KAMBA Camille et à son collaborateur, l’assistant MULENDA KINGWEZYA

Jacques pour l’encadrement scientifique qu’ils ont assuré tout le long de ce travail.
À mon père KALUBI MULAMBA Jean-Pierre et ma mère MPUNGA MUKEBA Marie-

Thérèse pour leur amour, leur soutien et leurs conseils.
À mes frères Nickson MBIYA, Delvard MUKEBA, Rouminigue TSHAMALA, Élie

TSHIMANGA et Mardochée KALUBI ;
À mes neveux et nièces Niclette TSHAMALA, Dan MUKEBA, Sylvie KAYOWA, David
KALUBI, Salomon TSHAMALA, Joseph BAATI, Edgard KALUBI et Èloy KALUBI.
À mes belles sœurs Rosie SIKYABA, Pierce NSONGA et Carmel NGOY ;
À mon aimable compagnon Jonathan LUNGUNGA ainsi qu’à mes proches amis, Linda
KAPASI, Darren KALONDA et Valdo WANUKE ;
À tous les enseignants du Département d’Informatique de Gestion et Sciences Commerciales

et Administratives ;
À mes collègues de classe Mariam RAMAZANI, Immaculée NEEMA, Gracia KABALADI,

Marlène NKULU, Borel KABWE, Gloire KASONGO, Josias MUYABA ainsi qu’à tous mes
frères et sœurs dans le Seigneur ; qu’ils trouvent ici l’expression de ma plus profonde gratitude.
IV
RÉSUMÉ
L’intégration des Technologies de l’Information et de la Communication, en sigle TIC, dans le

secteur de l’enseignement a amélioré de manière significative le rendement des institutions
aussi bien dans la gestion des activités administratives que dans celle des activités
académiques. À l’Institut Supérieur Pédagogique de Lubumbashi, les enquêtes sur l’utilisation
des TIC révèlent l’absence d’un usage optimal de l’outil informatique pour la gestion des
étudiants, précisément en matière de communication des informations pertinentes, susceptibles
d’influencer positivement ou négativement le rendement de leur formation. Le présent travail
se propose de mettre en place un mécanisme qui facilitera la communication des informations
aux étudiants. Ce mécanisme n’est autre qu’une application web sur laquelle chaque étudiant
inscrit aura la possibilité de se connecter à distance pour consulter les horaires et les
communiqués qui le concernent.
Mots clés : Communication, gestion des étudiants et application web.

V
SOMMAIRE
ÉPIGRAPHE.............................................................................................................................. I
DÉDICACE .............................................................................................................................. II
REMERCIEMENTS ................................................................................................................ III
RÉSUMÉ .................................................................................................................................IV
SOMMAIRE ............................................................................................................................. V
LISTE DES FIGURES .......................................................................................................... VII
LISTE DES TABLEAUX......................................................................................................... X
INTRODUCTION GÉNÉRALE ............................................................................................... 1
1. Présentation du sujet ....................................................................................................... 1
2. Choix et Intérêt du sujet .................................................................................................. 1
a. Choix du sujet.............................................................................................................. 1
b. Intérêt du sujet ......................................................................................................... 1
3. État de la question ........................................................................................................... 2
4. Problématique et Hypothèses .......................................................................................... 5
a. Problématique.............................................................................................................. 5
b. Hypothèses............................................................................................................... 6
5. Méthode et Techniques ................................................................................................... 6
a. Méthode....................................................................................................................... 6
b. Techniques ............................................................................................................... 6
6. Délimitation du sujet ....................................................................................................... 7
a. Dans l’espace............................................................................................................... 7
b. Dans le temps........................................................................................................... 7
7. Subdivision du travail ..................................................................................................... 8
Chapitre 1. ETUDE PREALABLE............................................................................................ 9
Introduction ............................................................................................................................ 9
1.1. Présentation de l’Institut Supérieur Pédagogique de Lubumbashi.............................. 9
1.1.1. Situation géographique ........................................................................................ 9
1.1.2. Historique de l’Institut Supérieur Pédagogique de Lubumbashi ....................... 10
1.1.3. Mission de l’ISP – Lubumbashi ......................................................................... 10
1.1.4. Fonctionnement et organisation de l’ISP – Lubumbashi ................................... 11
1.1.5. Présentation de la structure hiérarchique de l’ISP-Lubumbashi ........................ 12
1.2. Délimitation du périmètre d’étude ............................................................................ 13
1.2.1. Modélisation du métier ...................................................................................... 13
1.3. Critique de l’existant et proposition des solutions .................................................... 21
1.3.1. Critique de l’existant .......................................................................................... 21
1.3.2. Proposition des solutions ................................................................................... 22
Conclusion ........................................................................................................................... 22
Chapitre 2. CONCEPTION DU SYSTÈME INFORMATIQUE ............................................ 23
Introduction .......................................................................................................................... 23
2.1. Expression des besoins et spécification des fonctionnalités ......................................... 23
2.1.1. Exigences fonctionnelles ....................................................................................... 23
VI
2.1.2. Exigences non fonctionnelles (Exigences techniques) .......................................... 25

2.1.3. Identification et représentation des besoins ........................................................... 26
2.1.4. Spécification détaillée des besoins......................................................................... 31
2.2. Analyse du système....................................................................................................... 44
3.2.1. Analyse du domaine : modèles du domaine ...................................................... 44
3.2.2. Diagrammes des classes participantes ............................................................... 49
3.2.3. Diagrammes d’activités de navigation ............................................................... 56
2.3. Conception du système ................................................................................................. 60
3.2.4. Diagrammes d’interaction globale ..................................................................... 61
3.2.5. Diagrammes des classes de conception ............................................................. 66
3.2.6. Diagramme de packages .................................................................................... 71
2.4. Passage au modèle logique de données relationnel ...................................................... 72
Règle 1 : Transformation des entités/classes ................................................................... 72
Règle 2 : Associations un-à-plusieurs .............................................................................. 72
Règle 3 : Associations plusieurs-à-plusieurs et n-aires.................................................... 72
Règle 4 : Associations un-à-un ........................................................................................ 73
Conclusion ........................................................................................................................... 79
Chapitre 3. REALISATION DU SYSTÈME INFORMATIQUE ........................................... 80
Introduction .......................................................................................................................... 80
3.1. Choix de l’architecture logicielle .................................................................................. 80
3.1.1. Architecture logicielle du système informatique ................................................... 80
3.1.2. Architecture technique du système informatique .................................................. 83
3.1.3. Vue d’implémentation : Diagramme de composants ............................................. 84
3.1.3. Vue de déploiement : Diagramme de déploiement ................................................ 85
3.2. Choix des outils de développement .............................................................................. 86
3.2.1. Le Système de Gestion des Bases de données MariaDB ....................................... 86
3.2.2. L’environnement de développement intégré PHPStorm ....................................... 87
3.2.3. Le langage de programmation PHP ....................................................................... 87
3.3. Présentation de l’application ......................................................................................... 88
Conclusion ........................................................................................................................... 92
CONCLUSION GÉNÉRALE .................................................................................................. 93
RÉFÉRENCES BIBLIOGRAPHIQUES ................................................................................. 95
VII
LISTE DES FIGURES
Figure 1: Localisation de l'ISP-Lubumbashi (GOOGLE MAPS, 2021) ................................... 9

Figure 2: Structure Hiérarchique de l'Institut Supérieur Pédagogique de Lubumbashi
(Organisation administrative des services, 2014) .................................................................... 12
Figure 3 : Diagramme de contexte du système sous étude ...................................................... 15
Figure 4:Diagramme de cas d'utilisation métier ...................................................................... 16
Figure 5: Diagramme d'activités pour l'horaire des cours........................................................ 17
Figure 6 : Diagrammes d'activités pour l'horaire des examens ................................................ 18
Figure 7 : Modèle du domaine du système sous étude ............................................................ 20
Figure 8: Diagramme de contexte du nouveau système logiciel ............................................. 27
Figure 9: Diagramme de contexte du nouveau système logiciel ............................................. 27
Figure 10: Diagramme de cas d'utilisation du nouveau système logiciel ................................ 29
Figure 11: Diagramme de cas d'utilisation du nouveau système logiciel ................................ 29
Figure 12 : Fiche de description textuelle (Enregistrer un agent) ............................................ 32
Figure 13 : Fiche de description textuelle (Enregistrer un agent) ............................................ 32
Figure 14 : Fiche de description textuelle (Enrôler un étudiant) ............................................. 33
Figure 15 : Fiche de description textuelle (Enrôler un étudiant) ............................................. 33
Figure 16 : Fiche de description textuelle (Publier un horaire) ............................................... 34
Figure 17 : Fiche de description textuelle (Publier un horaire) ............................................... 34
Figure 18 : Fiche de description textuelle (Prendre la présence) ............................................. 35
Figure 19 : Fiche de description textuelle (Prendre la présence) ............................................. 35
Figure 20 : Fiche de description textuelle (Coter une épreuve) ............................................... 36
Figure 21 : Fiche de description textuelle (Coter une épreuve) ............................................... 36
Figure 22 : Fiche de description textuelle (Publier un communiqué) ...................................... 37
Figure 23 : Fiche de description textuelle (Disponibiliser un cours) ....................................... 38
Figure 24 : Fiche de description textuelle (Lire un cours) ....................................................... 39
Figure 25 : Diagramme de séquence (Enregistrer un agent).................................................... 40
Figure 26 : Diagramme de séquence (Enrôler un étudiant) ..................................................... 41
Figure 27 : Diagramme de séquence (Publier un horaire) ....................................................... 41
Figure 28 : Diagramme de séquence (Prendre la présence) ..................................................... 42
Figure 29 : Diagramme de séquence (Coter une épreuve) ....................................................... 42
Figure 30 : Diagramme de séquence (Publier communiqué)................................................... 43
VIII
Figure 31 : Diagramme de séquence (Disponibiliser un cours) ............................................... 43

Figure 32 : Diagramme de séquence (Lire un cours) ............................................................... 44
Figure 33:Modèle du domaine (Maintenir le système) ............................................................ 45
Figure 34: Modèle du domaine (Enregistrer un agent) ............................................................ 45
Figure 35 : Modèle du domaine (Enrôler un étudiant) ............................................................ 46
Figure 36 : Modèle du domaine (Publier un horaire) .............................................................. 47
Figure 37 : Modèle du domaine (Coter une épreuve) .............................................................. 47
Figure 38 : Modèle du domaine (Prendre la présence) ............................................................ 48
Figure 39 : Modèle du domaine (Publier un communiqué) ..................................................... 48
Figure 40 : Modèle du domaine (Disponibiliser un cours) ...................................................... 49
Figure 41 : Modèle du domaine (Lire un cours) ...................................................................... 49
Figure 42 : Diagramme des classes participantes (Enregistrer un agent) ................................ 50
Figure 43 : Diagramme des classes participantes (Enrôler un étudiant) .................................. 51
Figure 44 : Diagramme des classes participantes (Publier un horaire) .................................... 52
Figure 45 : Diagramme des classes participantes (Prendre la présence) ................................. 53
Figure 46 : Diagramme des classes participantes (Coter une épreuve) ................................... 54
Figure 47 : Diagramme des classes participantes (Publier un communiqué) .......................... 55
Figure 48 : Diagramme des classes participantes (Disponibiliser un cours) ........................... 55
Figure 49 : Diagramme des classes participantes (Lire un cours) ........................................... 56
Figure 50 : Diagramme d'activité de navigation (Appariteur) ................................................. 57
Figure 51 : Diagramme d'activité de navigation (Département) .............................................. 58
Figure 52 : Diagramme d'activité de navigation (Enseignant) ................................................ 59
Figure 53 : Diagramme d'activité de navigation (Étudiant) ..................................................... 60
Figure 54 : Diagramme d'interaction globale (Enregistrer un agent) ...................................... 61
Figure 55: Diagramme d'interaction globale (Enrôler un étudiant) ......................................... 62
Figure 56: Diagramme d'interaction globale (Publier un horaire) ........................................... 63
Figure 57: Diagramme d'interaction globale (Prendre la présence) ........................................ 63
Figure 58 : Diagramme d'interaction globale (Coter une épreuve) ........................................ 64
Figure 59: Diagramme d'interaction globale (Publier un communiqué) ................................. 64
Figure 60: Diagramme d'interaction globale (Disponibiliser un cours) .................................. 65
Figure 61: Diagramme d'interaction globale (Lire un cours) .................................................. 65
b. Figure 62 : Diagramme de classe de conception (Enregistrer un agent) ......................... 66
Figure 63: Diagramme de classe de conception (Enrôler un étudiant) .................................... 67
IX
Figure 64: Diagramme de classe de conception (Publier un horaire) ...................................... 67

Figure 65: Diagramme de classe de conception (Prendre la présence) ................................... 68
Figure 66: Diagramme de classe de conception (Coter une épreuve) ..................................... 68
Figure 67: Diagramme de classe de conception (Publier un communiqué) ............................ 69
Figure 68: Diagramme de classe de conception (Disponibiliser un cours) ............................. 70
Figure 69: Diagramme de classe de conception (Lire un cours) ............................................. 70
Figure 70: Diagramme de packages du métier ........................................................................ 71
Figure 71 : Modèle Logique de Données Relationnel (StudentMS)........................................ 78
Figure 72 : Architecture 3-tiers (Driat, 2020) .......................................................................... 80
Figure 73 : Architecture MVC (orm.bdpedia.fr, s.d.) .............................................................. 82
Figure 74 : Architecture physique du système informatique ................................................... 84
Figure 75 : Diagramme de composants du système informatique ........................................... 84
Figure 76 : Diagramme de déploiement du système informatique .......................................... 85
Figure 77 : Logo du SGBD MariaDB ...................................................................................... 86
Figure 78 : Logo PHPMyAdmin.............................................................................................. 86
Figure 79 : Logo de PHPStorm................................................................................................ 87
Figure 80 : Logo du langage de programmation PHP ............................................................. 88
X
LISTE DES TABLEAUX
Tableau 1: Acteurs du système étudié ..................................................................................... 14

Tableau 2: Acteurs du nouveau système logiciel ..................................................................... 26
Tableau 3 : Planification du projet en itérations ...................................................................... 30
Page |1
INTRODUCTION GÉNÉRALE
1. Présentation du sujet
Au cours des deux dernières décennies, les Technologies de l’Information et de la

Communication, TIC, se sont avérées être de solides outils en termes de processus de
développement à travers le monde, trouvant leur application dans quasiment tous les secteurs,
notamment l’éducation (Mequanint & Lemma, 2014). L’utilisation des TIC dans les systèmes
éducatifs favorise la communication des informations, l’enseignement à distance,
l’apprentissage libre et permet ainsi aux universités d’élargir l’accès à l’enseignement,
renforcer les réseaux d’enseignement et de promouvoir la recherche ainsi que les échanges
professionnels (Traoré, 2007).
La gestion des étudiants au sein de l’Institut Supérieur Pédagogique de Lubumbashi présente

encore quelques failles en raison du manque d’outils de communication optimale sur toute
information qui concerne les activités prévues (planification des horaires des cours et des
examens) et cela diminue de moitié la formation de ces derniers. Et pour pallier à cette
difficulté, la création d’un site interactif avec des fonctionnalités adaptées aux activités de
l’institution (Kocoglu & Moatty, 2010) s’avère être une solution adéquate.
Ainsi le présent travail, a pour objet de créer une application web qui facilitera dorénavant la
gestion automatisée des enseignements pour les étudiants à l’ISP-Lubumbashi.
2. Choix et Intérêt du sujet
a. Choix du sujet
Le choix de notre sujet est fondé sur le besoin de pouvoir explorer une des pistes de solution
aux problèmes de manque de mécanisme adapté de communication sur les enseignements entre
l’ISP-Lubumbashi et les étudiants.
b. Intérêt du sujet
L’intérêt de ce travail est de faciliter la diffusion des informations pertinentes en temps réel et
de permettre la fiabilité des renseignements fournis aux étudiants et aux visiteurs à l’ISP-
Lubumbashi. Ainsi, il présente plusieurs intérêts à la fois : personnel, social et scientifique.
Page |2
i. Intérêt personnel
Ce travail nous permettra de compléter nos connaissances par des recherches en

programmation et dans la création des sites web, au profit de l’application qui fait l’objet de ce
dernier. Et nous pourrons ainsi explorer une piste de solution au problème de communication
à l’ISP-Lubumbashi.
ii. Intérêt social
L’intérêt social de ce travail, est dans la certitude d’atteindre au même moment le plus grand
nombre de personnes, c’est-à-dire les étudiants concernés et éventuellement les visiteurs, et
leur donner des informations pertinentes facilitant ainsi la compréhension, l’exécution et la
clôture, dans les meilleurs délais, de toutes les tâches qui leur sont proposées dans le cadre de
leur formation et, aux visiteurs d’être suffisamment informés sur ce qui se passe réellement au
sein de l’institut.
iii. Intérêt scientifique
Sur le plan scientifique, ce travail est une base de données mise à la disposition de tous ceux
qui travailleront dans le même domaine que nous, en vue d’aller au-delà de nos limites.
3. État de la question
Sachant que nous montons sur les épaules des autres chercheurs, nous nous sommes situés par
rapport aux travaux dont la thématique a trait à notre sujet.
En effet, la plupart des chercheurs abordent ou discutent sur un même sujet ou thème. Toutefois
pour des raisons spécifiques, chacun s’intéresse à un aspect particulier auquel il peut apporter
des améliorations et/ou de nouveaux horizons. (Kimpinde, 2016)
Nous avons consulté le travail de Mulay (2020) intitulé « La [sic] mise en place d’une
application web d’identification des étudiants de l’institut supérieur pédagogique de
Lubumbashi en ligne ». Dans son travail, la problématique tournait autour du mode de
traitement de données de l’ISP-L’shi qui était encore manuel en dépit du grand nombre
d’informations à gérer lors de l’enregistrement et de l’inscription des étudiants ; occasionnant
ainsi la lenteur lors de l’identification de ces derniers et des difficultés de retracer leurs parcours
au sein de l’institut. Et l’hypothèse était de recourir à la technologie web, avec ses nombreuses
applications, qui faciliterait la bonne gestion des données en temps réel avec une sécurité accrue
Page |3
et serait une solution optimale au problème d’enregistrement et d’identification pour l’ISP-

L’shi.
Le travail de Mulay a produit une application web permettant l’enregistrement et

l’identification des étudiants inscrits à l’ISP-Lubumbashi ; résolvant ainsi le problème exposé
ci-haut et fournissant également des informations sur le parcours des étudiants au sein de
l’institut.
Par rapport au résultat de ce dernier, le présent travail se démarque dans la mesure où il pourrait
permettre aux étudiants enregistrés d’accéder, à distance, aux informations fournies par leur
département pour leur promotion ainsi qu’aux données personnelles qui cadrent avec
l’avancement des cours, tout au long de l’année académique. Et éventuellement aux visiteurs,
d’accéder aux informations générales sur l’organisation des enseignements à l’ISP-
Lubumbashi.
Nous avons consulté également le travail de Saiche et Ouyougoute (2015) intitulé

« Conception et réalisation d’une application web pour la gestion des étudiants d’une
école privée » cas d’étude de ‘ISA School’. Leur objectif était de concevoir et réaliser une
application web simple de gestion des entrées/sorties des étudiants ainsi que les [sic]
enseignants du centre de formation.
Les problèmes que rencontrait l’organisation d’étude étaient les suivants :
✓ Le volume important des informations traitées manuellement, provocant parfois des

erreurs dans l’établissement des documents ;
✓ La recherche difficile sur les registres qui engendre une perte de temps ;
✓ L’insécurité des informations ;
✓ La possibilité d’erreur dans le remplissage des différents documents et registres ;
✓ La possibilité d’erreurs dans le calcul des statistiques.
Leur proposition était d’informatiser le système d’information du centre, afin d’assurer l’accès
instantané aux données et la sécurisation de ces dernières, simplifiant ainsi le travail
administratif.
Page |4
L’application web créée à l’issue de ce travail permet d’assurer plusieurs fonctionnalités de

base à savoir : la création d’un dossier (étudiant ou enseignant), sa modification, la consultation
des différents dossiers, l’impression des différents documents et le calcul des statistiques.
En comparaison, l’application qui fait objet du présent travail permettrait la création des
comptes utilisateurs, l’affichage des communiqués du département, l’élaboration et l’affichage
des horaires, le téléchargement et la consultation des contenus des cours en ligne et la
présentation de l’état d’avancement des cours.
Enfin, un autre travail a attiré notre attention. Il s’agit de celui de Melle (2018) dont le titre est
« Application web pour la gestion du département de Mathématique et d’Informatique ».
Son système d’étude était doté d’une application monoposte développée en langage Visual
Basic et insuffisante pour la gestion des étudiants, des matières à enseigner et des notes. Cette
insuffisance était due à la délégation de toutes ces tâches à un seul agent et cela pouvait
engendrer des limitations telles que l’augmentation des risques d’erreur, l’influence négative
sur le rendement à cause de la taille des tâches à remplir par un seul agent et les difficultés de
gestion des notes telles que la saisie et la correction des données erronées. Pour résoudre ces
problèmes, Melle a proposé un ensemble d’améliorations pour enrichir le système actuel par
de nouvelles fonctionnalités et de nouveaux acteurs grâce à une application web. Cette
application permet de gérer la tâche de saisie et de consultation des notes et des absences des
étudiants du département.
L’application réalisée permet de gérer les absences des étudiants de manière souple, de
distribuer les efforts de saisie des notes et absences entre plusieurs acteurs et de dégager le
service de scolarité de contacter les étudiants qui doivent directement contacter les enseignants
en cas d’erreur de saisie ou d’absences justifiées.
Face à ces résultats, le présent travail se démarque dans la mesure où il permettrait aux étudiants
de consulter le rendement de leur participation aux cours en termes de présence et des notes
des travaux, et de contacter le département en cas d’erreur de saisie et d’absence justifiée.
En somme, l’application web qui fait objet du présent travail pourrait renfermer des
fonctionnalités pour faciliter le contact permanent entre l’ISP-Lubumbashi et ses étudiants,
donner un aperçu général sur les filières organisées à l’ISP-Lubumbashi et faciliter la
communication des informations qui cadrent avec les enseignements. Celle application devrait
permettre :
Page |5
✓ La gestion des comptes utilisateurs ;
✓ L’enrôlement des étudiants ;
✓ La publication des horaires ;
✓ La publication des communiqués émanant du département ;
✓ Le téléchargement du contenu des cours ;
✓ La saisie et l’affichage des notes des cours ;
✓ La saisie des présences.
4. Problématique et Hypothèses
a. Problématique
L’Institut Supérieur Pédagogique de Lubumbashi est une institution publique d’enseignement

supérieur. Elle accueille chaque année de nouveaux candidats et inscrit ses étudiants dans les
promotions de recrutement et dans les promotions montantes. Ces derniers ne sont pas tenus
informés dans les meilleurs délais sur toutes sortes d’activités académiques ; notamment celles
orientées vers l’enseignement et l’évaluation. Ceci s’explique par un certain nombre de
problèmes tels que :
• Le temps d’émission et de réception des informations n’est pas optimisé par manque
d’un mécanisme favorable ;
• Les communications portées à la connaissance des étudiants sont souvent affichées aux
valves qui ne sont pas toujours visitées par ces derniers ;
• Le retard dans la compréhension, l’exécution et la clôture de toute activité déclenchée

à l’issu d’une quelconque communication pertinente.
Face à cette situation, il convient de se poser des questions importantes à savoir :
✓ L’ISP-Lubumbashi, dispose-t-il d’un système de gestion des étudiants ?
✓ Si oui, est-il efficace ?
✓ Si non, pourquoi ?
Page |6
Et la question majeure dans pareille situation est celle de savoir : Quel système mettre en
place pour optimiser le processus de gestion des étudiants ?
b. Hypothèses
Le défi de l’Institut Supérieur Pédagogique de Lubumbashi étant majeur, à savoir, doter la

société Congolaise, en fonction de ses besoins, d’enseignants de haute qualité de formation,
celui-ci doit créer des bonnes conditions de contact avec ses étudiants pour assurer une bonne
gestion de ces derniers dans l’objectif d’une formation optimale en leur qualité d’enseignants.
Face à celui-ci, l’ISP-Lubumbashi dispose d’un système efficace de gestion mais qui n’est pas
optimal en termes de communication d’informations. Nous proposons alors un système qui
permettrait un contact permanent entre l’ISP-Lubumbashi et ses étudiants via un site web pour
une diffusion optimisée des informations qui cadrent avec les enseignements.
5. Méthode et Techniques
La création de cette application nécessite plusieurs techniques à la fois telles que l’observation
directe, l’interview et la technique documentaire, pour que les données soient les plus fiables.
Et la méthodologie qui sera utilisée pour la conception du système informatique est le processus
de développement logiciel UP (Unified Process) basé sur le formalisme UML (Unified
Modeling Language).
a. Méthode
UP est un acronyme anglais signifiant Processus Unifié en français. La méthode UP est un

processus d’ingénierie logicielle (SEP, pour Software Engineering Process), connu aussi
comme processus de développement logiciel, qui répond à la question fondamentale « Qui fait
quoi, quand et comment ? ». C’est un processus dans lequel nous transformons les besoins des
utilisateurs en logiciel (Arlow & Neustadt, 2005).
b. Techniques
i. Observation directe
Elle a consisté à observer ce qui se fait sur terrain c’est-à-dire au sein de l’Institut Supérieur
Pédagogique de Lubumbashi ayant pour mission de former les futurs enseignants. En ce qui
nous concerne, nous avons observé la manière de diffuser les informations par les départements
qui organisent les enseignements durant notre cursus académique.
Page |7
ii. Interview
Elle a consisté à poser directement des questions aux personnes ayant des responsabilités dans
les services qui nous intéressent ; tels que le chef du Département d’Informatique et
l’Appariteur Central de l’ISP-Lubumbashi.
iii. Technique documentaire
Elle a consisté à faire recours à la documentation afin de récolter les données susceptibles de
nous aider pour l’élaboration du travail.
Nous avons consulté des documents internes à l’organisation, c’est-à-dire l’ISP-Lubumbashi,

des ouvrages sur la modélisation UML, des articles sur l’intégration et l’utilisation des
Technologies de l’Information et de la Communication dans l’enseignement, des mémoires de
licence et de mater, des cours sur la conception des Systèmes d’Information et sur la
modélisation Orientée Objet ainsi que des sites web.
6. Délimitation du sujet
Le sujet qui fait l’objet de ce travail est limité, dans le temps et dans l’espace pour nous
permettre d’être précis et concis.
a. Dans l’espace
L’institut Supérieur Pédagogique de Lubumbashi est notre champ d’étude. Et, le département
d’Informatique de Gestion & des Sciences Commerciales et Administratives (IG & SCAD)
ainsi que l’apparitorat central, limitent ce travail dans l’espace, c’est-à-dire tout ce qui concerne
ce travail doit être en rapport avec l’enregistrement des étudiants et les enseignements.
b. Dans le temps
L’application web créée sera utile tant qu’elle répond et s’adapte mieux au temps et aux besoins
de l’organisation ainsi qu’à l’évolution technologique. Et la période mise sous étude est celle
qui va de l’an 2018 jusqu’à nos jours.
En l’an 2018, nous avons appris qu’il existe des départements qui gèrent les étudiants au
quotidien selon leurs programmes d’études et qui leur fournissent des informations en rapport
avec les enseignements et les évaluations. Dès lors, nous avons observé le déroulement et
l’évolution du processus de communication entre notre département et ses étudiants
Page |8
7. Subdivision du travail
En plus de l’introduction et de la conclusion, le présent travail est organisé en trois chapitres,

à savoir :
✓ Le chapitre premier intitulé Étude Préalable est consacré à la présentation de

l’organisation et à la description du domaine d’étude ;
✓ Le chapitre deuxième intitulé Conception du Système Informatique parle des différentes

étapes qui concourent à l’obtention du nouveau système logiciel ;
✓ Le chapitre troisième intitulé Réalisation du Système Informatique décrit le choix de

l’architecture logicielle et le choix des outils de développement pour l’implémentation du
Système conçu à cet effet ainsi que la présentation de l’application web.
Page |9
Chapitre 1. ETUDE PREALABLE
Introduction
La réalisation d’un projet au sein d’une institution nécessite au préalable une bonne
connaissance de celle-ci afin de pouvoir comprendre son fonctionnement et de cerner le(s)
processus qui cadre(nt) le mieux avec le thème sous étude.
Dans ce chapitre, nous allons présenter la structure d’accueil dans son ensemble, déterminer le
domaine d’étude, faire une analyse du (des) processus métier(s) et mettre en lumière les points
forts et les points faibles du système actuel qui seront améliorés dans le nouveau système.
1.1. Présentation de l’Institut Supérieur Pédagogique de Lubumbashi
1.1.1. Situation géographique
L’Institut Supérieur Pédagogique de Lubumbashi est un établissement public d’Enseignement

Supérieur située à 11° 39’ 12.1’’ de latitude Sud et 27° 28’ 01.3’’ de longitude Est (Google
maps, 2021). Et son adresse physique est au numéro 287 de l’avenue De La Révolution, dans
le Quartier Baudouin, Commune de Lubumbashi, Ville de Lubumbashi, Province du Haut-
Katanga.
Figure 1: Localisation de l'ISP-Lubumbashi (GOOGLE MAPS, 2021)

P a g e | 10
1.1.2. Historique de l’Institut Supérieur Pédagogique de Lubumbashi
L’Institut Supérieur Pédagogique (ISP) de Lubumbashi, alors École Normale Moyenne (ENM)
d’Élisabethville est une institution d’Enseignement Supérieur et Universitaire en République
Démocratique du Congo créée le 06 septembre 1959 par le Gouvernement Central de
Léopoldville et confiée à la congrégation des pères Bénédictins de Saint-André de Bruges
(Belgique) sous l’appellation de « Institut Saint Jérôme d’Élisabethville ». L’initiateur du
projet est le Révérend Père François Jean Chrysostome Don Guilbert (O.S.B. : Ordre de Saint
Benoît) qui devint le premier Directeur de l’établissement. À partir de 1960, L’institut a
bénéficié de l’appui de la Coopération Technique Belge (CTB) dans le cadre des relations
bilatérales, tant en personnel enseignant qu’en matériel jusqu’en 1991 à la suite de la rupture
des relations de Coopération entre la Belgique et la République du Zaïre.
En août 1971, le chef de l’État Mobutu créa l’Université Nationale du Zaïre (UNAZA) qui
regroupait les Campus Universitaires et des instituts d’Enseignement Supérieur technique et
PÉDAGOGIQUE. En septembre de la même année, il définit la structure des Instituts
Supérieurs Pédagogiques en tant que membres à part entière de l’Université Nationale, placés
sous tutelle du Commissaire d’État chargé de l’éducation nationale et dépendant du rectorat de
l’UNAZA. La « politique académique et administrative » des ISP est coordonnée par le Conseil
Général des ISP composé par les Directeurs Généraux et Directeurs des différents instituts. Le
Conseil Général, à son tour, se réfère au Conseil d’Administration de l’UNAZA pour toute
décision relative aux propositions émises tant sur le plan académique qu’administratif.
En 1981, l’Institut Supérieur Pédagogique de Lubumbashi devient un établissement public

d’enseignement supérieur jouissant de la personnalité juridique et sous tutelle de
l’Enseignement Supérieur et Universitaire (ESU). (Abekyamwale, 2015)
1.1.3. Mission de l’ISP – Lubumbashi
L’Institut Supérieur Pédagogique de Lubumbashi a pour mission de :
✓ Pourvoir le pays, en fonction de ses besoins, en enseignants de haut niveau de formation

générale et spécialisée aux qualités morales et pédagogiques éprouvées ;
✓ Stimuler chez le futur cadre une prise de conscience de son rôle d’agent de développement,
de la noblesse de sa mission et de la dignité de la personne humaine ;
P a g e | 11
✓ Organiser la recherche dans les différents domaines de formation en vue d’améliorer la

qualité de vie ;
✓ Vulgariser les résultats des recherches par la rédaction et la publication des ouvrages
divers. (Isplubum.wordpress.com, 2011)
1.1.4. Fonctionnement et organisation de l’ISP – Lubumbashi
L’Institut Supérieur Pédagogique de Lubumbashi est dirigé par le Conseil de l’Institut,

composé des membres du Comité de Gestion, de tous les Chefs des Sections, du délégué des
étudiants, des Corps académique, scientifique, administratif, technique et ouvrier sur décision
du Directeur Général après désignation de ces derniers par leurs pairs.
• Le comité de Gestion (CG)
Il est l’organe d’exécution et de gestion au quotidien de l’Institut. Ces réunions sont

hebdomadaires.
Le Comité de Gestion est composé des membres suivants :
- Le Directeur Général ;
- Le Secrétaire Général Académique ;
- Le Secrétaire Général Administratif ;
- L’Administrateur de Budget.
• Le Directeur Général (DG)
C’est l’organe qui supervise et coordonne l’ensemble des activités de l’ISP – Lubumbashi. À
ce titre, il assure l’exécution des décisions du Conseil de l’Institut et du Comité de Gestion.
• Le Conseil de Section
Cet organe organise et tient des réunions mensuellement et transmet ses procès-verbaux au
Comité de Gestion.
• Le Conseil de Département
Cet organe de base tient également ses réunions mensuellement conformément à l’Instruction
Académique n°31 du 20 octobre 1977 et transmet ses procès-verbaux au Conseil de Section.
(Abekyamwale, 2015)
P a g e | 12
1.1.5. Présentation de la structure hiérarchique de l’ISP-Lubumbashi
Figure 2: Structure Hiérarchique de l'Institut Supérieur Pédagogique de Lubumbashi (Organisation administrative des services, 2014)
P a g e | 13
1.2. Délimitation du périmètre d’étude
La délimitation du périmètre d’étude nous permet de réduire la complexité de modélisation de

toute l’entreprise en un tout au risque d’aller au-delà de nos attributions. De ce fait nous avons
délimité notre étude à un seul domaine d’activité.
Un domaine d’activité ou un métier de l’organisation est un sous-ensemble relativement

indépendant composé d’informations, de règles et de procédures de gestion.
Notre domaine d’activité est le Département d’Informatique de Gestion & des Sciences
Commerciales et Administratives (IG & SCAD), appelé structure de base qui gère au quotidien
les étudiants.
1.2.1. Modélisation du métier
1.2.1.1. Circulation de l’information
La gestion des étudiants par le département, dans le cadre de la communication, se fait de la

manière suivante : au début de chaque semestre, le département contacte les enseignants et sur
base de leur disponibilité, il élabore l’horaire des cours, le transmet à la section pour
approbation puis la section envoie cet horaire au Secrétariat Général Académique pour
validation. Après validation de cet horaire, le Secrétariat Général Académique le renvoie à la
section qui le remet à son tour au département pour un affichage à une ou plusieurs valves
choisies de manière aléatoire, par manque d’endroit approprié à cet effet, et qui ne sont pas
toujours visitées par les étudiants puis une copie est envoyée aux enseignants.
Pour les examens, les étudiants proposent l’horaire au département qui l’élabore puis le
transmet à la section pour approbation et la section envoie cet horaire au Secrétariat Général
Académique pour validation. Après validation de cet horaire, le Secrétariat Général
Académique le renvoie à la section qui le remet au département. Alors l’horaire ainsi validé est
affiché à une ou plusieurs valves choisies de manière aléatoire pour la communication aux
étudiants et une autre copie est envoyée aux enseignants.
Par ailleurs, le département utilise le moyen oral ou les réseaux sociaux pour communiquer
toute autre information telle que la modification d’un horaire de cours.
P a g e | 14
a. Recensement des acteurs
Le processus de gestion des étudiants en termes de communication fait intervenir plusieurs

acteurs.
Un acteur spécifie le rôle que joue une entité externe lorsqu’elle interagit directement avec le
système (Arlow & Neustadt, 2005, p.73). Un acteur peut être une personne physique, un
système externe ou même un matériel qui interagit avec le système.
Les différents acteurs qui interagissent avec le système de gestion des étudiants sont repris dans
le tableau ci-après :
Tableau 1: Acteurs du système étudié
N° Acteur Rôle
1 Département Le bureau qui élabore, affiche les horaires et

lance les communiqués
2 Enseignant La personne qui propose l’horaire des cours et

consulte les horaires des cours et des examens
3 Étudiant La personne qui consulte les horaires ainsi que

les communiqués et propose l’horaire des
examens
4 Section Le bureau qui approuve les horaires élaborés par

le département
5 Secrétariat Général Le bureau qui valide les horaires avant affichage

Académique
b. Diagramme de contexte
Le digramme de contexte nous donne une vue générale sur la délimitation du domaine d’étude.
Pour le cas de la gestion des étudiants par leur structure de base, qui est le département, ce
diagramme se présente de la manière suivante :
P a g e | 15
Figure 3 : Diagramme de contexte du système sous étude
1.2.1.2. Analyse fonctionnelle du métier
L’analyse fonctionnelle nous permet d’avoir une compréhension profonde du métier sous
étude. Pour réaliser cette analyse, nous nous servons du diagramme de cas d’utilisation qui est
un diagramme comportemental du formalisme UML (Ngongo, 2021)1.
Un diagramme de cas d’utilisation représente les grandes fonctionnalités du système étudié

(Kimpinde, 2016, p.22) sous forme des cas d’utilisation. Ces cas d’utilisation sont vus ici
comme des fonctions métiers du système qui apportent une valeur ajoutée « notable » à l’acteur
qui est en interaction avec ceux-ci (Roques & Vallée, 2007, p.62).
1
Source dérivée d’un cours non accessible au public
P a g e | 16
Figure 4:Diagramme de cas d'utilisation métier
1.2.1.3. Analyse formelle du métier
L’analyse formelle nous permet de bien comprendre le déroulement des activités au sein du
domaine étudié. Cette analyse est réalisée à l’aide du diagramme d’activités.
Un diagramme d’activités explique le comportement interne des cas d’utilisation. Ce

comportement s’applique aux flots de contrôle et flots de données propres à un ensemble
d’activités. (J. Gabay & D. Gabay, 2008)
Pour le cas du département, l’analyse est faite sur base de deux processus, avec deux
diagrammes d’activités qui expliquent respectivement la communication de l’horaire des cours
et la communication de l’horaire des examens.
P a g e | 17
✓ Communication de l’horaire des cours
Figure 5: Diagramme d'activités pour l'horaire des cours

P a g e | 18
✓ Communication de l’horaire des examens
Figure 6 : Diagrammes d'activités pour l'horaire des examens

P a g e | 20
1.2.1.4. Analyse structurelle du métier
L’analyse structurelle nous permet de définir les classes qui modélisent les entités ou les
concepts présents dans le domaine étudié. Cette analyse est matérialisée par un modèle du
domaine (Ngongo, 2021)2.
Le modèle du domaine est un diagramme de classe qui décrit ici la structure des entités
manipulées par les acteurs (Roques, 2008, p.76).
Figure 7 : Modèle du domaine du système sous étude
2
Source dérivée d’un cours non accessible au public
P a g e | 21
1.3. Critique de l’existant et proposition des solutions
1.3.1. Critique de l’existant
a. Point positif
La circulation de l’information au sein de l’organisation traduit une bonne collaboration entre

les différents acteurs du système. En effet, la communication verticale ascendante entre les
différents niveaux hiérarchiques de l’organisation se déroule sans interruption bien qu’étant
quelques fois lente. Et, la communication verticale descendante est assez fluide et ne connait
qu’une rupture au niveau de la transmission de l’information du département vers les étudiants
à cause du temps qui s’écoule avant que l’information atteigne les concernés.
Par ailleurs, la communication horizontale entre les étudiants eux-mêmes est sans interruption
et ne connait pas de lenteur, mais présente plutôt le risque de perte d’authenticité de
l’information.
b. Points négatifs
Le système actuel n’est pas optimal : au niveau de la communication verticale ascendante, il

faut environ une semaine pour que l’horaire proposé soit validé et au niveau de la
communication verticale descendante, un minimum de deux semaines est nécessaire pour que
l’information atteigne les entités concernées. Au total trois semaines s’écoulent pour la
communication d’une information pertinente qui influe sur la formation des étudiants de telle
sorte que le retard dans la compréhension, l’exécution, et la clôture de toute activité qui cadre
avec l’enseignement et les évaluations se fasse sentir dans les compétences, non suffisantes,
acquises des futurs formateurs encadrés par l’institution.
En effet, sur 60 étudiants 5% peuvent être informés d’une communication au moment opportun,
puis il faudra un minimum de deux semaines pour que près de 40% soient en possession de
cette information alors que les activités peuvent déjà avoir débuté. Le reste des étudiants sont
généralement informés par leur paire avec tous les risques inhérents à la communication orale ;
tels que la distorsion, la perte d’authenticité et l’incompréhension de l’information. Ceci
conduit généralement à une irrégularité dans la participation aux cours et aux évaluations de la
part des étudiants et une difficulté de maîtrise de la population estudiantine par les structures
qui les gèrent au quotidien : les départements.
P a g e | 22
Par ailleurs, la mise à jour des horaires affichés n’est pas communiquée officiellement et cela
met la majorité des étudiants ainsi que les enseignants dans une difficulté d’adaptation au
nouveau programme après ce genre de perturbation.
1.3.2. Proposition des solutions
Pour résoudre ces problèmes, nous proposons un système informatique permettant

l’élaboration, la mise à jour et la publication des horaires ainsi que le contact permanent entre
l’ISP-Lubumbashi et ses étudiants pour faciliter une bonne maitrise de ces derniers en vue
d’une formation complète durant de leur parcours au sein de cette institution.
Conclusion
Ce chapitre nous a permis de faire une présentation générale de notre champ d’étude ainsi
qu’une délimitation du domaine auquel nous nous sommes intéressés pour faire l’analyse du
métier. Ainsi, nous avons clairement identifié les processus à optimiser dans le nouveau
système compte tenu des points faibles qu’ils présentent dans le cadre de la communication des
informations.
P a g e | 23
Chapitre 2. CONCEPTION DU SYSTÈME INFORMATIQUE
Introduction
Un système informatique est un ensemble de moyens informatiques et de télécommunications,

matériels et logiciels, ayant pour ﬁnalité de collecter, traiter, stocker, acheminer et présenter
des données (Lonchamp,2017, p.1). Les logiciels constituent la partie immatérielle du système
informatique qui participent à l’automatisation de certains processus productifs au sein d’une
institution (Hossam, 2021).
Dans le présent chapitre, nous allons concevoir un nouveau système logiciel capable
d’optimiser le processus de gestion des étudiants grâce à la méthode UP, basée sur le
formalisme UML à l’aide duquel nous représenterons les différentes vues (statique,
fonctionnelle et dynamique) du système logiciel sous forme de diagrammes.
2.1. Expression des besoins et spécification des fonctionnalités
L’objectif de ce projet est de résoudre l’ensemble des problèmes mis en évidence au niveau de
la critique de l’existant dans le chapitre précédent ; qui se résument en un manque de
mécanisme efficace de communication. Le système logiciel qui sera réalisé aura une portée
locale, c’est-à-dire il sera utilisé à l’ISP-Lubumbashi qui est notre champ d’étude, plus
précisément au niveau du département ainsi qu’au niveau de l’apparitorat central.
Pour réaliser le projet de manière complète et cohérente, nous allons identifier à cette phase,
les besoins des utilisateurs, qui seront représentés sous forme d’exigences fonctionnelles du
système, et nous présenterons également les exigences non fonctionnelles de ce système.
2.1.1. Exigences fonctionnelles
Les exigences fonctionnelles définissent le système de base et déterminent donc ce que le

système fera et ne fera pas. Il s’agit ici des fonctionnalités que le système offre pour satisfaire
les besoins des utilisateurs. Les exigences fonctionnelles font donc en sorte que le système
fasse ce qu’il doit faire. Si elles ne sont pas mises en œuvre, le système ne sera pas opérationnel.
L’accent est ici placé sur ce que l’utilisateur veut atteindre. (De Wit, 2020)
Pour que le système logiciel qui fait objet de ce travail soit opérationnel, il devra permettre :
l’enregistrement d’un agent, l’enrôlement d’un étudiant, la publication d’un horaire, la
P a g e | 24
publication d’un communiqué, la disponibilisation d’un cours, la lecture et le téléchargement

éventuel d’un cours, la cotation d’une épreuve, le pointage de présence, la connexion au
système ainsi que la maintenance du système.
✓ L’enregistrement d’un agent ;
Le système logiciel doit permettre à l’administrateur d’enregistrer un agent dans la base de

données du système et ce dernier aura un compte utilisateur à l’aide duquel il pourra se
connecter sur le système.
✓ L’enrôlement d’un étudiant
Le système doit également permettre à l’appariteur d’enrôler un étudiant de sorte que ce dernier
ait accès aux informations internes qui le concernent sur le système.
✓ La publication d’un horaire
Avec cette fonctionnalité, le système logiciel doit permettre au département de créer un horaire
des cours ou un horaire des examens pour chaque promotion et cela pour une période bien
déterminée. Et cet horaire sera mis en ligne pour que les étudiants puissent le consulter.
✓ La publication d’un communiqué
Le système devrait permettre au département de créer un communiqué et de le mettre en ligne

à l’intention des étudiants.
✓ La disponibilisation d’un cours
Le système logiciel pourrait permettre à un enseignant de disponibiliser le contenu d’un cours

sur le système.
✓ La lecture et le téléchargement éventuel d’un cours
Le système logiciel pourrait permettre éventuellement qu’un étudiant ou un enseignant

télécharge un cours lors de la lecture.
✓ La cotation d’une épreuve
Le système logiciel pourrait permettre à chaque enseignant de créer, dans son cours, une
épreuve dans la base des données, dont il pourra déterminer le maximum puis d’attribuer une
côte à chaque étudiant inscrit au programme. La côte de chaque étudiant sera affichée en ligne
pour la consultation.
P a g e | 25
✓ Le pointage de présence ;
Le système logiciel pourrait permettre qu’un enseignant prenne la présence des étudiants à
chaque séance dans son cours. Le résultat sera affiché à l’intention des étudiants concernés.
✓ La connexion au système
Le système devrait permettre à chaque utilisateur de se connecter à sa session afin de bénéficier

des services du système selon son niveau d’accès.
✓ La maintenance du système
Le système doit permettre à l’administrateur de préparer le cadre dans lequel seront enregistrés
les agents et les étudiants puis de s’assurer du bon fonctionnement du système logiciel.
2.1.2. Exigences non fonctionnelles (Exigences techniques)
Les exigences non fonctionnelles indiquent « ce qu’un système devrait être » plutôt que « ce
qu’un système devrait faire ». Elles sont principalement dérivées d’exigences fonctionnelles
basées sur les commentaires du client et d’autres parties prenantes. Elles sont dites non
fonctionnelles car elles n’ont pas d’incidence sur ce que le système est en mesure de réaliser
ou non. (Myservername, 2021)
Le système logiciel conçu dans ce projet devra avoir des qualités telles que la maintenabilité,
la fiabilité, l’adaptabilité et la performance.
a. La maintenabilité
Le code du système logiciel doit avoir le moins de complexité possible pour permettre une
maintenabilité élevée.
b. La fiabilité
Le système logiciel doit être en mesure de fonctionner correctement même lorsque plusieurs
utilisateurs sont connectés et se servent des différentes fonctionnalités en même temps.
c. L’adaptabilité
Les interfaces du système logiciel doivent s’adapter à tout type de média.
d. La performance
Le système logiciel doit être en mesure d’exécuter une commande de l’utilisateur dans un bref
délai afin d’optimiser l’expérience utilisateur.
P a g e | 26
2.1.3. Identification et représentation des besoins
a. Recensement des acteurs
Un acteur est un utilisateur externe au système. Ce n’est ni les concepteurs, ni les développeurs
ni les testeurs du système et ce n’est forcément une personne physique (El Mouelhi, s. d.)3. Il
se sert uniquement des fonctionnalités lui proposées par le système pour répondre à ses besoins.
Les différents utilisateurs du nouveau système logiciel sont repris dans le tableau ci-après :
Tableau 2: Acteurs du nouveau système logiciel
N° Acteur Rôle
1 Étudiant La personne qui se connecte sur le système pour

consulter les informations internes de son
département et de sa promotion
2 Enseignant La personne qui disponibilise un cours et gère la

présence des étudiants ainsi que les épreuves
dans un cours
3 Appariteur La personne qui enregistre les étudiants
4 Département Le bureau qui publie les horaires, les

communiqués
5 Admin La personne qui enregistre les agents et s’occupe

de la maintenance du système logiciel
3
Support de cours accessible au public
P a g e | 27
b. Délimitation du périmètre
Dans le nouveau système logiciel, nous délimitons notre périmètre d’étude à l’aide d’un
diagramme de contexte dont le nom est Student Management System, qui signifie système de
gestion des étudiants en français ; associé à ses différents utilisateurs.
Figure 8: Diagramme de contexte du nouveau système logiciel
c. Identification des cas d’utilisation

Figure 9: Diagramme de contexte du nouveau système logiciel
1. Recensement de cas d’utilisation
Un cas d’utilisation représente une fonctionnalité du système (visible de l’extérieur du système)

ou un service que le système rend à un utilisateur (Cockburn, 2001).
Les différentes fonctionnalités du système logiciel qui fait l’objet du présent travail sont :
✓ Enregistrer un agent ✓ Télécharger un cours
✓ Enrôler un étudiant ✓ Coter une épreuve
✓ Publier un horaire ✓ Prendre la présence
✓ Publier un communiqué ✓ Se connecter
✓ Disponibiliser un cours ✓ Maintenir le système
✓ Lire un cours
P a g e | 28
2. Attribution de cas d’utilisation
Chaque utilisateur à accès, selon son niveau d’autorisation, aux fonctionnalités du système
logiciel réparties de la manière suivante :
• Étudiant • Département
✓ Se connecter ✓ Publier un horaire
✓ Lire un cours ✓ Publier un communiqué
✓ Télécharger un cours ✓ Se connecter

• Enseignant
✓ Disponibiliser un cours • Admin
✓ Coter une épreuve ✓ Enregistrer un agent
✓ Prendre la présence ✓ Maintenir le système
✓ Se connecter ✓ Se connecter
• Appariteur
✓ Enrôler un étudiant
✓ Se connecter
3. Diagramme de cas d’utilisation
Le diagramme de cas d’utilisation permet de préciser le contexte fonctionnel du système, en

décrivant les différentes façons que les acteurs utilisent le système (Roques & Vallée, 2007,
p.61).
Pour le cas du système logiciel dans le présent travail, le diagramme de cas d’utilisation se
présente de la manière suivante :
P a g e | 29
Figure 10: Diagramme de cas d'utilisation du nouveau système logiciel
Figure 11: Diagramme de cas d'utilisation du nouveau système logiciel

P a g e | 30
d. Classification des cas d’utilisation par priorité et risque
En nous référant à l’un des principes du processus UP (itératif et incrémental), nous planifions
notre projet en itérations en nous servant de deux critères : la priorité et le risque, pour
déterminer les cas d’utilisation à développer avant les autres et les incrémenter à la fin du
développement afin d’obtenir notre système logiciel complet.
Cette classification des cas d’utilisation se présente dans le tableau ci-après :
Tableau 3 : Planification du projet en itérations
N° Cas d'utilisation Priorité Risque Itération
1 Enregistrer un agent Haute Haut 2
2 Enrôler un étudiant Haute Haut 3
3 Publier un horaire Haute Haut 4
4 Publier un communiqué Moyenne Moyen 7
5 Disponibiliser un cours Basse Bas 8
6 Lire un cours Basse Bas 9
7 Télécharger un cours Basse Bas 10
8 Coter une épreuve Basse Moyen 6
9 Prendre la présence Moyenne Moyen 5
10 Se connecter Moyenne Bas 11
11 Maintenir le système Haute Bas 1

P a g e | 31
2.1.4. Spécification détaillée des besoins
À cette étape de notre projet, nous donnons les détails de réalisation des principaux cas
d’utilisation ou fonctionnalités répertoriés au point 2.1.3.
Ces détails seront présentés à l’aide de fiches de description textuelle de cas d’utilisation et des
diagrammes de séquence système.
Pour la spécification détaillée des besoins de notre système logiciel, nous présenterons d’abord
les fiches de description textuelle, chacune pour un cas d’utilisation appelé ici itération, ensuite
nous présenterons des diagrammes de séquence système pour les itérations majeures du
système logiciel.
a. Description textuelle des cas d’utilisation
La description textuelle d’un cas d’utilisation précise les interactions entre l’acteur et le
système logiciel et les actions que le système doit réaliser en vue de produire les résultats
attendus par les acteurs (J. Gabay & D. Gabay, 2008). Elle vient compléter le diagramme de
cas d’utilisation qui n’est utile que pour la discussion avec l’utilisateur car intuitif et concis
mais pas suffisant pour l’équipe de développement (Longuet, 2017)4.
4
Support de cours accessible au public
P a g e | 32
i. Itération 1
Identification
− Nom du cas : Enregistrer un agent
− But : L’administrateur veut donner à un agent l’accès au système logiciel
− Acteur(s) : Administrateur
− Responsable : Isra
− Date : Le 02.09.2021
− Version : 1.1
Séquencement
− Précondition : L’administrateur s’est connecté au système
− Enchaînement :
a. Scénario nominal
1. L’administrateur saisit les détails de l’agent puis valide
2. Le système crée un compte d’accès utilisateur puis notifie à l’agent les détails
du compte
b. Scénario alternatif
1a. L’administrateur modifie les détails du compte de l’agent
L’enchaînement démarre au point 2 du scénario nominal
c. Scénario d’exception
Le système affiche un message d’erreur en cas d’enregistrement d’un
utilisateur existant et de mauvaise manipulation en général
− Postcondition : Un agent a été enregistré
Rubrique optionnelle
− L’accès au système est protégé
− Le système est fiable
− Les contraintes liées à l’Interface Homme-Machine sont respectées
Figure 12 : Fiche de description textuelle (Enregistrer un agent)
Figure 13 : Fiche de description textuelle (Enregistrer un agent)

P a g e | 33
ii. Itération 2
Identification
− Nom du cas : Enrôler un étudiant
− But : L’appariteur veut donner à un étudiant l’accès au système logiciel
− Acteur(s) : Appariteur
− Date : Le 28.09.2021
− Version : 1.2
Séquencement
− Précondition : L’appariteur s’est connecté au système
− Enchaînement :
1. L’appariteur saisit les détails de l’étudiant puis valide
2. Le système enregistre l’étudiant et demande à l’utilisateur d’enrôler l’étudiant
dans une promotion
3. L’appariteur saisit les détails de l’enrôlement de l’étudiant puis valide
4. Le système crée un compte d’accès utilisateur puis notifie à l’étudiant les
détails du compte
3a. L’appariteur modifie les détails de l’enrôlement de l’étudiant puis valide
Le système affiche un message d’erreur en cas d’enregistrement d’un étudiant
existant et de mauvaise manipulation en général
− Postcondition : Un étudiant a été enrôlé
Figure 14 : Fiche de description textuelle (Enrôler un étudiant)
Figure 15 : Fiche de description textuelle (Enrôler un étudiant)

P a g e | 34
iii. Itération 3
Identification
− Nom du cas : Publier un horaire
− But : Le département veut communiquer un horaire aux étudiants
− Acteur(s) : Département
− Date : Le 28.09.2021
− Version : 1.1
Séquencement
− Précondition : Le département s’est connecté au système
− Enchaînement :
1. Le département saisit les informations de l’horaire puis valide
2. Le système affiche le tableau d’horaire
3. Le département saisit les cours dans le tableau puis valide
4. Le système enregistre l’horaire puis notifie aux étudiants
1a. Le département modifie les informations sur l’horaire puis valide
3a. Le département modifie les cours dans le tableau puis valide
Le système affiche un message d’erreur en cas de mauvaise manipulation du
système logiciel en général
− Postcondition : Un horaire a été publié
Figure 16 : Fiche de description textuelle (Publier un horaire)
Figure 17 : Fiche de description textuelle (Publier un horaire)

P a g e | 35
iv. Itération 4
Identification
− Nom du cas : Prendre la présence
− But : L’enseignant veut obtenir le rendement de participation au cours par les étudiants
− Acteur(s) : Enseignant
− Date : Le 28.09.2021
− Version : 1.1
Séquencement
− Précondition :
• L’enseignant s’est connecté au système
• Un étudiant est enrôlé
− Enchaînement :
1. L’enseignant saisit les informations de création de la séance puis valide
2. Le système enregistre la séance puis affiche la liste des étudiants
3. L’enseignant pointe la présence de chaque étudiant puis valide
4. Le système enregistre la présence de chaque étudiant
1a. L’enseignant modifie une information sur les détails de la séance puis
valide
3a. L’enseignant modifie la présence d’un étudiant valide
− Postcondition : La présence a été prise
Identification
Figure 18 : Fiche de description textuelle (Prendre la présence)
− Nom du cas : Prendre la présence
− But : L’enseignant veut obtenir le rendement de participation au cours par les étudiants
Figure 19 : Fiche de description textuelle (Prendre la présence)
P a g e | 36
v. Itération 5
Identification
− Nom du cas : Coter une épreuve
− But : L’enseignant veut attribuer une cote à chaque étudiant pour une épreuve
− Date : le 28.09.2021
− Version : 1.1
Séquencement
− Précondition :
− L’enseignant s’est connecté au système
− Un étudiant est enrôlé
− Enchaînement :
1. L’enseignant saisit les informations de l’épreuve puis valide
2. Le système enregistre l’épreuve puis affiche la grille des points
3. L’enseignant insère la cote de chaque étudiant puis valide
4. Le système enregistre les cotes puis notifie à chaque étudiant
1. Scénario alternatif
1a. L’enseignant modifie une information sur les détails de l’épreuve puis valide
3a. L’enseignant modifie la cote d’un étudiant valide
2. Scénario d’exception
− Postcondition : Une épreuve a été cotée
Figure 20 : Fiche de description textuelle (Coter une épreuve)

Identification
− Nom du cas : Coter une épreuve
− But : Figure 21 :veut

L’enseignant Fiche de description
attribuer textuelle
une cote à chaque (Coter
étudiant une
pour une épreuve)
épreuve
− Date : le 26.08.2021
− Version : 1.0
P a g e | 37
vi. Itération 6
Identification
− Nom du cas : Publier un communiqué
− But : Le département veut transmettre un communiqué aux étudiants
− Acteur(s) : Le département
− Date : Le 26.08.2021
− Version : 1.0
Séquencement
− Enchaînement :
1. Le département saisit les détails en rapport avec le communiqué puis valide
2. Le système enregistre le communiqué puis notifie aux étudiants
Le système affiche un message d’erreur en cas de mauvaise manipulation
− Postcondition : Un communiqué a été publié

Figure 22 : Fiche de description textuelle (Publier un communiqué)

Identification
− Nom du cas : Publier un communiqué
− But : Le département veut transmettre un communiqué aux étudiants
− Acteur(s) : Le département
− Date : Le 26.08.2021
− Version : 1.0
Séquencement
− Enchaînement :
P a g e | 38
vii. Itération 7
Identification
− Nom du cas : Disponibiliser un cours
− But : L’enseignant veut mettre en ligne le contenu d’un cours
− Date : le 03.09.2021
− Version : 1.0
Séquencement
− Précondition : L’enseignant s’est connecté au système
− Enchaînement :
1. L’enseignant sélectionne un cours
2. Le système affiche les détails du cours
3. L’enseignant ajoute le support du cours
4. Le système le système confirme le téléchargement du support
− Postcondition : Un cours a été disponibilisé

Figure 23 : Fiche de description textuelle (Disponibiliser un cours)
Identification
− Nom du cas : Disponibiliser un cours
− But : L’enseignant veut mettre en ligne le contenu d’un cours
− Date : le 03.09.2021
− Version : 1.0
P a g e | 39
viii. Itération 8
Identification
− Nom du cas : Lire un cours

− But : L’étudiant veut voir le contenu du cours
− Acteur(s) : Étudiant
− Date : le 03.09.2021
− Version : 1.0
Séquencement
− Précondition : Un cours a été disponibilisé

− Enchaînement :
1. L’étudiant demande au système d’afficher le contenu du cours
2. Le système affiche le contenu du cours
L’étudiant télécharge le cours
− Postcondition : un cours a été lu


Figure 24 : Fiche de description textuelle (Lire un cours)
Identification
− Nom du cas : Lire un cours

− But : L’étudiant veut voir le contenu du cours
− Acteur(s) : Étudiant
− Date : le 03.09.2021
− Version : 1.0
Séquencement
− Précondition : Un cours a été disponibilisé

− Enchaînement :
d. Scénario nominal
3. L’étudiant demande au système d’afficher le contenu du cours
4. Le système affiche le contenu du cours
e. Scénario alternatif
L’étudiant peut télécharger le cours
f. Scénario d’exception

P a g e | 40
b. Diagrammes de séquence système
Le diagramme de séquence système décrit la dynamique d’un système, c’est-à-dire il modélise

les interactions entre les objets dans un cas d’utilisation unique (www.creately.com , 2021). Le
diagramme de séquence système illustre les interactions entre un groupe d’objets en montrant,
de façon séquentielle, les envois de message qui interviennent entre les objets. Le diagramme
peut également montrer les transmissions des données échangées lors des envois de message
(Debrauwer & Van Der Heyde, s.d.).
i. Itération 1
Figure 25 : Diagramme de séquence (Enregistrer un agent)

P a g e | 41
ii. Itération 2
Figure 26 : Diagramme de séquence (Enrôler un étudiant)
iii. Itération 3
Figure 27 : Diagramme de séquence (Publier un horaire)

P a g e | 42
iv. Itération 4
Figure 28 : Diagramme de séquence (Prendre la présence)
v. Itération 5
Figure 29 : Diagramme de séquence (Coter une épreuve)

P a g e | 43
vi. Itération 6
Figure 30 : Diagramme de séquence (Publier communiqué)
vii. Itération 7
Figure 31 : Diagramme de séquence (Disponibiliser un cours)

P a g e | 44
viii. Itération 8
Figure 32 : Diagramme de séquence (Lire un cours)
2.2. Analyse du système
À cette phase nous identifions les classes qui seront réalisées à la phase de conception du
système logiciel.
L’analyse du système nous permet d’élaborer tour à tour : les modèles du domaine, les
diagrammes des classes participantes et les diagrammes d’activité de navigation.
3.2.1. Analyse du domaine : modèles du domaine
Dans la phase précédente, nous avons modélisé les besoins à l’aide du diagramme de cas
d’utilisation (Figure 2) ; ce qui s’apparente à une analyse fonctionnelle classique. L’élaboration
du modèle des classes du domaine, à ce niveau, nous permet d’opérer une transition vers une
véritable modélisation objet.
Le modèle du domaine nous permet donc d’élaborer la première version du diagramme de

classes. Ce modèle définit les classes qui modélisent les entités ou concepts présents dans le
domaine ou métier de l'application (du système logiciel). Il s'agit donc de produire un modèle
des objets du monde réel dans un domaine donné. Ces entités ou concepts peuvent être
identifiés directement à partir de la connaissance du domaine ou par des entretiens avec des
experts du domaine. (Audibert, 2013)
P a g e | 45
Pour le cas de l’actuel projet, ce modèle sera réalisé sur base de quelques cas d’utilisation que
présentés au point 2.1.3.b.
a. Pour le cas d’utilisation Maintenir le système
Figure 33:Modèle du domaine (Maintenir le système)
b. Pour le cas d’utilisation Enregistrer un agent
Figure 34: Modèle du domaine (Enregistrer un agent)

P a g e | 46
c. Pour le cas d’utilisation Enrôler un étudiant
Figure 35 : Modèle du domaine (Enrôler un étudiant)

P a g e | 47
d. Pour le cas d’utilisation Publier un horaire
Figure 36 : Modèle du domaine (Publier un horaire)
e. Pour le cas d’utilisation Coter une épreuve
Figure 37 : Modèle du domaine (Coter une épreuve)

P a g e | 48
f. Pour le cas d’utilisation Prendre la présence
Figure 38 : Modèle du domaine (Prendre la présence)
g. Pour le cas d’utilisation Publier un communiqué
Figure 39 : Modèle du domaine (Publier un communiqué)

P a g e | 49
h. Pour le cas d’utilisation Disponibiliser un cours
Figure 40 : Modèle du domaine (Disponibiliser un cours)
i. Pour le cas d’utilisation Lire un cours
Figure 41 : Modèle du domaine (Lire un cours)
3.2.2. Diagrammes des classes participantes
Le diagramme des classes participantes représente l’ensemble des classes qui interagissent pour
réaliser un cas d’utilisation. Il est particulièrement important puisqu’il fait la jonction entre,
d’une part, les cas d’utilisation, le modèle de la couche métier et l’interface avec l’utilisateur
(IHM). Ce diagramme modélise trois types de classes d’analyse ; notamment le dialogue, le
contrôle et les entités ainsi que leurs relations. Chaque classe d’analyse modélise une couche
de l’application (Ngongo, 2020)5.
5
Support de cours non accessible au public
P a g e | 50
a. Les classes de dialogue
Elles modélisent l’Interface Homme-Machine c’est-à-dire les interactions entre l’utilisateur et

l’application.
b. Les classes de contrôles
Elles modélisent la logique applicative du système logiciel. Elles font la jonction entre les
classes métiers et les interfaces utilisateurs.
c. Les classes entités
Elles sont les classes métiers qui proviennent du modèle du domaine. Il s’agit des objets
manipulés.
Pour notre système logiciel, nous modélisons un diagramme de classes participantes de chaque
cas d’utilisation.
i. Le cas d’utilisation Enregistrer un agent
Figure 42 : Diagramme des classes participantes (Enregistrer un agent)

P a g e | 51
ii. Le cas d’utilisation Enrôler un étudiant
Figure 43 : Diagramme des classes participantes (Enrôler un étudiant)

P a g e | 52
iii. Le cas d’utilisation Publier un horaire
Figure 44 : Diagramme des classes participantes (Publier un horaire)

P a g e | 53
iv. Le cas d’utilisation Prendre la présence
Figure 45 : Diagramme des classes participantes (Prendre la présence)

P a g e | 54
v. Le cas d’utilisation Coter une épreuve
Figure 46 : Diagramme des classes participantes (Coter une épreuve)

P a g e | 55
vi. Le cas d’utilisation Publier un communiqué
Figure 47 : Diagramme des classes participantes (Publier un communiqué)
vii. Le cas d’utilisation Disponibiliser un cours
Figure 48 : Diagramme des classes participantes (Disponibiliser un cours)

P a g e | 56
viii. Le cas d’utilisation Lire un cours
Figure 49 : Diagramme des classes participantes (Lire un cours)
3.2.3. Diagrammes d’activités de navigation
Le diagramme d’activité de navigation représente de manière formelle l’ensemble des chemins

possibles entre les principaux écrans proposés à l’utilisateur. Il fournit la possibilité de décrire
précisément et exhaustivement les aspects dynamiques de l’interface utilisateur (Roques,
2008).
Le diagramme de navigation ressemble fondamentalement à un organigramme, montrant le flot

d’action en action et sa modélisation peut être structurée par acteur ou par cas d’utilisation ().
Pour notre projet, un diagramme de navigation sera représenté pour chaque acteur excepté
l’acteur Admin.
P a g e | 57
a. L’acteur Appariteur
Figure 50 : Diagramme d'activité de navigation (Appariteur)

P a g e | 58
b. L’acteur Département
Figure 51 : Diagramme d'activité de navigation (Département)

P a g e | 59
c. L’acteur Enseignant
Figure 52 : Diagramme d'activité de navigation (Enseignant)

P a g e | 60
d. L’acteur Étudiant
Figure 53 : Diagramme d'activité de navigation (Étudiant)
2.3. Conception du système
L’objectif de cette phase est d’attribuer des responsabilités précises de comportement aux
classes d’analyse identifiées à la phase précédente. Nous représenterons le résultat de cette
étude dans les diagrammes d’interaction UML ; nous construirons le diagramme de classe
conception préliminaire qui s’apparente à une vue statique complétée, indépendamment des
choix technologiques qui seront effectués au chapitre suivant. (Roques, 2008)
P a g e | 61
3.2.4. Diagrammes d’interaction globale
Le diagramme d’interaction globale (diagramme de séquence détaillée ou diagramme de

communication) montre les interactions internes provoquées en plus des interactions du
système avec l’extérieur (Gérard, s.d.).
En effet, dans le diagramme de séquence système, le système (ici système logiciel) était vu
comme une boite noire (ligne de vie « StudentMS »). À partir des diagrammes des classes
participantes présentés au point 2.2.2., nous savons maintenant que le système est composé de
différents objets dont nous décrirons les interactions pour illustrer la réalisation de chaque cas
d’utilisation.
Ainsi, à chaque diagramme de séquence système correspondra un diagramme d’interaction

(diagramme de séquence détaillé).
a. Pour enregistrer un agent
Figure 54 : Diagramme d'interaction globale (Enregistrer un agent)

P a g e | 62
b. Pour enrôler un étudiant
Figure 55: Diagramme d'interaction globale (Enrôler un étudiant)

P a g e | 63
c. Pour publier un horaire
Figure 56: Diagramme d'interaction globale (Publier un horaire)
d. Pour prendre la présence
Figure 57: Diagramme d'interaction globale (Prendre la présence)

P a g e | 64
e. Pour coter une épreuve
Figure 58 : Diagramme d'interaction globale (Coter une épreuve)
f. Pour publier un communiqué
Figure 59: Diagramme d'interaction globale (Publier un communiqué)

P a g e | 65
g. Pour disponibiliser un cours
Figure 60: Diagramme d'interaction globale (Disponibiliser un cours)
h. Pour lire un cours
Figure 61: Diagramme d'interaction globale (Lire un cours)

P a g e | 66
3.2.5. Diagrammes des classes de conception
Le diagramme de classe de conception modélise toutes les classes nécessaires à

l’implémentation de l’application. C’est un diagramme qui n’est pas seulement lié aux simples
données mais à l’ensemble des classes de l’application (Ngongo,2020).
Il est établi à l’aide trois autres diagrammes ; notamment le diagramme des classes
participantes, le diagramme de séquence et le diagramme d’interaction globale.
✓ Le diagramme des classes participantes est la base du diagramme de classe de

conception ;
✓ Le diagramme de séquence nous aidera à recenser les interfaces que nous n’avons pas
encore ;
✓ Le diagramme d’interaction globale nous permettra de trouver d’autres classes

contrôles non représentées jusqu’alors.
Dans le présent projet, un diagramme de classe de conception sera réalisé pour les principaux
cas d’utilisation.
a. Pour le cas d’utilisation Enregistrer un agent
Figure 62 : Diagramme de classe de conception (Enregistrer un agent)

P a g e | 67
b. Pour le cas d’utilisation Enrôler un étudiant
Figure 63: Diagramme de classe de conception (Enrôler un étudiant)
c. Pour le cas d’utilisation Publier un horaire
Figure 64: Diagramme de classe de conception (Publier un horaire)

P a g e | 68
d. Pour le cas d’utilisation Prendre la présence
Figure 65: Diagramme de classe de conception (Prendre la présence)
e. Pour le cas d’utilisation Coter une épreuve
Figure 66: Diagramme de classe de conception (Coter une épreuve)

P a g e | 69
f. Pour le cas d’utilisation Publier un communiqué
Figure 67: Diagramme de classe de conception (Publier un communiqué)

P a g e | 70
g. Pour le cas d’utilisation Disponibiliser un cours
Figure 68: Diagramme de classe de conception (Disponibiliser un cours)
h. Pour le cas d’utilisation Lire un cours
Figure 69: Diagramme de classe de conception (Lire un cours)

P a g e | 71
3.2.6. Diagramme de packages
Pour illustrer le critère d’évolutivité de notre système logiciel, UML nous propose un concept
général appelé package (paquetage en français). Le package est un mécanisme général de
regroupement d’éléments en UML, qui est principalement utilisé en analyse et conception objet
pour regrouper des classes et des associations. (Roques, 2008).
Ce mécanisme nous permet de structurer les classes, selon la logique d’abord, en trois couches
principales ; une couche Présentation, une couche Logique Applicative et une couche Logique
Métier. La structuration selon les deux premières couches peut s’effectuer en tenant compte
des cas d’utilisation. La structuration de la couche Logique Métier est à la fois plus délicate et
plus intéressante, car elle fait appel à deux principes fondamentaux : cohérence et
indépendance.
✓ La cohérence consiste à regrouper les classes qui sont proches du point de vue
sémantique c’est-à-dire la signification, le sens
✓ L’indépendance nous permet de minimiser les relations entre les classes des paquetages
différents car les éléments de modélisation entre les différents paquetages doivent être
différents.
Ainsi, le diagramme de paquetage de notre système se présente de la manière suivante :
Figure 70: Diagramme de packages du métier

P a g e | 72
2.4. Passage au modèle logique de données relationnel
Un Modèle Logique de Données Relationnel (MLD-R) est la représentation des données d’un
système d’information réalisé en vue d’une mise en œuvre au sein d’un Système de Gestion de
Base de Données Relationnel (SGBD-R) (www.smartmodel.ch , s.d.). Il est réalisé à partir du
méta modèle de classe du langage UML qui correspond ici à l’ensemble des classes des
modèles du domaine avec leurs relations.
Pour passer de ce méta modèle UML au MLD-R, il faut mettre en œuvre quatre règles :
Règle 1 : Transformation des entités/classes
Chaque entité devient une relation. L’identifiant de l’entité devient clé primaire pour la relation.
Chaque classe du diagramme UML devient une relation. Il faut choisir un attribut de la classe
pouvant jouer le rôle d’identifiant.
Si aucun attribut ne convient en tant qu’identifiant, il faut en ajouter un de telle sorte que la
relation dispose d’une clé primaire (les outils proposent l’ajout de tels attributs).
Transformation des associations
Les règles de transformation que nous allons voir dépendent des cardinalités/multiplicités
maximales des associations. Nous distinguons trois familles d’associations :
✓ Un-à-plusieurs ;
✓ Plusieurs-à-plusieurs ou classes-associations, et n-aires ;
✓ Un-à-un.
Règle 2 : Associations un-à-plusieurs
Il faut ajouter un attribut de type clé étrangère dans la relation ﬁls de l’association. L’attribut
porte le nom de la clé primaire de la relation père de l’association.
Règle 3 : Associations plusieurs-à-plusieurs et n-aires
L’association (classe-association) devient une relation dont la clé primaire est composée par la
concaténation des identifiants des entités (classes) connectés à l’association. Chaque attribut
devient clé étrangère si l’entité (classe) connectée dont il provient devient une relation en vertu
de la règle 1.
P a g e | 73
Les attributs de l’association (classe-association) doivent être ajoutés à la nouvelle relation.
Ces attributs ne sont ni clé primaire, ni clé étrangère.
Règle 4 : Associations un-à-un
La règle est la suivante, elle permet d’éviter les valeurs NULL dans la base de données.
Il faut ajouter un attribut clé étrangère dans la relation dérivée de l’entité ayant la cardinalité
minimale égale à zéro. Dans le cas de UML, il faut ajouter un attribut clé étrangère dans la
relation dérivée de la classe ayant la multiplicité minimale égale à un. L’attribut porte le nom
de la clé primaire de la relation dérivée de l’entité (classe) connectée à l’association.
Si les deux cardinalités (multiplicités) minimales sont à zéro, le choix est donné entre les deux
relations dérivées de la règle R1. Si les deux cardinalités minimales sont à un, il est sans doute
préférable de fusionner les deux entités (classes) en une seule. (Soutou, 2007)
Le modèle logique de données relationnel du présent projet se présente de la manière suivante :
FACULTE (id, codeFaculte, description)
PROGRAMME (id, duree, description)
PROMOTION (id, nomPromotion, siglePromotion)
COURS (id, codeCours, intituleCours, description)
PERSONNE (id, nom, postNom, prenom, genre, lieuNaissance, dateNaissance, nationalite,

adresse, telephone, email)
CYCLE (id, nomCycle, details, statut, idFaculte#)
AGENT (idPersonne#, matricule, fonction, statut)
ETUDIANT (idPersonne#, codeEtudiant, statut)
HORAIRE (id, anneeAcademique, typeHoraire, periode, statut, idPromotion#)
DESCRIPTIONHORAIRE (id, jour, heure, idHoraire, idCours#)
COMMUNIQUE (id, numeroCommunique, datePublication, objet, contenu, signataire, statut,

idFaculte#)
COMPTEUSER (idCompte, password, etatConnexion, statut)

P a g e | 74
COMPTEETUDIANT (idCompte#, dateCreation, dateExpiration, idEtudiant#)
COMPTEAGENT (idCompte#, username, typeUser, idAgent#)
EPREUVE (id, nomEpreuve, dateEpreuve, pointsMax, pointsObtenus, statut, idEnrolement#,

idCoursParProgramme#)
PRESENCE (id, dateSeance, nbreHeuresPrestees, numeroSeance, participation,

idCompteUser#, idCoursParProgramme#, idEnrolement#)
ENROLEMENT (id, dateEnrolement, anneeAcademique, numeroEnrolement, validite,

idEtudiant#, idPromotion#, idProgramme#)
COURSPARPROGRAMME (id, volumeHoraire, ponderation, details, contenu, statut,

idCompteUser#, idPromotion#, idCours#, idProgramme#)
Et sa représentation graphique est donnée par la figure 69.

P a g e | 78
Figure 71 : Modèle Logique de Données Relationnel (StudentMS)

P a g e | 79
Conclusion
Dans ce chapitre, nous avons conçu le nouveau système informatique et présenté ses différents
aspects. En effet, grâce à la méthode UP et au langage de modélisation UML nous avons pu
adopter une démarche minimale des besoins au code dans le but de ne présenter que les
diagrammes nécessaires à la réalisation de notre projet.
Nous avons donc illustré l’aspect fonctionnel de notre système grâce au diagramme de cas
d’utilisation accompagné d’une spécification détaillée des besoins faite à l’aide des fiches de
description textuelle et des diagrammes de séquence système de chaque cas d’utilisation pour
illustrer l’aspect dynamique. Et les diagrammes d’interaction globale sont intervenus pour
montrer les interactions internes entre les objets du système. L’aspect statique de notre système
a été illustré à l’aide des diagrammes des classes qui permettent de spécifier la structure et les
liens entre les objets qui composent le système.
Quant aux diagrammes d’activité de navigation et de paquetages, ils nous ont permis
respectivement de présenter de manière formelle les principaux écrans proposés à l’utilisateur
et de regrouper les classes et les associations en packages selon les principes de cohérence et
d’indépendance. Le système ainsi conçu pourra facilement être implémenté et devenir un
produit qui apporte une solution aux problèmes de communication relevés dans le système
existant.
P a g e | 80
Chapitre 3. REALISATION DU SYSTÈME INFORMATIQUE
Introduction
La réalisation du système informatique est la phase qui nous permet de passer de l’abstrait au
concret en produisant un programme exécutable après la modélisation des besoins. Dans le
présent chapitre, nous allons présenter et justifier le choix de l’architecture logicielle ainsi que
le choix des outils de développement de notre application. Puis nous décrirons l’aspect
fonctionnel de notre application web dans la rubrique présentation de l’application, qui sera
essentiellement illustrée grâce aux interfaces des différents types d’utilisateurs du système.
3.1. Choix de l’architecture logicielle
3.1.1. Architecture logicielle du système informatique
Une architecture logicielle décrit la manière dont sont agencés les différents éléments d’une
application et comment ils interagissent entre eux (Gillebert, 2021). Autrement, une
architecture désigne la structure d’une application.
L’application web qui fait objet du présent travail est basé sur l’architecture 3 – tiers respectant
le MVC (Model – View – Controller).
a. L’architecture 3 – tiers
L’architecture 3 tiers est basée sur l’environnement client – serveur et structure une application
en trois couches ; notamment la couche Présentation, la couche de Traitement et la couche
d’accès aux données.
Figure 72 : Architecture 3-tiers (Driat, 2020)

P a g e | 81
i. La couche Présentation
Elle correspond à la partie visible et interactive de l’application pour les utilisateurs. On parle
d’interface homme – machine (IHM) ; elle peut être représentée en HTML pour être exploitée
par un navigateur web.
ii. La couche de Traitement
Elle correspond à la partie fonctionnelle de l’application, celle qui implémente la logique

métier, et qui 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 de présentation.
iii. La couche d’accès aux données
Elle correspond à la partie gérant l’accès aux données de l’application. Ces données peuvent
être propres à l’application, ou gérées par une autre application. Lorsque les données sont
propres à l’application, elles sont pérennes, car destinées à durer dans le temps, de manière plus
ou moins longue, voire définitives. (Wikipédia, 8 avril 2019)
b. Le pattern MVC
Du point de vue programmation, nous avons adopté le pattern MVC (Model – View –
Controller) car son usage est relativement généralisé pour les applications clients – serveurs
(Printz, 2006).
Le MVC est un motif de conception (design pattern) qui propose une solution générale au
problème de la structuration d’une application. Le MVC définit des règles qui déterminent dans
quelle couche de l’architecture, et dans quelle classe (orientée-objet) de cette couche, doit être
intégrée une fonctionnalité spécifique. Une application conforme à ces règles est plus facile à
comprendre, à gérer et à modifier. Ces règles sont issues d’un processus d’expérimentation et
de mise au point de bonnes pratiques qui a abouti à une architecture standard.
L’objectif global du MVC est de séparer les aspects traitement, données et présentation, et de
définir les interactions entre ces trois aspects. En simplifiant, les données sont gérées par
le modèle, la présentation par la vue, les traitements par des actions et l’ensemble est
coordonné par les contrôleurs
P a g e | 82
Figure 73 : Architecture MVC (orm.bdpedia.fr, s.d.)

i. Le modèle
Le modèle implante les fonctionnalités de l’application, indépendamment des aspects

interactifs. Le modèle est également responsable de la préservation de l’état d’une application
entre deux requêtes HTTP, ainsi que des fonctionnalités qui s’appliquent à cet état. Toute
donnée persistante doit être gérée par la couche modèle, mais des objets métiers non persistant
implantant une fonctionnalité particulière (un calcul, un service) sont également dans cette
couche. Le modèle gère les données de session (le panier dans un site de commerce
électronique par exemple) ou les informations contenues dans la base de données (le catalogue
des produits en vente, pour rester dans le même exemple). Cela comprend également les règles,
contraintes et traitements qui s’appliquent à ces données, souvent désignées collectivement par
l’expression logique métier de l’application.
ii. La vue
La vue est responsable de l’interface, ce qui recouvre essentiellement dans notre cas les
fragments HTML qui sont assemblés pour constituer les pages du site. La vue est également
responsable de la mise en forme des données (pour formater une date par exemple) et doit
d’ailleurs se limiter à cette tâche.
La vue est souvent implantée par un moteur de templates, dont les caractéristiques et avantages
dépendent des besoins du développeur.
P a g e | 83
iii. Les contrôleurs
Le rôle des contrôleurs est de récupérer les données utilisateurs, de les filtrer et de les contrôler,
de déclencher le traitement approprié (via le modèle), et finalement de déléguer la production
du document de sortie à la vue. L’utilisation de contrôleurs a également pour effet de donner
une structure hiérarchique à l’application, ce qui facilite la compréhension du code et l’accès
rapide aux parties à modifier. Indirectement, la structuration logique d’une application MVC
en contrôleurs et actions induit donc une organisation normalisée. (orm.bdpedia.fr, s.d.)
c. Nuance entre 3 tiers et MVC
À première vue, les trois niveaux de l’architecture 3 – tiers peuvent sembler similaires au Model
– View – Controller concept ; toutefois, topologiquement, ils sont différents. Une règle
fondamentale dans une architecture à trois couches est « la couche présentation ne communique
jamais avec la couche des données » ; dans le modèle à trois niveaux toute communication doit
passer par le niveau intermédiaire. Conceptuellement, le pattern MVC est triangulaire : la vue
envoie les mises à jour du contrôleur, le contrôleur met à jour le modèle, et la vue est à jour
directement à partir du modèle. (www.ebdesigner.com , 2012)
3.1.2. Architecture technique du système informatique
Une architecture technique ou physique du système informatique décrit l'ensemble des

composants matériels supportant l'application. Ces composants peuvent être :
✓ Des calculateurs (ou serveurs matériels) ;

✓ Des postes de travail ;
✓ Des équipements de stockage (baie de stockage, SAN, filers…) ;
✓ Des équipements de sauvegarde ;
✓ Des équipements réseaux (routeurs, firewalls, switches, load-
balancers, accélérateurs SSL).
L’architecture physique de notre système informatique est essentiellement composée des

postes de travail et d’un serveur web, telle qu’illustrée par la figure 74.
P a g e | 84
Figure 74 : Architecture physique du système informatique
3.1.3. Vue d’implémentation : Diagramme de composants
La vue d’implémentation est réalisée grâce à un diagramme structurel UML appelé diagramme
de composants. Ce dernier permet de représenter les composants logiciels d’un système ainsi
que les liens qui existent entre ces composants (J. Gabay & D. Gabay, 2008, p.49).
Le diagramme de composants du présent système est illustré par la figure 75.
Figure 75 : Diagramme de composants du système informatique

P a g e | 85
3.1.3. Vue de déploiement : Diagramme de déploiement
La vue de déploiement est réalisée grâce au diagramme de déploiement. Ce dernier permet de

représenter l’architecture physique supportant l’exploitation du système. Cette architecture
comprend des nœuds correspondant aux supports physiques (serveurs, routeurs…) ainsi que la
répartition des artefacts logiciels (bibliothèques, exécutables…) sur ces nœuds. C’est un
véritable réseau constitué de nœuds et de connexions entre ces nœuds qui modélise cette
architecture. (J. Gabay & D. Gabay, 2008, p.50)
Pour le présent système, ce diagramme est illustré par la figure 76.
Figure 76 : Diagramme de déploiement du système informatique

P a g e | 86
3.2. Choix des outils de développement
L’implémentation de notre système informatique a été rendue possible grâce à quelques outils
de développement ; notamment le Système de Gestion des Bases de données MariaDB avec
l’application web PHPMyAdmin, les templates BOOTSTRAP pour le frontend et le backend,
le langage de programmation PHP et l’environnement de développement intégré PhpStorm.
3.2.1. Le Système de Gestion des Bases de données MariaDB
Un Système de Gestion de Base de Données, désigne un logiciel informatique permettant

le stockage, la consultation, la mise à jour, la structuration ou encore le partage d'informations
dans une base de données. Il garantit en outre la confidentialité et la pérennité de ces données
(journaldunet, 08 janvier 2019).
MariaDB est un système de gestion de base de données édité sous licence GPL (licence qui fixe les
conditions légales de distribution d'un logiciel libre du projet GNU) créée par Michael "Monty" Widenius
et sa première version date du 29 octobre 2009 (Wikipédia, 27 avril 2021). Son logo est illustré par la figure
suivante :
Figure 77 : Logo du SGBD MariaDB
PhpMyAdmin (PMA) est une application Web de gestion pour les systèmes de gestion de base de
données MySQL et MariaDB, réalisée principalement en PHP et distribuée sous licence GNU GPL. Sa
première version date du 9 septembre 1998 (Wikipédia, 02 mars 2021)
Figure 78 : Logo PHPMyAdmin

P a g e | 87
3.2.2. L’environnement de développement intégré PHPStorm
PHPStorm est un environnement de développement intégré développé par JetBrains, spécialisé

pour le développement Web. Initialement conçu pour le développement PHP avec tout le
support de WebStorm, grâce à son extensibilité, plusieurs plugins existent pour étendre ses
fonctionnalités. Il supporte nativement les langages PHP, HTML, CSS et JavaScript (Ngoma,
2017). Sa première sortie date de 2009 (Wikipédia, 17 août 2021) et la version que nous
utilisons est PHPStorm 2017.01.1
Son logo est illustré par l’image suivante :
Figure 79 : Logo de PHPStorm
Grâce à cet IDE, nous avons utilisé des templates BOOTSTRAP que nous avons personnalisé
pour le design de nos pages web. Un template (parfois appelé layout) est une page web sans
contenu dont les éléments statiques sont déjà positionnés et mis en forme (Dabi – Schwebel,
s.d.). Il s’agit simplement d’une ou plusieurs pages web créées sur base d’un thème précis
prêtes à être utilisées.
3.2.3. Le langage de programmation PHP
PHP (pour Hypertext Preprocessor) est un langage de programmation open source très
populaire, qui est largement utilisé pour créer des pages web dynamiques.
À l'origine, le langage a été créé en 1995 par Rasmus Lerdorf. En 2015, la version 7 est sortie,
apportant de nombreuses améliorations, dont un gain de performances considérable et de
nouvelles fonctionnalités. PHP 7 a été rapidement adopté par les développeurs du monde entier.
PHP est un langage impératif orienté objet et est également intégré à une grande variété de
bases de données, ce qui le rend un langage assez puissant. De plus, le langage PHP
est Multiplateforme ; Il peut être installé sur n'importe quel système d'exploitation, y compris
P a g e | 88
Linux, Mac et Windows. Actuellement, PHP est utilisé sur plus de 80% des sites web sur
Internet. (Cours-gratuit, s.d.)
La figure suivante illustre le logo du langage PHP.
Figure 80 : Logo du langage de programmation PHP
3.3. Présentation de l’application
Cette rubrique est réservée pour la présentation des interfaces utilisateur de l’application web
de gestion des étudiants.
Cette application sera utilisée par 5 acteurs différents, notamment l’administrateur,

l’appariteur, le département, l’enseignant et l’étudiant.
Formulaire de gestion des facultés

P a g e | 89
Formulaire de gestion des cycles
Formulaire de gestion des étudiants

P a g e | 90
Formulaire d’authentification
Page d’accueil
P a g e | 91
Quelques lignes de code
//methode de creation d'une faculte
class FaculteDAO
{
public static function createFaculte(Faculte $faculte){
try{
$req = "CALL proc_createFaculte('".addslashes($faculte-
>getCodeFaculte())."',
'".addslashes($faculte-
>getDescription())."')";
$req_prepare = Connexion::getConnexion()->prepare($req);
$req_prepare->execute();
$req_prepare->closeCursor();
}catch (Exception $ex){
echo "Message = ".$ex->getMessage();
}
}
//methode d'affichage des facultes
public static function getAllFacultes(){
try{
$req = "CALL proc_getAllFacultes()";
$req_prepare = Connexion::getConnexion()->prepare($req);
$req_prepare->execute();
$result = $req_prepare->fetchAll(PDO::FETCH_ASSOC);
$req_prepare->closeCursor();
return $result;
}
}
//controleur de creation d'une faculte

<?php
require_once "../config/config.php";
require_once "../model/DAO/Connexion.class.php";
require_once "../model/DAO/FaculteDAO.class.php";
require_once "../model/entities/Faculte.class.php";
try{
$faculte = new Faculte(0, $_GET['codeFaculte'], $_GET['description']);

FaculteDAO::createFaculte($faculte);

}
header("location: ../view/backend/creerFaculte.view.php");
P a g e | 92
//afficher la liste des facultes

<?php
//recover the class codes
require_once "../../config/config.php";
require_once "../../model/DAO/Connexion.class.php";
require_once "../../model/DAO/FaculteDAO.class.php";
//call the method and recover the faculte list in the table
$faculteList = FaculteDAO::getAllFacultes();
$compteur=1;
foreach ($faculteList as $line){
echo "<tr>";
echo "<td style=\"text-align: center;\">".$compteur."</td>";
echo "<td>".$line['codeFaculte']."</td>";
echo "<td>".$line['description']."</td>";
echo "<td></td>";;
echo "<td><a href='modifierFaculte.view.php?id=".$line['id']."
&codeFaculte=".$line['codeFaculte']."
&description=".$line['description']."'
class='btn btn-warning btn-sm'>Modifier</a></td>";
echo "</tr>";
$compteur++;
}
?>
Conclusion
Les différents concepts évoqués dans le présent chapitre constituent l’ensemble des éléments
sur lesquels nous nous sommes appuyés pour implémenter notre application web avec les
fonctionnalités requises pour résoudre le problème de manque d’outils efficace de
communication dans le système d’information sous étude.
P a g e | 93
CONCLUSION GÉNÉRALE
Ce travail s’inscrit dans le cadre de la contribution à l’amélioration de la gestion des étudiants

de l’Institut Supérieur Pédagogique de Lubumbashi. L’absence d’un mécanisme efficace de
communication dans cet institut a comme conséquence, le manque d’atteinte de la finalité lui
assignée.
En effet, l’Institut Supérieur Pédagogique de Lubumbashi est une institution publique

d’enseignement supérieur dont l’une des missions est de pourvoir le pays en enseignants de
haut niveau de formation générale et spécialisée aux qualités morales et pédagogiques
éprouvées. Cependant, cet institut ne dispose pas de bonnes conditions de contact avec ses
étudiants afin de leur assurer une bonne formation en leur qualité d’enseignants. La
communication des informations qui cadrent avec les enseignements et les évaluations
(horaires et communiqués) n’est pas efficace et n’atteint pas la majorité des étudiants dans les
meilleurs délais, occasionnant ainsi du retard dans l’exécution des ordres reçus et une formation
incomplète de ces derniers.
Ce travail de mise en place d’une application web de gestion des étudiants apporte une solution
au problème de communication d’informations qui cadrent avec la formation des étudiants. Il
a été réalisé en trois chapitres dont le premier est consacré à la présentation générale du champ
d’étude et une délimitation du domaine ciblé pour l’analyse du métier, le second est consacré
à la conception du nouveau système informatique grâce au processus UP, méthode d’ingénierie
logicielle permettant de transformer les besoins des utilisateurs en logiciel, basé sur le
formalisme UML, langage de modélisation qui permet de représenter les différentes vues d’un
système informatique à l’aide des diagrammes. Ce langage nous a permis d’adopter une
démarche minimale des besoins au code dans le but de ne présenter que les diagrammes
nécessaires à la réalisation du projet.
Enfin, le troisième chapitre est consacré à l’implémentation du système informatique, conçu

dans le chapitre précédent, grâce à plusieurs outils de développement tels que le Système de
Gestion des Bases de Données MariaDB géré par le logiciel PHPMyAdmin et l’Environnement
de Développement Intégré JetBrains PhpStorm avec le langage de programmation PHP.
L’application ainsi réalisée permet d’enrôler les étudiants et de publier les horaires ainsi que
les communiqués actualisés à leur intention.
P a g e | 94
Mise à la disposition de l’Institut Supérieur Pédagogique de Lubumbashi, cette application

permettra de garder un contact permanent avec les étudiants, et de leur donner la possibilité
d’obtenir l’information nécessaire en temps réel afin que tout activité déclenchée à l’issu de
toute communication pertinente soit ouverte, exécutée et clôturée dans les délais prévus et que
les produits de cet établissement d’enseignement supérieur aient une formation complète au
profit de la société, particulièrement de la société Congolaise.
P a g e | 95
RÉFÉRENCES BIBLIOGRAPHIQUES
Ouvrages
Arlow, J. & Neustadt, I., (2005). UML 2 and the Unified Process (UML 2 et le Processus
Unifié). The Addison-Wesley Objet Series. 614p. ISBN 0-321-32127-8.
https://www.pdfdrive.com/uml-2-and-the-unified-process-practical-object-oriented-analysis-
and-design-2nd-edition-e156704689.html
Cockbrun, A., (2001). Writing effective use cases (Rédiger des cas d’utilisation efficaces). The
Addison-Wesley. 246p. http://pszwed.ia.agh.edu.pl/Specif/weuc0002extract.pdf
Debrauwer, L., & Van Der Heyde, F., (s.d.). La modélisation de la dynamique. Dans UML
2.5 : Initiation, exemples, et exercices corrigés (Eni,4). Eni editions. (pp. 59-64)
Gabay, J., & Gabay, D., (2008). UML 2 Analyse et Conception : Mise en œuvre guidée et
études de cas (Dunod), 225 p. ISBN 978-2-10-053567-5
Lonchamp, J., (2017). Les systèmes informatiques. Dans Introduction aux systèmes
informatiques : Architecture, composants, mise en œuvre (pp. 1-9). Dunod.
https://www.dunod.com/sites/default/files/atoms/files/9782100759446/Feuilletage.pdf
Muller, P., A., (s.d.). Modélisation objet avec UML. https://www.pdfdrive.com/modelisation-

objet-avec-uml-d50927470.html
Printz, J., (2006). Architecture logicielle _ Concevoir des applications simples, sûres et
adaptables. Dunod. https://www.pdfdrive.com/architecture-logicielle-concevoir-des-
applications-simples-sures-et-adaptables-d186169418.html
Roques, P., & Vallée, F., (2007). UML 2 en action, de l’analyse des besoins à la conception
(Eyrolles, 4). Groupe Eyrolles.
https://doc.lagout.org/programmation/Databases/SQL/UML.pdf
Roques, P., (2008). UML 2 par la pratique (Eyrolles, 6). Groupe Eyrolles.
https://www.pdfdrive.com/uml-2-par-la-pratique-e38718756.html
Soutou, C., (2007). UML 2 pour les bases de données (Eyrolles, 4). Groupe Eyrolles.
https://www.pdfdrive.com/uml-2-pour-les-bases-de-donnees-d39719351.html
P a g e | 96
Articles
Kocoglu, Y. & Moatty, F., (2010). Diffusion et combinaison des TIC. Réseaux, 2010/4(162),
33-71. Consulté le 07/06/2021 sur https://www.cairn.info/revue-reseaux-2010-4-page-33.htm
Mequanint D. & Lemma D., (décembre 2014). « L’intégration des TIC en pédagogie dans
les pays en voie de développement », Revue internationale d’éducation de Sèvres [En ligne],
67 | décembre 2014, consulté le 22 juin 2021 sur http://journals.openedition.org/ries/4117
Traoré, D., (2007). Intégration des TIC dans l’éducation au Mali. Distances et Savoirs,
2007/1(5), 67-82. Consulté le 23/06/2021 sur https://www.cairn.info/revue-distances-et-
savoirs-2007-1-page-67.htm
Mémoires
Kimpinde, K., (2016). Conception d’une application web d’enrôlement au test des nouveaux
candidats dans une institution d’enseignement supérieur, cas de l’ISP/L’SHI. [Mémoire de
Licence non publié]. Institut Supérieur Pédagogique de Lubumbashi.
Melle, Z., A., (2018). Application web pour la gestion du département de Mathématique et
d’Informatique. [Mémoire de Master, Université Larbi Ben M’hidi – Oum El Bouaghi].
http://hdl.handle.net/123456789/6936
Mulay, K., J., (2020). La mise en place d’une application web d’identification des étudiants
de l’institut supérieur pédagogique de Lubumbashi en ligne. [Mémoire de Licence non publié].
Institut Supérieur Pédagogique de Lubumbashi.
Saiche, C. & Ouyougoute, A., (2015). Conception et réalisation d’une application web pour
la gestion des étudiants d’une école privée, cas d’étude : ‘ISA School’. [Mémoire de Master,
Université A / Mira de Béijaïa]. http://www.univ-
bejaia.dz/xmlui/bitstream/handle/123456789/556/
Cours
Audibert, L., (2013). UML 2 : De l’apprentissage à la pratique. Consulté le 21 septembre 2021

sur https://laurent-audibert.developpez.com/Cours-UML/
El Mouelhi, A., (s. d.). UML : diagramme de cas d’utilisation [PDF].

http://www.Isis.org/elmouelhia/courses/uml/coursUMLDiagrammeCasUtilisation.pdf
P a g e | 97
Gérard, P., (s.d.). Introduction à UML 2 : Modélisation Orientée Objet de Systèmes Logiciels.
Université de Paris 13 – IUT Villetaneuse. 342 p.
Longuet, D., (2017). UML Cours 2: cas d’utilisation [PDF].

http://www.lri.fr/longuet/Enseignement/16-17/Et3-UML
Ngongo, E., (2020, 13 Janvier). Cours de conception des systèmes d’information. Institut
Supérieur Pédagogique de Lubumbashi.
Ngongo, E., (2021, 08 Juin). Cours de Question Spéciale de conception des systèmes
d’information. Institut Supérieur Pédagogique de Lubumbashi.
Webographie
Architecture 3 tiers. (8 avril 2019). Dans Wikipédia.

https://fr.m.wikipedia.org/wiki/Architecture_trois_tiers (Consulté le 04 octobre 2021).
Cours-gratuit.com, (s.d.). Cours PHP. Cours-gratuit. Consulté le 05 octobre 2021 sur

https://www.cours-gratuit.com/cours-php
Creately, (2021). Tutoriel sur les diagrammes de séquence : Guide complet avec exemples.
Consulté le 01 septembre 2021 sur https://creately.com/blog/fr/uncategorized-fr/tutoriel-sur-
le-diagramme-de-sequence/
Dabi – Schwebel, (s.d.). Template (page web). 1min30. Consulté le 05 octobre 2021 sur
https://www.1min30.com/dictionnaire-du-web/template-page-web
De Wit, E., (2020). Établir des exigences : mode d’emploi pour analystes fonctionnels. NCOI
learning. Consulté le 10 août 2021 sur https://blog.ncoi.be/fr/gestion_des_it_projets/etablir-
des-exigences-mode-demploi-pour-analystes-fonctionnels/
Gillebert, F., (2021, 03 septembre). Quelle architecture logicielle pour son application ?
Softfluent. Consulté le 01 octobre 2021 sur https://www.softfulent.fr/blog/architecture-
logicielle-pour-application/
Hossam, M., (2021, 14 Juin). Système informatique : Définition, structure et classification.

CyberUniversity. Consulté le 02 août 2021 sur
https://www.cyberuniversity.com/post/systeme-informatique-definition-structure-et-
classification
P a g e | 98
Isplubum.wordpress.com. (2011). Historique et Objectif de l’ISP. Consulté le 13 juin 2021

sur https://isplubum.wordpress.com/historique-et-obbjectif-de-lisp/
Journaldunet.fr, (08 janvier 2019). SGBD (Système de Gestion de Base de Données) :

définition, traduction et acteurs. Consulté le 05 octobre 2021 sur
https://www.journaldunet.fr/web-tech/dictionnaire-du-webmastering/1203633-sgbd-systeme-
de-gestion-de-base-de-donnees-definition-traduction-et-acteurs/
MariaDB. (27 avril 2021). Dans Wikipédia. https://fr.wikipedia.org/wiki/MariaDB (Consulté

le 05 octobre 2021)
Myservername, (2021). Caractéristiques des exigences fonctionnelles et des exigences non

fonctionnelles. Consulté le 10 août 2021 sur https://fr.myservername.com/features-functional-
requirements#Non_Functional_Requirement
Ngoma. (2017). PHPStorm un environnement de développement intégré WEB pour le pro.

Infomagenie. Consulté le 05 octobre 2021 sur https://informagenie.com/2037/ide-pour-php-
phpstorm/
orm.bdpedia.fr, (s.d.). Modèle – Vue – Controller (MVC). Consulté le 04 octobre 2021 sur
http://orm.bdpedia.fr/mvc.html
PhpStorm. (17 août 2021). Dans Wikipédia. https://fr.wikipedia.org/wiki/PhpStorm (Consulté

le 05 octobre 2021)
Smartmodel, (s.d.). Qu’est-ce qu’un Modèle Logique de Données Relationnel (MLD-R).

Consulté le 27 septembre 2021 sur https://www.smartmodel.ch/home/questce/mldr
webdesigner.com, (2021). Quelle est la différence entre une architecture à 3 niveaux et une
MVC ?. Consulté le 04 octobre 2021 sur https://webdesigner.com/q/what-is-the-difference-
between-3-tier-architecture-and-a-mvc-136298
Document internes à l’organisation
Abekyamwale, G., (2015). De l’organisation et du fonctionnement administratif de

l’ISP/LUBUMBASHI des origines à nos jours. Institut Supérieur Pédagogique de Lubumbashi.
Organisation administrative des services, (2014). Institut Supérieur Pédagogique de

Lubumbashi.

Épigraphe

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

Épigraphe

Transféré par

Droits d'auteur :

Formats disponibles

I

‘Une communication efficace est indispensable pour réussir

À mon papa Kalubi Mulamba Jean – Pierre et à ma maman

Mes plus vifs remerciements s’adressent :

Au professeur KAMBA Camille et à son collaborateur, l’assistant MULENDA KINGWEZYA

À mon père KALUBI MULAMBA Jean-Pierre et ma mère MPUNGA MUKEBA Marie-

À mes frères Nickson MBIYA, Delvard MUKEBA, Rouminigue TSHAMALA, Élie

À mes belles sœurs Rosie SIKYABA, Pierce NSONGA et Carmel NGOY ;

À tous les enseignants du Département d’Informatique de Gestion et Sciences Commerciales

À mes collègues de classe Mariam RAMAZANI, Immaculée NEEMA, Gracia KABALADI,

L’intégration des Technologies de l’Information et de la Communication, en sigle TIC, dans le

Mots clés : Communication, gestion des étudiants et application web.

2.1.2. Exigences non fonctionnelles (Exigences techniques) .......................................... 25

LISTE DES FIGURES

Figure 1: Localisation de l'ISP-Lubumbashi (GOOGLE MAPS, 2021) ................................... 9

Figure 31 : Diagramme de séquence (Disponibiliser un cours) ............................................... 43

Figure 64: Diagramme de classe de conception (Publier un horaire) ...................................... 67

LISTE DES TABLEAUX

Tableau 1: Acteurs du système étudié ..................................................................................... 14

Au cours des deux dernières décennies, les Technologies de l’Information et de la

La gestion des étudiants au sein de l’Institut Supérieur Pédagogique de Lubumbashi présente

2. Choix et Intérêt du sujet

Ce travail nous permettra de compléter nos connaissances par des recherches en

ii. Intérêt social

iii. Intérêt scientifique

et serait une solution optimale au problème d’enregistrement et d’identification pour l’ISP-

Le travail de Mulay a produit une application web permettant l’enregistrement et

Nous avons consulté également le travail de Saiche et Ouyougoute (2015) intitulé

Les problèmes que rencontrait l’organisation d’étude étaient les suivants :

✓ Le volume important des informations traitées manuellement, provocant parfois des

✓ L’insécurité des informations ;

✓ La possibilité d’erreur dans le remplissage des différents documents et registres ;

✓ La possibilité d’erreurs dans le calcul des statistiques.

L’application web créée à l’issue de ce travail permet d’assurer plusieurs fonctionnalités de

✓ La gestion des comptes utilisateurs ;

✓ L’enrôlement des étudiants ;

✓ La publication des horaires ;

✓ La publication des communiqués émanant du département ;

✓ Le téléchargement du contenu des cours ;

✓ La saisie et l’affichage des notes des cours ;

✓ La saisie des présences.

L’Institut Supérieur Pédagogique de Lubumbashi est une institution publique d’enseignement

• Le retard dans la compréhension, l’exécution et la clôture de toute activité déclenchée

Face à cette situation, il convient de se poser des questions importantes à savoir :

✓ L’ISP-Lubumbashi, dispose-t-il d’un système de gestion des étudiants ?

✓ Si oui, est-il efficace ?

Le défi de l’Institut Supérieur Pédagogique de Lubumbashi étant majeur, à savoir, doter la

UP est un acronyme anglais signifiant Processus Unifié en français. La méthode UP est un

iii. Technique documentaire

Nous avons consulté des documents internes à l’organisation, c’est-à-dire l’ISP-Lubumbashi,

En plus de l’introduction et de la conclusion, le présent travail est organisé en trois chapitres,

✓ Le chapitre premier intitulé Étude Préalable est consacré à la présentation de

✓ Le chapitre deuxième intitulé Conception du Système Informatique parle des différentes

✓ Le chapitre troisième intitulé Réalisation du Système Informatique décrit le choix de

Chapitre 1. ETUDE PREALABLE

1.1. Présentation de l’Institut Supérieur Pédagogique de Lubumbashi

1.1.1. Situation géographique

L’Institut Supérieur Pédagogique de Lubumbashi est un établissement public d’Enseignement

Figure 1: Localisation de l'ISP-Lubumbashi (GOOGLE MAPS, 2021)

1.1.2. Historique de l’Institut Supérieur Pédagogique de Lubumbashi

En 1981, l’Institut Supérieur Pédagogique de Lubumbashi devient un établissement public

1.1.3. Mission de l’ISP – Lubumbashi

L’Institut Supérieur Pédagogique de Lubumbashi a pour mission de :