ENSEIGNEMENT SUPERIEUR ET UNIVERSITAIRE

INSTITUT SUPERIEUR DE COMMERCE DE BUKAVU

ISC/BUKAVU

SECTION : SCIENCES DE GESTION COMMERCIALES ET ADMINISTRATIVES

OPTION : INFORMATIQUE DE GESTION

MISE EN PLACE D’UNE APPLICATION DE GESTION DE

PERCEPTION DE FRAIS SCOLAIRE DANS UNE ECOLE
SECONDAIRE : Cas de l’Institut Mwanga

Travail présenté et défendu en vue de l’obtention du

diplôme de Licence en informatique de gestion.
Par : ALBA ANJELANI Agnès
Directeur : Dr OMBENI CIRHUNGULA
Encadreur : CT MADJIDI ABDOU

Année académique : 2022-2023

 ~ ~

EPIGRAPHE

« l’Education est l’arme la plus puissante pour changer le monde. »

Nelson Mandela
 ~ ~

DEDICACES
A toi Dieu Tout Puissant créateur qui m’a guidé tout au long de ce cursus universitaire.

A vous mes très chers parents MATOKO Bernard et NYUMBAYALO Célestine pour le
sacrifice consenti.

A toi ma sœur ALBA NANI pour le soutien moral et financier.

A vous père AMATO Sébastien pour tout ce que vous m’avez souhaitée de bon, que Dieu Tout
Puissant vous bénisse.

A vous KASIMBIRA NAMBUZA Justin et mes petits frères MASTA MIKIWA, AMILCARE,
MARRTINI et la cadette Gorette pour votre amour filial.

ALBA ANJELANI Agnès

 ~ ~

REMERCIMENTS
Nous voici au terme de notre formation universitaire qui nous a fait beaucoup d’endurances et
d’encouragement de la part des certains personnes inoubliables.

Nous adressons nos remerciements à Dieu le Tout Puissant qui m’a gardé et protégé contre tout
sorte des maladies en me donnant le courage et l’endurance aux études durant ces cinq ans
passés à l’Institut Supérieur de Commerce de Bukavu ISC/Bukavu.

Nous saisissons de cette opportunité pour adresser nos remerciements aux autorités de
l’ISC/Bukavu et nos formateurs en général.

Au terme de ce travail, notre gratitude revient particulièrement et sincèrement au directeur

Prof. OMBENI CIRHUNGULA Olivier et à l’encadreur CT MADJID ABDOU qui en défit de
leurs multiples occupations ont acceptés sans gêne de diriger le présent travail.

Mes remerciements aussi à tous les bienfaiteurs qui nous ont prêtés main forte : Père Xavérien
Bernard Chibambo, papa KASHINDI et sa femme KANAKANA, MIVUMO, MIGOMBANO,
BIJENGE, USENI et sa femme.

A tous les camarades de l’auditoire ou de chambre, pour nos différentes interdépendances et

complémentarités : KAMAYUMBI PHILEMON Faustin, DANIEL MUKOMBE
et MADELEINE MUPENDA, AGNES, ANGE,DIVINE ,BISIMWA LUSAMBO Felix
Aux responsables de différentes structures de nous avoir accepté et encadré lors de nos
différents stages.

La bibliothèque de l’ISC/Bukavu et autre documentation sont plus reconnues.

ALABA ANJELANI Agnès

 ~ ~

SIGLES ET ABREVEATIONS

BD : Base de Données.
CSS: Cascading Style Sheet.
CELPA: Communauté des Eglises Libres Pentecôtistes en Afrique.
HTML: HyperText Markup Language.
LAN: Local Area Network.
MAN: Metropolitan Area Network.
MVC: Modèle-Vue-Contrôleur.
NTIC : Nouvelles Technologies de l’Information et de Communication.
OMT: Object Modeling Technology.
OOSE: Object Oriented Software Engineering.
PAN: Personal Area Network.
PDF : Portable Document File.
RLE: Réseau Local d'Entreprise ou Etendu.
SGBDR : Système de Gestion de Base de Données Relationnelles.
SGBDO : Système de Gestion de Base de Données Objet.
SGFSC : Système de Gestion Frais Scolaire.
SI : Système d’Information.
SQL : Structured Query Language.
2TUP: 2 Tracks Unified Process.
UML: Unified Modeling Language.
URL: Uniform Resource Locator
 ~ ~

TABLEAUX ET FIGURES
A. TABLEAUX
Tableau 1:Ressources Matériel..........................................................................................28
Tableau 2:Acteurs associés à leurs cas d’utilisations........................................................43
Tableau 3:Description textuelle du cas d’utilisation Authentification..............................47
Tableau 4:Description textuelle du cas d’utilisation Ajouter utilisateu............................49
Tableau 5:Description textuelle du cas d’utilisation Encoder des frais scolaires.............51
Tableau 6:Description textuelle du cas d’utilisation Enregistrement des dépenses..........52
Tableau 7:Représentation des cardinalités.........................................................................56
Tableau 8:Représentation des associations simples...........................................................57

B. FIGURES
Figure 1:Illustration d’un modèle......................................................................................13
Figure 2:Les vues en UML................................................................................................14
Figure 3:Organigramme de L’Institut Mwanga.................................................................23
Figure 4:Le livre de caisse.................................................................................................29
Figure 5: Carnet de centralisation des perceptions de frais scolaires...........................30
Figure 6:Schéma d’ensemble de la démarche UP..............................................................34
Figure 7:Schéma d’ensemble de la démarche UP7............................................................35
Figure 8:Méthode de développement en cascade...............................................................36
Figure 9:Situation de la capture des besoins techniques dans 2TUP.................................37
Figure 10:Architecture simple tiers....................................................................................37
Figure 11:Architecture client/serveur................................................................................38
Figure 12:Architecture 3 tiers............................................................................................38
Figure 13:Configuration matérielle du système.................................................................39
Figure 14:Etapes des processus dans 2UP.........................................................................40
Figure 15: Diagramme de cas d'utilisation.........................................................................45
Figure 16:passage de l’analyse à la conception.................................................................45
Figure 17:Diagramme des séquences « Authentification »...............................................48
Figure 18:Diagramme des séquences du scénario « Ajouter utilisateur ».........................50
Figure 19:Diagramme des séquences du scénario « Encoder frais scolaires payés...........51
Figure 20:Diagramme des séquences du scénario « Enregistrer dépenses ».....................53
Figure 21:Diagramme d’activités pour l’authentification..................................................54
Figure 22:Diagramme d’activités pour l’ajout d’un utilisateur.........................................54
Figure 23:Diagramme d’activités pour l’ensemble d’opérations qui se passent à la is.55
Figure 24:description complète d’une classe.....................................................................56
Figure 25:représentation du diagramme des classes..........................................................60
Figure 26:Modèle des données relationnelles optimisées..................................................62
Figure 27:Diagramme des composants..............................................................................62
Figure 28: Diagramme de déploiement..............................................................................63
Figure 29:Modèle-vue-contrôleur......................................................................................68
 ~ ~

0. INTRODUCTION GENERALE
0.1. Problématique
Cela fait au moins trois décennies que les ordinateurs ont envahi au monde professionnel de
beaucoup d’entre nous. Aujourd’hui, l’informatique s’introduit dans tous les domaines, y
compris celui de l’éducation. Avec l’apparition de nouveaux appareils tels que les tablettes,
les netbooks, les smartphones, et aussi l’accessibilité de l’Internet, les informations sont
disponibles partout et pour tous. L’importance de l’informatique est telle que les
établissements scolaires ont décidé de l’intégrer dans leur programme. Dans les universités,
les échanges entre professeurs et étudiants se font essentiellement par médias interposés.
Les devoirs sont traités en ligne, les échanges se font par email 1.

Depuis une dizaine d’années, les Etats africains tentent de se faire une place dans la société
de l’information. Ceci passe le plus souvent par des discours et des slogans qui mettent
Technologies de l’Information et de la Communication (TIC) au centre des débats et les
considèrent comme le véritable vecteur de développement. Seulement, en voulant éviter la
fracture numérique entre le nord et le sud, on oublie qu’une fracture interne pourrait naître
si le processus d’intégration de ces TIC n’est pas étudié de façon à répondre équitablement
à tous les besoins notamment éducatifs 2.

La République Démocratique du Congo en ce jour, on retrouve encore dans la plupart de

ses institutions publiques voire privées l’intégration de Technologie de l’Information (TIC)
fait encore défaut. Le personnel bien que qualifié et compètent, continue malgré tout de
commettre des erreurs dans l’exécutions de leurs tâches, cela est due à la non automations
des tâches dans la gestion de leurs activités.

La province du Sud-Kivu ne fait pas exception à ce problème où l’on observe l’existence

d’innombrables institutions Educatives et qui se disent modernes mais qui continuent
cependant à gérer les informations manuellement. Cela est à l’origine de beaucoup d’erreurs
qu’on trouve dans le domaine de l’éducation. C’est le cas de l’institut MWANGA qui gère
les informations relatives aux inscriptions de nouveaux candidats et au recouvrement de
frais scolaires.

1
SISSOKO-TOURE, Quelles utilisations des NTIC au lycée malien? Une comparaison public- privé,
Journées scientifiques 2 007 - Université Mohammed V – Souissi, p.1
2
Idem
 ~ ~

Le système manuel des inscriptions des élèves dans une institution éducative pose certains
défis liés à sa gestion. D’où certains élèves se retrouvent dans les classes où ils n’ont pas été
inscrits ; le gestionnaire éprouve des difficultés d’identifier l’effectif inscrit surtout pour les
humanités au niveau de troisième année ; le gestionnaire (préfet) doit faire saisir chaque
année les noms des élèves de son institution pour lui permettre d’élaborer les rapports.

Connaître le montant global de recettes journalières ou mensuelles en fonction de l’effectif

n’est pas assuré, la direction se contente alors de quelques recettes collectées par l’agent
percepteur ; un élève payant ses frais en plusieurs tranches risque de ne pas tout terminer et
étudier sans que le gestionnaire ne s’en rende compte. Ce dernier aura difficile d’identifier
qui a payé et qui n’a pas payé, conséquence de manque de précision des données 3.

Nous retrouvons certains de ces problèmes soulevés dans le paragraphe ci-haut dans la
gestion des payement des frais scolaires des élèves de l’Institut Mwanga, mais aussi le
difficulté de prouver un payement rapidement et facilement ; les erreurs de calculs qui
occasionnent souvent les surcharge et les ratures sur les documents utilisés, cela occasionne
un manque de confiance entre agent ; la lenteur dans la recherche surtout pour ce qui est de
la traçabilité d’un élève ayant étudier à l’Institut MWANGA.
De ce qui précède, la question suivante mérite une attention particulière :
 Un système informatique adapté à l’Institut MWANGA, de gestion et du suivi de la
perception des frais scolaires payés par les élèves faciliterait-elle au service chargé de la
perception de dégager à un temps réduit les différentes statistiques de perception de
frais ?
0.2. Hypothèses
Il est à noter que l’hypothèse est définie comme étant une réponse provisoire à la question
de recherche posée dans la problématique. Eu égard à ce qui précède, l’hypothèse suivante a
été émise :
 La mise en place d’un système informatique adapté à l’Institut Mwanga de gestion et du
suivi de la perception des frais scolaires payés par les élèves faciliterait au service chargé
de la perception de dégager à un temps réduit les différentes statistiques de perception de
frais.

3
SISSOKO-TOURE, Quelles utilisations des NTIC au lycée malien? Une comparaison public- privé,
Journées scientifiques 2 007 - Université Mohammed V – Souissi, p.8
 ~ ~

0.3. Objectifs du travail

0.4. Objectif principal

L’objectif principal dans le présent travail est d’arriver à mettre en place un système
informatique qui prendre en charge toutes les opérations relatives au paiement de frais
scolaire effectué par les élèves de l’institut MWANGA.
0.4.1. Les spécifiques objectifs
Le présent travail a pour objectifs spécifiques :

 Faciliter la production automatique des documents comptables et financiers,

 Assurer la conservation sécurisée des données relatives aux frais scolaires,
 Réduire la perte des documents justificatifs d’un paiement,
 Améliorer et enrayer les erreurs de calculs lors de paiements de frais scolaires.

0.5. Les méthodes et techniques utilisées

0.5.1. Les méthodes utilisées
Une méthode étant un ensemble d’opérations intellectuelles par lesquelles une branche
cherche à établir les vérités qu’elle poursuit, les démontre et les vérifie 4.
 La méthode structuro-fonctionnelle : elle nous a permis de faire connaissance de la
structure organisationnelle de l’institut MWANGA et le fonctionnement de son
service des finances particulièrement.
 La méthode UP (Processus Unifié) : Cette méthode (de conception orientée objet)
nous a permis de capturer les besoins fonctionnels, décrivant les cas d’utilisation
techniques et les besoins de réalisation et conception de l’application. Grâce aux
formalismes du langage de modélisation UML, nous présenterons l’ossature et les
différentes vues architecturales de l’application informatique.

0.5.2. Les Techniques utilisées

Une technique est l’ensemble de procédés dont le but est de parvenir à un résultat donné, que
ce soit en ce qui concerne la science, la technologie, l’art ou n’importe quel autre domaine.

Dans la présente étude, les techniques suivantes ont été utilisées pour la récolte de données :
1. La technique d’interview : elle nous a permis de recueillir les données dont nous
avions besoin afin d’avoir un bon moyen pour s’assurer de la nécessité d’informatiser.
2. La technique d’observation : elle nous a permis de nous rendre compte de la réalité
au suivi de paiement relatif aux frais scolaires et d’appréhender sa gestion.

4
Prof TSHUNDOLELA G, Cours d’initiation à la recherche scientifique, G2 IG, ISP/BUKAVU, 2013-2014
 ~ ~

3. La technique documentaire : nous a permis d’entrer en contact avec certaine

manuelle scientifique en rapport avec ce sujet, des ouvrages en matière de gestion,
informatique et bien d’autres.

0.6. Choix et intérêts du sujet

En se basant sur les difficultés auxquelles s’heurtent nos institutions éducatives, surtout les
écoles secondaires de notre pays en général, particulièrement l’institut MWANGA se
trouvant dans la ville d’UVIRA au Sud-Kivu dans la manière de gérer les informations liées
à la perception de frais scolaires, nous avons pensé mettre en place un système
d’information informatisé ; qui permettra à cette institution de palier tant soit peu aux
problèmes que causent la gestion manuelle qu’elle continue à utiliser jusqu’à présent

0.6.1. Intérêt scientifique

Le présent travail est conçu avec l’objectif de vouloir laisser une trace dans la science afin
de servir de référence aux futurs chercheurs qui auront le désir d’apporter leur contribution
dans ce domaine.

0.6.2. Intérêt de l’institution

A la fin de ce travail, notre institution d’accueil pourra bénéficier d’une application capable
de résoudre les problèmes causés par la gestion manuelle des informations liées à la
perception de frais scolaires.

0.6.3. Intérêt personnel

Personnellement nous avons opté de travailler dans ce domaine pour essayer de corriger tant
soit peu les lacunes se trouvant dans le système éducatif dans notre pays en général, en
particulier celui de l’institut MWANGA, mais aussi et surtout tester nos compétences dans
la recherche.

0.7. Délimitation du sujet

Etant donné que tout travail scientifique se délimite dans le temps et dans un espace donné,
le nôtre se restreint au sein de l’Institut MWANGA/UVIRA plus précisément dans les
services de finances et s’intéressera aux informations de la période allant de l’année 2022 à
2023, période caractérisée par l’afflux massif des élèves.

0.8. Subdivision du travail

 ~ ~

Hormis l’introduction et la conclusion, le présent travail est subdivisé en quatre chapitres, à

savoir :
 Le premier chapitre est intitulé : Revue de la littérature. Il donnera un aperçu global sur
les théories cadrant avec le sujet ainsi que l’état de la question.
 Le deuxième chapitre portera sur : L’étude du milieu et l’analyse du système existant.
Dans cette partie du travail, il sera question de décrire l’Institut Mwanga dans ses
différents aspects ainsi que de faire une étude approfondie de l’existant.
 Le troisième chapitre est consacré à la : Conception du nouveau système. Ici nous
présenterons quelques méthodes utilisées en informatique, dans lesquelles nous ferons le
choix d’une méthode qui nous permettra de mettre en place un nouveau système
d’information.
 Le quatrième chapitre sera consacré à la : Réalisation de l’application. Dans ce dernier
chapitre, il sera question de présenter les différents outils (matériels et logiciels) qui nous
ont permis à mettre en place l’application ainsi que le guide utilisateur.

0.9. DIFFICULTES RENCONTREES

Loin d’être une simple dissertation, nous avons rencontré les difficultés d’ordre temporel et
financier durant notre recherche. Les difficultés les plus importantes que nous avons
rencontrées sont liées à l’accès limité à certaines données et/informations car, nos
occupations vis-à-vis aux charges de l’horaire de cours ne nous ont pas permis de faire face
à tous les points invoqués dans ce travail efficacement.
S’ajoute le problème d’ordre financier ; accéder aux bibliothèques virtuelles, à toute
recherche de tout genre à l’internet et même dans les documents physiques il faut mobiliser
de l’argent.
Cela n’a pas fait que nous ne puissions pas continuer à pas de tortue et par grâce, morale,
endurance et soutien des autres nous avons contourné ces divers problèmes.
 ~ ~

PREMIER CHAPITREREVUE DE LA LITTERATURE

I.1. REVUE DE LA LITTERATURE THEORIQUE
I.1.1. Définition des concepts clés
A. Théorie Cadrant avec le sujet
 Ecole
Dans de nombreux pays en développement, la lutte contre l'analphabétisme passe par
l'instauration d'une scolarité obligatoire et gratuite afin de donner à tous les enfants une
éducation de base.
Pour une personne, apprendre à lire et à écrire est très important : Pour pouvoir être à l’aise
dans la société : dans la vie de tous les jours, il faut être capable de déchiffrer et de
comprendre toutes sortes d’informations écrites (papiers administratifs, notices, panneaux
dans la rue, plans, etc.) ; Pour avoir accès à la culture (la littérature, la presse écrite, etc.) ;
Pour pouvoir étudier. De plus, au niveau d’un pays, plus il y a de personnes qui font des
études, plus ce pays est doté de professeurs, d’ingénieurs, de chercheurs. C’est comme cela
que l’agriculture, l’industrie et les services se développent ; c’est comme cela aussi que
l’économie d’un pays progresse et que ses richesses augmentent (Encarta, 2009. )
Les institutions chargées à faire ce précieux travail sont appelées école, elles ont pour
mission principale de conduire les gens de l’ignorance vers la connaissance.
 Inscription
L’inscription est l’effet d’inscrire quelqu’un. C’est à dire mettre son nom sur une liste pour

qu’il fasse partie d’un groupe, d’une organisation, d’un établissement, etc. (LaRousse,

2016).

 Frais de scolarité

Frais payés pour l'enseignement (en particulier pour l'enseignement supérieur) (inedi, 2017).
Ceux-ci comprennent des frais contribuants au salaire des enseignants tout comme des frais
non-salariaux de fonctionnement. La structure des frais est fixée au niveau provincial par le
Gouverneur avant le début de chaque année scolaire. La contribution des ménages reste
donc une composante essentielle du financement de l’éducation publique. Ces éléments clés
sont à prendre en compte dans le calcul du coût unitaire (EPSIC, 2015, , p. 61)
 ~ ~

A. Théories relatives au système de gestion des bases des données

Néanmoins, une définition très générale est la suivante :
- Base de données : Une base de données est un ensemble structuré d’informations 5. Peu
importe le support utilisé pour rassembler et stocker les données (papier, fichiers, etc.),
dès lors que des données sont rassemblées et stockées d'une manière organisée dans un
but spécifique, on parle de base de données. Ceci revient à dire que parler de bases de
données ne donne pas la première impression qu’il ne s’agit que d’une base de données
informatique.
- Base de données informatisée : Une base de données informatisée est un ensemble
structuré de données enregistrées sur des supports accessibles par l'ordinateur
représentant des informations du monde réel et pouvant être interrogées et mises à jour
par une communauté d'utilisateurs6. Le résultat de la conception d'une base de données
informatisée est une description des données. Par description on entend définir les
propriétés d'ensembles d'objets modélisés dans la base de données et non pas d'objets
particuliers. Les objets particuliers sont créés par des programmes d'applications ou des
langages de manipulation lors des insertions et des mises à jour des données.
Cette description des données est réalisée en utilisant un modèle de données. Ce dernier est
un outil formel utilisé pour comprendre l’organisation logique des données. La gestion et
l’accès à une base de données informatisée sont assurés par un ensemble de programmes qui
constituent le Système de gestion de base de données (SGBD).
Une fois la base de données spécifiée, on peut y insérer des données, les récupérer, les
modifier voire même les détruire. C'est ce qu'on appelle manipuler les données. Les données
peuvent être manipulées non seulement par un Langage spécifique de Manipulation des
Données (LMD), mais aussi par des langages de programmation classiques.
NB : Les bases de données ont pris une place importante en informatique, et
particulièrement dans le domaine de la gestion. L'étude des bases de données a conduit au
développement de concepts, méthodes et algorithmes spécifiques, notamment pour gérer les
données en mémoire secondaire (c’est-à-dire disques durs).
En effet, dès l'origine de la discipline (informatique), les informaticiens ont observé que la
taille de la RAM ne permettait pas de charger l'ensemble d'une base de données en

5
T-Soft, Utilisation de base des données avec Access 2007, 10ème rue du Colisée 75008 Paris, 2009,
p.10
6
Pierre Gérard, MERISE : Modélisation de système d’information, Université de Paris 13, Paris 2004-
2006, p.20.
 ~ ~

mémoire. Cette hypothèse est toujours vérifiée, car le volume des données ne cesse de
s'accroître sous la poussée des nouvelles technologies du Web.
Ainsi, les bases de données de demain devront être capables de gérer plusieurs dizaines de
téraoctets de données, géographiquement distribuées à l'échelle d'Internet, par plusieurs
dizaines de milliers d'utilisateurs dans un contexte d'exploitation changeant (on ne sait pas
très bien maîtriser ou prédire les débits de communication entre sites) voire sur des nœuds
volatiles.
En physique des hautes énergies, on prédit qu'une seule expérience produira de l'ordre du
pétaoctet de données par an7.
Comme il est peu probable de disposer d'une technologie de disque permettant de stocker
sur un unique disque cette quantité d'informations, les bases de données se sont orientées
vers des architectures distribuées ce qui permet, par exemple, d'exécuter potentiellement
plusieurs instructions d'entrée/sortie en même temps sur des disques différents et donc de
diviser le temps total d'exécution par un ordre de grandeur.
A. Modèles de base de données
 Modèle hiérarchique
Ce type de modèle de données a été créé dans les années 1960 ; c’est le plus ancien modèle
de données.8 Notons ainsi qu’une base de données hiérarchique est une forme de système de
gestion de base de données qui lie des enregistrements dans une structure arborescente de
façon à ce que chaque enregistrement n'ait qu'un seul possesseur (par exemple, une paire de
lunettes n'appartient qu'à une seule personne).Ce modèle est le plus ancien. Selon ce type de
modèle, les informations sont groupées dans des enregistrements, chaque enregistrement
comporte des champs. Les enregistrements sont reliés entre eux de manière hiérarchique.
Cela signifie qu’à chaque enregistrement correspond un enregistrement parent.
Les liens hiérarchiques entre les différents types de données peuvent rendre très simple la
réponse à certaines questions, mais très difficile la réponse à d'autres formes de questions.
 Modèle de données entité
Ce type de modèle est le plus couramment utilisé pour la réalisation de modèles de données
logiques. Selon ce type de modèle, une base de données est un lot d’entités.
 Modèle Object

7
Pierre Gérard, MERISE : Modélisation de système d’information, Université de Paris 13, Paris 2004-
2006, p.25
8
Pierre Gérard, MERISE : Modélisation de système d’information, Université de Paris 13, Paris 2004-
2006, p.30
 ~ ~

La notion de bases de données objet est plus récente et encore en phase de recherche et de
développement. Ce type de modèle est fondé sur la notion d’objet de la programmation
orientée objet. Selon ce type de modèle, une base de données est un lot d’objets de
différentes classes. Chaque objet possède des propriétés, des caractéristiques propres, et des
méthodes qui sont des opérations en rapport avec l’objet.
 Modèle Relationnel
Une base de données relationnelle est une base de données structurée suivant les principes
de l'algèbre relationnelle. Le père des bases de données relationnelles est Edgar Frank Codd.
Chercheur chez IBM à la fin des années 1960, il étudiait alors de nouvelles méthodes pour
gérer de grandes quantités de données, car les modèles et les logiciels de l'époque ne le
satisfaisaient pas. Mathématicien de formation, il était persuadé qu'il pourrait utiliser des
branches spécifiques des mathématiques (la théorie des ensembles et la logique des
prédicats du premier ordre) pour résoudre des difficultés telles que la redondance des
données, l'intégrité des données ou l'indépendance de la structure de la base de données
avec sa mise en œuvre physique.9
Selon ce type de modèle, la base de données est composée d’un ensemble de tables (les
relations) dans lesquelles sont placées les données ainsi que les liens. Signalons que chaque
ligne d’une table est un enregistrement et que ces modèles sont simples à mettre en œuvre.
Nous pouvons par ici dire donc que le modèle relationnel de données est celui d’une base de
données organisée selon un modèle de données de type relationnel, à l’aide d’un SGBD
permettant ce type de modèle.
I.1.2. Notion sur la méthode UP
Le processus unifié est un processus de développement logiciel, c’est-à-dire qu’il regroupe
les activités à mener pour transformer les besoins d’un utilisateur en système logiciel ( 10).
Le processus unifié fournit un cadre au développement logiciel pour la construction de
systèmes orientés objet.
Le processus unifié répond aux exigences fondamentales suivantes :
 être guidé par les besoins des utilisateurs ;
 être centré sur l’architecture logicielle ;
 être itératif et incremental.
A. Origine du processus unifié

9
Patrice Buche, Réaliser une base de données avec Access, INA Paris Grignon, 2005, p.15
10
http://sabricole.developpez.com/uml/tutoriel/unifiedProcess/ consulté le 22/12/2019
 ~ ~

Le terme « Unifié » est très approprié puisqu’il s’agit de la fusion des travaux d’Ivar
Jacobson, Grady Booch (au départ chez Objectory) et de James Rumbaugh, enrichie de
nombreux apports issus d’UML (développé en parallèle) et du produit commercial RUP,
sorti en 1998 et mis à jour par IBM (après le rachat de Rational qui avait lui-même acheté
Objectory en 1995). D’autres ont permis de peaufiner le processus, notamment Walker
Royce et Philippe Kruchten pour la planification et la gestion de projet11.
B. Activités de la méthode UP
Les activités représentent les actions à effectuer au cours d'une phase : une phase passe par
l'ensemble des activités. Le temps passé par activité est fonction des phases.
Les activités de développement sont définies par des disciplines ou workflows
fondamentales suivantes : Modélisation métiers, Exigences, Conception, Implémentation,
Tests, Déploiement, Gestion de la configuration, Gestion de projet, Environnement12.
C. Les phases de la méthode UP
Les phases d'un processus de développement sont des états de celui-ci à un instant t. Le
cycle de développement du Processus Unifié organise les tâches et les itérations en quatre
phases :
 Création : spécification des besoins et aussi une sorte d'étude de faisabilité où on
effectue les recherches nécessaires pour décider si on poursuit ou non le projet ;
 Élaboration : on développe de façon incrémentale l'architecture du noyau, les risques
et la plupart des besoins sont identifiés ;
 Construction : on construit des sous-ensembles exécutables et stables du produit
final ;
 Transition : le produit final est livré en version bêta à la disposition des Utilisateurs.

D. Les principes du processus unifié

Comme susdit, le Processus Unifié (UP) est piloté par les cas d’utilisation (eux même
guidés par les risques), centré sur l’architecture logicielle, itératif et incrémental.
Le projet sera donc mené selon les besoins et les exigences (fonctionnelles et non
fonctionnelles) : points d’entrée sur lesquels l’analyse des risques va principalement
s’exercer pour organiser les plans d’itération.
Les risques majeurs (souvent liés à l’architecture) seront traités en premier lieu dans le
but de les lever au plus tôt : gestion et pilotage par les risques, de vrais points forts pour la
méthode.
11
http://sabricole.developpez.com/uml/tutoriel/unifiedProcess/ consulté le 27/12/2019
12
http://sabricole.developpez.com/uml/tutoriel/unifiedProcess/, consulté le 22/12/2019.
 ~ ~

Le Processus Unifié est opposé au cycle de vie en cascade trop figé et rigide, et se lit
selon deux axes: vertical (enchainement de disciplines et d’activités au sein d’une itération)
et horizontal (enchainement dynamique sur l’axe temporel de phases et d’itérations)13. Et ce
ça la démarche que nous allons adopter dans la réalisation de notre système
I.1.3 Langage de modélisation « UML »14
Le développement des systèmes est une tâche d’une grande envergure et un investissement
important pour toute entreprise. La modélisation des systèmes déjà existants ou d’un
système à construire est une étape importante du cycle de développement des systèmes. La
modélisation permet de visualiser, souvent d’une manière graphique, un système tel qu’il
est ou comment nous souhaitons qu’il va être.
La modélisation, d’une manière générale, aide à l’élaboration et à la structuration des idées
et permet de faciliter la communication entre humains.

 UML : est conçu pour modéliser divers types de systèmes, de taille quelconque et pour
tous les domaines d’application (gestion, scientifique, temps réel, système embarqué).
Permet de diviser le système d’information (d’une organisation) en systèmes métiers
et système informatique. Le système métier modélise les aspects statiques et dynamiques de
l’activité selon une vision externe et une vision interne (en ignorant l’implémentation
technique) tandis que le système informatique recouvre la partie automatisée du système
métier concrétisant les choix effectués parmi les différentes technologies d’actualité. Les
concepts manipulés sont les mêmes, à chacun de ces deux niveaux d’abstraction.
Est fortement inspiré de l’approche 4+1 vues (logique, composants, processus,
déploiement et cas d’utilisation) indépendantes définies par P. Kruchten pour exprimer les
diverses perspectives de l’architecture d’un système informatique.

Se compose d’une part des éléments de modélisation qui représentent toutes les
propriétés du langage et d’autre part des diagrammes (de cas d’utilisation, de classes,
d’objets, d’états-transitions, d’activités, de séquence, de collaboration, de composants et de
déploiement) qui en constituent l’expression visuelle et graphique.

N’impose pas de processus de développement logiciel particulier, même si celui

sous-jacent est un processus itératif (précisant à chaque itération les degrés d’abstraction),
incrémental (ex : en divisant le développement en étapes aboutissant chacune à la

13
http://sabricole.developpez.com/uml/tutoriel/unifiedProcess/, consulté le 27/12/2019.
14
Idem
 ~ ~

construction de tout ou partie du système), centré sur l’architecture (au niveau de la

modélisation comme de la production), conduit par les cas d’utilisation (modélisant
l’application à partir des modes d’utilisation attendus par les utilisateurs), piloté par les
risques (afin d’écarter les causes majeures d’échec) tel que le 2TUP (Two Tracks Unified
Process) présenté notamment dans l’ouvrage « UML en action – De l’analyse des besoins à
la conception en Java de P ».
Prend en compte de manière complètement intégrée l’ingénierie des besoins (cas
d’utilisation).
Est automatisable pour générer du code à partir des modèles vers les langages et les
environnements de programmation.
Est générique, extensible (en plus de couvrir les possibilités des différentes technologies
objet existantes) et configurable.
Se veut intuitif, simple et cohérent15.
A. Définition d’un modèle

Un modèle est une abstraction de la réalité. Modéliser consiste à identifier les

caractéristiques intéressantes ou pertinentes d’un système dans le but de pouvoir l’étudier
du point de vue de ses caractéristiques.

 ILLUSTRATION D’UN MODELE16

Figure 1:Illustration d’un modèle

B. Caractéristiques d’un modèle

Un bon modèle doit posséder deux caractéristiques essentielles :

15
GUIBERT O, Analyse et Conception des Systèmes d’Information – Méthodes Objet. Le langage de
modélisation objet UML, Département Informatique de l’Institut Universitaire de Technologie de l’Université

Bordeaux, p.3. Url : http://methode_objet-lelangage-de-modelisation.pdf.

16
Conception de QSI
 ~ ~

 Il doit faciliter la compréhension du phénomène (système) étudié, il réduit la

complexité ;
 Il doit permettre de simuler le phénomène (système) étudié, il reproduit ses
comportements.
C. Utilité d’UML dans la modélisation

UML opte pour l'élaboration des modèles, plutôt que pour une approche qui impose une
barrière stricte entre analyse et conception. Les modèles d'analyse et de conception ne
diffèrent que par leur niveau de détail, il n'y a pas de différence dans les concepts utilisés.
UML n'introduit pas d'éléments de modélisation propres à une activité (analyse, conception)
; le langage reste le même à tous les niveaux d'abstraction.

Cette approche simplificatrice facilite le passage entre les niveaux d'abstraction.

L'élaboration encourage une approche non linéaire, les "retours en arrière" entre niveaux
d'abstraction différents sont facilités et la traçabilité entre modèles de niveaux différents est
assurée par l'unicité du langage.

 UML favorise donc le prototypage, et c'est là une de ses forces. En effet, modéliser
une application n'est pas une activité linéaire. Il s'agit d'une tâche très complexe, qui
nécessite une approche itérative, car il est plus efficace de construire et valider par
étapes, ce qui est difficile à cerner et maîtriser.
Permet donc non seulement de représenter et de manipuler les concepts objet, il sous-
entend une démarche d'analyse qui permet de concevoir une solution objet de manière
itérative, grâce aux diagrammes, qui supportent l'abstraction.
Pour exprimer les diverses perspectives de l’architecture d’un système, les auteurs
UML proposent 4+1 vues, selon le schéma suivant :

 VUES d’UML

Figure 2:Les vues en UML

1) La vue logique
 ~ ~

Cette vue exprime la perspective abstraite de la solution en termes de classes, d’objets, de

relations, de machine à états de transition, etc…, de manière indépendante des langages de
programmation et des environnements de développement utilisés pour les mettre en œuvre.
Il s’agit d’exprimer le problème de façon abstraite. Les concepts utilisés incluent les
concepts de la majorité des méthodes orientés objets existantes. Cette vue concerne
l’intégrité de conception.
2) La vue des composants

Cette vue exprime la perspective physique de l’organisation du code en terme de modules,

des composants et surtout des concepts du langage et de l’environnement d’implémentation.
Cette perspective dépend du choix du langage utilisé. Dans cette perspective, le concepteur
est surtout intéressé par des aspects de gestion de codes, d’ordre de compilation, de
réutilisation. UML offre des concepts adaptés comme les modules, l’interface, les
composants, les relations de dépendance etc… Malheureusement la plus part des
concepteurs ignorent cette vue. Cette vue concerne l’intégrité de gestion17.

3) La vue des processus

Cette vue exprime la perspective sur les activités concurrentes et parallèles (tâches et
processus) du système. On y trouve les activités parallèles, et leur communication et
synchronisation. Cette vue concerne l’intégrité d’exécution.

4) La vue de déploiement
Elle exprime la répartition du système à travers un réseau de calculateurs et de nœuds
logiques de traitement. Cette vue est utile pour décrire la répartition du système réparti, elle
concerne l’intégrité de performance.

5) La vue des cas d’utilisation

Cette vue guide et justifie les autres en ce sens que la modélisation fondée sur les scénarios
(cas d’utilisation) constitue ce que l’on fait de mieux aujourd’hui. Cette approche constitue
l’unique moyen de guider la modélisation, de trouver le bon modèle.
D. Diagrammes UML
UML propose 13 diagrammes pour modéliser un système. Selon la vue que l’on veut
décrire, statique ou dynamique, ces diagrammes sont :
 Représentation statique du système
La vue statique comprend les diagrammes suivants :
17
YACOUB S., Modélisation Objet avec UML, 2011, pp.5-15.
Url : http://modélisation_objet_avec_UML.pdf. Consulté le 15/11/2019.
 ~ ~

 Diagramme Objets ;
 Diagramme de classes ;
 Diagramme des composants ;
 Diagramme de déploiement ;
 Diagramme de packages ;
 Diagramme de structure composite.
 Représentation dynamique du système
 Diagramme de cas d’utilisation ;
 Le diagramme de séquences ;
 Le diagramme d’état de transition ;
 Le diagramme d’activités ;
 Le diagramme de communication.
 Le diagramme de collaboration

I.1.4 Généralités sur le Web18

Le World Wide est Web est rapidement devenu le service le plus utilisé sur
l'Internet. C'est ce qui a rendu le mot "Internet" un mot de notre jargon de tous les
jours pour la plupart d'entre nous. Le "père" du World Wide Web, Tim Berner Lee, a conçu
les bases en mars 1989. Il a conçu le HyperText Mark up Language (HTML) à partir d'un
autre format utilisé pour les documents appelé le SGML.

Le WWW fonctionne en utilisant le concept d'hypertexte. À l'intérieur d'une page, il y a des

mots clés ou des images qui ont des liens qui, lorsque vous cliquez dessus, vous amènent à
une autre page Web.

Cette "explosion" de popularité a commencé en 1995. Il y avait environ 70 millions de

pages web sur le world wide web en 1996. Le chiffre était estimé à 200 millions de pages en
1997. En août 1999, le nombre dépassait les 800 millions de pages. En mars 2000, on
passait à 1,5

Milliards de pages. On parle aujourd'hui de plus de 8 milliards. L'une des raisons est la
facilité de concevoir une page Web.

18
Guy PUJOLLES, les réseaux informatiques, édition Eyrolles, Paris, 2008, p.34
 ~ ~

Tous les logiciels de traitement de texte populaires peuvent maintenant convertir

leurs documents en format de page Web (HTML). Mais, il y a aussi des logiciels spécialisés
pour la conception qui sont encore plus puissant

A. Différence entre une page Web et un site Web

Une page Web est un fichier, parce qu’elle contient du texte, des images et des liens à
d'autres pages.

Un site Web est un regroupement de pages sur un sujet, un thème, un commerce, une
organisation. Un site Web a aussi une page principale. C'est une page Web qui aide les
lecteurs à naviguer sur le site pour trouver l'information voulue.

Un site Web doit aussi être structuré. Comment une page Web est-elle reliée à une autre ? Y
va-t-il un ou plusieurs chemins ou parcours que les lecteurs peuvent utiliser pour naviguer à
travers le site? Par exemple. Au début et à la fin de chaque page, il y a plusieurs boutons de
navigation pour passer à la page précédente ou suivante.

B. Différence entre un site web statique et un site web dynamique19

 Les sites statiques : ce sont des sites réalisés uniquement à l'aide des langages (X)
HTML et CSS. Ils fonctionnent très bien mais leur contenu ne peut pas être mis à jour
automatiquement, il faut que le propriétaire du site (le webmaster) modifie le code
source pour y ajouter des nouveautés. Ce n'est pas très pratique quand on doit mettre à
jour son site plusieurs fois dans la même journée ! Les sites statiques sont donc bien
adaptés pour réaliser des sites "vitrine", pour présenter par exemple son entreprise, mais
sans aller plus loin. Ce type de site se fait de plus en plus rare aujourd'hui, car dès que
l'on rajoute un élément d'interaction (comme un formulaire de contact), on ne parle plus
de site statique mais de site dynamique.20
 Les sites dynamiques : plus complexes, ils utilisent d'autres langages en plus de (X)
HTML et CSS, tels que PHP et MySQL. Le contenu de ces sites web est dit
"dynamique" parce qu'il peut changer sans l'intervention du webmaster ! La plupart des
sites web que vous visitez aujourd'hui, y compris le Site du Zéro, sont des sites
dynamiques.

C. Avantages d’un site statique

19
Mathieu NEBRA, Concevez votre site web avec PHP et MySQL, édition Dunod, Avril 2010, p.8.
20
 ~ ~

On vient de voir qu'un site statique possède beaucoup d'inconvénient : il faut s'y connaître
en HTML pour le modifier et l'étape de mise à jour est fastidieuse. Mais il faut aussi
reconnaître au site statique des avantages dans plusieurs domaines : le site internet est mis à
jour en local (sur la machine de l'administrateur) : il n'y a donc pas de surprise une fois que
le site est en ligne.

Le site internet ne fait pas appel aux technologies en perpétuelles évolutions qui permettent
la mise en place de site dynamique (Php, Ruby, Python, Perl, Java, ASP, etc.) : on gagne
donc en sécurité et en veille technologique. Le site internet statique consomme peu de
ressource serveur : le site n'utilisant aucune technologie compliquée (au hasard : Php +
MySQL + Apache), les coûts d'entretien et de maintenance en activité sont très inférieurs à
ceux d'un site
dynamique.

Le site internet statique se sauvegarde plus facilement : ceux qui ont déjà manipulé les bases
de données MySQL utilisées pour la création de sites dynamiques savent
que c'est une galère à sauvegarder et à restaurer. Le fait de disposer directement des pages
HTML du site facilite la sauvegarde (un simple copier / coller sur une clé USB).

D. Avantages d’un site dynamique

De nombreux scripts gratuits existent déjà et permettent de réaliser tous les sites qu'on
souhaite. Ainsi en téléchargeant le script (ou CMS : Content Management System) qui va
bien, il sera très simple de créer un forum, un blog ou tout autre site.

La mise à jour est très simple : une fois le script dynamique en place, on met à jour le site en
ligne dans la partie « administration » du site. On peut donc mettre à jour le site de
n'importe quel ordinateur et même depuis certains téléphones mobiles (avec accès Internet
naturellement).
Avec un site dynamique il est possible de réaliser une grande interaction avec les visiteurs :
les visiteurs peuvent donc rester beaucoup plus longtemps sur vos pages si les
fonctionnalités sont intéressantes.

Quant à nous nous allons mettre en place un site dynamique en utilisent d'autres langages en
plus de HTML5 et CSS, tels que PHP et MySQL.
 ~ ~

I.2. REVUE DE LA LITTERATURE EMPIRIQUE (Etat de la question)

Pour réaliser la présente étude, nous avons fait recours aux différents travaux qui ont trait
avec la thématique sous étude, ceci dans le souci de ne pas avoir la même orientation que
nos prédécesseurs.
Il s’agit de travaux de :
 CHANCE BYAMUNGU Augustin dans son mémoire intitulé : « Réalisation d’une
application de gestion des paiements des frais scolaires dans des institutions
d’enseignement secondaire : Cas de l’Institut Kasali »21, il a soulevé plusieurs
problèmes rencontrés dans la gestion administrative que dans la gestion financière et
ce sont ces mêmes problèmes qui ont fait l’objet de sa recherche. Sa recherche étant,
étant donné que toutes les tâches cadrant avec l’administration et la finance étaient
manuelles, il a mis sur pied une application informatisée la gestion administrative et
celle financière qui, à sa fin a produit plusieurs résultats notamment : la production
automatique du reçu de paiement, la recherche rapide des informations cadrant avec la
gestion des frais (situations sur les paiements par élève, par option et par section), la
production automatique des documents comptables et financiers (journal, bon d’entrée
caisse et le bon de sortie caisse). Il a utilisé plusieurs méthode pour la réalisation de
son travail tels que la méthode Analytique,etc… Mise à part les résultats produits, ce
dernier avait poursuivi au cours de sa recherche à éradiquer tout malentendu ou vol
qui surgiraient en faisant un envoi des messages téléphoniques au responsable de
chaque élève et bien la réinscription automatique pour les élèves des classes montantes
ou des élèves ayant doublé des promotions voir même les statistiques des élèves pour
chaque option et section.

 AMURI JOSEPH, dans son travail de mémoire intitulé : « Conception d’un site web
de suivi de paiement de frais académiques : Cas de l’Institut Pédagogique de
Bukavu »22. Pour la conception de son système, il a utilisé la démarche UP7 pour la
modélisation des différents diagrammes, partant des problèmes qu’il a rencontré dans
la gestion de paiement de frais académique il a profité de ce problème pour qu’il soit

21
CHANCE BYAMUNGU A., Réalisation d’une application de gestion des paiements des frais
scolaires dans des institutions d’enseignement secondaire : Cas de l’Institut Kasali, Mémoire, L2
Informatique, Département d’informatique de gestion, ISC-Bukavu, 2018-2019, inédit.
22
AMURI JOSEPH, Conception d’un site web de suivi de paiement de frais académiques : Cas de
l’Institut Pédagogique de Bukavu, Mémoire, L2 Informatique, Département d’informatique de gestion,
ISP/BUKAVU, 2014-2015, inédit.
 ~ ~

l’objet de sa recherche. Sa recherche étant donné que toutes les tâches cadrant avec la
finance étaient manuelles, il a mis sur pied une application informatisée la gestion
financière qui, à sa fin a produit plusieurs résultats notamment : la production
automatique du reçu de paiement, la recherche rapide des informations cadrant avec la
gestion des frais (situations sur les paiements par Etudiant, par faculté et par section),
la production automatique des documents comptables et financiers (journal, bon
d’entrée caisse et le bon de sortie caisse). Il a utilisé plusieurs méthodes pour la
réalisation de son travail tels que la méthode Analytique, etc…
 Byenda Kazunguzibwa, Notification des paiements des frais scolaires : « cas du
23
Lycée Nyakavogo Bagira », Mémoire inédit, ISP/Bukavu, 2015/2016. Ce
dernier fait exception des autres au sens où l’auteur veut à travers ce projet remédier
au problème selon lequel il y a des élèves qui quittent à la maison chaque fois pour
l’école et qui normalement n’étudient jamais car, leurs parents leurs donnent de la
prime au compte de l’école qu’ils s’en approprient. Alors l’auteur a pensé à cela et a
abouti à implémenter un système pouvant alerter les parents de ces élèves toutes les
fois qu’ils donnent de l’argent à payer les études et que ces élèves le payent. Donc
ces parents sont au courant de la situation financière de leurs enfants.
Le présent travail vise à développer une application web qui permettra au gestionnaire
de l’Institut Mwanga de contrôler et rationaliser les recettes et les dépenses aisément enfin
d’en expliquer les écarts suivants les prévisions du budget au cours d’un mois, d’un
semestre et/ou d’une année. C’est aussi juste permettre à celui-ci de gagner son minimum
de temps pendant ce contrôle car il ne sera plus en train d’aller à la pêche de l’information
dans d’autres services qui la détiennent mais qu’il puisse l’avoir non en effectuant des vas et
vient, mais en la recherchant d’une manière automatique dans la base des données
commune dans laquelle chaque service enregistre ces données et d’en retrouver dans le cas
échéant pendant qu’il est à son poste de travail.

23
Byenda Kazunguzibwa, Notification des paiements des frais scolaires : « cas du Lycée Nyakavogo
Bagira », Mémoire inédit, ISP/Bukavu, 2015/2016.
 ~ ~

Deuxième chapitre
ETUDE DU MILIEU D’ETUDE ET ANALYSE DU SYSTEME EXISTANT
II.1. PRESENTATION DE L’INSTITUT MWANGA D’UVIRA
L’Institut MWANGA D’UVIRA c’est une école conventionnée catholique du Diocèse
d’Uvira, située dans l’avenue DANILO CATARZI, quartier SONGO, ville d’Uvira,
province du Sud-Kivu en République Démocratique du Congo. L’Institut MWANGA
d’Uvira est limité :
A l’EST : Par la coordination des Ecoles conventionnées catholique et le stade de l’Unité
d’Uvira.
A l’OUEST : par le courant des prêtres diocésains de la cathédrale saint Paul d’Uvira.
Au Nord : par la cathédrale Saint-Paul d’Uvira et l’Ecole Primaire MUNANIRA.
Au Sud : Par le ruisseau KABINDULA.
II.1.1. Historique
En Avril 1962 : création du Diocèse d’Uvira avec comme 1er EVEQUE, Monsieur
DANILO CATARZI de la congrégation des Missionnaires Pères Xaveriens, 6 mois après
(le 02 OCTOBRE 1962) Monseigneur DANILO KATARZI crée l’école sous la
dénomination de COLLEGE STELLA MARIS (Collège Etoile de la Mer).
L’année scolaire 1962-1963
Il y a eu ouverture de la 1ère classe du cycle d’orientation dans l’après-midi, à l’école
primaire Saint-Paul aujourd’hui, Ecole primaire MUNANIRA, avec une dizaine d’élèves.
Avec comme 1er préfet : LE PERE TASI MISSIONNAIRE Xavériens, en même temps
administrateur Diocésain des Ecoles catholiques.
NB. L’année scolaire 1963-1964 : ouverture de la 2ème C.O, toujours à l’école primaire
Saint-Paul, mais la rébellion Muleliste qui a entré à Uvira le 15 Mai 1964 interromps tout.
De 1964-1967 : Avec la rébellion Muleliste, tout est arrêté, même le projet de construction
de l’école au Mont BULA (Communément appelé chez KANZELE).
L’année scolaire 1967-1968 Il y a eu :
Réouverture du collège Stella Maris avec comme préfet et administrateur Diocésain des
Ecoles, le PERE TONY XOTTA (xavériens).
Délocalisation de l’Ecole, de l’Ecole primaire Saint Paul au LYCEE IMMACULATA
(actuel LYCEE UMOJA).
L’année scolaire 1969-1970
 ~ ~

Après construction de 2 blocs de 4 salles chacun sur ce site par le Père CHIMA (Xavériens),
le collège Stalla Maris est encore délocalisé, du Lycée Immaculata vers ses enceintes
propres et actuelles. Le 10/10/1970, le collège Stella Maris décroche son 1er arrêté
d’agrément /N°EDN/CABMIN/085/70 avec 16 classes, dont 8 classes du cycle
d’orientation, 4 classes de l’option MATH-PHYSIQUE et 4 classes de l’option
commerciale et Administrative.
En 1973 : Avec la Zaïrianisation, le collège STELLA MARIS change de dénomination et
devient INSTITUT MWANGA D’UVIRA.
En 1974 : Le père TONY XOTTA (Xavérien) cède la direction de l’Ecole à Monsieur
NINDAGA BAMBAGA.
En 1976-1977 : présentation de l’Examen d’Etat par la 1ère promotion à BUKAVU et la 2e
promotion au Lycée UMOJA.
De 1993 à 1994 :
Il y a eu construction du bâtiment communément appelé « BLOC littéraire à 6 classes par le
frère STAN (des frères de la charité).
Parmi les anciens élèves, enseignants et préfet, nous pouvons citer :
ELEVES : LUNGWE-MUSHOBIRARA, YUMA-MIRANDU, MUYENGWA-
KAHENDJA, DJUMA-MATENGA, MIGOMBANO-MBARUKO, NDJILA – HERI,
BASHULILE-KASIRA, KIZA-MUHATO, LUWAWA-MTOTO NGOMBO, JUMATANO
MWIRIRI.
ENSEIGNANT : Monsieur VANUEL, Kiss et Petit Robert (3 premiers enseignants à
l’ouverture de l’école ; ils étaient des volontaires de l’IRSAC (Actuel CRH/Uvira), FOMA-
MAZIBO, ALEXIS-DEDE, BIANGA WARUZI, MAYELE – MICHEL, MATABAZI-
Lambert, MAYUGI-Thomas, …
PREFET : Père TASI, Père TONNY XOTTA (Xavériens), NINDAGA-BAMBAGA,
MUSHEGEZI-MWENEBIREKE, ASSUMANI-NAMURABA, MUKE-KITAMBALA,
RUVUTO-MAYUGI, NDASIMA-Thomas, LUWAWA-MTOTO NGOMBO,
RAMAZANI-RUZOREZA, SHAURI-SIKALABADJA, préfet en exercice.
A l’époque des Salésiens, nous avons eu comme préfets :
Père Jean-Marie Nivard RUBAKERE, Père Célestin MUSEMAKWELI, Père Jean Bosco-
DUBELE, Père Damas KAMWANYA-TIMBWE, Père Antoine KABENGELE MAKOLO,
Père Justin KAMWIRA-MASUMBUKO, Père BANZA-KASONGO Yves.
 ~ ~

Depuis sa création, l’école MWANGA d’Uvira a déjà accueilli de 1973 à nos jours, 45.860
élèves dont 19.373 filles. Diplômés d’Etat obtenus de 1976 à 2022 : 4.088, dont 1602 filles.
(Source : Archive de l’Institut MWANGA D’UVIRA).
II.1.2. Structure organisationnelle et fonctionnelle
II.1.2.1 Organigramme de L’Institut Mwanga

 STRUCTURE ADMINISTRATIVE

Cette structure permet à bien comprendre notre organigramme compte tenu de la description
des tâches que chaque personnel assume dans la hiérarchie. Cependant, cette description des
tâches est ainsi repartie de la manière ci-après :

CONSEIL
D’ADMINISTRATION

COORDINATION DES ECOLES

CONVENTIONNEES CATHOLIQUES

PREFET

PERCEPT DIRECTEUR DE PROVISEUR

RICE DISCIPLINE

SECRETAIRE

CORPS ENSEIGNANT

OUVRIER

Figure 3:Organigramme de L’Institut Mwanga

 ~ ~
24
II.1.2.2. Structure fonctionnelle
 CA (Conseil d’Administration) : est un organe qui se charge à réunir tous les
problèmes que l’Ecole connait afin d’en proposer des pistes des solutions ;
 Coordination des Ecoles conventionnées catholiques : Elle donne les données, les
instructions directes au préfet des études et toute autre démarche que le préfet va
mener au courant de l’année ;
 Préfet : c’est lui le chef d’établissement, il coordonne toutes les activités. Il est aussi
l’autorité compétente officiellement reconnu pour gérer, administrer l’école avec
d’autres membres du comité de direction. Ses missions sont les servants:
Faire le suivi individualisé des élèves du point de vue éducatif et pédagogique en
liaison avec le conseiller principal de l’éducation.
Il coordonne toutes les activités au sein de l’école et veille à l’application des
directives du ministère de l’éducation nationale et de toutes les autorités hiérarchiques.
 La perceptrice : Elle a double rôle :
Elle est chargée de collecter et de comptabiliser l’argent payé par les élèves et par après, elle
fait un rapport à la direction.

 Proviseur : il perfectionne les horaires (horaires des cours, des examens), il rend
visites aux enseignants pendant les leçons enseignées dans des classes différentes
sanctionnées par une côte chiffrée attribuée à l’enseignant, il fait aussi le suivi des
documents pédagogiques tenus par les enseignants.
 D.D : l’ordre étant de rigueur dans toute société pour la bonne continuité de cette
dernière, le directeur de discipline est appelé à assurer d’ordre et la discipline au sein
de l’école en s’inspirant au règlement d’ordre intérieur. Il a la compétence d’exclure
un élève temporairement voir même définitivement sur décision du conseil de
discipline en cas de la violation de la loi.
 Le Secrétaire : il est sous l’ordre du préfet, il reçoit et expédie les différentes lettres.
Il fait la saisie des rapports scolaires, les questions des examens et il est appelé aussi à
garder le secret de l’école. Il a comme tâche:
- De mettre à jour les dossiers administratives ;
- De s’occuper de la réception et distribution des courriers ;
- Indicatorier les lettres, donner les numéros aux lettres reçues et expédiées ;
- Soumettre les lettres écrites au chef d’établissement pour signature, etc.

24
Source : Archive de l’Institut MWANGA D’UVIRA.
 ~ ~

 Le Corps Enseignant : il est chargé de transmettre les connaissances aux élèves. Il

dispense non seulement les cours pratiques ou théoriques mais également il donne la
morale, le savoir-vivre et savoir-faire aux élèves. Ses tâches sont les suivantes :
- Fournir un bon environnement aux élèves ;
- Assurer un bon encadrement des élèves ;
- Transmettre une connaissance de qualité aux élèves ;
- Maintenir la discipline et ordre dans toute la classe où il est affecté.
 Ouvrier : il est chargé de la propreté et de la sécurité de l’école tous les jours et
chaque instant.
LES RESSOURCES HUMAINES

L’Institut MWANGA D’UVIRA, c’est une école gérée par l’Etat congolais avec arrêté
d’agrément : N°MINEPSP/CABMIN/043/2007, du 20/11/2007, mais sous contrôle de
l’église catholique.

EFFECTIFS ENSEIGNANTS

L’institut MWANGA d’Uvira compte 57 enseignants officiellement engagés, dont 14

diplômes d’Etat, 24 gradués et 19 licenciés. L’école a aussi 7 enseignants visiteurs tous
qualifiés ; 49 enseignants mécanisés et payés par l’Etat congolais.

OUVRIERS : 4 dont 3 gardiens de maisons SOFAS, 7 enseignants visiteurs tous qualifiés.

PERSONNELS ADMINISTRATIFS : 7 : 1 préfet, 2 directeurs des Etudes, 2 directeurs de

disciplines, 1 secrétaire et 1 surveillant.
DEVISE DE L’ECOLE
« Discipline, Compétence, Excellence ».
BATIMENTS : 8 bâtiments réparties en :

24 salles de classes, 1 laboratoire d’informatique, 1 grande salle, 1 bureau d’archive, 1

préfecture, 2 directions des études, 2 directions de discipline, 1 secrétaire, 1 cantine scolaire.

OPTIONS ORGANISEES : 4 options + Education de base

 Commerciale et gestion
 Scientifique
 Latin-philo
 Agriculture – générale.
 ~ ~

NB : La mécanique générale n’a jamais été opérationnelle faute de salle et du

matériel.
EFFECTIFS ELEVES : 2107 élèves dont 823 filles et 245 finalistes.
775 élèves en Enseignement de base et 1332 élèves aux humanités.
Source : Archive de l’Institut Mwanga d’Uvira.
OBJECTIF OU MISSION DE L’ECOLE
L’objectif de l’institut Mwanga d’uvira est :
 Rendre l’école plus disciplinée
 Rendre l’école plus compétitive
 Rendre l’école plus excellente et édifiante
 Toute concurrence, plus rayonnante partout au Monde.

II.2. ANALYSE DU SYSTEME EXISTANT

L’analyse de l’existant est un processus d’étude d’un système en vue de déterminer son
fonctionnement en comprenant les tâches de chacun des postes et la manière dont il répond
aux requêtes des utilisateurs.

L’analyse débouche sur un plan préparatoire de la conception et la mise en œuvre du

nouveau système. Cette étape primordiale à toute mise en route des projets permet de
définir un cadre, d’éviter les redites, d’aiguiser l’esprit critique et de favoriser la créativité.

II.2.1. Présentation du système existant

En ce qui est de l’activité au sein de l’Institut Mwanga, disons que cette institution
d’enseignement secondaire respecte le standard de réalisation en son sein comme pour
toutes les autres institutions. Ainsi, dans le cadre de la finance qui fait l’objet de cette
thématique, l’Institut Mwanga c’est une école conventionnée catholique qui, lors des
paiements des frais scolaires, utilisent tous les documents tenus par d’autres institutions
pour la réalisation de ses missions. Ce faisant, il utilise différents documents comptables
dans lesquels sont enregistrés toutes les opérations, notamment : le Bon d’entrée caisse, le
Bon de sortie caisse, le Reçu et bien le Livre de caisse. Chaque document joue un rôle
spécifique dans ce processus (le processus de suivi de paiements) ainsi que le registre
d’inscription qui est tenu souvent par le Secrétaire de l’école.

Cependant, le paiement au sein de l’Institut Mwanga se fait de la manière suivante :

 ~ ~

 Pour chaque période de paiement bien définie, l’élève doit se présenter au bureau du
Percepteur où il effectue le paiement, lequel paiement est enregistré dans le livre de
caisse par le percepteur,
 Après chaque enregistrement, le percepteur doit élaborer un reçu attestant le
paiement effectué par l’élève,
 Après ceci, il est obligé de compléter pour chaque fin de la journée le total du
montant perçu au cours de cette journée tout en spécifiant le libellé du type de
montant encaissé,
 Le percepteur rédige chaque fin de la journée un rapport à remettre au comptable, qui
du reste tient le Journal pour passation des écritures comptables,
 Pour chaque période définie, le percepteur procède à l’élaboration des listes des
paiements effectués par classe et par option pour bien se rassurer un bon
recouvrement des frais et réalise le suivi,
 Le promoteur doit avoir le rapport de tous les paiements effectués chaque jour
ouvrable lorsqu’il y en a eu ainsi que le Préfet des études.

II.2.1.1. Présentation des ressources utilisées

 Ressources matérielles
Les ressources matérielles suivantes sont utilisées par le service chargé de la gestion de frais
scolaires au sein de l’institut mwanga. Il s’agit de :
 La machine dactylographie en cas de la rédaction des rapports, est en bonne Etat
 La machine calculatrice, en bonne Etat
 Stylos et papiers,
 L’ordinateur de la marque DELL qui assure la saisie de certains documents tels que le
reçu de paiement, le bon d’entrer et de sorti, le journal…,
 Une photocopieuse, Imprimante LASER, et scanneur. En bonne Etat

 Ressources humaines

L’institut mwanga d’uvira comprend en son sein un nombre limité des agents par
rapport aux tâches ou activités effectuées. Ils sont tous qualifiés et formés chacun dans son
domaine pour assurer une bonne gestion.

N° TITRE NIVEAU D’ETUDE

2 Proviseur Licencié
 ~ ~

3 préfet Licencié

4 Secrétaire Gradué

5 Comptable Gradué

6 Perceptrice Diplômé
Tableau 1:Ressources Matériel

 Resources logicielles

L’institut MWANGA ne dispose pas d’un logiciel pour la gestion de frais scolaires.
Il utilise encore un système fastidieux dans le traitement des informations qui circulent au
sein de l’école.
 Mode de traitement des informations
L’institut MWANGA gère les activités liées au paiement des frais scolaires ne se
réalisent pas par des ordinateurs c’est à-dire que les activités se font d’une manière non
informatisée. Le mode de traitement utilisé pour le suivi de paiement des frais scolaires au
sein de l’institut Mwanga se fait manuellement.
II.2.2. Présentation de documents et des supports utilisés
- Les supports utilisés

Les supports qu’utilise l’institut Mwanga dans la gestion des frais scolaires payés par les
élèves sont : les registres et les papiers pour l’archivage des différents documents.

- Documents utilisés

Un document est un renseignement écrit qui sert de preuve d’informations ou de

témoignage. Les documents sont d’habitude subdivises en deux types. Il y a des documents
d’entrée et des documents de sortie. Parmi ces documents, nous citons :

1) Le reçu de paiement des frais scolaires

Le reçu de paiement est un document qui atteste le paiement effectué par l’élève. Sur ce
reçu est mentionné le montant payé par l’élève au cours d’une date bien précise sur un type
de frais bien défini. Il contient cependant les informations suivantes :
 Le libellé précisant l’essentiel sur l’Institution ;
 Le numéro du reçu ;
 Le montant payé ;
 La classe de l’élève ayant effectué le paiement ;
 ~ ~

 Le nom complet de l’élève ayant effectué le paiement ;

 La somme du montant payé en toute lettre ;
 Le motif du paiement ;
 La date d’élaboration du reçu ;
 Le nom et la signature du Receveur.
Le livre de caisse
a. Rôle : c’est un document qui enregistrerait les entrées et les sorties de liquidité. Les entrées sont
constituées par les versements de la caisse et les sorties sont les différentes dépenses engagées.
C’est un document inhabituellement utilisé édicté par la coordination provinciale des écoles
conven tionnées Catholique à ses écoles.

Figure 4:Le livre de caisse

 Carnet de centralisation des perceptions de frais scolaires

Le carnet de centralisation de perceptions de frais scolaires est un document utilisé pour
ressortir les élèves en ordre avec les frais scolaires et ceux encore redevables.
Voici sa présentation sur l’image ci-bas :
 ~ ~

Figure 5: Carnet de centralisation des perceptions de frais scolaires

II.2.3. Critique du système existant

De manière générale et selon le grand Robert, une critique c’est une analyse, un
commentaire, une discussion, une étude, un examen, un jugement d’une œuvre, un ouvrage
pour en faire ressortir les qualités et les défauts. Dans la même optique, il sera question dans
cette étude de présenter les aspects positifs et négatifs du système d’information existant
avant de proposer les pistes pour pallier aux défaillances du système existant.
II.2.3.1. Aspects positifs
Pour ce qui est de l’aspect positif, disons que l’institut mwanga d’uvira réalise d’une
manière peu rationnelle la gestion et le suivi des frais scolaires payés par les élèves malgré
les différentes failles qui découle de ladite gestion, qui demeure manuel jusqu’à présent. Le
service chargé de la perception de frais scolaires procède sans difficulté majeure à
l’enregistrement des frais scolaires ainsi qu’à leur suivi malgré le temps long que cette
opération nécessite.
II.2.3.2. Aspects négatifs
Il sied de signaler que le système d’information existant au sein de l’institut mwanga n’est
pas parfait surtout dans la gestion et le suivi des paiements des frais scolaires payés par les
élèves car les données sont exposées à une perte courante vu qu’elles sont enregistré sur des
supports (supports et documents) qui peuvent se détruire à tout moment voir même
disparaitre ou être volés pour de raisons différentes, ce qui peut conduire à la perte et à la
disparition des informations sensibles. La recherche et le partage des informations prennent
beaucoup de temps du fait que le système n’est pas informatisé.
 ~ ~

II.2.4. Propositions des solutions

Deux solutions peuvent être proposées dans ce cas pour le suivi des frais scolaires payés
par les élèves au sein de l’institut mwanga. Il s’agit de la solution manuelle réorganisée et
de la solution informatique.

 la solution manuelle réorganisée

Pour cette solution, il s’agit de proposer à l’institut mwanga de mettre à la disposition des
élèves un cahier de paie par classe que tout professeur (enseignant) entrant à la première
heure peut contrôler et signer lorsqu’un élève a versé un montant pour confirmer du
montant versé. Ce cahier sera remis avec la somme payée au chargé des paiements après la
première heure par le même professeur et le comptage de l’argent doit s’effectuer à
l’immédiat pour éviter toute sorte de tentative qui puisse surgir après. Cette solution aura
comme avantage à l’école, la stabilité des élèves en classe, le recouvrement rapide car se
faisant dans toutes les classes à la même heure mais présente également des inconvénients
en ce sens que le professeur ne saura pas tenir compte de tous les cas qui puissent exister à
l’égard des élèves mais également la routine car l’école gardera toujours son statut comme
avant, ce qui ne procure pas un service parfaitement fiable.

 La Solution informatique

Pour cette solution, il s’agit de mettre à la disposition de l’école un outil informatique sur
lequel est installé un logiciel permettant d’assurer le suivi des frais scolaires payés par les
élèves. Ce logiciel pouvant fonctionner en réseau ou en local, va permettre à l’institut
mwanga le stockage d’une masse importante d’informations, le partage et la recherche des
informations en temps réel. Cette solution permettre d’enregistrer d’une manière
automatique toutes les opérations relatives à la paie et au suivi des frais scolaires payés par
les élèves de l’institut mwanga.
 ~ ~

Troisième chapitre
CONCEPTION DU NOUVEAU SYSTEME D’INFORMATION

Ce chapitre est subdivisé en trois sections principales. Dans la première section, nous allons
présenter différentes méthodes de développement informatique, la deuxième section concerne
le choix ainsi que la description de la méthode utilisée et enfin dans la dernière section est
axée sur le développement de la méthode que nous allons utiliser (Gabay, (2008),).
III.1. Présentation des quelques méthodes de conception
Dans cette section, nous allons présenter quelques méthodes de développement informatique
entre autres la méthode MERISE, la méthode UP et à la fin la méthode UP7.
III.1.1. La méthode MERISE
MERISE est un acronyme qui signifie Méthode d’Étude et de Réalisation Informatique par les
Sous-Ensembles ou pour les Systèmes d’Entreprise.
Cette méthode a comme objectif d’aider, de guider les concepteurs des systèmes
d’information dans leurs phases d’analyses, de conception et de développement de
l’application.
La méthode MERISE est caractérisée par :
 L’approche systémique en ayant une vue d’entreprise en termes de système : le
système de pilotage, le système d’information et le système opérant ;
 La séparation de données (coté statique) et des traitements (coté dynamique) ;

 L’approche par niveau (niveau conceptuel, niveau organisationnel, le niveau logique

ainsi que le niveau physique).
III.1.2. La méthode UP
Le processus Unifié est une méthode générique de développement logiciel orienté objet
développée par les concepteurs d’UML. Générique signifie qu’il est nécessaire d’adapter UP
au contexte du projet, de l’équipe, du domaine ou de l’organisation. Le processus unifié
permet d’affecter les taches et des responsabilités au sein d’une organisation de
développement logiciel. C’est une approche adaptée pour des grands projets (chef de projet,
Analyste, intervenant…), approche adaptée pour des petits projets mais pas particulièrement
conçu pour le développement des systèmes embarqués.
III.1.2.1. Les principes d’UP
Ci-dessous, les différents principes de la méthode UP :
 ~ ~

 Processus guidé par les cas d’utilisation : le système se définit d’abord par les utilisateurs
et leurs cas d’utilisation ;
 Processus itératif et incrémental :
Les avantages du développement itératif se caractérisent comme suit :
 Les risques sont évalués et traités au fur et à mesure des itérations ;
 Les premières itérations permettent d’avoir un feed-back des utilisateurs ;
 Les tests et l’intégration se font de manière continue.
 Processus centré sur l’architecture ;
 Le processus orienté par la réduction des risques.
Quatre concepts d’UP répondent à ces questions :
 Rôle (qui ?)
 Activité (comment ?)
 Artefact (quoi ?)
 Workflow (quand ?)
III.1.2.2. Les phases du processus Unifié
Le processus Unifié est subdivisé en quatre phases qui sont :
▪ La phase d’Inception c’est la phase de lancement des activités.
▪ La phase d’élaboration : Cette phase reprend les résultats de la phase d’Inception et
élargit l’appréciation de la faisabilité sur la quasi-totalité des cas d’utilisation. Ces cas
d’utilisation se retrouvent dans le diagramme des cas d’utilisation qui est ainsi complété.
▪ La phase de construction est centrée sur la production d’une première version du produit.
Elle est fortement concentrée sur les activités de conception, d’implémentation et de test.
▪ La phase de transition, après les opérations de test menées dans la phase précédente, il
s’agit dans cette phase de livrer le produit pour une exploitation réelle. C’est ainsi que
toutes les actions liées au déploiement sont traitées dans cette phase.

NB : Une phase peut être divisée en itérations. Une itération est un circuit complet de
développement aboutissant à une livraison (interne ou externe) d’un produit exécutable.25
III.1.2.3. Les activités du processus unifié
Les activités menées à l’intérieur des quatre phases sont plus classiques, car déjà bien
documentées dans les méthodes existantes. Par ailleurs, nous nous limiterons donc à ne
donner qu’une brève explication de chaque activité. Le processus unifié est subdivisé en
différentes activités qui sont :

25
-Joseph Gabay et David Gabay (2008), UML2 Analyse et Conception
 ~ ~

 L’expression des besoins ;

 L’analyse ;
 La conception ;
 L’implémentation ;
 Le test.
Ci-dessous, le schéma qui montre les deux dimensions de la méthode UP.

Figure 6:Schéma d’ensemble de la démarche UP.

III.1.3. La méthode UP7

La démarche UP7 a été proposée par Joseph Gabay Directeur de projet informatique au
CNRS-Paris et chargé de cours à l’Université de Paris Dauphin avec David Gabay, directeur
chef de projet chez Cap Gemini une entreprise informatique se trouvant en France. La
démarche UP7 est articulée suivant deux axes : les quatre phases qui correspondent à celles
d’UP et sept activités contrairement à UP qui propose seulement 5 activités. Ainsi, on peut
présenter dès ce stade un premier schéma d’ensemble de la démarche suivant ces deux axes:
 ~ ~

Figure 7:Schéma d’ensemble de la démarche UP7.

Le grisé sur le schéma représente l’effort à consentir pour chaque activité durant les phases
d’un projet. Ainsi par exemple, pour l’activité 2 (Exigences fonctionnelles), l’activité
commence légèrement lors de la phase de lancement puis se déroule principalement lors de la
phase d’élaboration et se termine en phase de construction. 26 Il est à noter que sur le schéma,
la proportion que représente chaque activité par rapport à l’ensemble de la charge de
développement d’un projet a été respectée graphiquement.
III.1.3.1. Les activités de la méthode UP7
 Modélisation métier :
 Exigences fonctionnelles :
 Analyse des cas d’utilisation :
 Synthèse de l’analyse :
 Conception :
 Implémentation :
 Test :
Dans les lignes qui suivent, nous allons beaucoup plus détailler ces différentes
activités.

26
-Joseph Gabay et David Gabay (2008), UML2 Analyse et Conception
 ~ ~

III.2. CHOIX DE LA METHODE CHOISIE27

Notre choix a porté sur la méthode de Processus Unifié. Déjà démontrer dans le chapitre
premier comme quoi ce processus de développement UP 28 associé à UML a une forte
orientation de montrer que le système à construire se définit d’abord avec les utilisateurs
(voire le principe d’UP : « processus guidé par le cas d’utilisation »). Les cas d’utilisation
permettent d’exprimer les interactions du système avec les utilisateurs.
Une seconde orientation est de montrer comment les cas d’utilisation constituent un vecteur
structurant pour le développement et les tests du système. Ainsi donc, le développement peut
se décomposer par cas d’utilisation et la réception du logiciel sera elle aussi articulée par cas
d’utilisation.
Nous allons élaborer notre application avec une méthode de développement en cascade
présentée sur la figure suivante :

Figure 8:Méthode de développement en cascade

II.2.2. Capture des besoins techniques

On va s’intéresser à la branche droite du cycle en Y qui est « la capture des besoins
techniques »en couvrant avec celle des besoins fonctionnels ; les contraintes qui ne traitent
pas la description applicative.

Nous choisissons lors de cette phase l’environnement de travail ainsi que l’architecture
globale utilisée pour notre système.

27
La pore d’entrée d’UP est la capture des besoins (inception) et sa porte de sortie est la transition (livraison du
produit pour une exploitation réelle).

28
La pore d’entrée d’UP est la capture des besoins (inception) et sa porte de sortie est la transition (livraison du
produit pour une exploitation réelle).
 ~ ~

Figure 9:Situation de la capture des besoins techniques dans 2TUP

1. Architectures Client/serveur
L’expression des besoins techniques implique également le choix d’architecture. Ce choix
est crucial puisqu’il intervient dans l’évolutivité du système, le temps de développement, le
coût et les performances.
1.1 Architecture simple tiers La conception de l’application est élaborée de manière à
fonctionner sur un ordinateur unique. En fait, tous les services fournis par l'application
résident sur la même machine et sont inclus dans l'application.
Toutes les fonctionnalités sont donc comprises dans une seule couche logicielle.

Figure 10:Architecture simple tiers

1.2 Architecture client/serveur

C’est une architecture 2-tiers appelée aussi architecture client lourd/serveur. Elle est assez
simple dans sa mise en œuvre. Ce type d'architecture est constitué uniquement de deux
parties : le «client lourd» demandeur de service d’une part et le «serveur des données» qui
fournit le service d'autre part.
 ~ ~

Nous aurons donc la base de données qui sera délocalisée sur un serveur dédié appelé le
serveur de données qui fournira les données à exploiter.

Figure 11:Architecture client/serveur

1.3 Architecture trois tiers Cette architecture physique est assez semblable à
l’architecture client/serveur, mais en plus des « clients » et du serveur des données évoqués
plus haut, un serveur d'application intervient comme un troisième tiers. En effet, les
machines clientes, également appelées « clients légers » ne contiennent que l'interface de
l'application de manière qu’elles se déchargent de tout traitement.

En effet, le traitement est ainsi assuré par le serveur d'application, qui sert de liaison
entre l'interface applicative et les données localisées au niveau du serveur de données.

Figure 12:Architecture 3 tiers

2. Configuration matérielle du système Les choix des prérequis techniques déjà

mentionnés dans l’étude préliminaire, lors de l’expression des besoins opérationnels,
impliquent des contraintes relatives à la configuration du réseau matériel, les performances
d’accès aux données ainsi que la sécurité du système, l’intégration des applications, la
volumétrie et le mode d’utilisation du système.

Afin de concevoir notre application, nous avons opté pour l’architecture 3-tiers.
 ~ ~

Elle représente la solution la plus adaptée à notre système car elle nous offre :
- Des meilleures performances grâce à la répartition des charges de travail
;
- Une disponibilité de l’information en temps réel ; - Une répartition des
tâches entre les acteurs du système et - Une technologie à la mode et plus
présentable.
La configuration matérielle de notre système est schématisée comme suit :

Figure 13:Configuration matérielle du système

Comme le montre la figure II.6, notre système est équipé de :

- Un serveur de gestion de base de données comportant une importante capacité de

stockage, doit être disponible afin qu’on puisse y accéder à tout moment, et doit avoir
une puissante capacité de traitement dans le cas où plusieurs clients y accèdent en
même temps.
- Les clients web sont des ordinateurs de bureau ou toutes sortes de machine ayant un
navigateur web qui permet d’accéder en local.
- Le serveur web est un serveur qui répond aux commandes des clients.
- Le serveur d’application est l’environnement d’exécution des applications
II.2.3. Capture des besoins fonctionnels
Nous commencerons cette étape par introduire les différentes étapes de processus de 2TUP
comme illustré dans la figure ci-dessous :
 ~ ~

Figure 14:Etapes des processus dans 2UP

On va s’intéresser à la branche gauche du cycle en Y qui est « la capture des besoins

fonctionnels » en décrivant les différentes façons qui seront disponible pour permettre les
acteurs d’utiliser la future application.

1. Identification des acteurs

Un acteur représente l’abstraction d’un rôle joué par des entités externes qui interagissent
directement avec le système étudié. Un acteur peut consulter et/ou modifier directement l’état
du système, en émettant et/ou en recevant des messages éventuellement porteurs de données.
Voici les acteurs du système :

Le préfet, le secrétaire, le (la) caissier(ère) et l’administrateur du système sont les

acteurs qui interagissent avec notre système.
Le préfet comme gestionnaire de l’école, doit s’authentifier sur la plate-forme. Une
fois le préfet authentifié, il peut maintenant procéder à ajouter les agents, le barème, afficher
tout ce qu’il peut afficher, ...

Le secrétaire au service du bureau aussi doit en premier lieu s’authentifier au système,

après il peut démarrer avec ses activités avec le système.

Le(a) caissier(ère), lui aussi peut s’authentifier, modifier son droit d’accès, encoder
l’argent payé par les élèves, encoder les avances sur la prime des enseignants, …
 ~ ~

L’administrateur lui sera en train d’ajouter les utilisateurs au système après son
authentification. Donc il est là pour initialiser le système et contrôler sa bonne mise en
marche.

2. Identification des cas d’utilisation

Un cas d'utilisation (Use case) « représente un ensemble de séquences d'actions réalisées par
le système et produisant un résultat observable intéressant pour un acteur particulier ».

En effet, ils sont des représentations fonctionnelles du système, ils permettent de modéliser les
attentes des utilisateurs afin de réaliser une bonne délimitation du système et également
d'améliorer la compréhension de son fonctionnement. Les cas d’utilisation sont déclenchés
suite à la stimulation d'un acteur externe.

A. Diagramme des cas d’utilisation

Le tableau suivant représente quelques cas d’utilisation et les acteurs.
Acteurs Cas d’utilisations

Administrateur - S’authentifier ;
Ajouter utilisateurs
Modifier son droit d’accès

-
-
Préfet - S’authentifier ;
Modifier son droit d’accès ;
Ajouter agents;
Modifier agents;
Fixer un barème pour les emprunts

-
-
-
-
-
- Ajouter un motif de payement ;
- Modifier un motif de payement ;
- Imprimer la fiche d’emprunt;
- Imprimer la liste d’agents ;
- Imprimer liste de dépenses engagées par mois,
 ~ ~

trimestre et année ;
- Imprimer l’effectif des élèves par classe,
section, option, par sexe;
- Afficher situation caisse par classe, mois,
trimestre et année ;
- Afficher situation élève par classe, options,
mois, trimestre et année.

Secrétaire - S’authentifier ;
- Modifier son droit d’accès;

- Inscrire un élève ;

- Modifier une inscription ;

- Ajouter une section ;

- Modifier une section ;

- Ajouter une option ;

- Modifier une option ;

- Imprimer l’effectif des élèves par classe,

section, option, par sexe;
Caissière - S’authentifier ;
- Modifier son droit d’accès;
- Encoder les frais scolaires payés;
- Enregistrer les dépenses ;
- Emprunter aux agents ;
- Imprimer un reçu pour l’élève ;
- Afficher les dépenses engagées ;
- Afficher situation élèves par
classe, mois, trimestre, …;
Tableau 2:Acteurs associés à leurs cas d’utilisations

Par la suite, nous illustrons graphiquement ce tableau par un diagramme des cas
d’utilisation global (voir la Figure II.8 ci-dessous)
~ ~
 ~ ~

Figure 15: Diagramme de cas d'utilisation

Ce diagramme représente les cas d’utilisation sans en montrer les détails, chaque cas
d’utilisation sera détaillé plus bas.

B. Diagrammes des séquences

Le diagramme des séquences est un diagramme d’interaction entre les objets, qui met
l’accent sur le classement des messages par ordre chronologique durant l’exécution du
système.

Un diagramme des séquences est un tableau dans lequel les objets sont rangés sur l’axe
des abscisses et des messages par ordre d’apparition sur l’axe des ordonnées.
Il est utilisé pour représenter certains aspects dynamiques d’un système : dans le
contexte d’une opération, d’un système, d’un sous-système, d’un cas d’utilisation (un scénario
d’un cas d’utilisation) selon un point de vue temporel.
Jacobson a proposé le premier (encore lui !) des stéréotypes de classes pour décrire
la réalisation d’un cas d’utilisation. Nous allons nous inspirer de ses travaux pour remplacer
le système vu comme une boîte noire (du point de vue de l’analyse) par des objets logiciels
(du point de vue de la conception), comme cela est illustré par les diagrammes des
séquences présentés ci-après29.

Figure 16:passage de l’analyse à la conception

29
Pascal Roques; UML2 par la pratique : Etudes de cas et exercices corrigés ; 5ème Edition Eyrolles ; 2006 ;
p.255
 ~ ~

Nous utiliserons ces trois stéréotypes (avec leurs symboles graphiques associés, dans
les diagrammes des séquences) pour montrer graphiquement comment un message émis par
un acteur traverse les couches présentation, application et métier.

À l’intérieur du système, Jacobson distingue les trois stéréotypes :

<<Boundary>> : classes qui servent à modéliser les interactions

entre le système et ses acteurs.

<<Control>> : classes utilisées pour représenter la coordination, l’enchaînement et

le contrôle d’autres objets. Elles sont en général reliées à un cas d’utilisation particulier.
C’est comme un moteur de Workflow30.

<<Entity>> (Métier) : classes qui servent à modéliser des informations

durables et souvent persistantes.

Présentation des scénarii

Description textuelle des cas d’utilisation31
Une autre présentation intéressante32 consiste à séparer les actions des acteurs et du
système en deux colonnes comme suit :
B.1. Authentification

Sommaire d’identification
Titre : S’authentifier

30
Système permettant d’automatiser un flux d’information au sein d’une organisation ; pas toujours
visible par l’utilisateur, il permet, lorsqu’une donnée est entrée dans le système d’information, de la propager
dans tous les modules du système qui en ont besoin, selon une programmation prédéfinie. (Cours PGI, ERP
(Master CCA), analyse des progiciels, p.7 )
31
Partie obligatoire des cas d’utilisation
32
Cette présentation a été recommandée par C. Larman dans la première version de Applying UML and
Patterns [Larman 97].
 ~ ~

Résumé : ce cas d’utilisation permet à l’utilisateur de s’authentifier au système.

Acteurs : Préfet, caissier et secrétaire.
Description des scénario
Préconditions : Avoir au préalable un compte et saisir son pseudo et mot de
passe.
Post-condition : Le cas démarre après le point 1 de l’enchainement nominal ;
l’utilisateur s’authentifie.
Scénario nominal
1. L’utilisateur saisi son pseudo 2. Le système vérifie les données
et son mot de passe entrées après validation auprès de la base
de données.
3. Le système affiche l’espace associé
à
l’utilisateur.

Enchainement alternatif
A1 : pseudo et mot de passe provisoirement erroné
L’enchainement A1 démarre au point 1 du scénario nominal.
A2 : le système indique à l’utilisateur que les informations d’authentification
sont erronées, pour la première fois ou deuxième fois. le scénario nominal reprend au
point 1.
Enchainement d’erreur
E1 : pseudo et mot de passe définitivement erroné
L’enchainement E1 démarre au point 1 du scénario nominal.
E2 : le système indique à l’utilisateur que le code est erroné, pour la troisième
fois.
Le cas d’utilisation se termine en échec.
Tableau 3:Description textuelle du cas d’utilisation Authentification
 ~ ~

- Diagramme des séquences du scenario nominal « s’authentifier»

Dans ce diagramme loop (1,3) indique qu’il aura une répétition d’affichage de
l’interface d’authentification jusqu’à la validation du pseudo et mot de passe (voir Figure
II.10).
Figure 17:Diagramme des séquences « Authentification »

B.2. Ajouter utilisateur

Sommaire d’identification
Titre : Ajouter utilisateur
Résumé : ce cas d’utilisation permet à l’administrateur d’ajouter un utilisateur.
Acteur : Administrateur,
Description des scénario
Pré-condition : Afficher formulaire d’ajout utilisateur.
Post-condition : Le cas démarre après le point 4 de l’enchainement nominal ; utilisateur
ajouter.
Scénario nominal
1.Le système affiche un formulaire
d’ajout d’un utilisateur.
 ~ ~

2. L’administrateur saisit les données

nécessaires et soumet le formulaire au
système. 3. Le système vérifie la validité des
données.
4. Le système envoie un message de
confirmation.

5. L’administrateur valide la boite de

dialogue par OK.
Enchainement
alternatif A1 : données
invalides
L’enchainement A1 démarre au point 2 du scénario nominal.
A2 : le système indique les champs dont les données sont invalides une ou deux fois. le
scénario nominal reprend au point 2.
Enchainement d’erreur
E1 : données définitivement erronées
L’enchainement E1 démarre au point 2 du scénario nominal.
E2 le système indique à l’administrateur que les données sont erronées, pour la troisième
fois.
Le cas d’utilisation se termine en échec.
Tableau 4:Description textuelle du cas d’utilisation Ajouter utilisateu

Diagramme des séquences du scénario nominal « Ajouter utilisateur »

Figure 18:Diagramme des séquences du scénario « Ajouter utilisateur »

 ~ ~

B.3. Encodage des frais scolaires payés

Sommaire d’identification
Titre : Encoder frais scolaires payés
Résumé : ce cas d’utilisation permet à la caissière d’encoder les frais scolaires versés par les
élèves.
Acteur : Caissière.
Description des scénarii
Pré-condition : Afficher formulaire d’encodage des frais scolaires.
Post-condition : Le cas démarre après le point 4 de l’enchainement nominal ; frais scolaires
encoder.
Scénario nominal
1.Le système affiche un formulaire
d’encodage des frais scolaires.
2. La caissière remplit les champs de saisie et
soumet le formulaire au système.
3.Le système vérifie la validité des données.
4 : Le système envoie un message de
confirmation.

5. La caissière valide la boite de dialogue

par OK.
Enchainement alternatif A1
: données invalides
L’enchainement A1 démarre au point 2 du scénario nominal.
A2 : le système indique les champs dont les données sont invalides une ou deux fois. le
scénario nominal reprend au point 2.
Enchainement d’erreur
E1 : données définitivement erronées
L’enchainement E1 démarre au point 2 du scénario nominal.
E2 : le système indique à la caissière que les données sont erronées, pour la troisième fois.
Le cas d’utilisation se termine en échec.

Tableau 5:Description textuelle du cas d’utilisation Encoder des frais scolaires

- Diagramme de séquence du scénario « Encoder frais scolaires payés »

Figure 19:Diagramme des séquences du scénario « Encoder frais scolaires payés

B.4. Enregistrement des dépenses

Sommaire d’identification
Titre : Enregistrer dépenses
Résumé : ce cas d’utilisation permet à la caissière d’enregistrer les dépenses engagées.

Acteur: Caissière.
 ~ ~

Description des scénarii

Pré-condition: Afficher formulaire d’enregistrement des dépenses.
Post-condition : Le cas démarre après le point 4 de l’enchainement nominal ; dépense
enregistrée
Scénario nominal
1.Le système affiche un formulaire
d’enregistrement des dépenses.
2. La caissière remplit les champs de
saisie et soumet le formulaire au système.
3 :Le système vérifie la validité des
données.
4 :Le système envoie un message de
confirmation.

5. La caissière valide la boite de

dialogue par OK.
Enchainement alternatif
A1 : données invalides
L’enchainement A1 démarre au point 2 du scénario nominal.
A2 : le système indique les champs dont les données sont invalides une ou deux fois. le
scénario nominal reprend au point 2.
Enchainement d’erreur
E1 : données définitivement erronées
L’enchainement E1 démarre au point 2 du scénario nominal.
E2 : le système indique à la caissière que les données sont erronées, pour la troisième
fois.
Le cas d’utilisation se termine en échec.
Tableau 6:Description textuelle du cas d’utilisation Enregistrement des dépenses
 ~ ~

- Diagramme des séquences du scénario « Enregistrer dépenses »

Figure 20:Diagramme des séquences du scénario « Enregistrer dépenses »

NB : Pour le reste des cas d’utilisation, nous ne détaillons pas tout pour raison de simplifier
mais l’enchainement logique est le même.
C. Diagramme d’activités.
Le diagramme d’activités met l’accent sur les traitements. Il est donc particulièrement adapté
à la modélisation du cheminement de flots de contrôle et de flots de données. Il permet ainsi
de représenter graphiquement le comportement d’une méthode ou le déroulement d’un cas
d’utilisation.
Les diagrammes d’activités sont relativement proches des diagrammes d’états transitions dans
leur présentation, mais leur interprétation est différente.
Une activité représente une exécution d’un mécanisme, un déroulement d’étapes
séquentielles. Le passage d’une activité vers une autre est matérialisé par une transition. Les
transitions sont déclenchées par la fin d’une activité et provoquent le début immédiat d’une
autre.
Symboles utilisés :
 ~ ~

Nœud d’action
Nœud de contrôle de décision Contrôle
d’activité à l’invocation.
Contrôle de fin d’activités.
Accepter l’action sur l’événement temporel.
Contrôle qui fractionne un flux en plusieurs flux courants.

C.1. Diagramme d’activités pour l’authentification

Figure 21:Diagramme d’activités pour l’authentification

C.2. Diagramme d’activités pour l’ajout d’un utilisateur.

 ~ ~

Figure 22:Diagramme d’activités pour l’ajout d’un utilisateur.

C.3. Diagramme d’activités pour l’ensemble d’opérations qui se passent à la caisse

Figure 23:Diagramme d’activités pour l’ensemble d’opérations qui se passent à la caisse.

Représentation des classes

La modalisation objet est utilisée dans le langage UML pour définir des objets métiers et
l’architecture de l’application. Ces objets sont créés en tant qu’instance de classe et
interagissent dynamiquement pour offrir le comportement décrit par les cas d’utilisation.
La modélisation objet définit le comportement requis par les différentes classes pour assurer la
bonne mise en place des cas d’utilisation et des règles de gestion.
Les objets constituent la base de l’architecture des applications, ils peuvent être réutilisés à
travers des domaines d’application ou encore être identifiés et dérivés directement des cas
d’utilisation ou des domaines d’application. Une classe est composée :
 Attributs : représentant des données dont les valeurs représentent l’état de
l’objet.
 La méthode : il s’agit des opérations applicables aux objets.
 ~ ~

Formalisme général et exemple

Une classe se représente à l’aide d’un rectangle comprenant plusieurs compartiments.

Les trois compartiments de base sont :

- La désignation de la classe ; -
La description des attributs et
- La description des opérations.
Nom
de la
c
lasse
A
ttributs
…
Opé
rations
…
Figure 24:description complète d’une classe

Représentation des associations entre les classes.

Le modèle de données en UML comprend trois associations génériques principales :

Généralisation, association et dépendance ; à partir de ces trois associations de base, nous
représentons ainsi les différents types d’association qui décrivent les dépendances entre les
classes déjà citées

Association simple : les associations simples sont des liaisons logiques entre entités.

Les cardinalités : précisent combien d’objets de classe considérée peuvent être liés à
un objet de l’autre classe.

Le tableau suivant illustre une représentation des cardinalités ;

Cardinalités Désignation
1 Un et un seul
0…1 Zéro ou un
N Entier naturel
m… n De m à n (deux entiers
naturels)
0…* De 0 à plusieurs
1…* De 1 à plusieurs
Tableau 7:Représentation des cardinalités
 ~ ~

Le tableau suivant illustre les associations simples en indiquant leurs désignations, les classes
participantes et leurs cardinalités.
N Désignation Classes participantes Cardin
° alités
1 Effectuer Elèves 0…*
Payements 1…*
2 Prendre Inscriptions Elèves 1…*

1…*
3 Faire Inscriptions 1…*
Options 1…*
4 Encoder Utilisateurs 1
Dépenses 1…*
5 Contenir Sections 1
Options 1…2
6 Passer Payements 1…*
Options 1…*
7 Concerner Payements 1…*
Motifs 1…*
8 Assurer Utilisateurs 1
Payements 1…*
9 Recevoir Agents 1
Avance Salaires 1…*
1 Encoder Utilisateurs 1
0 Avances 1…*
salaires
1 Avoir Inscriptions 1
1 Relevés 1
1 Concerner Seuils 1
2 Options 1
1 Concerner Seuil 1
3 s Motifs 1
Tableau 8:Représentation des associations simples
 ~ ~

Règles de gestion.
Une règle de gestion décrit une condition d’exécution d’une action. Ci-dessous nous
présentons les différentes règles de gestion de notre application :

- RG1 : Un utilisateur peut être un préfet, un secrétaire, une caissière (des supers
utilisateurs) ou un administrateur.
- RG2 : le préfet peut effectuer des différentes dépenses à des dates différentes.
- RG3 : le secrétaire peut inscrire plusieurs élèves dans différentes classes réparties dans
différentes options et pendant différentes années.
- RG4 : 0 ou plusieurs élèves inscrits peuvent effectuer un ou plusieurs payements.
- RG6 : une caissière peut encoder plusieurs payements, encoder plusieurs dépenses et
accorder des emprunts aux agents.
- RG5 : Un administrateur gère la plateforme de suivi de gestion financière
D. Diagramme des classes.
Une classe est un ensemble d’objets ayant les mêmes propriétés (attributs) et un même
comportement. Au cours de l’exécution de notre programme, les identificateurs d’un objet
correspondront à une adresse mémoire quelconque.
~ ~
 ~ ~

Figure 25:représentation du diagramme des classes.

La figure ci-dessous récapitule les tableaux précédents dans un diagramme de classes qui
Contient les informations telles que les classes, les associations, les règles de gestion et les
propriétés.
Modèle relationnel des données optimisées:
Dans ce qui suit, nous présentons le modèle relationnel de données optimisées : Pour
représenter une association du type plusieurs vers plusieurs, il faut introduire une nouvelle
relation dont les attributs sont les clés primaires des classes en association et dont la clé
primaire est la concaténation de ces deux attributs.

En appliquant les règles de passage ci-haut marquées, nous obtenons le modèle relationnel
suivant :
~ ~
 ~ ~

Figure 26:Modèle des données relationnelles optimisées

E. Diagramme des composants

Le diagramme des composants ci-dessous, montre les différents types de composants
d’exploitation du système.

Figure 27:Diagramme des composants

F. Diagramme de déploiement

Nous allons finalement décrire l’implantation physique de notre application de suivi

de gestion financière d’une école grâce à un dernier type de diagramme proposé par UML :
le diagramme de déploiement.
Le diagramme de déploiement montre la configuration physique des différents
matériels qui participent à l’exécution du système, ainsi que les artéfacts qu’ils supportent.
Ce diagramme est constitué des « nœuds » connectés par des liens physiques. Les symboles
des nœuds peuvent contenir des artéfacts (et non plus des composants comme en UML 1).
Un artéfact modélise une entité physique comme un fichier. On le représente par un
 ~ ~

rectangle contenant le mot-clé « artifact ». On explicite la présence d’un artéfact sur un

nœud de déploiement en imbriquant son symbole dans celui du nœud englobant. Si un
artéfact implémente un composant ou une classe, on dessine une flèche en pointillés avec le
mot-clé « manifest » allant du symbole de l’artéfact au symbole du composant qu’il
implémente.
Chaque acteur a son propre poste client qui est un « PC » connecté au serveur
intranet de l’école, lequel est lui-même un PC serveur. Ce serveur intranet contient en
particulier l’application d’authentification. Chacun des trois acteurs a en outre sa propre
interface homme-machine, matérialisée par une vue. Ces trois vues utilisent un même
service d’authentification général, contenu par le serveur intranet. Les agents, les élèves sont
stockés dans une base de données spécifique, de même que les dépenses et d’autres
ressources métiers.
Le serveur métier héberge pour sa part les autres applications ainsi que les bases de
données. Les différents types de nœuds sont donnés à titre d’exemple sur la figure suivante :

Figure 28: Diagramme de déploiement

Conclusion partielle.
Nous avons présenté, dans ce chapitre, la conception de notre système à travers les
différents diagrammes UML (diagramme de cas d’utilisation, diagramme de séquence,
diagramme d’activité, diagramme de classe ,etc.). Dans le chapitre suivant, nous traiterons de
la présentation de l’application et/ou résultat du travail.
 ~ ~

QUATRIEME CHAPITRE REALISATION DU NOUVEAU SYSTEME

D’INFORMATION
Dans ce chapitre, les points suivants seront développés, le langage de programmation
utilisé, le système de gestion de base des données, la réalisation de l’application,
l’estimation du coût de l’application mis en place, le manuel guide utilisateur et sera bouclé
la présentation des codes sources.
IV.1. CHOIX DU LANGAGE DE PROGRAMMATION ET DE SGBD
A. CHOIX DU LANGAGE DE PROGRAMMATION

Selon le dictionnaire jargon informatique, un langage de programmation est un langage qui

permet d’écrire des programmes informatiques. Il existe plusieurs langages de
programmations, tels que le langage C, le langage C++, le langage JAVA, le langage SQL,
le langage PHP, le langage HTML, etc.
Notre choix est porté sur le langage PHP combiné avec les langages HTML et CSS et
JAVASCRIP.
Le langage HTML, ou Hyper TextMarkupLanguage, permet de retracer et de mettre en
forme des documents variés, depuis du simple texte jusqu’à des documents multimédia
riches avec la définition d’HTML 5 [Rém].
Le rôle est en quelque sorte de « décorer » votre page web, lui donner de l’allure. On utilise
le CSS en particulier pour réaliser la mise en page du site, pour définir la police, la taille du
texte, la couleur du texte et du fond, etc. [Mat 2007].
Le sigle PHP signifiait à l’origine Personal Home Page. Pour RasmusLerdorf, l’auteur de ce
qui allait devenir le langage de script côté serveur incorporable dans tout document
XHTML que nous connaissons, il s’agissait alors d’ajouter quelques fonctionnalités à ses
pages personnelles. Il permet de créer des pages Web dynamiques et interactives. Le PHP
permet en outre de créer des pages interactives. Une page interactive permet à un visiteur de
saisir des données personnelles. Ces dernières sont ensuite transmises au serveur, où elles
peuvent rester stockées dans une base de données pour être diffusées vers d’autres
utilisateurs. Un visiteur peut, par exemple, s’enregistrer et retrouver une page adaptée à ses
besoins lors d’une visite ultérieure. Il peut aussi envoyer des e-mails et des fichiers sans
avoir à passer par son logiciel de messagerie. En associant toutes ces caractéristiques, il est
possible de créer aussi bien des sites de diffusion et de collecte d’information que des sites
d’e-commerce, de rencontres ou des blogs.Pour contenir la masse d’informations collectées,
PHP s’appuie généralement sur une base de données, généralement MySQL mais aussi
 ~ ~

SQLite avec PHP 5, et sur des serveurs apaches. PHP, MySQL et Apache forment d’ailleurs
le trio ultradominant sur les serveurs internets. Quand ce trio est associé sur un serveur à
Linux, on parle de système LAMP(Linux, Apache, MySQL, PHP). PHP est utilisé
aujourd’hui par plus de la moitié des sites de la planète et par les trois quarts des grandes
entreprises françaises. Pour un serveur Windows, on parle de système WAMP, mais ceci est
beaucoup moins courant.
Comme beaucoup d’autres langages, le PHP a été spécialement conçu pour le
développement d’applications web, il peut être intégré au HTML. Pour ce faire, le code
PHP est inclus entre une balise de début (ensemble de symboles) et une balise de fin qui
permettent au serveur de passer en mode PHP. La partie PHP correspond donc à la partie
créative et dynamique du document HTML finalement envoyé par le serveur et que le
navigateur transformera en page web.
Dans l’utilisation du PHP, trois composants sont nécessaires :
 Un analyseur PHP ;
 Un serveur web (Apache par exemple) ;
 Un navigateur web.
Le PHP possède de nombreuses fonctions permettant d’exploiter les bases de données parmi
lesquelles nous citons : InterBase, PostgreSQL, dBAse, MySQL, IBM DB2, ODBC,
Informix, Oracle et Ingres, pour ne citer que les plus connues [Van 2005].
B. CHOIX DU SYSTÈME DE GESTION DE GESTION DE BASE DE DONNEES
(SGBB).
Aujourd'hui, la disponibilité de systèmes de gestion de bases de données fiables permet aux
organisations de toutes tailles de gérer des données efficacement, de déployer des
applications utilisant ces données et de les stocker. Les bases de données sont actuellement
au cœur du système d'information des entreprises.
En informatique, un système de gestion de base de données (SGBD) est un logiciel système
destiné à stocker et à partager des informations dans une base de données, en garantissant la
qualité, la pérennité et la confidentialité des informations, tout en cachant la complexité des
opérations.
Un SGBD (en anglais DBMS pour database management system) permet d'inscrire, de
retrouver, de modifier, de trier, de transformer ou d'imprimer les informations de la base de
données. Il permet d'effectuer des comptes-rendus des informations enregistrées et comporte
des mécanismes pour assurer la cohérence des informations, éviter des pertes d'informations
dues à des pannes, assurer la confidentialité et permettre son utilisation par d'autres logiciels.
 ~ ~

Selon le modèle, le SGBD peut comporter une simple interface graphique jusqu'à des
langages de programmation sophistiqués.
Une Base de Données (BD ou BDD) est un ensemble structuré et organisé permettant le
stockage de grandes quantités d’informations afin d’en faciliter l’exploitation (ajout, mise à
jour, recherche).
Un Système de Gestion de Base de Données(SGBD) est un ensemble de programmes qui
permet la gestion et l’accès à une base de données.
Les bases des données ont quelques caractéristiques, Les données sont :
 Enregistrées sous une forme structurée ;
 Accessibles ;
 Non redondantes ;
 Cohérentes.
Objectifs d’un SGBD
Un système de gestion de base des données dispose les caractéristiques suivantes :
 Description / modélisation des données
 Insertion des données
 (Sécurité et intégrité des données)
 Accès aux données
 (Gestion des accès concurrents)
 (Sécurité et intégrité des données)
 Mise à jour des informations
Intérêt d’un SGBD
Le système de gestion de base des données se fonde sur les intérêts suivants :
 Structuration rigoureuse des données
 Stockage de données volumineuses
 Diffusion de l’information
 Mise à jour de l’information
 Exploitation : accès à l’information.
Types de SGBD

Dans la liste de SGBD qui existe, nous pouvons citer certains qui sont plus couramment
utilisés.
 SQL(StructuredQuery Langage)
 ~ ~

Le SQL est un langage de requêtes, une norme utilisée par de nombreux SGBD
variantes (ex. : MySQL).
 Access
Access est un logiciel grand-public de la suite OFFICE manipulant la base des
données (BD) par interface.
Autres systèmes de gestion de base des données : Oracle, SQLServer, etc.
Dans le cadre de ce travail, le choix est porté sur le système de gestion de base des données
MySQL qui un SGBD centralisé, embarqué, distribué, pour entreprises, groupes de travail
et particuliers
 Outils utilisés
Dans la réalisation de notre système (partie informatique et électronique),

nous avons utilisés les outils ci-après :

 L’éditeur de code Notepad++ : pour la programmation de l’application ;

 Le serveur WAMP ;
 L’environnement matériel
Pour le développement de notre application, nous avons utilisés l’environnement
suivant :
IV.2. Manuel utilisateur
IV.2.1. Description Fonctionnelle
 Un ordinateur DELL ;
 Capacité du disque dur : 500 GB ;
 Processeur : Intel(R) Core (TM) i5-4200M CPU @ 2.50 GHz 2.50 GHz
 Mémoire RAM : 4.00 Go ;
 Type de système : Système d’exploitation 64 bits, processeur x64.
IV.2.2. Configuration du système
Pour l’implémentation du présent système de gestion de frais scolaire, n’importe quel
ordinateur avec un système d’exploitation peut le supporter.
L’installation du serveur local WAMP pour les machines avec windows dans le matériel où
le système devra fonctionner est aussi capitale et contraignante sans laquelle le système ne
peut fonctionner.
Au moins un navigateur doit être installé dans la machine surtout le Navigateur Opéra Mini
pour l’exécution du système.
IV.2.3. Comment démarrer le système
Avant de démarrer le système, le serveur local « wamp » doit être d’abord démarré. Par la
suite, le lancement du navigateur, n’importe lequel où l’on doit saisir l’URL suivant :
 ~ ~

« http://127.0.0.1/ Frais Scolaire» du serveur de l’emplacement du système dans la barre

d’adresse.
 Le Framework CodeIgniter-3.0.0
Nous avons beaucoup utilisé ce Framework pour vouloir organiser les codes et faciliter leur
manipulation car il respect bien le modèle MVC. Voyons en quelques mots ce qu’un
Framework.
En programmation informatique, un Framework est un kit de composants logiciels
structurels, qui définissent les fondations et les grandes lignes de l'organisation de tout ou
partie d'un logiciel (architecture)33.
Autrement dit, un Framework PHP est un ensemble de codes qui fournit une organisation
ainsi qu'un grand nombre de fonctionnalités, dont le nombre et la qualité diffèrent selon les
Framework. Ainsi, la maîtrise d'un Framework vous permet de ne vous occuper que de
votre site et de laisser le reste à d'autres développeurs, c'est-à-dire sa base, son socle, mais
aussi tout ce qui s'articule autour : les classes, les fonctions, etc.
Si l'on devait résumer le Framework en une phrase, on dirait que CodeIgniter est une base
réduite en fonctionnalités mais hautement performante, pouvant faire appel à des classes et
à des fonctions très complètes lorsque le besoin s'en fait sentir.
 L’architecture globale d’une application MVC
L'architecture de CodeIgniter est basée sur le patron de conception MVC. Il s'agit d'un
patron de conception permettant de séparer le code d'accès aux données, la présentation et le
contrôle de l'ensemble des actions.
MVC est l'acronyme de Modèle-Vue-Contrôleur ! Autrement dit, nous allons séparer notre
application en au moins trois parties

Figure 29:Modèle-vue-contrôleur

33
Citation : Wikipédia
 ~ ~

 a. Le contrôleur
Le contrôleur est ce qui va être appelé en premier. Il n'y a qu'un seul contrôleur par URL.
Donc, deux URL différentes appelleront deux contrôleurs différents. Le contrôleur se
charge d'appeler tous les composants : bibliothèques, helpers, vues, modèles, mais aussi de
faire les nombreuses vérifications nécessaires.
Le contrôleur sera donc la partie la plus importante pour le développeur PHP. Tout ce qui se
passe dans le contrôleur sera invisible aux yeux des visiteurs. Le contrôleur n'a pas pour rôle
d'envoyer au navigateur un message d'erreur, il a pour rôle de trouver cette erreur.
L'affichage de cette erreur se fera via une autre couche d'abstraction. Avec CodeIgniter,
vous verrez que chaque contrôleur est une classe qui est appelée selon l'URL. Et comme
toute classe qui se respecte, elle possède un certain nombre de méthodes qui représenteront
les différentes actions que le contrôleur peut effectuer.
 Les vues
Les vues sont directement responsables de tout ce que l'on va envoyer aux
navigateurs. Les vues seront donc composées principalement de HTML. Nous y trouverons
aussi du PHP qui nous servira pour afficher des variables et faire quelques boucles.
Il n'y a pas de limite au nombre de vues. Alors qu'avec les contrôleurs, nous avions
une URL par contrôleur, ici, nous pouvons très bien avoir cinq vues par contrôleur. Le rôle
du contrôleur est aussi d'appeler la bonne vue. De plus, rien n'empêche le contrôleur de faire
appel à plusieurs vues.
 c. Le modèle
Cette dernière couche d'abstraction permet de faire le lien entre le contrôleur et la
base de données. Il est toujours conseillé de séparer convenablement les requêtes que vous
envoyez à la base de données et les instructions qui vont utiliser ces données. Le modèle
permettra donc d'envoyer des requêtes à la base de données et d'en retourner le résultat sous
forme brute (sans HTML). Nous y trouverons donc des fonctionnalités typiques des bases
de données (ajouter, modifier, supprimer...). Dans la plupart des cas, si les bases de données
ont bien été pensées, il y aura un modèle pour chaque table34.

34
www.openclassrooms.com
 ~ ~

 Arborescence d’une application respectant ce modèle MVC

 La classe PDF PHP TCPDF

TCPDF est une classe PDF de PHP qui nous a servi de générer nos rapports ou états
de sortie en format PDF (portable document file).
 ~ ~

IV.3. Référence pour l’utilisation du système

Pour l’utilisation de l’application, après avoir installé tous les éléments nécessaires
(WAMP, Navigateur), une fois l’application lancée, l’utilisateur se retrouve devant
l’interface suivante :

En voulant se connecter à la base des données, cliquez sur « Connectez-vous» et la

fenêtre suivante apparait :

Après avoir fourni le login et le mot de passe, si correcte, dans la page

administrateur Cliquez sur Login et vous vous retrouver devant l’interface de
l’administrateur qui est la suivante :
 ~ ~

L’administrateur (super utilisateur) a la possibilité d’ajouter les utilisateurs du

système à partir du bouton « Manage_users » au coin supérieur gauche, modifier son droit
d’accès « bouton « Mon compte » et en fin il peut se déconnecter au système par le bouton
« Déconnexion » au coin supérieur droit.
Avec le bouton « Manage_users », nous avons par exemple le résultat suivant :

Via l’image ci haut l’utilisateur peut ajouter d’autres utilisateurs avec le bouton
Nouvel nous avons cette interface :
 ~ ~

Avec le bouton « Mon compte », c’est le compte de l’utilisateur qui est connecter
qui doit apparaitre de la sorte : là il peut modifier son compte.

a) Connecté entant que Préfet, ses cas d’utilisation sont les suivants :

Une foi le mot de passe et le login sont correcte l’interface du préfet

apparait comme suit :
 ~ ~

Le préfet avec son menu peut : ajouter, modifier et supprimer si nécessaire un agent,
un motif de paiement, un seuil de versement à la caisse, un barème pour emprunt aux agents
et seulement faire la modification des avances et dépenses en cas d’erreurs encodées à la
caisse, modifie son droit d’accès au système comme tout utilisateur le fera, affiche ses
rapports ou ses états qu’il est permis de voir et en fin se déconnecte au système.
Les pages d’ajout, modification et suppression ont presque de ressemblance sur le
plan présentation que celle présentée ci-haut.

b). Connecté entant que secrétaire :

Une foi le mot de passe et le login sont correcte l’interface du préfet

apparait comme suit :
 ~ ~

Le secrétaire aussi peut ajouter, modifier et supprimer une instance de la classe

élèves, inscriptions, sections, options et afficher ses états de sortie ; enfin peut modifier son
droit d’accès aussi et se déconnecter. Un exemple de la page d’ajout d’un élève:

Une fois qu’on veut ajouter un nouvel élève, cliquer sur le bouton « Nouvel » et
voici le résultat déclenché :
 ~ ~

En remplissant le formulaire et en cliquant sur le bouton « Enregistrer », vous ajoutez

une information dans la base.

C. Connecté entant que caissière :

 ~ ~

Une foi le mot de passe et le login sont correcte l’interface du préfet

apparait comme suit :

A la caisse, se font : l’ajout, modification et suppression d’une instance de la classe

perceptions, l’ajout d’une instance de la classe avances et dépenses et enfin l’affichage des
rapports.

Pour chaque requête il y a différents critères qui sont définis et à remplir pour
envoyer cette dernière. Par exemple, affichons « La liste des élèves par option », dans le
menu « autres vues » cliquez sur « La liste de paie par mois » et vous obtiendrez ce qui
suit :
 ~ ~

Remplissez ce formulaire (les trois premiers champs c’est à sélectionner) et cliquez sur
le bouton « Envoyer » et vous obtenez le résultat qui suit :

Tous ces menus sont manipulables de la manière ci-haut présentée.

 La caissière
Chargée de recouvrement des frais scolaires, d’encodage des avances sur prime des
agents et des dépenses engagées au cours d’une période peut afficher ce qui suit :
 ~ ~

Elle affiche la même chose que le préfet sauf qu’elle affiche ou imprime en plus le
reçu comme preuve de paiement pendant l’encodage des frais scolaires. Une fois lancer un
enregistrement, automatiquement il y a lancement du reçu à imprimer et/ou elle peut
imprimer un reçu n’importe quand car il est associé au nom de chaque élève. Voici en bref
comment ça se passe :

Sur cette page nous avons des enregistrements concernant la perception, la petite
flèche montre le bouton sur lequel on doit cliquer pour afficher le reçu de l’élève
correspondant à son nom. Une fois le bouton pressé, voici le résultat :
 ~ ~

 Reçue de Paiement

 Liste des Elèves Ayant déjà payer quelque chose par période dans une classe
 ~ ~

 Liste des Elèves Ayant déjà payer quelque chose sur une tranche (Première
Trache)

INSTITUT MWANGA D’UVIRA

 Liste des Elèves Inscrits dans la classe de Septième

INSTITUT
INSTITUTMWANGA
MWANGAD’UVIRA
D’UVIRA

:
 ~ ~

IV.4. Estimation du coût du logiciel

 Détermination du coût du logiciel par la méthode COCOMO II
COCOMO II est un modèle qui permet d'estimer le coût, l'effort et le temps nécessaire au
développement d’un logiciel. C’est une méthode pour estimer le coût d'un projet logiciel
dans le but d'éviter les erreurs de budget et les retards de livraison, qui sont
malheureusement habituels dans l'industrie de développement logiciel.
Le modèle original de COCOMO a été édité la première fois par le Dr.Barry Boehm en
1981 et a reflété les pratiques en matière de développement de logiciel de cette époque.
Durant les 15 années suivantes, les techniques de développement de logiciel ont changé
[Rud 2003].
Il existe plusieurs versions de COCOMO, notamment la version COCOMO 81-COCOMO
de base, COCOMO 81-intermédiaire, COCOMO 81-détaillé et la version COCOMO II.
La méthode COCOMO 81 se base sur une approche algorithmique pour déterminer «
l’effort » et le « temps de développement » d’une application. [Rud 2003].
Cette méthode couvre les phases du cycle de développement
Suivantes :
 Aspect technique
 Analyse fonctionnelle
 Analyse organique
 Programmation
 Tests
 Documentation
 Qualité
 Contrôle
 Gestion
 Encadrement
 Suivi du projet
 Gestion des configurations
 Evolution du produit
Elle ne prend pas en compte les activités concernant les
Phases ne faisant pas partie du cycle de développement
 Les études de faisabilité
 La spécification des besoins techniques
 ~ ~

 La validation opérationnelle chez le client

 L’exploitation
 La maintenance

Dans le cadre de ce travail, nous allons utilisé la version COCOMO 81- COCOMO
de base car c’est elle qui inclus le type de notre projet, projet simple ou organique parce que
exécuté par une seule personne.
Le tableau suivant reprend la structure de COCOMO de base :
Nature du projet Estimation effort Estimation durée
Simple (Organique) PM=2,4(KLOC)1,05 D=2,5(PM)0,38
Modéré (semi de PM=3,0(KLOC)1,12 D=2,5(PM)0,35
taché)
Complexe PM=3,6(KLOC)1,20 D=2,5(PM)0,32
(Embarqué)
Avec :
PM= Effort en personne mois ;
KLOC= Milliers de ligne de code
D=Durée en mois
P= PM/D= Nombre de personnes requises
N.B : Dans le modèle de base, M=1.
Notre projet de mémoire comporte 5303 lignes des codes.
KLOC=5303/1000=5,303
PM=2,4(KLOC)1,05= 2,4(5,303)1,05=13,8
D=2,5(PM)0,38= 2,5(13,8)0,38=6,8 mois à peu près 7 mois.
P= PM/D=13,8/6,8=2 personnes
Dans notre projet, un employé a un salaire mensuel de 550$.
Coût du projet= P*D*Salaire mensuel=2*7*500=7700$
Le coût de notre logiciel s’élève à 7700$au cas où un chaque employé allait recevoir
550$ par mois.
 ~ ~

IV.5. PRESENTATTION DES CODES SOURCES ET DES ETATS DE SORTIE

IV.5.1. CODE SOURCE (pas tous les codes)
~ ~
~ ~
 ~ ~

Conclusion
A toute chose sa fin, nous voici à la fin de notre rédaction qui a porté sur « la mise en place
d’une application web de gestion de frais scolaire : cas de l’Institut Mwanga/Uvira».

L'objectif principal étant de développer une application web qui permettra au gestionnaire de
l’Institut Mwanga de contrôler et rationaliser les recettes et les dépenses aisément enfin d’en
expliquer les écarts suivants les prévisions du budget au cours d’une période donnée. Juste
permettre à celui-ci de gagner son minimum de temps pendant ce contrôle car il ne sera plus
en train d’aller à la pêche de l’information dans d’autres services qui la détiennent mais qu’il
puisse l’avoir non en effectuant des vas et vient, mais en la recherchant d’une manière
automatique dans la base des données commune dans laquelle chaque service enregistre ces
données et d’en retrouver dans le cas échéant pendant qu’il est à son poste de travail.
Pour atteindre les objectifs fixés dans ce travail, nous l’avons subdivisé en trois chapitres :
Le chapitre premier a porté sur les généralités (présentation) sur le milieu d’étude et cadre de
référence (description des certains concepts ayant trait avec notre sujet).
Le deuxième chapitre a été consacré à l’étude et modélisation du système informatisé, dans
ce dernier nous avons capturé les différents besoins (fonctionnels et non fonctionnels) du
système à mettre en place et exploité certains diagrammes UML pour structurer et faire
comprendre tout on long du processus de développement ce qu’est notre application et ce
qu’elle sera en train faire.
En fin le chapitre troisième a porté sur la présentation de l’application et/ou résultat de
travail, dans celui-ci nous avons présenté ce que fait l’application (les différentes vues de
celle-ci) ou alors son mode de fonctionnement.
Arriver à ce stade, il ne s'agissait pas d'une improvisation, mais une conception qui a tenu
compte de certaines règles à respecter du langage UML et l’implémentation d’une
application web.
Après analyse du système existant (en monoposte), nous avons remarqué que le problème
de partage des données se fait sentir dans cette institution éducative du coté paiement de frais
scolaire ; ce qui fait orchestrer beaucoup d’erreurs, de lenteur, de routine car chaque service
travail sur ses données. Le problème qui s’ajoute est que le contrôle de tous les flux
financiers entre autres le recouvrement des frais scolaires, les avances sur la prime, la paie
des agents et les dépenses engagées au cours d’une période est moins efficace.
 ~ ~

Cela étant, nous avons opté à une solution de la technologie web pour faire face à ces
problèmes pour faire interagir simultanément les utilisateurs du présent logiciel aux mêmes
données.
Ainsi, compte tenu des questions de départ, cette application garantirait et/ou permettrait :
 Le partage des données entre services car accédant tous à une même base de données;
 Au préfet d’ajouter et mettre à jour les propriétés des agents, de déterminer le seuil de versement à
la caisse, de fixer le barème pour emprunt des agents, ajouter un motif de paiement, de mettre à
jour les emprunts et dépenses encoder par la caissière, d’afficher les listes des élèves par classe,
par sexe, par option au cours d’une année scolaire, de consulter la situation de la caisse par mois et
la situation financière des élèves par classe et par année , d’afficher les listes des emprunts par
mois, d’afficher les listes des dépenses par mois et d’afficher la liste de paie des agents ;
 Au secrétaire d’inscrire les nouveaux élèves et les anciens dans les classes montantes et d’afficher
les listes possibles des élèves inscrits et en fin
 A la caissière d’encoder les frais scolaires, d’enregistrer les dépenses engagées pendant une
période donnée et les emprunts auprès des agents, de consulter la situation de la caisse par mois et
la situation financière des élèves par classe et par année, d’afficher les listes des dépenses et des
emprunts.
Tenant compte de ces différentes possibilités que cette application offre à ses utilisateurs, il y
aurait diminution de la lourdeur des tâches de routine, la lenteur dans le processus, les
erreurs inattendues ; et cette application aiderait au gestionnaire à prendre des décisions à
partir des informations nettement obtenues et en fin elle permettrait à chaque service de
mettre à jour et consulter les données d’une même base de données sur une machine distante.
En confrontant alors les hypothèses émises aux résultats auxquels nous avons abouti, nous
confirmons sans doute que dans l’ensemble notre application constitue une solution aux
différentes interrogations identifiées dans notre milieu de recherche ; car l’application est
prête à être déployée sur des serveurs locaux sur lesquels d’autres machines clientes peuvent
se connecter pour se changer des informations d’une même base de données qui a des
données consultées et mises à jour dans chaque service au temps opportun.
La voie reste ouverte aux autres chercheurs qui voudraient nous emboîter le pas en menant
une recherche semblable à la nôtre. Ils pourront par exemple penser à une plateforme qui
peut s’adapter à tout mode de fonctionnement des écoles secondaires dans la province du
Sud-Kivu et/ou de la République Démocratique du Congo en générale dans le processus
financier et faire interagir le système aux partenaires externes des établissements
secondaires.
 ~ ~

Nous reconnaissons enfin que, comme toute œuvre humaine reste imperfectible, ce travail
est loin d’être parfait. C’est la raison pour laquelle toute suggestion ou remarque serait la
bienvenue de la part des lecteurs. Ainsi nous aurons tous contribué unanimement à
l’évolution de la science
 ~ ~

Bibliographie
P.RONGERE (1971), Méthode de science sociale, Paris, Dalloz, p.25
REIX, R. (1969), Traitement des informations, éd. Foucher, Paris, P.9
ENGELS J. (Avril 2009), PHP5 : Cours et exercices 2ème éditions : PHP 5.2 et 5.3, Editions
EYROLLES, Paris, p. 662.
Pascal Roques (2006), UML2 par la pratique : Etudes de cas et exercices corrigés, 5ème
Edition Eyrolles, p.364
Gabay, J. G. ( (2008),). UML2 Analyse et Conception : Mise en œuvre guidée avec études de
cas,. DUNOD, Paris, ISBN-2-10-053567-5. .
Prof. Dr. Musangu Luka (2015-2016), Notes de cours de conception de systèmes
d’information : processus unifié (L1 IG), cours inédit, ISP/Bukavu, p.125
Philipe Norigeon (1999), Cours PGI, ERP (Master CCA), analyse des progiciels, p.136
Byenda Kazunguzibwa, Notification des paiements des frais scolaires : « cas du Lycée
Nyakavogo Bagira », Mémoire inédit, ISP/Bukavu, 2015/2016.
CHANCE BYAMUNGU A., Réalisation d’une application de gestion des paiements des
frais scolaires dans des institutions d’enseignement secondaire : Cas de l’Institut Kasali,
Mémoire, L2 Informatique, Département d’informatique de gestion, ISC-Bukavu, 2018-
2019, inédit.
AMURI JOSEPH, Conception d’un site web de suivi de paiement de frais
académiques : Cas de l’Institut Pédagogique de Bukavu, Mémoire, L2 Informatique,
Département d’informatique de gestion, ISP/BUKAVU, 2014-2015, inédit.
http://www.foad-mooc.auf.org/IMG/pdf/droit_des_tic.pdf, url consulté le

23/03/2017 à 01h : 12’

http://www.ird.fr/informatiquescientifique/documents/sgbd/sql/formation_SGB
D_cour_SGBD.pdf, url consulté le 22/03/2017 à 02h 20’
http://www.bibliotheque.auf.org/doc_num.php?explnum_id=81, url consulté le
16/02/2017 à 02h : 28’
http://pageperso.lif.univ-mrs.fr/~christine.campioni/documents/BD/BDrelationnelles.pdf; url
consulté le 22/02/2017 à 23h : 50’
https://www.u-picardie.fr/~furst/docs/1-UML_Besoins.pdf, url consulté le
16/02/2017 à 7h : 22’
http://fr.wikipedia.org/wiki/WampServer , lien valide le 11/06/2017 à 13h00’.
http://fr.wikipedia.org/wiki/JavaScript, lien valide le 2/06/2017 à 23h00’.
http://www.mysql.fr/why-mysql/white-papers/
 ~ ~

Table des matières

EPIGRAPHE..................................................................................................................I
DEDICACES.................................................................................................................II
REMERCIMENTS.....................................................................................................III
SIGLES ET ABREVEATIONS.................................................................................IV
TABLEAUX ET FIGURES.........................................................................................V
A. TABLEAUX.......................................................................................................V
B. FIGURES............................................................................................................V
0. INTRODUCTION GENERALE...........................................................................1
0.1. Problématique................................................................................................................1

0.2. Hypothèses......................................................................................................................2

0.3. Objectifs du travail........................................................................................................3

0.4. Objectif principal...........................................................................................................3

0.4.1. Les spécifiques objectifs.............................................................................................3

0.5. Les méthodes et techniques utilisées.................................................................3

0.5.1. Les méthodes utilisées................................................................................................3

0.5.2. Les Techniques utilisées.............................................................................................3

0.6. Choix et intérêts du sujet....................................................................................4

0.6.1. Intérêt scientifique......................................................................................................4

0.6.2. Intérêt de l’institution................................................................................................4

0.6.3. Intérêt personnel........................................................................................................4

0.7. Délimitation du sujet...........................................................................................4

0.8. Subdivision du travail.........................................................................................5
 Le premier chapitre est intitulé : Revue de la littérature. Il donnera un aperçu
global sur les théories cadrant avec le sujet ainsi que l’état de la question.........................5

0.9. DIFFICULTES RENCONTREES........................................................................5

PREMIER CHAPITREREVUE DE LA LITTERATURE.......................................6
I.1. REVUE DE LA LITTERATURE THEORIQUE...........................................................6

I.1.1. Définition des concepts clés......................................................................................6

A. Théorie Cadrant avec le sujet..................................................................................6
A. Théories relatives au système de gestion des bases des données.....................7
 ~ ~

A. Modèles de base de données......................................................................................8

I.1.2. Notion sur la méthode UP.........................................................................................9
A. Origine du processus unifié...........................................................................................9

B. Activités de la méthode UP..........................................................................................10

C. Les phases de la méthode UP......................................................................................10

D. Les principes du processus unifié...............................................................................10

I.1.3 Langage de modélisation « UML »...............................................................................11

A. Définition d’un modèle................................................................................................12

 ILLUSTRATION D’UN MODELE................................................................12

B. Caractéristiques d’un modèle.....................................................................................13

C. Utilité d’UML dans la modélisation...........................................................................13

I.1.4 Généralités sur le Web.............................................................................................15

I.2. REVUE DE LA LITTERATURE EMPIRIQUE (Etat de la question).......................19

Deuxième chapitre.......................................................................................................21
ETUDE DU MILIEU D’ETUDE ET ANALYSE DU SYSTEME EXISTANT....21
II.1. PRESENTATION DE L’INSTITUT MWANGA D’UVIRA.....................................21

II.1.1. Historique.....................................................................................................................21

II.1.2. Structure organisationnelle et fonctionnelle..............................................................23

II.1.2.1 Organigramme de L’Institut Mwanga..............................................................23

II.1.2.2. Structure fonctionnelle.............................................................................................24

II.2. ANALYSE DU SYSTEME EXISTANT.......................................................................26

II.2.1. Présentation du système existant..........................................................................26

II.2.1.1. Présentation des ressources utilisées.................................................................27
II.2.2. Présentation de documents et des supports utilisés..................................................28

II.2.3. Critique du système existant.......................................................................................30

II.2.3.1. Aspects positifs....................................................................................................30

II.2.3.2. Aspects négatifs...................................................................................................30
II.2.4. Propositions des solutions.....................................................................................31
Troisième chapitre.......................................................................................................32
CONCEPTION DU NOUVEAU SYSTEME D’INFORMATION.........................32
 ~ ~

III.1. Présentation des quelques méthodes de conception...................................................32

III.1.1. La méthode MERISE...........................................................................................32

III.1.2. La méthode UP.....................................................................................................32
III.1.2.1. Les principes d’UP............................................................................................32
III.1.2.2. Les phases du processus Unifié........................................................................33
III.1.2.3. Les activités du processus unifié......................................................................33
III.1.3. La méthode UP7...................................................................................................34
III.1.3.1. Les activités de la méthode UP7.......................................................................35
III.2. CHOIX DE LA METHODE CHOISIE......................................................................36

II.2.2. Capture des besoins techniques.................................................................................36

II.2.3. Capture des besoins fonctionnels...............................................................................39

Description textuelle des cas d’utilisation.......................................................................46

Sommaire d’identification................................................................................................47
Sommaire d’identification................................................................................................48
Sommaire d’identification................................................................................................50
Sommaire d’identification................................................................................................51
Représentation des classes..........................................................................................55
QUATRIEME CHAPITRE REALISATION DU NOUVEAU SYSTEME
D’INFORMATION.................................................................................................................64
IV.1. CHOIX DU LANGAGE DE PROGRAMMATION ET DE SGBD.........................64

A. CHOIX DU LANGAGE DE PROGRAMMATION................................................64

B. CHOIX DU SYSTÈME DE GESTION DE GESTION DE BASE DE DONNEES

(SGBB).....................................................................................................................................65

 L’environnement matériel.......................................................................................67
IV.2. Manuel utilisateur.........................................................................................................67

IV.2.1. Description Fonctionnelle....................................................................................67

IV.2.2. Configuration du système....................................................................................67
IV.2.3. Comment démarrer le système............................................................................67
IV.3. Référence pour l’utilisation du système......................................................................71

IV.5. PRESENTATTION DES CODES SOURCES ET DES ETATS DE SORTIE 85

Conclusion....................................................................................................................88
Bibliographie................................................................................................................91
~ ~