INSTITUT SUPERIEUR PEDAGOGIQUE DE NGANDAJIKA (ISP NGANDAJIKA)
SECTION : SCIENCES APPLIQUÉES DÉPARTEMENT : INFORMATIQUE DE GESTION
Par MULUMBA KALEKA Robert
Dirigé par : Professeur John TSHIBAMBA MUKENDI
Encadré par : Assistant Etienne KALANGA MPIANA
DEDICACE
Je dédie ce mémoire à mes très chers parents Marcel KALEKA MUDIAYI et Albertine NTUMBA MUKOKA, les premiers artisans de mon éducation, à travers vos conseils, vos sacrifices et vos prières, vous m’avez transmis les valeurs de courage, d’honnêteté et de persévérance.
Puissiez –vous trouver dans ce modeste effort la reconnaissance de tout ce que je vous dois.
REMERCIEMENTS
Nous remercions infiniment le Tout Puissant Seigneur Jéhovah, lui qui nous a fait don de son Esprit pour réaliser ce travail.
Nos remerciements s’adressent en particulier à mon Directeur Général de l’ISP/NGKA
Monsieur le Professeur Robert KANYIKI WA CILOMBO, le Secrétaire Académique Pierre CIBANGU MUABILA MUKUBAYI, le Secrétaire Administratif Papy MULAJ et l’Administrateur du Budget Nestor NDALA pour leurs conseils, leur disponibilité et leur contribution à la réussite de cette recherche.
Nos remerciements s’adressent au Professeur John TSHIBAMBA MUKENDI qui a accepté humblement de diriger et d’encadrer ce travail en dépit de ses multiples occupations.
Nous tenons à exprimer ma profonde gratitude à mon codirecteur de ce travail Ir Etienne KALANGA, pour sa disponibilité ses conseils avisés et son accompagnement constant tout au long de ce mémoire, ses observations pertinentes et son exigence scientifique ont grandement contribué à l’enrichissement et à la qualité de ce travail.
Nos remerciements s’adressent aussi à tous les enseignants : professeurs, chefs des travaux et assistants qui ont défilé dans le seul but de nous tailler et nous donner cette forme que nous avons aujourd’hui ; nous citons nommément : Ingénieur Etienne KALANGA MPIANA ; Ingénieur Modeste LUKUSA CIAMALA ; Ingénieur Jean MUAMBA
MUAMBA ; Ingénieur Romain ILUNGA KABAMBA ; Ingénieur Danis KALOMBO ; Ingénieur Séraphin KAZADI MBALA ; Chef de Travaux Denis NTUMBA MULAMBA et corps enseignants de l’ISP/ Ngandajika.
Nos sentiments de gratitude s’adressent au Directeur Provincial de la DINACOPE Lomami 2 je cite BOKAKO NGWELI Théophile et à tous les personnels, pour avoir soutenu et facilité nos recherches. Egalement nous remercions le Secrétaire de la DINACOPE Provinciale KABONGO TUENGU Gédéon pour les informations claires et précises que vous m’avez fournie.
Nos profonds remerciements s’adressent également : à mes frères et sœurs, Jean –Pierre
KALEKA KALEKA ; Chantal MUSUMBA KALEKA ; Aimé NTSHILA KALEKA ; Gédéon
MPOYI KALEKA ; Marie TSHILANDA KALEKA ; Fidèle KABEDI KALEKA; Mado NZEBA KALEKA ; Gibert MUKANDILA KALEKA ; Pascal MBAYA KALEKA ; André
MUDIAYI KALEKA ; Marie KABOLA KALEKA, Dieudonné KALAMBAYI BALOJI, Dieudonné KAZADI KATOMBE ; que l’effort fournis pour l’élaboration de ce travail vous montre un exemple.
A ma très chère femme Julie MUJINGA MUTOMBO à qui je présente le fruit de ma sueur.
Nos enfants : TSHITITA Anuarite ; MUDIAYI Arthur, Alice KAPENGA que ce travail soit un modèle dans notre famille.
Nos collègues et connaissances : Robert MULUMBA KALEKA ; Stéphane MUKADI BEYA ; Marcel MUTAMBAYI MBUYI ; Patrice LUKUSA KABEYA, Annuella KABANGU MULUMBA ; Mireille MIANDABU KALAMBAYI ; Thérèse MIANDA KALONJI ; Me Doris KAYOKA KABEYA ; Me Iron Van KALOMBO MUSOKO ; Me Matthieu KASONGO MUKANDILA ; Me Trésor NYEMBO WA NYEMBO pour leurs incitations et recommandations dans nos études.
Enfin, que tous ceux dont les noms ne sont pas ici cités et qui, de près ou de loin, nous ont apporté leur assistance, trouvent dans ces quelques pages l’expression de notre profonde gratitude et de notre reconnaissance.
SIGLES ET ABREVIATIONS
RDC : République Démocratique du Congo
NGKA : Ngandajika
ISP : Institut Supérieur Pédagogique
DINACOPE : Direction Nationale de Contrôle, de la préparation de
la paie et de la maîtrise des effectifs
SECOPE : Service de Contrôle et de la Paie des Enseignants
PACI : Point d’Appui à la Coordination de l’Enseignement
PASS : Assistant Provincial
NTIC : Nouvelles Technologies d’Information et de Communication
ARG : Argent
FP : Fiche de Paie
ETA : Etat de paie
PROVED : Province Educationnelle
SERNIE : Service National d’Identification des Elèves
SG : Secrétaire Général
SQL : Structured Query Language
PU : Processus Unifié
URL : Uniform Resource Locator
WAMP : Windows Apache MySQL PHP
WWW : Word Wide Web.
VS Code : Visual Studio Code
OHUI : Huissier
SSEN : Sentinelle
SCHA : Chauffeur
SDAC : Dactylographe DINACOPE
STRA : Travailleur DINACOPE
CTB : Coopération Technique Belge
LISTE DES FIGURES
Figure 1: Organigramme ……………………………………………………………………………………………. 17
Figure 2:Diagramme de cas d’utilisation ………………………………………………………………………. 25 Figure 3: diagramme de séquence pour la connexion d’un enseignant ……………………………… 27 Figure 4: le diagramme de séquence pour la connexion d’un chef DINACOPE ………………… 28 Figure 5: le diagramme de séquence pour l’ajout d’un nouvel enseignant …………………………. 29
Figure 6: le diagramme de séquence pour l’ajout d’une école ………………………………………….. 30
Figure 7:Diagramme de séquence pour l’envoi du message ……………………………………………. 31 Figure 8: diagramme d’activités pour la connexion de l’enseignant…………………………………. 32 Figure 9:Diagramme d’activités pour la connexion du chef DINACOPE …………………………. 33 Figure 10: Diagramme d’activités pour l’ajout d’un enseignant ………………………………………. 34 Figure 11: Diagramme d’activités pour l’ajout d’une école ……………………………………………. 35 Figure 12: Diagramme d’activités pour l’envoi de message ……………………………………………. 36 Figure 13: diagramme de classe ………………………………………………………………………………….. 37 Figure 14: Diagramme de Composants ………………………………………………………………………… 39 Figure 15: Interface Bienvenue …………………………………………………………………………………… 43 Figure 16: Interface Accueil ……………………………………………………………………………………….. 44 Figure 17: Interface Actualités ……………………………………………………………………………………. 45 Figure 18: Interface Connexion …………………………………………………………………………………… 46
Figure 19: Interface Enseignants …………………………………………………………………………………. 47 Figure 20: Interface administrateur ou Dashboard …………………………………………………………. 48
Figure 21: Interface Bienvenue …………………………………………………………………………………… 49
Figure 22: Interface Ajout d’une école…………………………………………………………………………. 50 Figure 23: Interface message reçus ……………………………………………………………………………… 51 Figure 24: Interface Contact ……………………………………………………………………………………….. 52 Figure 25: Interface Galerie Média ……………………………………………………………………………… 53
LISTE DES TABLEAUX
Tableau 1: Les 4 phases du Processus Unifié………………………………………………………………… 21
Tableau 2: Exemples de livrables à chaque étape ………………………………………………………….. 21
Tableau 3: Rôle UML ……………………………………………………………………………………………….. 22
Tableau 4: Diagrammes structurels ……………………………………………………………………………… 23
Tableau 5: Diagrammes comportementaux …………………………………………………………………… 24
Tableau 6 : Fiche descriptive du visiteur………………………………………………………………………. 26
Tableau 7: Fiche descriptive de l’enseignant ………………………………………………………………… 26
Tableau 8 : Fiche descriptive du chef DINACOPE ……………………………………………………….. 26 Tableau 9: Fiche descriptive de l’Administrateur ………………………………………………………….. 27
Page sur 65 RESUME
Manual management of unpaid teachers presents several challenges, including slow information processing, the risk of errors, data loss, and a lack of transparency in monitoring. To address these issues, this work proposes the implementation of a computerized system aimed at ensuring better management of unpaid teachers. This system will allow for the recording, centralization, and processing of data related to the concerned teachers, while facilitating the quick generation of reports and tracking of financial situations. The main objective is to modernize the management process in order to reduce payment delays, improve information reliability, and strengthen decision-making.
- INTRODUCTION
La Province Educationnelle de LOMAMI 2, comme de nombreuses provinces éducationnelles de la République démocratique du Congo, fait face à un paradoxe administratif troublant, certains enseignants sont officiellement recensés par l’État et pourvus d’un numéro matricule, mais, malgré cette reconnaissance officielle de leur statut, ils n’ont jamais perçu leur rémunération. Cette situation illustre une contradiction manifeste entre la reconnaissance administrative d’un enseignant et l’absence de tout versement salarial correspondant. Elle révèle en creux des dysfonctionnements au sein du dispositif national de paie du personnel enseignant et met en lumière l’urgence d’une intervention ciblée, ce rapport met en évidence le paradoxe de milliers d’enseignants régulièrement recensés et porteurs d’un numéro matricule, mais qui ne perçoivent aucun salaire, révélant ainsi les limites du dispositif national de paie
[Ministère de l’EPST Rapport sur la situation des enseignants non payés RDC 2021, p.7]
Dans de nombreux systèmes éducatifs, la gestion administrative des enseignants constitue un enjeu fondamental, notamment en ce qui concerne la rémunération. Ce phénomène résulte souvent de dysfonctionnements dans les processus de gestion, du manque de transparence, ou encore de l’absence de mécanismes efficaces de suivi. Dans ce contexte, la conception d’un système informatisé de gestion apparaît comme une solution prometteuse. Un tel système permettrait d’améliorer la gestion des données relatives aux enseignants et de garantir une transparence accrue. De plus, il faciliterait la centralisation des informations, la prise de décision et l’assurance d’un traitement équitable du personnel enseignant, ce rapport souligne que l’absence de mécanismes efficaces de suivi et de gestion administrative constitue un obstacle majeur à la transparence et à l’équité dans la rémunération des enseignants, particulièrement dans les pays à faibles revenus. [UNESCO, Rapport mondial sur l’éducation 2020 : inclusion et éducation –tous sans exception, Paris, UNESCO, 2020 p. 85].
Ce travail porte donc sur la conception et l’implémentation d’un système informatisé destiné à gérer efficacement les cas des enseignants impayés dans la province éducationnelle
LOMAMI 2. L’objectif de ce mémoire est de concevoir et de proposer un système informatisé de gestion dédié à ces enseignants matriculés impayés, de manière à corriger efficacement cette anomalie structurelle, administrative complexe, aux répercussions humaines, sociales et éducatives significatives [Ministère de l’EPST, Rapport sur la Situation des Enseignants non mécanisé et impayés en RDC 2021 P. 12].
0.1. PROBLEMATIQUE
La gestion manuelle des enseignants impayés dans plusieurs institutions éducatives entraîne des difficultés majeures : retards dans la mise à jour des données, erreurs dans le traitement des informations, absence de traçabilité, et incapacité à produire des rapports fiables dans les délais requis. Ces contraintes compromettent l’efficacité du suivi administratif et financier. Dans ce contexte, l’adoption d’un système informatisé devient indispensable pour améliorer la transparence et l’efficience de la gestion des enseignants impayés.
Ainsi, pour mieux comprendre notre sujet, les interrogations suivantes orientent notre réflexion :
- Comment un système informatisé peut-il contribuer à l’amélioration de la gestion des enseignants impayés dans une structure éducative ?
- Quelles sont les fonctionnalités essentielles que doit intégrer un tel système pour en assurer l’efficacité ?
- Quels types de données doivent être collectés organisés et traités pour assurer un suivi rigoureux et fiable ?
0.2. HYPOTHESE
Nous posons l’hypothèse selon laquelle la conception d’un système informatisé de gestion des enseignants impayés permettrait d’améliorer significativement l’efficacité administrative. Cette amélioration se traduirait par une réduction des erreurs de traitement, une mise à jour plus rapide des données et une facilitation du suivi ainsi que de la régularisation des situations financières des enseignants concernés.
0.3. ETAT DE LA QUESTION
La gestion des enseignants impayés est un défi majeur dans plusieurs systèmes éducatifs, notamment en raison des retards administratifs et des problèmes de financement. L’informatisation de cette gestion permettrait une meilleure transparence, une réduction des erreurs et une accélération des paiements, les travaux ci -après ont été repérés :
Steve Ndjule – ISC Bandundu, a travaillé sur « la mise en place d’un système informatisé pour la gestion des enseignants impayés dans le cadre du SECOPE
Bandundu1 », une solution pour améliorer la transparence et l’efficacité dans le suivi des impayés.
Qui-vive Kusakana – UPN, a mis en place un système de « gestion informatisée de la rémunération des enseignants », un système pour automatiser le paiement des enseignants afin de réduire les retards et les erreurs.
Muhindo Ngaingai Alphée – ISC Beni, a fait « La Modélisation informatique de la gestion des horaires des enseignants de l’enseignement supérieur et universitaire », une architecture client-serveur pour optimiser l’organisation et la planification des horaires.
0.4. CHOIX ET INTERET DU SUJET
0.4.1. INTERET PERSONNEL
Ce projet concrétise mes compétences en développement web (Html, JavaScript, PHP et MySQL) et en gestion de projet Informatique.
0.4.2. UN INTERET SCIENTIFIQUE
Le présent travail permettra, non seulement de mettre en pratique les connaissances acquises tout au long de notre cursus académique mais aussi, constituera une documentation solide pour les chercheurs qui voudront aborder cette optique.
0.4.3. UN INTERET SOCIETAL
Le présent travail aidera les utilisateurs à réduire considérablement le temps de traitement et de vérification de gestion claire et traçable des salaires des enseignants, réduisant ainsi les risques de corruption, d’erreurs administratives et favoritisme.
0.5. METHODES ET TECHNIQUES
0.5.1. METHODES
Pour atteindre les objectifs que nous nous sommes assignés, plusieurs méthodes seront d’émis. Tout au long de ce travail, il sera question des méthodes suivantes :
a) Le Processus Unifié (PU) : UML n’est pas une méthode de développement logiciel, mais un langage de modélisation graphique utilisé pour représenter les éléments, les processus et les relations d’un système informatique, indépendamment de la méthode employée.
b) La méthode comparative : La méthode de comparaison a permis de mettre en parallèle plusieurs situations par rapport aux méthodes d’évaluation et de réévaluation des données y relatives, afin d’interpréter les résultats en tenant compte des objectifs poursuivis par l’organisation.
0.5.2. TECHNIQUES
Dans le cadre de ce travail, nous avons utilisé deux méthodes suivantes :
a) Technique documentaire : Elle a permis d’accéder à des documents écrits ayant traits au présent travail, notamment des mémoires, des Travaux de Fin de Cycle, des cours, les différentes fiches de traitement et des articles.
b) Technique d’interview directe : elle nous a permis de faire l’entretien avec les membres du service de gestion des enseignants impayés de ladite province.
0.6. L’OBJECTIF DU TRAVAIL
L’objectif de notre travail est de concevoir et mettre en œuvre un système informatisé pour la gestion des enseignants impayés dans la Province Éducationnelle LOMAMI 2, afin d’améliorer la fiabilité et l’efficacité du traitement, en s’appuyant sur les langages et outils de développement web come HTML, JavaScript, PHP et MySQL.
0.7. DELIMITATION DU SUJET
Délimiter un travail consiste à le limiter dans temps et dans l’espace :
Dans le temps, les données et/ou informations qui constituent ce travail couvre la période allant de 2024-2025.
Dans l’espace, ce travail se concentre sur la Direction Nationale de contrôle, de la préparation de la paie et de la maitrise des effectifs des enseignants du personnel Administratif des établissements scolaires « DINACOPE » de la province Educationnelle LOMAMI 2.
0.8. SUBDIVISION DU TRAVAIL
Notre étude sera structurée en quatre chapitres hors mis l’introduction et la conclusion. Le premier chapitre intitulé « systèmes d’information et bases de données » nous expliquera le système d’information et la base de données. Le second chapitre intitulé « Présentation de la Direction Nationale de Contrôle de Paie » nous présentera la DINACOPE au niveau Provincial. Dans le troisième chapitre intitulé : « Modélisation du système d’information », il est sera question de présenter la structure générale et détaillée de l’application mise en place. Et par la suite le dernier prendra « Implémentation du site web » en son sein la présentation ainsi que le guide de l’utilisateur pour l’application dont il a été question au troisième chapitre.
0.9. DIFFICULTES RENCONTREES
Comme tout travail scientifique, les difficultés ne manquent jamais. Parmi les difficultés rencontrées on peut citer le manque des travaux qui cadre directement avec la Direction Provinciale, les Informations sur les enseignants impayés sont souvent éparpillées dans plusieurs services, beaucoup d’établissements utilisent encore des fichiers papiers ou Excel non centralisés.
CHAPITRE I. SYSTEMES D’INFORMATION ET BASES DE DONNEES
I.1. SYSTEME D’INFORMATION
I.1.1. DEFINITION
Un système d’information est un ensemble de personnes, de procédures et de ressources qui recueillent, transforment et diffusent l’information dans une organisation.
Le système d’information est composé d’éléments divers pouvant être chargés de stocker et de traiter les informations relatives au système opérant afin de les mettre à la disposition du système de pilotage [NGELEKA ST. COURS DE TECHNIQUE DE BANQUE INEDIT 2020-
2021].
I.1.2. ASPECTS TECHNOLOGIQUES D’UN SYSTEME D’INFORMATION
Les aspects technologiques sont d’une grande importance pour gestionnaires utilisateurs du fait que le système d’information informatisé quoi que tributaire des techniques de traitement de l’information, est conçu et exploité par des personnes provenant de divers milieux organisationnels aux yeux des gestionnaires utilisateurs. On doit mesurer le succès d’un système d’information non seulement par son efficience dans l’usage de la technologie de l’information mais aussi par son efficacité dans l’attente des buts des utilisateurs et des entreprises.
I.1.3. LES RESSOURCES D’UN SYSTEME D’INFORMATION
Un système d’information utilise des ressources humaines (utilisateurs finals et informaticiens), des ressources matérielles (machines et supports) et des ressources logicielles (programmes et procédures) pour accomplir des fonctions qui servent à convertir en produits informatiques des ressources en données.
I.1.4. LES ACTIVITES D’UN SYSTEME D’INFORMATION
Les activités d’un système d’information sont :
– L’entrée des données ;
– La transformation des données en information ;
– La sortie des produits informatiques ;
– Le stockage des données ;
– Le contrôle de la performance d’un système et – L’identification du système.
I.2. SYSTEME INFORMATIQUE
• DEFINITION Un système informatique est un sous-ensemble du système d’information dans lequel toutes les transformations nécessaires d’informations sont effectuées par des machines de traitement automatique d’informations qui sont les ordinateurs [NGELEKA ST. COURS DE TECHNIQUE DE BANQUE INEDIT 2020-2021].
• CLASSIFICATION DES SYSTEMES INFORMATIQUES D’une manière pratique, nous distinguons différents types de systèmes informatiques classifiés selon un degré donné.
- Selon le degré d’organisation : ï‚· Le système indépendant ; ï‚· Le système intégré.
- Selon le degré d’automatisation Le traitement manuel
Le traitement mécanique
Le traitement automatique - Selon l’architecture de traitement
L’informatique centralisée
L’informatique décentralisée ou répartie
L’informatique distribuée ou mixte
I.2.1. ROLES D’UN SYSTEME INFORMATIQUE
Les rôles d’un système informatique sont :
Traiter les informations
Stocker les informations
Diffuser les informations
Communiquer les informations
Tenir compte des valeurs ajoutées
I.2.2. QUALITES D’UN SYSTEME INFORMATIQUE
Un système informatique doit posséder les qualités suivantes :
La fiabilité
La rapidité
La sécurité
La pertinence
I.3. LES BASES DE DONNEES ET LE SYSTEME DE GESTION DE BASE DE DONNEES
La gestion d’informations se faisait jadis à partir de fiches manuscrites puis dactylographiées, classées bien souvent selon un index.
Avec l’informatique, un certain nombre d’opérations peuvent être automatisées et l’enregistrement des informations est donc passé de la fiche manuelle à un support informatique (Bande magnétique, disque dur, disquette etc…). Ces informations peuvent être organisées dans des fichiers dans un premier temps. Ces fichiers se sont organisés en un véritable ensemble dévolu à la gestion des informations de l’entreprise. Mais organiser la gestion de données à partir d’un système de gestion de fichiers est une solution qui n’est pas satisfaisante : lourde à gérer, trop dépendante de l’organisation physique. Même si l’emploi de méthodes d’analyse permet, dans une certaine mesure, de limiter la redondance et l’inconsistance des données, il reste clair que seules de nouvelles solutions techniques peuvent améliorer la possibilité de rapprocher ou de lier entre elles les informations de même sens. C’est pourquoi, d’autres systèmes de gestion de données se sont mis en place : les Systèmes de Gestion de Bases de Données (SGBD) ; leur objectif principal étant d’éliminer les inconvénients directs de ces fichiers en espérant, par là même, éliminer les inconvénients indirects.
I.3.1. LES BASE DE DONNEES
a) DEFINITION Une base de données est un ensemble structuré de données, enregistrées sur des supports, accessibles par l’ordinateur, représentant les informations du monde réel et pouvant être interrogées et mises à jour par une communauté d’utilisateurs. La base de données est destinée à la gestion, au stockage, à l’actualisation et à la consultation d’entités de différentes natures (et de leurs données), sachant que ces entités ont un lien les unes avec les autres.
b) CARACTERISTIQUES OU CRITERES D’UNE BASE DES DONNEES Une base de données répond généralement à trois critères suivants :
L’exhaustivité : ce qui implique la présence dans la base des données, de tous les renseignements qui ont trait aux applications en question.
La non-redondance : implique la présence d’un renseignement donné une et une
seule fois
La structure : ce qui implique l’adaptation du mode de stockage des renseignements aux traitements qui les exploiteront et les mettront à jour, ainsi qu’au coût de stockage dans l’ordinateur.
c) FONCTIONS DES BASES DE DONNEES Les bases de données ont pour fonctions de :
Décrire les données qui seront stockées ;
Manipuler ces données (ajouter, modifier, supprimer des informations) ;
Consulter les données et traiter les informations obtenues (sélectionner, trier, calculer, agréger,) ;
Définir des contraintes d’intégrité sur les données (contraintes de domaines, d’existence,) ;
Définir les protections d’accès (mots de passe, autorisations,) ;
Résoudre les problèmes d’accès multiples aux données (blocages, inter blocages) ; Prévoir des procédures de reprise en cas d’incident (sauvegardes, journaux,).
I.3.2. LE SYSTEME DE GESTION DES BASES DE DONNEES
Un ensemble de logiciels de gestion, de contrôle d’accès aux données et aux programmes les manipulant [NGELEKA ST. COURS DE TECHNIQUE DE BANQUE INEDIT 2020-2021].
I.3.2.1. LES OBJECTIFS DE SGBD
Plus précisément, les objectifs d’un SGBD sont les suivants :
1. LIENS ENTRE LES DONNEES
Les systèmes de gestion des fichiers traditionnels souffrent également de ce qu’ils ne permettent pas de définir et de manipuler des liens complexes entre les données. Ces liens correspondent à des associations que l’on peut isoler entre les objets de l’application que l’on veut représenter. Un SGBD doit être fondé sur un modèle de données dont le but est précisément de définir la structuration des données que le système peut représenter et les liens qui peuvent être établis entre ces données.
2. COHERENCE DES DONNEES
Dans un ensemble de données contenant une masse importante de connaissances, la cohérence des données stockées par rapport à la réalité est une nécessité. C’est pourquoi un SGBD doit permettre à l’utilisateur de définir des règles permettant de maintenir la cohérence de la base. Ces règles définissent des propriétés que les données doivent satisfaire. Le maintien de la cohérence d’une base des données passe également par la mise en place d’un système d’autorisation qui permet de limiter certaines manipulations à des groupes d’utilisateurs responsables.
3. SOUPLESSE D’ACCES AUX DONNEES Un SGBD doit permettre d’accéder facilement à n’importe quelle donnée de la base. Plus précisément, le système doit permettre d’accéder aux données par l’intermédiaire des langages déclaratifs (non procéduraux) et de haut niveau que l’on appelle classiquement langages de requêtes. Le langage des requêtes peut être utilisés de façon interactive par des utilisateurs pour consulter la base des données ou faire des modifications. On voit donc apparaître deux manières différentes d’accéder à une base de données : dans une application connectée au SGBD (c’està-dire un programme écrit par un utilisateur) ou de façon interactive en utilisant le langage des requêtes.
4. SECURITE
Un SGBD doit être capable de protéger les données qu’il gère contre toute sorte d’agressions extérieures. Ces agressions peuvent être physiques comme une panne d’un périphérique de stockage ou une erreur logicielle. Elles peuvent aussi être humaines, comme une manipulation délibérément malveillante d’un utilisateur. Pour protéger les données contre les pannes matérielles et logicielles, le SGBD doit permettre la pose des points de reprise permettant de redémarrer le système et de le remettre dans un état satisfaisant, ainsi que la journalisation des modifications faites sur les données, afin de pouvoir défaire et/ou refaire ces modifications.
5. PARTAGE DES DONNEES
Nous avons dit précédemment que partager des données entre plusieurs applications
(utilisateurs) a été l’un des besoins essentiels qui ont conduit au concept de base de données.
Différentes applications opérant sur les mêmes données doivent pouvoir s’exécuter comme si elles étaient seules à opérer sur ces données. C’est au SGBD d’offrir des moyens de contrôler ce partage des données, de détecter d’éventuels conflits d’accès pouvant exister entre plusieurs utilisateurs ou plusieurs applications, et de donner les outils pour les résoudre.
6. INDEPENDANCE DES DONNEES
L’indépendance est un des aspects majeurs offerts par un système de gestion de bases de données. Une application manipulant ses données par l’intermédiaire de fichiers est fortement dépendante de ses données.
En effet, l’application doit connaître la structuration des fichiers ainsi que les méthodes d’accès à ces derniers : Si, pour une raison majeure, la structuration ou les méthodes d’accès doivent être changé, cela ne peut pas se faire sans remettre en question l’application de façon significative. Un SGBD, au contraire, doit permettre d’écrire des applications sans se soucier de la structuration physique des données et des méthodes d’accès associées.
Le système peut ainsi évoluer pour prendre en compte de nouveaux besoins sans remettre en cause les applications déjà écrites. L’indépendance des données est un concept lié à l’évolution et à la maintenance d’une application. On peut distinguer deux niveaux d’indépendance : l’indépendance physique et l’indépendance logique.
L’indépendance physique doit permettre de modifier les structures de stockage ou les méthodes d’accès aux données sans que cela ait de répercussion au niveau des applications. On pourra ainsi ajouter ou supprimer un index sur une collection, changer la représentation interne des données numériques ou bien changer une méthode de tri. Il est très important de pouvoir faire évoluer la représentation physique des données pour permettre au système de s’adapter aux données de telle ou telle application particulière dont les performances nécessiteront des méthodes d’accès différentes. Un système qui ne permet pas de séparer clairement les représentations physiques et logiques des données aura des performances qui ne seront bonnes que pour l’application et la configuration de données que le programmeur aura initialement prévues.
L’indépendance logique doit permettre de modifier l’organisation des données sans affecter les utilisateurs. Ce niveau d’indépendance a pour but de permettre d’enrichir une base de données existante pour prendre en compte de nouvelles structures sans pour autant remettre en cause celles qui existent déjà.
L’indépendance logique permet donc de faire face à de nouveaux besoins, ce qui est indispensable, si l’on considère qu’une base de données est un modèle du monde réel et que le monde réel, de même que les besoins des utilisateurs, changent au cours du temps. Il faut noter que ce principe d’indépendance des données est un idéal souvent très difficile à atteindre et que selon les systèmes que l’on considérera, on constatera différents niveaux d’indépendance.
7. PERFORMANCE
La réalisation des fonctions ci-dessus ne doit pas être obtenue aux dépens des performances globales du système. Un SGBD doit être capable de gérer un volume important de données et d’offrir un temps d’accès raisonnable aux utilisateurs. Ce besoin de performance fait qu’une grande partie de la technologie des bases de données a été et est encore consacrée à l’amélioration des techniques d’accès et d’optimisation. Les problèmes de performance et d’optimisation sont sous-jacents dans tous les problèmes considérés dans le domaine des bases de données.
8. ADMINISTRATION ET CONTROLE
L’administrateur du système joue un rôle primordial dans la conception et la maintenance d’un SGBD. En effet, une base de données étant utilisée par plusieurs utilisateurs à la fois, et ces utilisateurs ayant des besoins qui peuvent parfois être incompatibles, le contrôle et l’administration de la base doivent être confiés à une personne indépendante. Plus précisément, le rôle de l’administrateur est le suivant :
– Décider de l’information contenue dans la base. L’administrateur est en charge de la définition des structures de données contenues dans la base et de leur évolution éventuelle pour prendre en compte de nouvelles applications.
– Décider des structures physiques et des stratégies d’accès. L’administrateur définit la façon dont les données sont représentées au niveau physique ainsi que les différentes méthodes de stockage et d’accès. L’indépendance physique doit rendre possible cette spécification de façon entièrement autonome.
– Définir les autorisations accordées aux utilisateurs.
– Définir les points de reprise et les sauvegardes.
– Optimiser l’organisation physique pour augmenter les performances globales du système ou pour tenir compte de nouvelles spécifications.
En résumé, l’administrateur du système est chargé de gérer tous les aspects du SGBD qui ne sont pas automatisés et qui ne doivent pas transparaître au niveau des utilisateurs. Son rôle est d’autant plus important que la durée de vie d’une application utilisant un système de gestion de bases de données est longue et que pendant cette durée de vie, l’application devra souvent évoluer pour s’adapter à des changements de spécifications.
I.3.2.2. LES TYPES DE SGBD
Il existe plusieurs types de SGBD, mais dans le cadre de notre travail, nous essayerons de parler de SGBD hiérarchique, réseau, relationnel et le SGBD objet.
1. LES SGBD HIERARCHIQUES
Ce sont les premiers SGBD apparus (notamment avec IMS d’IBM). Ces systèmes de gestions de bases données font partie des SGBD navigationnelles constituées d’une gestion de pointeurs entre les enregistrements. Le schéma de la base de données est une arborescence.
2. LES SGBD RESEAUX Les SGBD réseaux viennent juste après le SGBD hiérarchique, elles ont très vite détrôné le SGBD hiérarchique dans les années 70. Ce sont aussi des SGBD navigationnelles qui gèrent des pointeurs entre les enregistrements. Cette fois-ci le schéma de la base de données est beaucoup plus ouvert. Sans doute les SGBD réseaux sont plus rapides que SGBD hiérarchiques.
3. LES SGBD RELATIONNELLES A l’heure actuelle, les SGBD relationnelles sont les plus utilisées. Les données sont représentées en de tables. Elles sont basées sur l’algèbre relationnelle et un langage déclaratif (généralement SQL).
4. LES SGBD DEDUCTIVES Dans les SGBD déductives, les données sont aussi représentées en tables (prédicats), le langage d’interrogation se base sur le calcul des prédicats et la logique du premier ordre.
5. LES SGBD OBJETS
Les données sont représentées sous forme d’objets au sens donné par les langages orientés objet : pour simplifier, les données (au sens habituel) sont enregistrées avec les procédures et fonctions qui permettent de les manipuler. Les SGBD orientés objet (SGBDOO) supportent aussi la notion d’héritage entre classes d’objets. Ces dernières années le développement rapide des langages orientés objet a mis en avant les SGBDOO qui permettent la sauvegarde directe des objets manipulés par ces langages.
De plus les manipulations de données à structures complexes, en particulier dans les traitements qui font intervenir le multimédia, sont facilitées avec les SGBDOO. Le modèle relationnel a montré ses limites pour ce type de données. On verra en particulier que les structures de données complexes sont éclatées par le modèle relationnel et la reconstitution de la structure nécessite des opérations (jointures) lourdes et coûteuses en performance. Cependant les SGBDOO ne sont utilisés actuellement que pour des usages bien spécifiques et il n’existe pas encore de normes communément admises. Les SGBDR ont aussi leurs atouts. Ils reposent sur une théorie formelle plus solide que les SGBDOO. Ils sont aussi plus souples pour répondre aux interrogations de la base non prévue au départ. La recherche est active dans le domaine des SGBDOO. Pour garder leur part du marché et répondre aux besoins des utilisateurs, les grands SGBD relationnels ajoutent progressivement une couche objet à leur noyau relationnel.
Les données sont stockées sous forme d’objets, c’est-à-dire de structures appelées classes présentant des données membres. Les champs sont des instances de ces classes [NGELEKA ST. COURS DE TECHNIQUE DE BANQUE INEDIT 2020-2021].
I.3.3.3 QUELQUES SGBD RECONNUS
• Oracle • Ingres • Gemstone
• DB2 • Informix • ObjectStore
• SQL Server • O2 • Jasmine Access, …..
CHAPITRE II. PRESENTATION DU SERVICE DE CONTROLE ET DE LA PAIE DES ENSEIGANTS DE LOMAMI 2
II.1. PRESENTATION DE L’EXISTANT
II.1.1. HISTORIQUE DE L’ENTREPRISE
Dans le cadre de pratique d’ajustement structurel préconisé par les institutions de Breton Woods à partir de l’année 1980, relatif à l’assainissement et à la maitrise des effectifs des agents et fonctionnaire des différents ministères, les directives du gouvernement avaient consisté à atteindre un objectif majeur qui est celle de maîtriser les effectifs du personnel de l’administration publique et les masses salariales des rémunérations du personnel de carrière de service public de l’Etat.
Ainsi donc, à partir de 1982 il sera constaté que les efforts consentis dans ce domaine dans les différents ministères et au ministère de l’enseignement primaire secondaire et professionnel EPSP en particulier n’avait pas atteint entièrement l’objectif poursuivi. Fort de se tondre, le ministère de l’enseignement primaire secondaire et professionnel EPSP en sigle convoquera le travail du centre catholique NGANDA dont le but était de définir les structures des établissements scolaires et de déterminer en conséquence les effectifs relatifs aux : (Ecoles, Bureaux, Elèves, Enseignants et Personnel Administratif) et les travaux de ce centre sont rendus possible grâce à l’appui de la coopération technique belge CTB en sigle. [MUKENGE MUKENDI 2011].
En 1985, le commissaire d’Etat de l’EPSP après avis favorable du gouvernement prendra l’arrêté N° DEPS/CCE/001/0121/85 du 24 septembre 1985 portant création d’un service spécialisé du contrôle, de maîtrise des effectifs et de la paie des enseignants et du personnel administratif des écoles et bureaux, « SECOPE » en sigle. Ce texte de base, a été modifié et complété par l’arrêté ministériel MINEPSP /CABMIN/001/00085/92 du 30 janvier 1992 Une source [Rapport Nestor 2009. P 25]
En 2020 un Arrêté Ministériel N°MINEPST/CABMIN-ETAT/LB/0511/2020 DU
01/04/2020 Modifiant et complétant l’arrêté Ministériel N°MINEPST/CABMINETAT/JLB/0197/2020 DU 19/02/2020 portant restructuration de quelques Provinces
Educationnelles d’Enseignement Primaire, Secondaire et Technique, pour la Province de Lomami. [TUENGU G. 2025]
II.1.2. APERÇU GEOGRAPHIQUE
Le Bureau de la Direction Provinciale du Service de DINACOPE Lomami 2 se situe dans la Province de Lomami, ville de Mwena –Ditu , Avenue : Njanja ; Quartier Mandam, Commune de Bondoyi.
Il est limité :
Au Nord par l’Université Morave
Au Sud par le chemin de fer vers Kananga et le stade de Bondoyi
A l’Est par le Marché Central de Mwene ditu
A l’Ouest par la direction provinciale de SERNIE et le siège de la fondation ika
II.2. ORGANISATION STRUCTURO-FONCTIONNELLE DE DIRECTION PROVINCIALE LOMAMI 2
a) STRUCTURE ORGANISATIONNELLE
- Directeur
- Secrétariat
- Collège des PASS
- Services Provinciaux
– Service statistique – Service de contentieux
– Service informatique – Service du personnel
– Service d’archives – Service radio phonie – Service de comptabilité (communication)
– Service de paie – Service administrative.
b) STRUCTURE FONCTIONNELLE
- DIRECTEUR PROVINCIAL
Le directeur provincial de DINACOPE a pour tâche :
Coordonner toutes les activités du service
Engager le service et le représenté auprès des autorités de sa juridiction
Faire le suivi et l’évaluation des attributions confiées aux collaborateurs
Orienter et faire appliquer les instructions de la hiérarchie relatives au contrôle, à l’encadrement et au suivi de la paie
Superviser la paie en province
Approuver et autoriser les dépenses
- SECRETARIAT
Il a comme tâche :
La réception et exploitation des lettres et dossiers administratifs
L’expédition des réponses des lettres et dossiers administratifs
La collection des dossiers des enseignants pour traitements par les assistants provinciaux
COLLEGE DES PASS
Ils ont comme tâche :
Exploiter et contrôler les dossiers des écoles, bureaux, et agents engagés qui proviennent des antennes ;
Dépouiller, vérifier et remettre aux chefs d’antennes les listings de paie à transmettre aux établissements scolaires ;
Assurer le contrôle physique des enseignants dans leurs milieux du travail ;
Apprêter les dossiers des établissements scolaires, bureaux gestionnaires et des agents à transmettre au Directeur provincial ;
Exploiter les rapports de paie, écoles, bureaux provenant des antennes et la mise à jour des situations des agents ou des enseignants.
- SERVICES PROVINCIAUX
a) Service statistique : Ils sont les collaborateurs du Directeur en matière statistique. Ils font les collectes des données statistiques concernant les écoles, les enseignants, bureaux gestionnaires.
b) Service Informatique : C’est le secrétariat technique du DINACOPE. Il sert à la conservation ou à la sauvegarde de la base des données de l’EPSP Lomami 2, à la saisie des documents administratifs et s’occupent de la correspondance par Internet et réceptionné les différents documents.
c) Service d’Archives : Elle est chargée à la sauvegarde des archives de DINACOPE par exemple les listings de paie.
d) Service de Comptabilité : Il est chargé de : Garder les frais de fonctionnements des écoles primaires pour permettre aux chefs d’établissements. Il s’occuper des problèmes de paie en cas d’omission des agents, bureau provincial ou antennes DINACOPE. Puis par la suite gère tous les cas qui ont trait à l’argent.
e) Service de Paie : Elle s’occupe de la paie
f) Service de contentieux : Il s’occupe
– De tous les dossiers litigieux provenant de nos antennes ;
– D’initier et faire le suivi des données juridiques ;
– De proposer des solutions aux problèmes du contentieux.
g) Service du Personnel : Il a pour rôle
– De diriger les services administratifs
– D’élaborer des ordres des missions
– De calculer et veuillez à la liquidation des frais des missions
– D’assurer les correspondances administratives.
h) Service radio phonie : Il s’occupe de la communication avec les différentes antennes
i) Service administrative : Il s’occupe de l’administration du service [Rapport du Bureau de la DINACOPE Provinciale 2024-2025].
II.3. ORGANIGRAMME DE LA DIRECTION PROVINCIALE DINACOPE/ LOMAMI 2
La direction provinciale DINACOPE/LOMAMI 2 est composée de :
– DIPRO : Directeur provincial
– PASS : Assistant Provincial
– OHUI : Huissier
– SSEN : Sentinelle
– SCHA : Chauffeur
– SDAC : Dactylographe DINACOPE – STRA : Travailleur DINACOPE
a) DIPRO : il est chargé de :
– Comptabilité, Gestion Personnel
– Chargé Archive, Collège des PASS
b) PASS : chargé de :
– Pair & Contentieux, Opération. Radio
– Chargé Statistique, Pass. Administration
– SCHA, SSEN, STRA, SDAC
– Intendant
c) OHUI – OPS
– Informaticien – Relation Publique
– Secrétariat.
Figure 1: Organigramme
III. CRITIQUE DE L’EXISTANT ET PROPOSITION DE SOLUTION
- ASPECT POSITIF
Le service provincial de la DINACOPE/Lomami 2 est doté d’une structure hiérarchique claire, avec des services spécialisés (informatique, paie, statistiques, contentieux, etc.) et une organisation rigoureuse. Certains membres du personnel sont motivés à accomplir leurs tâches, et les outils bureautiques élémentaires (ordinateurs, imprimantes) sont disponibles dans certains bureaux.
- ASPECT NEGATIF
Malgré cette organisation, la gestion des enseignants impayés reste manuelle, dispersée entre plusieurs services, et non centralisée. Cela entraîne :
des retards dans la transmission des dossiers,
des erreurs de traitement,
une absence de suivi précis de la régularisation des cas,
des enseignants oubliés ou traités en double,
et un manque total de traçabilité des décisions prises.
De plus, les données sont souvent stockées sur papier ou dans des fichiers Excel locaux, sans base de données partagée, ce qui complique la consolidation et la production de rapports fiables.
- ÉBAUCHE DES SOLUTIONS
a) SOLUTION MANUELLE AMELIOREE
Le chef de service pourrait mettre en place des cahiers de suivi physique pour les
cas d’enseignants impayés, avec vérification manuelle auprès des antennes DINACOPE et des établissements. Les rapports de situation seraient ensuite synthétisés trimestriellement.
AVANTAGE :
Maintien de la méthode actuelle, facile à comprendre.
Contrôle physique direct par le chef de service.
INCONVENIENTS :
Lenteur de traitement.
Risque élevé d’erreurs, de pertes de documents. Absence de traçabilité automatisée.
Non visualisation des cas en temps réel.
- SOLUTION INFORMATIQUE PROPOSEE
Pour pallier ces limites, il est recommandé de mettre en place un système informatisé de gestion des enseignants impayés. Ce système serait accessible en ligne et comporterait :
Un espace administrateur (ajout/modification des enseignants impayés),
Un tableau de bord de suivi des paiements et statuts,
Un système de messagerie pour réclamations,
Une base de données centralisée MySQL,
Des rapports automatiques par école, zone, période, etc.
AVANTAGES DE LA SOLUTION INFORMATIQUE
Meilleure traçabilité des cas enregistrés et traités,
Génération rapide de rapports statistiques,
Accès direct et sécurisé aux données par les agents autorisés,
Gain de temps et réduction des erreurs humaines,
Communication facilitée entre les antennes et la direction provinciale [Rapport du Bureau de la DINACOPE Provinciale 2024-2025].
CONCLUSION : CHOIX DE LA MEILLEURE SOLUTION
La solution informatique s’impose comme la meilleure option. Elle permet non seulement de centraliser et sécuriser les données, mais aussi de répondre de manière efficace à la problématique sociale et administrative des enseignants impayés, tout en modernisant le service
DINACOPE.
CHAPITRE III : MODELISATION AVEC UML
III.1. INTRODUCTION
Modélisation est la conception d’un modèle. Selon son objectif et les moyens utilisés. En informatique, on parle de modélisation des données pour désigner une étape de construction d’un système d’information.
Dans le présent chapitre il sera question de présenter le langage de modélisation utilisé ainsi que ses fonctionnalités et son bienfondé dans le présent travail. Comme démarche utilisée, on se servira de la démarche de processus unifié [MBI 2014].
Ce projet vise à concevoir un système informatisé capable de gérer efficacement les enseignants impayés dans un établissement ou une entité éducative (ministère, inspection, école, etc.). Il s’agit de recenser, suivre et produire des rapports fiables sur les enseignants concernés afin d’appuyer les démarches administratives et financières pour leur régularisation.
En utilisant la modélisation UML (Unified Modeling Language), vise à améliorer l’efficacité et la transparence dans le suivi des rémunérations.
III.2. PROCESSUS UNIFIE
Est une méthodologie de développement logiciel qui peut être utilisée pour la mise en place d’un système informatisé de gestion des enseignants impayés. C’est une méthode itérative, incrémentale et centrée sur les cas d’utilisation. Elle guide le projet depuis l’analyse des besoins jusqu’à la mise en production du système.
Les 4 phases du Processus Unifié appliquées à notre système :
PHASE OBJECTIF APPLICATION AU SYSTEME DE GESTION DES ENSEIGNANTS IMPAYES
- Phase d’inception Définir la vision, les objectifs du projet, les principaux cas d’utilisation, et les risques • Identifier les besoins : Pourquoi les enseignants ne sont pas payés ?
• Déterminer les utilisateurs du système (DRH, direction financière, enseignants, etc.)
• Élaborer les premiers cas d’utilisation (enregistrer enseignant, signaler impayé, générer rapport, etc.) - Phase d’élaboration Analyser, concevoir l’architecture et valider les exigences • Modéliser le système avec UML : diagrammes de cas d’utilisation, classes, séquence, etc. • Déterminer les modules : gestion des enseignants, états de paiement, génération de rapports • Identifier les contraintes techniques (base de données, réseau, accès sécurisé, etc.)
- Phase de construction Développer et tester le système • Implémenter les fonctionnalités : formulaire d’enregistrement, tableau de bord de suivi des
PHASE OBJECTIF APPLICATION AU SYSTEME DE GESTION DES ENSEIGNANTS IMPAYES
paiements
• Tester chaque module (tests unitaires, tests fonctionnels)
• Intégration progressive des composants - Phase de transition Déployer le système, former les utilisateurs, corriger les derniers bugs • Déploiement dans les écoles ou ministères concernés
• Formation des utilisateurs (agents administratifs, enseignants)
• Recueil de retours d’expérience et ajustements
Tableau 1: Les 4 phases du Processus Unifié
AVANTAGES DU PROCESSUS UNIFIE POUR CE PROJET
Bonne maîtrise du risque : (détection des problèmes dès les premières phases)
Itératif : possibilité d’améliorer à chaque cycle
Flexible : on peut adapter les priorités selon les besoins (ex : traiter d’abord les enseignants du primaire)
Basé sur les cas d’utilisation : facilite la compréhension des fonctionnalités réelles.
Exemples de livrables à chaque étape
PHASE LIVRABLES ATTENDUS
Inception Cahier des charges, Diagramme de cas d’utilisation, Liste des acteurs
Élaboration Diagrammes UML (classes, séquence), Architecture du système, Prototypes
Construction Code source, Interfaces utilisateur, Résultats de tests
Transition Manuel utilisateur, Formation, Rapport de validation, Système installé
Tableau 2: Exemples de livrables à chaque étape
CAHIER DES CHARGES / BESOINS FONCTIONNELS
Enregistrement des enseignants impayés
Suivi des démarches administratives
Génération de rapports (par école, zone, ancienneté, etc.)
Consultation des informations par les responsables
Historique de traitement des cas
III.3. A QUOI SERT UML
UML (Unified Modeling Language) sert à modéliser visuellement le système que tu veux développer. Dans le cas de la mise en place d’un système informatisé pour la gestion des enseignants impayés, UML te permet de représenter clairement les besoins, les processus, les utilisateurs, les données et les interactions avant même de coder quoi que ce soit.
POURQUOI UTILISER UML POUR CE PROJET ?
Voici à quoi sert UML dans ce contexte :
OBJECTIF RÔLE D’UML
Comprendre le système à développer UML permet de représenter les fonctionnalités attendues (ex : signaler un impayé, générer un rapport, consulter l’état de paiement d’un enseignant, etc.)
Identifier les acteurs On utilise le diagramme des cas d’utilisation pour identifier qui fait quoi (enseignant, DRH, administration, comptable, etc.)
Concevoir la structure du système Le diagramme de classes montre comment les données sont organisées (enseignant, paiement, mois, statut, etc.)
Visualiser les interactions Avec le diagramme de séquence, on illustre comment les objets communiquent pour accomplir une tâche (ex : « générer un rapport de paiement mensuel »)
Analyser les flux de travail Le diagramme d’activités permet de décrire les étapes d’un processus (ex : traitement d’un cas d’impayé)
Préparer le développement UML aide les développeurs à bien comprendre ce qu’ils doivent coder. Il sert de plan technique clair
Tableau 3: Rôle UML
III.4. LES DIAGRAMMES UML
Les diagrammes en UML (Unified Modeling Language) sont des représentations graphiques qui permettent de modéliser un système logiciel sous différents angles : fonctionnel, structurel, comportemental et technique. Ils aident à comprendre, concevoir, documenter et communiquer le fonctionnement du système.
Les 14 principaux diagrammes UML (classés en 2 grandes familles)
a. DIAGRAMMES STRUCTURELS (REPRESENTENT LA STATIQUE DU SYSTEME)
DIAGRAMME RÔLE PRINCIPAL EXEMPLE DANS LA GESTION DES ENSEIGNANTS IMPAYÉS
Diagramme de classes Montre les entités (objets), leurs attributs, méthodes et relations Représenter les classes :
Enseignant, Paiement, Mois, Statut
Diagramme d’objets Instance réelle d’un diagramme de classes à un instant donné Montrer un exemple d’enseignant avec son paiement en janvier
Diagramme de composants Visualise les modules du système et leurs interactions Interface utilisateur, base de données, module de génération de rapport
Diagramme de déploiement Représente la disposition physique du système (serveurs, machines, etc.) Montrer comment le système est déployé : poste DRH ↔ serveur central
Diagramme de packages Regroupe les classes en soussystèmes logiques Séparer les modules : Gestion des enseignants, des paiements, des rapports
Diagramme de structure composite Décrit la structure interne d’une classe ou d’un composant complexe Visualiser l’organisation interne d’un composant comme « Suivi des paiements »
Tableau 4: Diagrammes structurels
b. DIAGRAMMES COMPORTEMENTAUX (REPRESENTENT LA DYNAMIQUE DU SYSTEME)
DIAGRAMME RÔLE PRINCIPAL EXEMPLE DANS TON SYSTÈME
Diagramme de cas
d’utilisation Montre les interactions entre les utilisateurs (acteurs) et le
système « Enregistrer un enseignant », « Signaler un impayé », « Générer un rapport »
Diagramme de séquence Montre les échanges de messages dans le temps entre objets Comment un enseignant demande son état de paiement et reçoit la réponse
Diagramme de communication Alternative au diagramme de séquence, mais en mettant l’accent sur les connexions Idem que le diagramme de séquence, mais en réseau
Diagramme
d’activités Décrit les flux de travail ou processus métier Déroulement du traitement d’un dossier impayé
DIAGRAMME RÔLE PRINCIPAL EXEMPLE DANS TON SYSTÈME
Diagramme d’étatstransitions Montre les états d’un objet et ses transitions État d’un paiement : « En attente », « Approuvé », « Payé »
Diagramme de temps Montre comment les objets changent au cours du temps Suivi des paiements mensuels pour un enseignant
Diagramme
d’interaction globale Combine plusieurs séquences pour décrire un scénario complexe Processus complet de gestion des enseignants dans une école
Tableau 5: Diagrammes comportementaux
Pour le présent travail va tout simplement se servir de quatre diagrammes parmi les quatorze. Il s’agit de diagramme de classes, le diagramme de cas d’utilisation, le diagramme de séquence et celui d’activités car UML n’étant pas une méthode, leur utilisation est laissée à l’appréciation de chacun. Même si le diagramme de classes est généralement considéré comme l’élément central d’UML ; des méthodologies, telles que le processus Unifié, axent l’analyse en tout premier lieu sur les diagrammes de cas d’utilisation (Use case).
III.5. PRESENTATION DES DIAGRAMMES
III.5.1. DIAGRAMME DE CAS D’UTILISATION (USE CASE)
Le diagramme de cas d’utilise se compose de 3 éléments principaux :
a. Un acteur : c’est l’idéalisation d’un rôle joué par une personne externe, un processus ou une chose qui interagit avec un système. Il se représente par un petit bonhomme avec son nom inscrit dessous.
b. Un cas d’utilisation : c’est une unité cohérente représentant une fonctionnalité visible de l’extérieur. Il réalise un service de bout en bout, avec un déclenchement, un déroulement et une fin, pour l’acteur qui l’initie. Un cas d’utilisation modélise donc un service rendu par le système, sans imposer le mode de réalisation de ce service. Il représente par une ellipse contenant le nom du cas (un verbe à l’infinitif), et optionnellement, au-dessus du nom, un stéréotype.
c. Les relations : trois types de relations sont pris en charge par la norme UML et sont graphiquement représentées par des types particuliers de ces relations. Les relations indiquent que le cas d’utilisation source présente les mêmes conditions d’exécution que le cas issu. Une relation simple entre un acteur et une utilisation est un trait simple.
- PRESENTATION DE NOTRE CAS D’UTILISATION
Figure 2:Diagramme de cas d’utilisation
Ces tableaux doivent décrire les cas d’utilisation les plus importants de notre système et leurs acteurs.
Tableau 6 : Fiche descriptive du visiteur
Acteur n° 1 Acteurs Visiteur
Type Acteur externe
Flots d’informations Scénarios :
- Consulter les informations du site
- Envoyer les messages à la DINACOPE Provinciale
Conditions
Tableau 7: Fiche descriptive de l’enseignant
Acteur n° 2 Acteurs Enseignant
Type Acteur externe
Flots d’informations Scénarios :
- Consulter les informations du site
- Envoyer les messages à la DINACOPE Provinciale
- Voir la liste des enseignants impayés et leurs statuts
Conditions Pour voir ou consulter la liste des enseignants impayés et leurs statuts, l’enseignant doit s’authentifier avec le nom utilisateur et mot de passe.
Tableau 8 : Fiche descriptive du chef DINACOPE
Acteur n° 4 Acteurs Chef DINACOPE
Type Acteur Interne
Flots d’informations Scénarios :
- Consulter les informations du site
- Se connecter
- Voir (lire) les messages envoyés par les enseignants et chefs d’établissements
- Voir la liste des enseignants impayés et leurs statuts
Conditions Pour qu’un chef DINACOPE puisse se connecter au système, il doit avoir un nom utilisateur et un mot de passe
Tableau 9: Fiche descriptive de l’Administrateur
Acteur n° 5 Acteurs Administrateur
Type Acteur Interne
Flots d’informations Scénarios :
- Consulter les informations du site
- Se connecter au système
- Vérifier les nouveaux messages – Ajouter un enseignant
- Modifier le statut d’un enseignant – Ajouter une école
- Actualiser les contenus du site
Conditions Pour se connecter à la page d’administrative, l’administrateur doit utiliser les informations d’authentification pour les admin.
III.5.2. DIAGRAMMES DE SEQUENCES
Les diagrammes de séquences donnent en détail la façon dont les opérations faites au système sont effectuées.
III.5.2.1. DIAGRAMME DE SEQUENCE POUR L’ENSEIGNANT
Ce diagramme représente la connexion de l’enseignant au système, pour y arriver, il doit saisir le nom utilisateur et le mot de passe, puis par la suite cliquer sur « Connexion ». Les informations saisies sont soumises au système pour afin vérifier l’authenticité et établir la connexion ou rejeter.
Figure 3: diagramme de séquence pour la connexion d’un enseignant
III.5.2.2. DIAGRAMME DE SEQUENCE POUR LE CHEF DINACOPE
Celui-ci représente la connexion du chef DINACOPE, il aura à saisir son nom et son mot de passe, puis cliquer sur « CONNEXION ».
Figure 4: le diagramme de séquence pour la connexion d’un chef DINACOPE
III.5.2.3. DIAGRAMME DE SEQUENCE POUR L’AJOUT D’UN ENSEIGNANT
L’ajout d’un enseignant est fait par l’administrateur du site, qui soit un agent de la
DINACOPE provinciale de LOMAMI 2. Ce cas permet à un administrateur d’ajouter, par l’instruction du Chef DINACOPE, l’ajout d’un nouvel enseignant impayé dans le système. Pour ce faire, l’administrateur doit s’authentifier avec son nom et mot de passe, puis par la suite se connecter à la page d’administration où il fera face à 4 menu notamment : ajout d’un enseignant, voir les enseignants, ajout d’une école, voir les messages. Pour ce cas, il doit cliquer sur « ajout d’un enseignant. Le formulaire de l’ajout d’un enseignant s’affiche avec les informations recommandées de tout enseignant impayé. Lors de l’ajout, les conditions suivantes sont vérifiées : remplir tous les champs, n’avoir pas saisi le mot et les informations existants dans le système.
Figure 5: le diagramme de séquence pour l’ajout d’un nouvel enseignant
III.5.2.4. Diagramme de séquence pour l’ajout d’une école
Ce diagramme montre comment une école est ajoutée dans le système. Ce cas permet à l’administrateur d’ajouter une école, car elle constitue une information importante pour la connexion d’un enseignant et chef d’établissement dans le système. Dans ce formulaire, l’administrateur après la saisie des informations sur l’école, attribue aussi un nom d’utilisateur et un mot de passe.
Figure 6: le diagramme de séquence pour l’ajout d’une école
III.5.2.5. DIAGRAMME DE SEQUENCE POUR L’ENVOI DU MESSAGE
L’envoi du message dans le système. Ce cas permet aux acteurs comme : visiteur, enseignant et chef d’établissement de pouvoir contacter le chef de la DINACOPE provinciale de Lomami. Pour ce faire, l’acteur doit lancer le formulaire, puis par la suite saisir son profil et message à envoyer.
III.5.3. DIAGRAMMES D’ACTIVITES
Ce diagramme va présenter les traitements réalisés par le système. Il décrit le comportement lié à une activité donnée. Pour ce système, nous allons détailler les cas suivants, nécessaires du système :
– la connexion enseignant ;
– connexion chef d’établissement ;
– connexion chef DINACOPE ;
– ajout d’un enseignant ;
– ajout d’une école ;
– envoi d’un message.
III.5.3.1. DIAGRAMME D’ACTIVITES POUR LA CONNEXION DE L’ENSEIGNANT
Les activités de la connexion de l’enseignant se présentent de la manière suivante :
Figure 8: diagramme d’activités pour la connexion de l’enseignant
III.5.3.2. DIAGRAMME D’ACTIVITES POUR LA CONNEXION DU CHEF DINACOPE
Les activités de la connexion du chef DINACOPE se présentent de la manière suivante :
Figure 9:Diagramme d’activités pour la connexion du chef DINACOPE
III.5.3.3. DIAGRAMME D’ACTIVITES POUR L’AJOUT D’UN ENSEIGNANT
Les activités mises en œuvre pour l’ajout d’un enseignant dans le système se présentent comme suites :
Figure 10: Diagramme d’activités pour l’ajout d’un enseignant
III.5.3.4. DIAGRAMME D’ACTIVITES POUR L’AJOUT D’UNE ECOLE
Les activités mises en œuvre pour l’ajout d’une nouvelle école dans le système sont les suivantes :
III.5.3.5. DIAGRAMME D’ACTIVITES POUR L’ENVOI DE MESSAGE
Pour envoyer le message à la DINACOPE provinciale, le système propose les activités suivantes :
Figure 12: Diagramme d’activités pour l’envoi de message
III.5.4. LE DIAGRAMME DE CLASSE
Le diagramme des classes, un schéma utilisé pour présenter les classes et les interfaces des systèmes avec les différentes relations entre ces classes.
Pour notre cas, le diagramme de classe se présente de la manière suivante :
Figure 13: diagramme de classe
III.5.5. LE DIAGRAMME DE COMPOSANTS
Le diagramme de composants ci-dessous présente l’architecture logique de notre application web de gestion des enseignants impayés dans la province éducationnelle de LOMAMI 2. Ce schéma illustre les différents modules fonctionnels qui composent le système, leurs interactions ainsi que leur relation avec la base de données centrale. Chaque composant représente une unité fonctionnelle indépendante, développée pour accomplir une tâche spécifique dans l’écosystème du système global.
L’architecture du système suit une approche modulaire et orientée services, où chaque module remplit un rôle précis. Le système repose sur une interface utilisateur Web centralisée qui communique avec différents modules métiers via des appels internes. L’ensemble des modules interagit avec une base de données relationnelle (MySQL) qui centralise l’ensemble des informations (enseignants, écoles, utilisateurs, messages, etc.).
DESCRIPTION DES COMPOSANTS
Interface Utilisateur (Web UI) : Il s’agit des interfaces accessibles aux utilisateurs finaux (enseignants, administrateurs, chefs DINACOPE, visiteurs). Il permet d’interagir avec toutes les fonctionnalités du système via un navigateur web. Fonctions principales : Accès aux formulaires de connexion, Consultation des listes d’enseignants impayés, Envoi de messages, Tableau de bord administrateur.
Module Authentification : Il permet d’identifier les utilisateurs à l’aide de leur nom d’utilisateur et mot de passe, puis de leur attribuer des droits selon leur rôle (administrateur, enseignant, etc.). Fonctions principales : Vérification des identifiants, Redirection vers l’espace correspondant, Gestion des sessions utilisateurs.
Module Gestion Enseignants : Ce module permet à l’administrateur d’ajouter, modifier ou supprimer les enseignants impayés. Il est essentiel au cœur du système car il traite directement la problématique du non-paiement. Fonctions principales : Enregistrement des enseignants impayés, Mise à jour du statut de paiement,
Consultation des enseignants par filtre (école, mois, etc.)
Module Gestion Écoles : Ce module assure la gestion des établissements scolaires enregistrés dans le système. Il permet de lier chaque enseignant à une école spécifique et de créer des identifiants pour les utilisateurs liés à cette école. Fonctions principales : Enregistrement des écoles, Attribution de logins par école, Visualisation des écoles par région ou zone
Module Messagerie : Ce composant offre un système de communication interne entre les utilisateurs (enseignants, visiteurs) et le service DINACOPE. Il centralise toutes les plaintes, questions ou suggestions envoyées via le formulaire de contact. Fonctions principales : Envoi de message au chef DINACOPE, Consultation des messages reçus, Suivi et traitement des réclamations.
Base de Données (MySQL) : C’est le composant fondamental du système, qui assure le stockage, la sécurité et la persistance des données. Tous les modules accèdent à la base de données pour lire, écrire ou mettre à jour les informations. les données stockées sont : Comptes utilisateurs, Informations sur les enseignants et écoles, Messages et communications.
Figure 14: Diagramme de Composants
CHAPITRE IV : IMPLEMENTATION DU SITE WEB
Dans ce quatrième et dernier chapitre, nous allons présenter l’ensemble des outils matériels et logiciels utilisés pour la conception de notre système, ainsi que les interfaces principales qui composent notre application web [site web dynamique].
I. PRESENTATION DES OUTILS
- ENVIRONNEMENT HARDWARE
Ordinateur : LENOVO
Processeur Intel(R) Cèlerons(R) CPU 1000M @ 1.80GHz, 1800 MHz, 2 cœur(s), 2 processeur(s) logique(s) RAM : 8 GO
Smartphone : Techno Spark10c
- ENVIRONNEMENT SOFTWARE
2.1. HTML (HyperText Markup Language)
Description: Langage standard de balisage utilisé pour structurer le contenu des pages web.
Rôle : Il a permis de créer l’ossature des pages de l’application, comme les formulaires de connexion, d’ajout d’enseignants, et les interfaces de consultation.
2.2. CSS (Cascading Style Sheets)
Description : Langage de style utilisé pour la mise en forme visuelle des documents HTML (couleurs, polices, mise en page, etc.).
Rôle : Il a servi à styliser les interfaces utilisateur pour les rendre plus agréables, accessibles et professionnelles.
2.3. JavaScript
Description : Langage de programmation côté client, utilisé pour rendre les pages web interactives.
Rôle : Il a été utilisé pour valider les formulaires, améliorer l’interactivité (ex. : alertes, messages dynamiques) et rendre l’interface plus fluide.
2.4. PHP (Hypertext Preprocessor)
Description : Langage de script côté serveur, utilisé pour développer des applications web dynamiques.
Rôle : Il a été le moteur logique de l’application. PHP gère l’authentification des utilisateurs, la communication avec la base de données, le traitement des formulaires, etc.
2.5. MySQL
Description : Système de gestion de base de données relationnelle (SGBD), open source, souvent utilisé avec PHP.
Rôle : Il a servi à stocker toutes les données du système : informations sur les enseignants, écoles, messages, comptes utilisateurs, etc.
2.6. SQL (Structured Query Language)
Description : Langage de requête permettant d’interagir avec des bases de données relationnelles.
Rôle : Il a été utilisé pour écrire les requêtes permettant d’insérer, lire, mettre à jour ou supprimer les données dans la base MySQL.
2.7. phpMyAdmin
Description : Interface web qui permet de gérer des bases de données MySQL de manière graphique.
Rôle : Il a été utilisé pour créer la base de données, gérer les tables, exécuter les requêtes SQL, et surveiller les opérations de manière conviviale sans ligne de commande.
2.8. XAMPP
Description : Environnement de développement local regroupant Apache, MySQL, PHP et Perl.
Rôle : Il a permis de simuler un serveur local pour développer et tester le système sans connexion internet. Apache a été utilisé comme serveur HTTP, et MySQL comme moteur de base de données.
2.9. Apache
Description: Serveur HTTP open source, inclus dans XAMPP, utilisé pour héberger des applications web.
Rôle : Il a servi à exécuter localement l’application PHP et à répondre aux requêtes du navigateur.
2.10. Visual Studio Code (VS Code)
Description : Éditeur de code source léger et puissant, avec de nombreuses extensions.
- Rôle : Il a été utilisé comme environnement de développement principal pour écrire, organiser et gérer le code HTML, CSS, JavaScript et PHP du projet [https://www.mysql.com/ – Site officiel du système de gestion de base de données MySQL]
II. DEMONSTRATIONS DES INTERFACES :
Cette partie dénombre la présentation des Scénarios applicatifs de l’application. Nous allons présenter dans ce qui suit, les imprimes-écran des principales interfaces réalisées dans notre site web.
Les interfaces qui seront présentées sont les suivantes :
Interface Bienvenue
Interface Accueil
Interface Actualités
Interface Connexion
Interface Enseignants
Interface Dashboard ou Administrateur
Interface Ajout d’un enseignant
Interface Ajout d’une école
Interface Message reçus Interface Contact
Interface Galerie Média.
II.1. Interface Bienvenue
Vision smartphone Vision PC/Tablette Figure 15: Interface Bienvenue
II.2. Interface Accueil
Vision smartphone Vision PC/Tablette Figure 16: Interface Accueil
II.3. Interface Actualités
Vision smartphone Vision PC/Tablette II.4. Interface Connexion
Vision smartphone Vision PC/Tablette II.5. Interface Enseignants
Vision smartphone Vision PC/Tablette II.6. Interface Dashboard (administrateur)
Vision smartphone Vision PC/Tablette Figure 20: Interface administrateur ou Dashboard
II.7. Interface Ajout d’un enseignant
Vision smartphone Vision PC/Tablette II.8. Interface Ajout d’une école
Vision smartphone Vision PC/Tablette II.9. Interface Messages reçus
Vision smartphone Vision PC/Tablette II.10. Interface Contact (Message)
Vision smartphone Vision PC/Tablette II.11. Interface Galerie Média
Vision smartphone Vision PC/Tablette CONCLUSION GENERALE
Au terme de ce travail, nous avons pu démontrer que la problématique des enseignants impayés dans la province éducationnelle de LOMAMI 2 constitue un enjeu à la fois administratif, humain et social. Le décalage entre la reconnaissance officielle des enseignants par l’État et l’absence de rémunération régulière traduit une faiblesse systémique dans la gestion des effectifs et des salaires au sein du secteur éducatif congolais.
En réponse à cette problématique, nous avons conçu et proposé un système informatisé de gestion des enseignants impayés. Ce système, développé à l’aide des technologies web
(HTML, PHP, JavaScript et MySQL), permet d’enregistrer, de suivre et de produire des rapports fiables sur la situation administrative des enseignants. L’utilisation du langage de modélisation UML (diagrammes de cas d’utilisation, de classes, de séquence et d’activités) nous a permis de structurer efficacement les différentes fonctionnalités du système.
Ce travail s’inscrit dans un triple perspectif :
Pratique, en apportant une solution opérationnelle à une réalité persistante ;
Scientifique, en mettant en œuvre les principes de la conception de systèmes informatiques ;
Sociétale, en contribuant à la transparence, à l’équité et à la bonne gouvernance dans le secteur éducatif.
Cependant, ce projet n’est qu’une première étape. Des perspectives d’amélioration peuvent être envisagées, notamment l’intégration d’une couche mobile pour un accès à distance, la synchronisation avec des bases de données nationales comme celle du SECOPE, ou encore l’ajout d’un module de génération automatique de rapports statistiques.
Nous recommandons vivement aux responsables éducatifs, aux autorités administratives ainsi qu’aux développeurs locaux de s’approprier cette solution et de la faire évoluer afin qu’elle serve de modèle pour d’autres provinces et secteurs confrontés à des défis similaires.
Ainsi, ce mémoire aura permis de démontrer que l’informatisation ciblée des processus administratifs dans l’enseignement peut contribuer de manière significative à la résolution des dysfonctionnements chroniques, en particulier dans les zones défavorisées.
BIBLIOGRAPHIES
I. Ouvrages
- Laudon, K. C., & Laudon, J. P. (2016). Systèmes d’information de gestion. Pearson Education France.
- Date, C. J. (2012). Introduction aux systèmes de bases de données. Pearson.
- Pressman, R. S. (2013). Ingénierie du logiciel – Une approche pratique. McGrawHill.
- Sommerville, I. (2011). Ingénierie des systèmes logiciels. Éditions Pearson.
- Booch, G., Rumbaugh, J., & Jacobson, I. (2005). Le langage UML – Guide de l’utilisateur. Eyrolles.
II. NOTES DE COURS - [Professeur Apollinaire CIBAKA CIKONGO], Notes de Cours d’Initiation à la Recherche Scientifique, ISP/NGKA G2 Info,
- [CT Denis NTUMBA MULAMBA], Notes du cours d’Informatique Générale, G1 Informatique de Gestion, ISP/NGKA 2021
- [Stève NGELEKA MUSANGU], Cours de Techniques de banques de données, troisième Graduat Informatique de Gestion, ISP/NGKA 2021
- [Antoine ILUNGA LOMBE], Cours MAI 1 en deuxième Graduat Informatique de Gestion 2022
III. MEMOIRES ET TFC - [Steve NDULU 2015], Mise en place d’un système informatisé pour la gestion des enseignants impayés : cas du SECOPE Bandundu.
- [vive Kusakana 2016 ] Mise en place d’un système informatisé pour la gestion de la rémunération des enseignants dans une école : cas de l’Institut Ngolo Zabambuta à l’Université Pédagogique Nationale ‘’UPN’’
- [Muhindo Ngaingai Alphée 2019 ] La Modélisation informatique de la gestion des horaires des enseignants de l’enseignement supérieur et universitaire », cet article scientifique propose une approche basée sur une architecture client –serveur pour optimiser la gestion des paiements. Il a été écrit par à l’Institut Supérieur de Commerce de Beni.
- MUKENGE MUKENDI, Mise en place d’un système informatisé pour la gestion des enseignants impayés : cas du SECOPE, Mémoire de fin d’études, Université de Kinshasa, 2011.
IV. WEBOGRAPHIE - https://www.mysql.com/ – Site officiel du système de gestion de base de données MySQL.
- https://www.php.net/ – Documentation officielle du langage PHP.
- https://developer.mozilla.org/fr/ – Références HTML, CSS et JavaScript.
- https://uml-diagrams.org/ – Documentation sur les différents types de diagrammes UML.
- https://www.education.gouv.cd/ – Portail officiel de l’Enseignement primaire, secondaire et technique en RDC.
TABLE DES MATIERES
EPIGRAPHE ………………………………………………………………………………………………………………. I
DEDICACE ……………………………………………………………………………………………………………… III
SIGLES ET ABREVIATIONS ……………………………………………………………………………………. V
LISTE DES FIGURES ………………………………………………………………………………………………. VI
LISTE DES TABLEAUX …………………………………………………………………………………………. VII
RESUME ………………………………………………………………………………………………………………. VIII
CHAPITRE I. SYSTEMES D’INFORMATION ET BASES DE DONNEES ……………………. 5
I.1. SYSTEME D’INFORMATION ………………………………………………………………………….. 5
I.2. SYSTEME INFORMATIQUE ……………………………………………………………………………. 6
I.3. LES BASES DE DONNEES ET LE SYSTEME DE GESTION DE BASE DE
DONNEES ……………………………………………………………………………………………………………… 7
CHAPITRE II. PRESENTATION DU SERVICE DE CONTROLE ET DE LA PAIE DES
ENSEIGANTS DE LOMAMI 2 …………………………………………………………………………………. 13
II.1. PRESENTATION DE L’EXISTANT ……………………………………………………………….. 13
II.1.1. HISTORIQUE DE L’ENTREPRISE ……………………………………………………………. 13
II.1.2. APERÇU GEOGRAPHIQUE …………………………………………………………………….. 13
II.2. ORGANISATION STRUCTURO-FONCTIONNELLE DE DIRECTION
PROVINCIALE LOMAMI 2 ………………………………………………………………………………….. 14 a) STRUCTURE ORGANISATIONNELLE ………………………………………………………. 14
b) STRUCTURE FONCTIONNELLE ……………………………………………………………….. 14
II.3. ORGANIGRAMME DE LA DIRECTION PROVINCIALE DINACOPE/ LOMAMI 2
……………………………………………………………………………………………………………………………. 16
CHAPITRE III : MODELISATION AVEC UML ………………………………………………………… 20
III.1. INTRODUCTION ………………………………………………………………………………………… 20
III.2. PROCESSUS UNIFIE ……………………………………………………………………………………. 20
III.3. A QUOI SERT UML ……………………………………………………………………………………… 21
III.4. LES DIAGRAMMES UML ……………………………………………………………………………. 22
III.5. PRESENTATION DES DIAGRAMMES …………………………………………………………. 24
II.1. Interface Bienvenue 43
II.2. Interface Accueil 44
II.3. Interface Actualités 45
II.4. Interface Connexion 46
II.5. Interface Enseignants 47
II.6. Interface Dashboard (administrateur) 48
II.7. Interface Ajout d’un enseignant 49
II.8. Interface Ajout d’une école 50
II.9. Interface Messages reçus 51
II.10. Interface Contact (Message) 52
II.11. Interface Galerie Média 53
CONCLUSION GENERALE 54
BIBLIOGRAPHIES 55
I. Ouvrages 55
II. NOTES DE COURS 55
III. MEMOIRES ET TFC 55
IV. WEBOGRAPHIE 55
TABLE DES MATIERES 56
III.5.1. DIAGRAMME DE CAS D’UTILISATION (USE CASE) ……………………………. 24
III.5.2. DIAGRAMMES DE SEQUENCES …………………………………………………………… 27
III.5.3. DIAGRAMMES D’ACTIVITES ………………………………………………………………. 31
III.5.4. LE DIAGRAMME DE CLASSE ………………………………………………………………. 37
III.5.5. LE DIAGRAMME DE COMPOSANTS ……………………………………………………. 38
I. PRESENTATION DES OUTILS ……………………………………………………………………… 40
- ENVIRONNEMENT HARDWARE ……………………………………………………………… 40
- ENVIRONNEMENT SOFTWARE ……………………………………………………………….. 40
II. DEMONSTRATIONS DES INTERFACES : ………………………………………………….. 42
Naviguez vers congovirtuel
Naviguez vers Kinkiesse