RÉPUBLIQUE DÉMOCRATIQUE DU CONGO

ENSEIGNEMENT SUPÉRIEUR ET UNIVERSITAIRE

UNIVERSITÉ DE KINSHASA
FACULTÉ POLYTECHNIQUE
DÉPARTEMENT DE GÉNIE ÉLECTRIQUE ET INFORMATIQUE

TP DE LANGAGE DE PROGRAMMATION ET
COMPILATION
Rapport du projet gestion académique

Présenté par : Kanga Kakulungoma Jonathan

Kanke Kaseba Junior
Lusakueno Kianzambi Perside
Malu Lupongo Junior

Année académique : 20242025

Introduction

0.1 Problématique

Dans un monde de plus en plus numérique, l'absence d'un site web dédié au département
de Génie Électrique limite la visibilité, la diusion des informations, et la communication
entre étudiants, enseignants et partenaires. Il devient donc nécessaire de mettre en place
une solution moderne et accessible pour centraliser les données du département.

Ce projet vise à développer une application web dynamique permettant aux étudiants de
consulter leurs résultats immédiatement après la délibération et de consulter leur dossier
académique au sein de la faculté.

0.2 Objectifs du projet

Face à une variété de langages largement utilisés dans le développement d'applications

web tels que HTML, CSS, PHP, JavaScript, Python, C++, etc., l'objectif principal de
ce projet est de permettre aux étudiants que nous sommes de mettre en ÷uvre et de
maîtriser les concepts développés dans le cours, dont entre autres la capacité de choisir le
langage de programmation le plus adapté à un problème donné.

Outre l'objectif principal, ce projet a également comme objectifs :

 Concevoir un site web fonctionnel et dynamique pour le département de Génie

Électrique.
 Orir une plateforme de communication, de partage de documents, d'achage des
informations académiques.
 Valoriser les activités, projets, et résultats de recherche du département.

0.3 Méthodologie adoptée

Pour mener à bien ce projet, nous avons adopté une méthodologie structurée en cinq
étapes clés, permettant une progression logique et ecace du travail :

0.3.1 Analyse des besoins

Nous avons commencé par identier les utilisateurs cibles de la plateforme, principalement
les étudiants, les enseignants et les membres administratifs. Cette étape nous a permis
de cerner leurs attentes respectives et de dénir les fonctionnalités essentielles à intégrer
dans le système.

0.3.2 Conception

Sur base de l'analyse précédente, nous avons élaboré l'architecture générale du site, en
décrivant les diérents modules ainsi que les relations entre les entités. Des schémas de

1
modélisation (MCD, MLD, diagrammes UML) ont été utilisés pour visualiser la structure
du système.

0.3.3 Développement

Le développement s'est eectué en deux volets :

 Front-end : avec les langages HTML5, CSS3 et JavaScript, en créant des interfaces
dynamiques, ergonomiques et adaptatives.
 Back-end : avec le framework NestJS et une base de données MySQL, pour la
gestion des utilisateurs, des données et des règles métier.

0.3.4 Tests et validation

Une fois les diérentes fonctionnalités développées, nous avons procédé à une série de
tests unitaires et fonctionnels, aussi bien côté client (interface utilisateur) que côté serveur
(API et base de données). Ces tests nous ont permis de vérier le bon fonctionnement du
système et d'identier d'éventuelles erreurs à corriger.

0.3.5 Mise en ligne

Enn, une version fonctionnelle a été déployée sur un environnement local, dans l'objectif
de valider l'intégration complète de l'interface avec les fonctionnalités back-end. Une mise
en production sur un hébergement distant est envisagée dans les étapes futures.

2
1 Cahier des charges / Analyse des besoins

1.1 Présentation de la faculté

La faculté Polytechnique de l'Université de Kinshasa accueille des centaines d'étudiants

chaque année, avec un encadrement assuré par un corps professoral et administratif varié.
La faculté Polytechnique compte quatre départements à savoir : génie civil, génie élec-
trique, génie informatique et génie mécanique, et chaque département a des orientations.

Ainsi, à l'issue du premier cycle, l'apprenant aura le diplôme de Licence en sciences de l'in-
génieur selon l'orientation du département suivi. Et à l'issue de sa formation du deuxième
cycle, l'élève ingénieur sera appelé à avoir l'un des diplômes de Master ingénieur civil
selon les orientations organisées dans les 4 départements, à savoir :

 Génie électrique :
 Électronique
 Electro-énergétique
 Génie civil :
 Structures et ouvrages d'art
 Hydraulique et constructions hydrauliques
 Génie mécanique :
 Constructions mécaniques
 Electromécanique
 Génie Informatique :
 Informatique

1.2 Description des besoins fonctionnels et non fonctionnels

1.2.1 Besoins fonctionnels

Les spécications fonctionnelles décrivent les principales fonctionnalités que le site web
du département de Génie Électrique devra orir aux utilisateurs naux.

 Page d'accueil :
 Présentation succincte du département
 Achage dynamique des actualités et événements
 Accès rapide aux diérentes rubriques du site
 Formations :
 Liste des lières (Licence, Master, etc.)
 Description des programmes (UE, crédits, durée)
 Ressources pédagogiques :
 Téléchargement de documents (cours, TD, rapports, mémoires)

3
  Accès à des liens utiles (plateforme e-learning, base de données scientiques)
 Corps enseignant :
 Liste des enseignants avec leurs spécialités
 Prol individuel (CV académique, publications, contacts)
 Espace étudiant/enseignant (optionnel) :
 Authentication par identiant et mot de passe
 Accès personnalisé aux notes, documents et annonces

1.2.2 Besoins non fonctionnels

Les spécications non fonctionnelles dénissent les exigences techniques et qualitatives du

site web.

 Accessibilité :
 Le site doit être consultable sur ordinateurs, tablettes et smartphones (respon-
sive design)
 Il doit être compatible avec les navigateurs récents (Chrome, Firefox, Edge. . .)
 Performance :
 Le temps de chargement des pages doit être rapide
 Le site doit pouvoir supporter un nombre élevé de connexions simultanées
 Ergonomie :
 Interface simple, intuitive, facile à prendre en main
 Charte graphique claire et adaptée à l'identité du département
 Maintenabilité et évolutivité :
 Le site doit être facilement modiable pour ajouter de nouvelles pages ou mo-
dules
 Le code doit être structuré et commenté pour faciliter la maintenance
 Disponibilité :
 Le site doit être opérationnel 24h/24 et 7j/7 avec un taux de disponibilité d'au
moins 99 %
 Un système de sauvegarde régulière doit être prévu

4
2 Conception du système
Pour la conception du système, nous avons subdivisé le travail en deux équipes : une pour
le front-end et une autre pour le back-end.

2.1 Choix technologiques

En raison des connaissances de chaque membre du groupe et de la facilité d'apprentissage,

nous avons choisi :

 Langages Front-end :
 HTML5
 CSS3
 JavaScript
 Langages Back-end :
 NestJS
 MySQL
 Hébergement :
 Hébergement local

5
2.2 Architecture Technique du système

Figure 1  Architecture Technique du système

6
2.3 Modélisation de la BD (MCD, MLD, MPD) et diagrammes

Figure 2  Modélisation MCD

7
 8

Figure 3  Modélisation MLD

 Figure 4  Modélisation MPD

Figure 5  Diagramme d'utilisation

9
Figure 6  Diagramme de classe

10
Figure 7  Diagramme de séquence

11
 Figure 8  Diagramme UML

2.3.1 Explication du diagramme

ˆ Contexte général du système

Le système modélisé représente une plateforme de gestion académique complète. Il couvre
plusieurs domaines clés :

 Gestion des utilisateurs (étudiants, enseignants, administrateurs, sta, chef de dé-

partement)
 Suivi académique (résultats, paiements, TFC, état d'avancement des cours)
 Gestion documentaire et bibliothèque
 Gestion des communiqués, salles, laboratoires et équipements
 Planication via un calendrier académique

ˆ Structure utilisateur (héritée depuis UserEntity) La classe UserEntity joue un

rôle central. Elle contient les attributs d'authentication communs à tous les types d'uti-
lisateurs : username, email, password, salt, et role.

Elle est liée (relation OneToOne) à :

 EtudiantEntity
 EnseignantEntity

12
  AdministrateurEntity
 ChefDepartementEntity
 StaffEntity

Chaque utilisateur possède donc un compte unique et ses informations spéciques sont
stockées dans sa propre entité.

ˆ Entité EtudiantEntity L'étudiant est relié à :

 UserEntity (compte utilisateur)

 DepartementEntity (aliation)
 PromotionEntity (niveau d'études)
 Plusieurs ResultatEntity (notes)
 Plusieurs TfcEntity (travaux de n de cycle)
 FraisPaiementEntity (suivi des paiements)

On peut ainsi gérer tout le parcours académique de l'étudiant.

ˆ Personnel académique

 EnseignantEntity : lié à UserEntity, DepartementEntity, supervise des TfcEntity.

 ChefDepartementEntity : lié à UserEntity, gère un département et les ensei-
gnants.
 AdministrateurEntity : utilisateur avec rôle d'administration, lié à un StaffEntity.

ˆ Résultats et paiements

 ResultatEntity : lié à un étudiant, un administrateur et à un paiement.

 FraisPaiementEntity : gère les frais académiques, liés à un étudiant, une année et
un département.

Cela garantit que seuls les étudiants en ordre peuvent recevoir leurs résultats.

ˆ Bibliothèque et documents

 BibliothequeEntity : liée à un département, contient des livres et des TFC.

 EmpruntEntity : associe un livre, un étudiant et la bibliothèque.

Ce module permet une gestion ecace des ressources documentaires.

ˆ Cours et progression pédagogique L'état d'avancement d'un cours est suivi via
EtatAvanceCoursEntity, qui est lié à :

 un EnseignantEntity
 une PromotionEntity
 une AnneeEntity
 un CoursEntity

13
ˆ Communiqués et gestion de la vie académique CommuniqueEntity permet de
diuser des messages à divers publics :

 Étudiants, enseignants, chefs de département

 Par département, promotion, ou salle

Les auteurs possibles sont les administrateurs et chefs de département.

ˆ Laboratoire et équipements

 LaboratoireEntity : lié à un département

 EquipementEntity : lié à un laboratoire

Ce module permet la gestion du matériel technique et scientique.

ˆ Calendrier académique Le CalendrierEntity est lié à :

 Une PromotionEntity
 Une AnneeEntity

Il permet de planier les cours, examens et activités importantes.

ˆ Conclusion : Le diagramme UML présenté reète une architecture claire, modulaire et

bien structurée, adaptée à un système de gestion académique. Il respecte les principes de
séparation des responsabilités, d'encapsulation et de cohérence relationnelle. L'ensemble
des entités est relié de manière à favoriser une navigation uide dans les modules du
système.

14
3 Implémentation

3.1 Description des principales fonctionnalités

 Authentication sécurisée avec rôle (étudiant, professeur, admin)

 Achage dynamique du prol de l'utilisateur
 Interface de messagerie
 Accès aux cours, enseignants et documents personnels

3.2 Captures d'écran ou aperçu des interfaces

Figure 9  Accueil

Figure 10  Connexion

15
 Figure 11  Cours

Figure 12  Horaire

Figure 13  Notications

3.3 Problèmes rencontrés et solutions apportées

Au cours de la réalisation du projet, plusieurs dicultés ont été rencontrées tant au niveau
du développement du front-end que du back-end. Voici un récapitulatif des principaux
problèmes et des solutions que nous avons mises en place :

 Problème de structure des pages

Les diérentes pages HTML étaient initialement mal structurées, ce qui rendait
la navigation incohérente. Solution : Nous avons consulté des sites d'universités
existants pour nous inspirer de leur arborescence et améliorer la cohérence de la
structure.

16
 Problème de design et d'organisation des chiers
L'interface manquait de cohérence graphique et certains chiers (CSS, images)
n'étaient pas bien liés aux pages. Solution : Nous avons demandé conseil à des
étudiants spécialisés en design pour obtenir des recommandations visuelles, puis ré-
organisé tous les chiers dans des dossiers appropriés et corrigé les chemins dans le
code.
 Problème d'ajout des étudiants dans la base de données
Lors de l'implémentation, l'enregistrement des étudiants dans la base de données
posait problème, notamment en raison de la logique de traitement mal structurée.
Solution : Nous avons utilisé la structure proposée par NestJS, en séparant les
responsabilités via les chiers Service (pour la logique métier) et Controller (pour
l'exposition des routes). Cette approche a permis une meilleure organisation du code
et une insertion uide des données dans la base.
 Problème de gestion des rôles des utilisateurs
Il n'était pas évident de distinguer les diérents types d'utilisateurs (étudiant, en-
seignant, administrateur. . .) dans l'application. Solution : Nous avons déni une
énumération Role dans NestJS (enum Role), attribuée à chaque entité utilisateur.
Cela nous a permis de gérer dynamiquement les autorisations selon les rôles dans le
système.

17
4 Résultats et tests

4.1 Résultats obtenus

À ce stade du développement, l'interface front-end de l'application est presque totalement

nalisée. Elle ore une navigation uide et présente l'ensemble des interfaces prévues pour
les diérents utilisateurs (étudiants, enseignants, administrateurs).

Du côté back-end, les principales fonctionnalités ont été implémentées avec succès. Le
traitement des requêtes, la gestion des entités (utilisateurs, cours, résultats, etc.) ainsi
que l'intégration de la base de données fonctionnent correctement, même si certaines
parties nécessitent encore des optimisations.

Dans l'ensemble, le système est opérationnel de manière partielle et ore déjà un aperçu
fonctionnel des objectifs xés en début de projet.

4.2 Scénarios de tests réalisés

Pour évaluer les performances et la cohérence de notre solution, plusieurs scénarios de

tests ont été réalisés de manière indépendante sur le front-end et le back-end :

 Test des interfaces utilisateur (front-end) : Simulation de navigation entre

les diérentes pages (accueil, connexion, tableau de bord, cours, notications) pour
valider la réactivité et l'ergonomie.
 Test de création et d'achage des cours (front-end) : Ajout de cours ctifs
et achage dans l'espace dédié de l'étudiant.
 Test de gestion des utilisateurs (back-end) : Vérication de l'ajout, de la sup-
pression et de la modication des utilisateurs via les services et contrôleurs NestJS.
 Test d'authentication et de rôles (back-end) : Identication correcte des
utilisateurs selon leur rôle (étudiant, enseignant, administrateur) grâce à l'utilisation
d'un énumérateur de rôles.

4.3 Limitations actuelles

Malgré les progrès réalisés, plusieurs limitations subsistent dans la version actuelle du
projet :

 Absence de liaison entre le front-end et le back-end : À ce jour, les deux

parties de l'application n'ont pas encore été connectées. L'échange de données entre
les interfaces utilisateur et la base de données via l'API reste donc à implémenter.
 Manque de mécanisme de sauvegarde du code : Aucun système de sauve-
garde automatique n'a été mis en place. Ainsi, en cas de perte ou de suppression
accidentelle du code, aucune restauration n'est possible, ce qui constitue un risque
important.

18
  Optimisation incomplète du back-end : Certaines requêtes ou fonctionnalités
backend mériteraient des améliorations pour gagner en ecacité, notamment dans
la gestion des erreurs et la sécurité des données.

5 Conclusion et perspectives

5.1 Conclusion

La réalisation de ce projet nous a permis de concevoir un système de gestion académique

structuré, modulaire et adapté aux besoins spéciques d'une faculté universitaire. En
combinant des technologies modernes côté front-end (HTML, CSS, JavaScript) et back-
end (NestJS, base de données relationnelle), nous avons pu développer une architecture
claire capable de gérer plusieurs types d'utilisateurs, de documents, de résultats et de
services académiques.

Même si certaines fonctionnalités restent à connecter (notamment l'intégration complète

entre l'interface utilisateur et l'API), les résultats actuels témoignent de la cohérence
globale du projet et de la faisabilité technique d'un tel système.

5.2 Apports personnels et techniques

Ce projet a constitué une expérience d'apprentissage enrichissante à plusieurs niveaux :

 Sur le plan personnel : nous avons développé notre capacité à travailler en équipe,
à répartir les tâches ecacement et à surmonter les obstacles techniques ensemble.
 Sur le plan technique : nous avons manipulé des outils et concepts professionnels
tels que :
 l'architecture MVC avec NestJS,
 la gestion des routes, services et contrôleurs,
 la communication avec une base de données,
 l'organisation des rôles utilisateurs (via une énumération Enum),
 l'intégration du design dans des interfaces responsives.
Nous avons également utilisé des outils de modélisation (UML, MCD/MLD/MPD)
pour structurer le système dès la conception.

5.3 Perspectives d'amélioration

Dans la suite du projet, plusieurs améliorations sont envisagées :

 Connexion complète front-end / back-end : il est impératif d'établir la com-

munication entre les deux parties pour rendre le système pleinement fonctionnel.
 Mise en place d'un système de sauvegarde automatique : an d'éviter toute
perte de données ou de code, nous envisageons d'intégrer des outils de gestion de

19
 version (comme GitHub) ou de déploiement en ligne sécurisé.
 Optimisation de la sécurité et des performances : renforcer les vérications
côté back-end, améliorer la gestion des erreurs, et assurer la protection des données
sensibles.
 Ajout de nouvelles fonctionnalités : telles que la messagerie interne, l'inscription
en ligne, la gestion des horaires et la génération automatique des bulletins.

Ces perspectives visent à faire de notre application un outil complet, moderne et évolutif
au service du département de Génie Électrique.

20
Bibliographie
https ://youtu.be/mGMlGr Rf T k?si = M T pRmV jkzKe56JoO

21
Annexes

22
23
24