[I]

EPIGRAPHE
« Lorsque vous êtes debout faisant votre prière, si vous avez quelque chose
contre quelqu´un, pardonnez, afin que votre Père qui est dans les cieux vous
pardonne aussi vos offenses ».

Marc 11:25
 [II]

DEDICACE
À Vous mes très chers parents, TSHIBANGU KAZADI Stanis et
NGOIE MUKALA Ida, pour tous les innombrables bienfaits, vos sacrifices, vos
soutiens tant spirituels et financiers et vos précieux conseils envers moi
pendant tout mon cursus académique.

Dickson
MONGA
 [III]

AVANT-PROPOS
La fin d’une chose, marque le commencement d’une nouvelle
chose mais toute fois cette dernière doit être préparée, justifiée par cette fin
de la même manière, la fin de notre vie estudiantine marque le début de la
vie professionnelle. Cette fin est marquée par ce travail réalisé en vue de
préparer et justifier notre passage vers un autre.

Ce travail est le couronnement de la fin du cycle de Graduat à

l’Université de Kamina (UNIKAM).

C’est pourquoi avant tout, nous exprimons notre gratitude au

seigneur Dieu tout puissant pour sa grâce, son salut et son Amour infini dans
notre vie qui, sans cela nos efforts demeuraient vains, que la gloire l'honneur
lui soient rendus.

L’œuvre que nous avons le réel plaisir de vous présenter,

n’aurait son sens s’il n’avait pas eu le sentiment de notre Directeur en la
personne de l’Ir Baldo MWAMBA en dépit de ses multiples occupations s’est
voué entièrement pour diriger ce travail. Ses observations, ses critiques, ses
remarques, ses orientations ainsi que sa franche collaboration y ont pour une
relève indispensable à l’achèvement de ce travail.

Nos sentiments de gratitudes s’adressent à toutes les autorités

académiques et au corps professoral de l’université de Kamina (UNIKAM).

Mention spéciale à toute ma famille KYUNGU, TOFTING

MWENZE, YVES KAZADI, SAM MWAMBA, MARIE JOSÉ, MIRIAME ILUNGA
sentez-vous remercier du fond du cœur.

Nous ne pouvons pas passer inaperçu nos combattants de

lutte, HORNEL KANONO, HARITON MALOBA, PROSPER MWAMBA, ROSCO
KAZADI, GEORGETTE CIYOYI, JEAN-PIERRE NGOYI, MERY BANZA, MARIE
BARUANI, JULIE KYUNGU, SAM MWILABWE,

Nous exprimons une reconnaissance particulière à tous nos

amis et connaissances exceptionnellement à ROBISO TAMBO, FILS MWANZA

Que tout ceux dont leurs noms ne sont pas repris à cette
section du travail, l’expression de notre profonde reconnaissance vous ai
transmise.
 [IV]

Dickson
MONGA
 [1]

INTRODUCTION GENERALE
1. PRESENTATION DU SUJET
Le domaine de la gestion informatique connait une telle
ampleur de nos jours, que des nombreuses entreprises voulant profiter du
secteur ont vus le jour avec beaucoup de progrès.

L’apparition de traitement rationnel et automatique de

l’information « l’informatique » a facilité aux entreprises de traiter, stocker
les informations (données) grâce à son outil appeler ordinateur.

Comme nous l’avons épinglé ci-haut l’informatique est une

science de traitement rationnel et automatique des informations grâce à un
système de machine appelé ordinateur1, maintenant vu l’apport positif de
l’informatique, toutes les sociétés, entreprises cherchent toujours à s’adapter
à cette réalité en changeant leurs manière de gérer ou même d’exploiter les
informations : « Gestion manuelle des informations sur papier qui occasionne
la perte des documents et la lenteur d’accès aux informations ».

En utilisant la machine électronique capable de traiter les

informations d’une manière automatique et fournissant le résultat escompté
après traitement « ordinateur » notre application web facilitera une gestion
aisée des sites miniers. La division de mine étant un ensemble des divisions
et autres services publique de mine et de carrière peut recourir à l’outil
informatique pour pouvoir gérer ses sites miniers.

De ce fait nous abordons le sujet « conception et

implémentation d’une application web de gestion des sites miniers
au sein d’une division provinciale de mine » (cas de la division
provinciale de Kamina).

1
Ir Trésor MWAMBA, Cours informatique générale G1 INFO/UNIKAM 2019, inédit.
 [2]

2. ETAT DE LA QUESTION
Elle se présente de manière brève ou résumé des recherches
antérieures et résultats. C’est bilan critique de ce qui a été produit dans le
domaine de la recherche concernée ou encore une étape où le chercheur
présente les différentes recherches similaires à celui de se son travail.

Nous ne pouvons pas passer inaperçu l’idée de dire que nous

sommes les seuls à pouvoir aborder ce sujet, il y a eu bien sûr nos
prédécesseurs scientifiques qui ont parlé sur ça et sous autres aspect. Nous
avons fait une référence sur le sujet de :

 Illyés MANSOUR « conception et réalisation d’une application

web de gestion des interventions » l’année universitaire 2016-
2017.

C’est un projet qui se présente dans le cadre d’un stage de fin

d’étude en vue de l’obtention du diplôme national d’ingénieur en science
appliquée et technologique à l’université de Tunis El Manar. Son projet est
réalisé au sein de New Connect Engineering qui est l’une de meilleure
entreprise tunisienne de type SARL fondé en 2006 offrant différents services
et produits tels que l’anti intrusion afin de protéger au maximum des biens
privés et particuliers et leur bienêtre. L’objectif de ce travail est de pouvoir
concevoir et réaliser une application web permettant particulièrement la
gestion des interventions effectuées par des techniciens afin de réaliser une
meilleure suivie. Cette société avait comme système architectural
client/serveur permettant de réaliser plusieurs opérations de gestion tels
que :

 Gestion des fiches client et fournisseurs ;

 Gestion comptable.

Ce système avait comme faille :

 Perte de temps à cause de la mise à jour manuelle ;

 L’impossibilité de faire des statistiques claires causées par le
stockage effectué sur le support de papier.

La solution provisoire proposée par l’auteur consiste à donner

la possibilité aux techniciens de saisir les fiches d’intervention sur le système
ainsi les tâches effectuées peuvent être suivies en permanence par les
utilisateurs de l’application.
 [3]

Sur ce, notre sujet conception et implémentation d’une

application web de gestion des sites miniers trouve un chemin commun
par rapport à ce dernier mais seulement que celui-ci parle d’une gestion des
interventions que de la gestion des sites miniers.

3. PROBLEMATIQUE
Le dictionnaire encyclopédique, défini la problématique comme
étant : « un ensemble des questions, des problèmes concernant un domaine
de connaissance ou des problèmes qui se sont passés par une situation dans
un conte idéologique »

La problématique est donc l’ensemble des questionnements

élaborés à partir de la question posée par le sujet.

Raison pour laquelle l’on demande chaque fois la

problématique pour nous donner la position ou encore chercher d’autres
procédures pour éviter le plagiat, sur ce nous allons nous appuyer sur les
questions suivantes ;

 Quelles sont les nécessités pour aboutir à l’implémentation et

comment va-t-elle fonctionner au sein de la division de mine
concernant la problématique.
 Comment résoudre le problème de la mise à jour des sites, ce qui
engendre des conflits miniers dans la distribution des sites.

4. HYPOTHESE
Du latin hypothèse, elle est une proposition à partir de
laquelle on raisonne pour résoudre un problème, pour démontrer un
théorème.2

Face à ces préoccupations il s’avère très important de

mettre à la disposition de la division de mine une solution de gestion
informatique en implémentant une application web qui permettra de gérer
d’une manière permanente les sites.

5. CHOIX ET INTERET DU SUJET

5.1. CHOIX DU SUJET
Le choix de notre sujet n’est pas une imagination mais un choix
concordant avec notre formation en gestion informatique et une observation
personnelle après avoir passé un mois de stage dans ladite division.
2
LE PETIT ROBERT POUR TOUS, édition 2010
 [4]

5.2 INTERET DU SUJET

Après avoir terminé ce sujet nous serons capables de concevoir
une application Web qui va faire la gestion des sites miniers.

 INTERET PERSONNEL

Ce travail est d’un intérêt capital, pour nous qui sommes

chercheurs, Ça va nous aider d’accueillir un surplus sur les notions
informatiques beaucoup plus dans la gestion. Il va nous permettre de
concrétiser toutes les théories acquises tout au long de notre parcours
universitaire en pratique.

 INTERET SCIENTIFIQUE
Apres avoir eu connaissance en informatique, vu que nous ne
sommes pas les premiers ou les derniers à être inspirer de ce sujet, voilà
pourquoi nous laisseront cette œuvre à l’orientation de ceux-là qui viendront
après nous dans le même domaine.
 INTERET SOCIAL
Ce travail, apportera plus à la division de mines en leur
disposant une application Web de gestion des sites miniers qui facilitera un
contrôle bénéfique à tous les exploitants miniers.

6. DELIMITATION DU SUJET
Considérant les théories sur la délimitation, nous préférons
nous limiter uniquement sur l’étude des sites miniers de la province du Haut
Lomami et non des carriers.
Du point de vu temporel nous n’allons pas en vrai limiter notre
travail en temps, nous allons pouvoir mettre une solution qui jusqu’à ce que
les problèmes liés à la gestion de sites soient résolu avec un maximum de
succès.

7. METHODOLOGIE ET TECHNIQUE
7.1 METHODOLOGIE
La méthode est la manière de conduire sa pensé, de penser, de
dire ou de faire quelque chose suivant certains principes et avec un certain
ordre.3

3
http://www.wikipedia.com/fr.m.wiktionary.org/methode, Consulté le 24/06/2022, 13h42
 [5]

Dans le cadre de notre travail nous allons utiliser la méthode

Processus Unifié UP en français processus unifié.

7.2 TECHNIQUE
La technique est l’ensemble des procédés exploités par le
chercheur. C’est la phase de collecte des données qui intéressent son champ
d’étude. Pour collectionner les données traites à notre recherche, nous avons
procéder par les techniques suivantes :

 TECHNIQUE DOCUMENTAIRE

Cette technique nous permet de recourir aux sources écrites

en vue d’obtenir les informations nécessaires à la réalisation du travail.

La technique documentaire nous a permis de lire un certain

nombre d’ouvrages, revues et article ayant traits à notre sujet de recherche.

 TECHNIQUE D’INTERVIEW

Dans cette technique il y a contact entre l’enquêteur et

l’enquêté afin de permettre à l’enquêteur de récolter certaines informations
de l’enquête concernant un objet ou un fait précis. D’où, nous nous sommes
entretenus dans le cadre administratif avec le secrétaire NGOY MUTWE WA
BAKULU et dans le cadre technique avec l’ingénieur HYLKOUM attaché au
bureau géologie.

 TECHNIQUE D’OBSERVATION

La technique d’observation nous a permis d’entrer en contact

avec les opérations effectuées par le système existant afin d’affirmer la
réalité sur la circulation des informations dans le système, par une
observation directe sur déroulement des activités.
 [6]

8. SUBDIVISION DU TRAVAIL
Hormis l’introduction générale et la conclusion générale, notre
sujet se subdivise en quatre chapitres dont :

 Premier chapitre : définition des concepts et considérations

théoriques

Dans ce chapitre nous présenterons l’ensemble de théories

nécessaires pour bien aborder ce travail en donnant les définitions des
concepts et du domaine de l’application, en suite nous donnerons les
théories nécessaires sur la Méthode utilisé, enfin le langage de
programmation.

 Deuxième chapitre : présentation de l’existant. Spécification des

besoins et analyse du métier

Ce chapitre sera consacré à la présentation de notre champ

d’étude puis passerons à la modélisation du processus métier ciblée, analyse
des besoins, description des données, enfin critiquerons l’existant afin
d’émettre les faiblesses et rechercher les solutions.

 Troisième chapitre : conception du système informatique

Tout au long de ce chapitre, il sera question de faire une

représentation de l’architecture du système, de la solution informatique
portant sur la conception des diagrammes de séquence de conception, le
diagramme de classes de conception ainsi le diagramme de déploiement.

 Quatrième chapitre : implémentation de la solution nouvelle :

Architecture technique et implémentation

Il s’agira dans ce chapitre de déterminer le type

d’architecture qui sera utilisée et puis implémenter l’application qui tournera
selon les améliorations obtenues dans le chapitre précèdent.
 [7]

Chapitre premier :DEFINITION DES CONCEPTS ET

CONSIDERATIONS THEORIQUES
I.1. DEFINITION DES CONCEPTS
 Conception : donc ce l’effet de comprendre et de concevoir les
choses, ou élaboration d’une idée, d’un projet. 4
 Implémentation : Mise en place sur un ordinateur d’un système
d’exploitation ou d’un logiciel adapté aux besoins et à la configuration
informatique.5
 Application web : Une application web est une interface web
applicative disponible uniquement sur le web et accessible via un
navigateur internet, qui peut être hébergée en cloud ou sur des
serveurs dédiés, toute les données sont stockées sur un serveur web
 Web : Le terme web désigne en anglais une toile d’araignée. C’est une
technologie informatique permettant de consulter via un navigateur
des pages regroupées sur des sites via le réseau internet. 6
 Gestion : Action de gérer, d’administrer, de diriger, d’organiser
quelques choses. La gestion est une science de l’administration, de la
direction d’une organisation et ses différentes fonctions
 Site minier : Situation du lieu ou du terrain étant là pour
l’exploitation minière

4
http://wiktionary.org/dictionnaire/conception/ (consulté le 01/07/2022 à 11h22)
5
http://wiktionary.org/dictionnaire/implementation/ (consulté le 01/07/2022 à 11h30)
6
http://www.astuce-aide-informatique.info, 08/07/2022 à 13h40’
 [8]

I.2. CONSIDETATIONS THEORIQUES.

I.2.1. PRESENTATION DU PROCESSUS UNIFIE
Un processus définit une séquence d’étapes, en partie
ordonnées, qui concourent à l’obtention d’un système logiciel ou à l’évolution
d’un système existant.7

L’objet d’un processus de développement est de produire des

logiciels de qualité qui répondent aux besoins de leurs utilisateurs dans des
temps et des coûts prévisibles.

Un processus unifié est un processus de développement

logiciel construit sur UML ; il est itératif et incrémental, centré sur
l’architecture, conduit par les cas d’utilisation et piloté par les risques. 8

I.2.2. LE PROCESSUS UNIFIE EST CONDUIT PAR LES CAS

D'UTILISATION
Un cas d’utilisation est une fonctionnalité du système
produisant un résultat satisfaisant pour les utilisateurs, les cas d’utilisation
saisissent les besoins fonctionnels et leur ensemble forme le modèle des cas
d’utilisation qui décrit les fonctionnalités complètes du système.

I.2.3. LE PROCESSUS UNIFIE EST CENTRE SUR

L'ARCHITECTURE
Le rôle de l'architecture logicielle est comparable à celle que
joue l'architecte dans la construction d'un bâtiment. Le bâtiment est
envisagé de différents points de vue : structure, services, conduite de
chauffage, plomberie, etc. Ce regard multiple dessine une image complète
du bâtiment avant le début de la construction. De la même façon,
l'architecture d'un système logiciel peut être décrite comme les différentes
vues du système qui doit être construit.

I.2.4. LE PROCESSUS UNIFIE EST ITERATIF ET

INCREMENTAL
Le développement d'un produit logiciel destiné à la
commercialisation est une vaste opération qui peut s'étendre sur plusieurs
mois, voire sur une année ou plus. Il n'est pas inutile de découper le travail

7
Pascal Roques, Franck Vallée, UML 2 en action de l’analyse des besoins à la conception, éd.
Eyrolles, 4eme édition, 2007, p.12.
8
Ir valery KABONGO, séminaire G3 INFO/UNIKAM 2022, inédit.
 [9]

en plusieurs parties qui sont autant de mini-projets (Concept systémique de

système et sous-systèmes).

Chacun d'eux représente une itération qui donne lieu à un

incrément. Les itérations désignent des étapes de l'enchaînement d'activités,
tandis que les incréments correspondent à des stades de développement du
produit.

I.2.5. LE PROCESSUS UNIFIE EST PILOTE PAR LES RISQUES

Dans ce cadre, les causes majeures d’échec d’un projet logiciel
doivent être écartées en priorité. Nous identifions une première cause
provenant de l’incapacité de l’architecture technique à répondre aux

contraintes opérationnelles, et une seconde cause liée à l’inadéquation du

développement aux besoins des utilisateurs.

I.2.6. LE CYCLE DE VIE DU PROCESSUS UNIFIE

Comme le montre la figure le cycle de vie du processus unifié
se caractérise par deux axes :

 Un axe vertical qui modélise l’enchainement des activités qui seront

itérées un certain nombre de fois ;
 Un axe horizontal représentant l’évolution des phases ou des itérations
dans le temps.

Toutes les activités n’ont pas la même importance durant chaque phase.
 [10]

I.2.7. ETAPES DE LA METHODE UP

Nous avons 4 Etapes :
1. La phase de création : Portée et rôle du produit, Réduire les risques les
plus importants, Etudier rentabilité, viabilité commerciale.
2. La phase d’élaboration ; Créer l’architecture de référence, Saisir
l’essentiel des besoins, Réduire les risques de moindre gravité.
3. La phase de construction ; Développer le système complet, S’assurer
que le produit peut être utilisé par les clients.
4. La phase de transition ; S’assurer que l’on dispose d’un produit prêt à
être livré à l’ensemble des utilisateurs, Former les utilisateurs.

I.2.8. PRESENTATION DU LANGAGE UML

UML (Unified Modeling Language en anglais soit langage de
modélisation unifiée) se définit comme un langage de modélisation
graphique et textuel destiné à comprendre et décrire des besoins, spécifier
et documenter des systèmes, esquisser des architectures logicielles,
concevoir des solutions et communiquer des points de vue. UML unifie à la
fois les notations et les concepts orientés objet. 9

Les méthodes utilisées dans les années 1980 pour organiser la

programmation impérative (notamment Merise) étaient fondées sur la
modélisation séparée des données et des traitements. Lorsque la
programmation par objets prend de l’importance au début des années 1990,
la nécessité d’une méthode qui lui soit adaptée devient évidente. Plus de
cinquante méthodes apparaissent entre 1990 et 1995 (Booch, Classe-
Relation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE, etc.) mais aucune ne
parvient à s’imposer. En 1994, le consensus se fait autour de trois
méthodes :

 OMT (Objet Modeling Technique) de James Rumbaugh fournit une

représentation graphique des aspects statiques, dynamiques et
fonctionnels d’un système.

9
Pascal Roques, les Cahiers du programmeur UML2 modéliser une application web, 4e éd.
Eyrolles, paris 2004, p.4
 [11]

 Booch (Object Oriented Developpement) de Grady Booch, introduit

les concepts de paquetage, diagramme de classes, diagramme
d’objet et diagramme d’états.
 OOSE (Object Oriented Software Engineering) d’Ivar Jacobson fonde
l’analyse sur la description des besoins des utilisateurs (cas
d’utilisation ou use case).

Chaque méthode avait ses avantages et ses partisans. Le

nombre de méthodes en compétition s’était réduit, mais le risque d’un
éclatement subsistait : la profession pouvait se divise rentre ces trois
méthodes, créant autant de continents intellectuels qui auraient du mal à
communiquer.

Événement considérable et presque miraculeux, les trois

gourous qui régnaient chacun sur l’une des trois méthodes se mirent
d’accord pour définir une méthode commune qui fédérerait leurs apports
respectifs (on les surnomme depuis « the Amigos »). UML (Unified Modeling
Language) est né de cet effort de convergence. L’adjectif unified est là pour
marquer qu’UML unifie, et donc remplace.

En fait, et comme son nom l’indique, UML n’a pas l’ambition

d’être exactement une méthode : c’est un langage. La version d’UML en
cours à la fin 2020 est UML 2.5.1 et les travaux d’amélioration se
poursuivent.

UML 2.5.1 comporte ainsi quatorze types de diagrammes

représentant autant de vues distinctes pour représenter des concepts
particuliers du système d’information. Ils se répartissent en deux grands
groupes10 :

Diagrammes structurels ou diagrammes statiques

 Diagramme de classes (Class diagram) ;

 Diagramme d’objets (Object diagram) ;
 Diagramme de composants (Component diagram) ;
 Diagramme de déploiement (Deployment diagram) ;
 Diagramme de paquetages (Package diagram) ;
 Diagramme de structures composites (Composite structure diagram) ;
 Diagramme de profils (profil diagram).

10
Laurent AUDIBERT, UML 2.0, Institut Universitaire de Technologie de Villetaneuse,
département informatique, 1ère année, 2007, p.22
 [12]

Diagrammes comportementaux ou diagrammes dynamiques

- Diagramme de cas d’utilisation (Use case diagram) ;

- Diagramme d’activités (Activity diagram) ;
- Diagramme d’états-transitions (State machine diagram) ;
- Diagramme de séquence (Séquence diagram) ;
- Diagramme de communication (Communication diagram) ;
- Diagramme global d’interaction (Interaction overview diagram) ;
- Diagramme de temps (Timing diagram).

Tous ces diagrammes sont d’une utilité variable selon les cas,
toute activité à l’occasion d’une modélisation.

I.3. LANGAGE DE PROGRAMMATION.

I.3.1. LANGAGE INFORMATIQUE
Langage Passage de la langue naturelle via le langage de haut
niveau au langage machine.

Une application va donner du sens, en transformant un

contenu (des entrées) en un autre contenu (des sorties), par un calcul
informatique en prenant de la place et en prenant du temps. La valeur
ajoutée dépend de la force du langage et de l’intelligence de l’application.

Un langage informatique est un langage destiné à décrire

l'ensemble des actions consécutives qu'un ordinateur doit exécuter, Un
langage informatique est une manière pragmatique de donner des
instructions à un ordinateur.

Un langage informatique est rigoureux : à une instruction

correspond une action du processeur. Le langage utilisé par le processeur est
le langage machine. Il s'agit d'une suite de 0 et de 1 (en hexadécimal), pas
compréhensible facilement par le commun des mortels.

Il est donc plus pratique de trouver un langage intermédiaire,

compréhensible par l'homme, qui sera ensuite transformé en langage
machine pour être exploitable par le processeur.

L'assembleur est un langage proche du langage machine mais

il permet déjà d'être plus compréhensible. Toutefois un tel langage dépend
étroitement du type de processeur utilisé (chaque type de processeur peut
avoir son propre langage machine).
 [13]

Ainsi un programme développé pour une machine ne pourra

pas être « porté » sur un autre type de machine. Pour pouvoir l'utiliser sur
une autre machine il faudra alors parfois réécrire entièrement le programme.

I.3.2. AVANTAGES DE LANGAGES INFORMATIQUES

Un langage informatique a donc plusieurs avantages :

 Il est plus facilement compréhensible que le langage machine ;

 Il permet une plus grande portabilité, c’est-à-dire une plus grande
facilité d’adaptation sur des machines de types différents.

La liste n’est pas exhaustive.

I.3.3. CHOIX DU LANGAGE DE PROGRAMMATION

Pour produire cette application, nous aurons besoin d’un langage
de programmation pouvant nous servir à manipuler les données.

Ainsi, pour ce qui nous concerne, parmi les différents langages de

programmation utilisés tels que : C++, C#, PASCAL, VISUAL BASIC, DELPHI,
JAVA, PHP, HTML, C, notre choix a porté sur le PHP (HyperText Préprocesseur)
car il est un langage de programmation libre principalement utilisé pour produire
les pages web dynamiques via un serveur http, mais pouvant également
fonctionner comme n’importe quel langage interprété de façon locale, en plus il
est un langage impératif orienté objet11.

11
www.wikipedia.com, Consulté le 22 Mai 2022 à 09h41’.
 [14]

Chapitre Deuxième : PRESENTATION

DE L’EXISTANT,
SPECIFICATION DES BESOINS ET ANALYSE DU
METIER
II.1. GENERALITE
Le présent chapitre est consacré à la présentation du champ
d’étude et de l’analyse de l’existant. Il se consacrera à la description du
domaine où nous donnerons une présentation un peu détaillée de notre
système ; à la modélisation du processus métier où nous tracerons différents
diagrammes ; en suite passerons à l’analyse des besoins et description des
données ; ainsi qu’au critique de l’existant et nous terminerons par la
proposition de la nouvelle solution

II.2 PRESENTATION DE L’ENTREPRISE

II.2.1 HISTORIQUE
Avant le découpage, la Division était divisée en deux : Division
Nord et-Division Sud. C’est à partir du 17-Octobre-2018 que la Division
Provinciale des Mines et Géologie du Haut-Lomami a eu naissance.

Les Mines comme substance Minéral se trouvant dans le sous-

sol ou en surface étaient déjà connue par nos ancêtres à l’époque
précoloniale. Avec le cuivre ils se fabriquaient des anneaux et des croisettes
tandis que le fer leur procurait des couteaux, machette, houe, lance et autres
armes…

Après la conquête du pays, les Colonisateurs créèrent des

Sociétés à charte pour la prospection et l’exportation rationnelle des
gisements riches en divers substances minérales.

Cette activité minière étaient supervisées par le Gouvernement

Général du Congo Belge dans la sixième Direction Général de l’économie a
Léopold ville actuelle Kinshasa et comprimées la direction de l’économie de
finances et mines jusqu’à l’indépendance en 1960.

Avec la formation du Gouvernement en 1960 fut créé le

ministère des terres mines et énergie qui avec le diffèrent Gouvernement
successifs changera d’appellation comme suit :

 Ministère de terre ; mine et énergie 1960 ;

 Ministre de mine et affaire foncière 1969 ;
 [15]

 Département des mines et énergie 1979 ;

 Vice primature chargée des mines 1996 ;
 Ministère des mines et hydrocarbure 1997 ;
 Ministère des mines 2009 à nos jours.

II.2.2 SITUATION GEOGRRAPHIQUE

La Division Provinciale des Mines et Géologie couvre toute
l'étendue de la Province du Haut-Lomami, elle s'étend sur une superficie de
120 345km², le Siège Provincial de la Division Provinciale des Mines se trouve
dans la Ville de Kamina, Commune de Kamina, Quartier Centre Urbain,
Avenue de l’école N071, dans la Province du Haut-Lomami.

II.2.3. OBJECTIF
La Division Provinciale des Mines poursuit les objectifs
suivants :

 Coordonner, superviser, contrôler et orienter les opérations

extractives des minerais depuis le site jusqu’au transport de ces
derniers ;
 Répondre aux besoins socio-économiques de la province ;
 Générer les ressources financières de l’Etat ;
 Etudier et octroyer les concessions d’exploitation minière aux
opérateurs économiques par le biais du cadastre minier ;
 Etudier les différentes étapes de traitement des produits minéraux
par le service géologique et du CRM.

II.2.4. STRUCTURE FONCTIONNELLE DE L’ENTREPRISE

a. DU POINT DE VUE POLITIQUE

La Division Provinciale des Mines est sous la tutelle du

ministère des mines qui est le chef hiérarchique.

b. DU POINT DE VUE ADMINISTRATION

Administration des mines comprend :

 Le Secretariat général ;
 Les Directions ;
 Les Divisions ;
 Et autres services administratifs du ministère en charge des mines,
y compris ceux qui interviennent dans l’administration du code
minier et de toutes ses mesures d’applications.
 [16]

Ils sont régis conformément aux textes légaux et règlementaire

en vigueur relatif à l’administration publique.
Les directions techniques qui interviennent dans les processus
de l’octroi de droit minier et/ou des carrières sont :
 Direction de Géologie ;
 Direction des Mine ;
 Direction de Protection de l’Environnement minier ;
 Direction des Carriers.

DIVISION PROVINCIALE DES MINES ET GEOLOGIE

Le bureau provincial des mines et géologie est constitué de

plusieurs bureaux, notamment :

1. Bureau du Chef de Division lié au Secrétariat de la Division ;

Les neufs Bureaux Provinciaux qui sont :

 Bureau Gestion des Ressources Humaines ;

 Bureau Administration et Finances ;
 Bureau des Mine ;
 Bureau de Géologie ;
 Bureau Carriers ;
 Bureau Documentation, Archives et NTIC ;
 Bureau de Protection de l’Environnement Minier ;
 Bureau d’Etude et Planification Minière ;
 Bureau Inspection Meunière.

3. Les deux Bureaux Miniers Isolés :

 Bureau Minier isolé de MALEMBA-NKULU ;

 Bureau Minier isolé de BUKAMA.

4. Les Antennes Minières :

 Antenne de KANIAMA ;
 Antenne de KABONGO ;
 Antenne KINDA-KIBULA.
Les Antennes Minières ont des cellules comprenant les
contrôleurs et enquêteurs chargés des activités Minières Locales.

STRUCTURE DU MINISTERE DES MINES DE LA RDC

 [17]

 Le Secretariat General
 La Cellule Technique de Coordination et de Planification minières
 Le service d’Assistance et d’Encadrement de la Mine à Petite
échelle
 Le cadastre Minier
 Le Centre d’expertise, d’évaluation et de certification des
Substances Minérale Précieuses et Semi-Précieuses
 Les entreprises minières relevant du portefeuille de l’Etat.
LA SUCCESSION DE GRADE DANS L’ADMINISTRATION PUBLIQUE

 Le Secretariat General
 Le Directeur National
 Le Chef de Division (C.D)
 Le Chef de Bureau (C.B)
 Attaché de Bureau de Première classe (ATA1)
 Attaché de Bureau de Deuxième classe(ATA2)
 Agent de Bureau de Première classe (AGA1)
 Agent de Bureau de Deuxième classe(AGA2)
 Agent Auxiliaire de Première classe (AA1)
 Agent Auxiliaire de Deuxième classe(AA2)
 L’Huissier.

Cette ossature nous donne la vue générale sur la manière dont

les domaines des mines sont gérés tout au niveau national que provincial.
En province les activités sont dirigées par le Ministère
Provincial des Mines et Tourisme qui est secondé par le Chef de Division des
Mines, à savoir que son administration compte sur les deux types d’agents :
1. Les Nouvelles Unités ;
2. Les Agents Sous-Statut.

D. FONCTIONNEMENT
 [18]

Les fonctionnements de la Division Provinciale des Mines et

Géologie ça se fait de la manière suivante :
 La Division Provinciale de Mine du Haut-Lomami à la tête nous
voyons Monsieur NYEMBO MUKUNA Sadiki dont le rôle est de
coordonnée, géré et superviser toutes les activités de la Division
Provinciale ;
 Le Secrétariat Provinciale de la Division Provinciale des Mines est
dirigé par Monsieur NGOY MUTWE WA BAKULU, Dont son rôle est
de réceptionner, classifier et ranger tous les lettres reçues et
renvoyées ;
 Le Bureau des Services Généraux et du Personnel Dirigé par
l’intérimaire le Chef de bureau SAMSON; il s’occupe de la gestion
des ressources humaines plus spécialement la gestion des
carrières des agents ; L’indentifications des besoins en ressources
humaines à la fois en formation et perfectionnement.
 Le Bureau de Mines : Dont le rôle est de superviser l’extraction
dans les usines et l’acharnement de ces produits vers les marchas
légaux ou étrangers par l’octroi d’une attestation des transports
des substances minérales ;
 Bureau de Protection de l’Environnement Minier qui est géré par
Madame ILUNGA KASONGO Viviane Dont les attributs concernent
aux instructions et à l’efficacité des terrains, aux mesures
d’atténuation et dans la réhabilitation environnementale ;
 Le Bureau Administration et Finances Dirigé par Monsieur MPIANA
KABULO Samson dont les attributions reviennent dans l’excursion
au nom de l’Etat de tous les opérateurs relatifs aux recettes et
aux dépenses.
 Le Bureau Inspection Minière est géré par Monsieur Darius MBAYO
WA KASONGO et qui a comme attribution lutter contre la fraude,
prévenir les infractions constatées et réprimer les infractions par
les amandes et peine prévu par le code et les règlements miniers.
 Bureau Carrières géré par Monsieur KABWE KITAMBALA Dieudonné
ayant pour la mission des sensibilisations des exploitants sur tout
ce qui prévoit le code minier en matière d’exploitation de
recherche de traitement ; de transformation ; ainsi que de la
commercialisation des substances minérales et des produits des
carrières.
 Bureau d’Etude et de Planification dont la mission est de :
 Collecter en province les données nécessaires :
 A l’élaboration des diagnostics économiques et sectoriels ;
 [19]

 A la programmation et à la budgétisation des programmes et

projets économiques et sectoriels ;
 Au suivi et à l’évaluation des politiques, projets et
programmes économiques et sectoriels ;
 A l’élaboration du projet du budget d’investissement de la division
provinciale.
 Bureau Géologie : Géré par le chef de Bureau Didier MUSANS, Ce
Bureau est là pour le prélèvement des échantillons.
 [24]

I.2.5. ORGANIGRAMME DE LA DIVISION PROVINCIALE DES MINES ET GEOLOGIE DU HAUT-

LOMAMI

CHEF DE
DIVISION

SECRETARIAT

Bureau Bureau
Bureau Bureau Bureau
Gestion Doc, Bureau Bureau Bureau
Administratio d’Etude et Bureau Protection de
des Arch. et Mines Carrière Inspection
n et Finances Planification Géologie l’environnem
Ressources NTIC s Minière
Humaines ent minier

Bureau Minier Isolé de Bureau Minier Isolé de

MALEMBA-NKULU BUKAMA

Antenne Minière
Antenne Minière Antenne Antenne Minière
Rive GAUCHE Antenne Antenne Minière Antenne Minière de
Rive DROITE Minière de de KIBANDA
MALEMBA- Minière de de KIKONDJA/KIPA
MALEMBA- KANIAM
NKULU a KABONGO NKINDA/KIBU MBA
NKULU a A
MWANZA-SEYA LA
MULONGO
 [26]

II.3 ANALYSE DU METIER

II.3.1 DESCRIPTION DU METIER
Est l’ensemble d’activités liées les unes aux autres et qui
prennent fin qu’à la livraison d’un service

II.3.2 ETUDE PRELIMINAIRE

a. DESCRIPTION TEXTUELLE DE PROCESSUS METIER

1. La SAEMAPE dépose une copie d’avis technique contenant les

mentions suivantes (le nom de l’exploitant, le type d’exploitation
« concession minier ou zone d’exploitation », la zone géologique,
permis de recherche ou permis d’exploitation) à l’intention du ministre
provincial au secrétariat
2. Le secrétaire transfert la copie au bureau de géologie
3. Le bureau géologie vérifie l’avis technique, s’il est favorable il revoit la
réponse positive au secrétariat sinon il conteste ce dernier.

b. BESOIN EXPRIME

4. Avoir les sites à jour

5. Communiquer facilement avec le système extérieur (SAEMAPE) en cas
de d’une modification effectuée

ACTEURS DEFINITION ROLE

Service de contrôle de Déposer avis technique,

SAEMAPE
matière première consulter les sites

Responsable des activités Vérifier l’avis technique,

BUREAU
liées à la gestion des sites Consulter les sites, modifier
GEOLOGIE
miniers et ajouter

Responsable du bon
Consulter les sites, vérifier
SECRETARIAT fonctionnement des activités
l’avis technique
de l’entreprise

c. INDENTIFICATION DES ACTEURS

 [27]

d. DIAGRAMME DE CONTEXTE STATIQUE

Le Modèle de contexte statique délimite le domaine d’étude en

précisant :

 Ce qui est à la charge du système et

 En identifiant l’environnement extérieur au système étudié avec
lequel ce dernier communique.

Ses composants sont :

 Les acteurs externes. Un acteur externe est une entité externe au

système étudié qui interagit avec le système.
 Un processus unique symbolisant le Système Information étudié
 Échange entre le système étudié et son environnement.
 [28]

e. DIAGRAMME D’ACTIVITE

Le diagramme d’activité est l’un des diagrammes dynamiques

d’UML. Il ressemble fondamentalement à un ordinogramme, montrant le flot
de contrôle d’action en action. Les éléments de base du diagramme d’activité
sont les suivants :

 Des actions ;
 Des flots de contrôle entre actions ;
 Des décisions (aussi appelés branchements conditionnels) ;
 Un début et une ou plusieurs terminaison(s) possible(s).
 [29]

II.3.3. CONTRAINTES FONCTIONNELLES

II.3.4. CAPTURE DES BESOINS FONCTIONNELS
a. IDENTIFICATION DE CAS D’UTILISATION DU METIER

b. FICHE DE DESCRIPTION DES CAS D’UTILISATION/ SCENARIO

 Titre : ENVOYER AVIS TECHNIQUE

 Objectif : Permettre à la Saemap d’envoyer un avis technique.
 Acteurs : Saemap (principal)
 Post-conditions :
 Scénario nominal :
1. Saisir informations avis technique.
2. Valider saisie
3. Enregistrer informations
4. Envoyer avis technique
 [30]

 Titre : VERIFIER AVIS TECHNIQUE

 Objectif : Permettre au secrétariat de la division des mines de
vérifier l’avis technique envoyé par la Saemap.
 Acteurs : Secrétariat
 Post-conditions :
 Scénario nominal :
5. Déterminer les coordonnées géographiques.
6. Déterminer son permis de recherche
7. Déterminer son permis d’exploitation
8. Accorder avis favorable
 [31]

 Titre : TRAITER AVIS TECNHIQUE

 Objectif : Permettre Au bureau géologie de traiter l’avis
technique.
 Acteurs : bureau géologie
 Pré conditions :
 Post-conditions :
 Scénario nominal :
9. vérifier les coordonnées géographiques.
10. Vérifier le permis de recherche
11. Vérifier le permis d’exploitation
12. Enregistrer
 Scénario alternatif :
13. 2. a Si les coordonnées géographiques correspondent aux

coordonnées d’une zone de recherche ou d’une zone d’exploitation

on n’arrête le processus.
14. 2. b Sinon, Fournir information
 [32]

Chapitre Troisième : CONCEPTION DU SYSTEME

INFORMATIQUE
III.1. INTRODUCTION
La conception du système informatique permet d’acquérir une
compréhension approfondie des contraintes liées au langage de
programmation, à l’utilisation des composants et au système d’exploitation.
Elle détermine les principales interfaces et les transcrits à l’aide d’une
notation commune.

Tout au long de ce chapitre, il sera question de faire une

représentation de l’architecture du système, de la solution informatique
portant sur la conception des diagrammes de séquence de conception,
diagrammes des classes de conceptions ainsi que la construction du modèle
logique de données.

III.2. CAPTURE DES BESOINS DU SYSTÈME INFORMATIQUE

III.2.1. ACTEURS DU SYSTÈME INFORMATIQUE
Un acteur représente l’abstraction d’un rôle joué par des
entités externes (utilisateur, dispositif matériel ou autre système) qui
interagissent directement avec le système étudié. Un acteur peut consulter
 [33]

et/ou modifier directement l’état du système, en émettant et/ou en recevant

des messages éventuellement porteurs de données12.

ACTEURS TYPE ROLE

Son rôle est de venir solliciter une possible
EXPLOITANT Externe
exploitation des minerais dans des sites miniers.

GEOLOGUE Interne Il est responsable de la gestion des sites minier.

Il est chargé de gérer les utilisateurs du

ADMINISTRATEUR Interne système, s’assurer du bon fonctionnement du
système.

Dans notre cas, les acteurs sont :

III.3. ANALYSE DU SYSTÈME INFORMATIQUE

III.3.1. DIAGRAMME DES CAS D’UTILISATION DE CONCEPTION
Le diagramme de cas d’utilisation « use case diagram » vient
décrire le système étudié en privilégiant le point de vue de l’utilisateur. Il
permet de recueillir, d’analyser, d’organiser les besoins, et de recenser les
grandes fonctionnalités de ce système. Le diagramme de cas d’utilisation
vient faire le lien entre les fonctionnalités (cas d’utilisations) et les acteurs en
précisant ce que doit faire le système sans spécifier comment il le fait. Ce
diagramme permet donc de répondre principalement à deux questions
concernant un système : de quoi s’agit-il ? Et Qui fait quoi ?

Le diagramme de cas d’utilisation est un schéma qui montre

les cas d’utilisation (ovales) reliés par des associations (lignes) à leurs
acteurs (icône du « stick man », ou représentation graphique équivalente).
Chaque association signifie simplement « participe à ». Un cas d’utilisation
doit être relié à au moins un acteur13.

Les diagrammes de cas d’utilisation qui permettent de

recueillir, d’analyser et d’organiser les besoins, et de recenser les grandes
fonctionnalités d’un système. Il s’agit donc de la première étape UML
d’analyse d’un système. Un diagramme de cas d’utilisation capture le
comportement d’un système, d’un sous-système, d’une classe ou d’un
composant tel qu’un utilisateur extérieur le voit. Il scinde la fonctionnalité du
12
P. Roques et F. Vallée, UML 2 en action de l’analyse des besoins à la conception, 4e Ed.
EYROLLES, paris 2007, p. 51
13
Pascal Roques, UML 2.5 par la pratique, Etudes de cas et exercices corrigés, 8è édition
Eyrolles, p.24.
 [34]

système en unités cohérentes, les cas d’utilisation, ayant un sens pour les
acteurs14.

A) LES ELEMENTS DES DIAGRAMMES DE CAS D’UTILISATION

Acteur : est une entité externe qui agit sur le système ; le terme acteur ne
désigne pas seulement les utilisateurs humains mais également les autres
systèmes. Les acteurs sont des classificateurs qui représentent des rôles au
travers d'une certaine utilisation (cas) et non pas des personnes physiques.
Ce sont des acteurs types.

Il se représente par un petit bonhomme avec son nom inscrit

dessous. Il est également possible de représenter un acteur sous la forme
d’un classeur stéréotypé « actor ».

Cas d’utilisation : un cas d’utilisation spécifie une fonction offerte par

l’application à son environnement. Un cas d’utilisation modélise donc un
service rendu par le système, sans imposer le mode de réalisation de ce
service. Un cas d’utilisation se représente par une ellipse contenant le nom
du cas (un verbe à l’infinitif), et optionnellement, au-dessus du nom, un
stéréotype.

B) REPRESENTATION DU DIAGRAMME DE CAS D’UTILISATION

La frontière du système est représentée par un cadre. Le nom

du système figure à l’intérieur du cadre, en haut. Les acteurs sont à
l’extérieur et les cas d’utilisation à l’intérieur.

C) RELATIONS DANS LE DIAGRAMME DE CAS D’UTILISATION

Relation d’inclusion : une relation d’inclusion d’un cas d’utilisation A par

rapport à un cas d’utilisation B signifie qu’une instance de A contient le
comportement décrit dans B : le cas A dépend de B. Lorsque A est sollicité, B
l’est obligatoirement, comme une partie de A. Cette dépendance est
symbolisée par le stéréotype « include ».

Relation de généralisation : un cas A est une généralisation d’un cas B si

B est un cas particulier de A. Cette relation de généralisation/spécialisation
est présente dans la plupart des diagrammes UML et se traduit par le
concept d’héritage dans les langages orientés objet.

Relation d’extension : On dit qu’un cas d’utilisation A étend un cas

d’utilisation B lorsque le cas d’utilisation A peut être appelé au cours de
14
Laurent AUDIBERT, op.cit., p.25.
 [35]

l’exécution du cas d’utilisation B. Exécuter B peut éventuellement entraîner

l’exécution de A : contrairement à l’inclusion, l’extension est optionnelle. Le
cas de base peut fonctionner tout seul, mais il peut également être complété
par un autre, sous certaines conditions, et uniquement à certains points
particuliers de son flot d’événements appelés points d’extension. Cette
dépendance est symbolisée par le stéréotype « extend ».

D) RELATION ENTRE ACTEUR ET CAS D’UTILISATION

Relation d’association : une relation d’association est chemin

de communication entre un acteur et un cas d’utilisation et est représenté un
trait continu.

E) RELATION ENTRE ACTEURS

La seule relation possible entre deux acteurs est la

généralisation : un acteur A est une généralisation d’un acteur B si l’acteur A
peut-être substitué par l’acteur B. Dans ce cas, tous les cas d’utilisation
accessibles à A le sont aussi à B, mais l’inverse n’est pas vrai.
 [36]

III.3.2. DIAGRAMME DES CLASSES PARTICIPANTES DE

CONCEPTION
Le diagramme de classes participantes est un diagramme de

classes UML qui décrit cas d’utilisation par cas les trois principales classes
d’analyse et leurs relations15 :

 Les classes dialogues possèdent des attributs et des opérations.

Les attributs représentent des champs de saisie ou des résultats.
Les opérations quant à elles, représentent des actions de
l’utilisation sur l’Interface Homme Machine ;
 Les classes contrôles contiennent des opérations. Ces opérations
représentent la logique applicative de l’application, les règles
métiers ou les comportements du système informatique ;
 Les classes entités possèdent en général des informations
persistantes de l’application.
1. Diagramme de classes participantes Consulter programme
exploitation

15
Joe NTAMBWE, mise au point d’un système de gestion des panneaux publicitaires, mémoire
de licence, L2 Informatique et télécommunications, UPL, 2011, inédit.
 [37]

2. Diagramme de classes participantes Mettre à jour programme

«boundary»
Page menus

-Menus

EXPLOITANT +Afficher page programme()

3.
«Control» «entity»
Ctrl Avis technique AVIS TECHNIQUE

-Numrefavistech
+Afficher page programme()
-Nomexploitant
+Enregistrer()
-Typeexploitation
+Rechercher()
-Zonegeologique
+Modifier()
-Permisexploitation
+Supprimer()

«boundary»
Page Avis technique
<
-Numrefavistech
-Nomexploitant
-Typeexploitation
-Zonegeologique
-Permisexploitation

+Enregistrer()
+Rechercher()
+Modifier()
+Su pprimer()

Diagramme de classes participantes solliciter exploitation

«entity»
«boundary» PROGRAMME
Page menus
-Reference
-Menus
-Datedebut
+Afficher page programme() -Datefin
-Heuredebut
-Heurefin
GEOLOGUE -Nbreexploitant
-Ageexploitant

«Control»
Ctrl Programme

+Afficher page programme()

+Enregistrer()
+Rechercher()
+Modifier()
+Su pprimer()
+Imprimer()

«boundary»
Page Programme

-Reference
< -Datedebut
-Datefin «entity»
-Heuredebut SITE S MINIE RS
-Heurefin
-Numrefsite
-Nbreexploitant
-Nomsite
-Ageexploitant
-Capacitesite
+Enregistrer()
+Rechercher()
-Nbreexploitant
+M odifier() -Localisationsite
+Supprimer()
+Imprimer() -Dureeexploitation

4. Diagramme de classes participantes Gérer sites miniers

 [38]

«boundary»
Page Menus
5. -Menus
ADMINISTRATEUR
+Lancer page()
«entity»
«ontrol»
Utilisateurs
Ctrl Utilisateurs
-Id_user
-nom_user
-prenom_user
+Lancer page() -age_user
+INSERT() -sexe_user
+SELECT() -statut_user
+UPDATE(
+DELETE()
+IMPRIMER()
«boundary»
Page Utilisateurs
-Id_user
-nom_user
-prenom_user
-age_user
-sexe_user
-statut_user

+INSERT()
+SELECT()
+UPDATE(
+DELETE()
+IMPRIMER()

Diagramme de classes participantes Gérer utilisateurs

6. «boundary»
Page Menus
-Menus
UTILISATEURS
+Ouvrir page()

«control» «entity»
Ctrl Authentification Utilisteurs
-Id
+Ouvrir page() -Login
+Connecter() -Pass word
+Annuler()
«boundary» +Quitter()
Page Authentification
-Id
-Login
-Pass word

+Connecter()
+Annuler()
+Quitter()

Diagramme de classes participantes s’authentifier

 [39]

III.4. CONCEPTION DES INTERACTIONS SYSTÈMES

III.4.1. DIAGRAMME DE SÉQUENCE DÉTAILLÉE DU SYSTÈME
Par rapport aux diagrammes de séquences système, nous
remplacerions, ici, le système, vu comme une boîte noire, par un ensemble
d’objets en collaboration. Ces objets sont des instances des trois (3) types de
classes d’analyse du diagramme de classes participantes, à savoir des
dialogues (les classes qui permettent les interactions entre l’IHM et les
utilisateurs), des contrôles (les classes qui modélisent la cinématique de
l’application) et des entités (les classes métier, qui proviennent directement
du modèle du domaine).
 [40]

1. Diagramme de séquence de conception consulter

GE OLOGU E Page M enus Page Programme

Ctrl Programme PROGRAM M E
1: Lancer page Programme()
2: Lancer page ()

3: Create form()
2.
4: Affichage de la page()
D
5: Sélectionner programme()
6: Sélectionner()

7: SELECT()

8: Résultat()
9: Résultat()
10: Affichage détail programme()

11: Saisir nouvelles donnée()

12: Valider saisie()

13: Valider()
14: U PDATE()

EXPLOITANT Page Menus Page Programme

15: Résu ltat() PROGRAMME
Ctrl Programme
1: Lancer page Programme() 16: Résulatat()
17: Affichage détail programme()
2: Lancer page ()

3: Create form()
4: Affichage de la page()

5: Rechercher programme()
6: Rechercher()

7: SELECT()

8: Résultat()
9: Résultat()
10: Affichage du résultat()

11: Sélectionner programme()

12: Sélectionner()
13: SELECT()

14: Résultat()

15: Résulatat()
16: Affichage détail programme()

iagramme de séquence conception Mettre à jour programme

 [41]

3. Diagramme de séquence conception solliciter exploitation

GEOLOGUE Page Sites miniers

Page Menus
Ctrl Sites miniers SITES MINIERS
1: Lancer page sites miniers()
2: Lancer page ()

4: Affichage de la page()
3: Create form()
4.
Opt 5: Saisir données du site minier() D
6: Valider saisie()
7: Valider()
8: INSERT()
[ENREGISTRER]

9: Résultat()
10: Résultat()
11: Message de confirmation()

Opt 12: Saisir l'identifiant()

13: Lancer la recherche()

14: Rechercher()
15: SELECT()
[RECHERCHE R]

16: Résultat()
17: Résulatat()
18: Message de confirmation()

Opt 19: Saisir l'identifiant()

20: Lancer la recherche()

21: Rechercher()
22: SELECT()

23: Résu ltat()

EXPLOITANT Page M enus 24: Résultat()
Page Avis technique
25: Affichage du résultat() Ctrl Avis technique AVIS TECHNIQU E
1: Lancer page Avis technique()
26: Saisir nouvelles données()
[MODIF IER]
2: Lancer page ()
27: Valider saisie()
28: Valider()
29: UPDATE()
3: Create form()
4: Affichage de la page()

5: Saisir informations() 30: Résu ltat()

OPT
31: Résultat()
32: Message de confirmation()
6: Valider saisie()
7: Valider()

OptALT 33: Saisir l'identifiant() 8: INSE RT()

34: Lancer la recherche()

35: Rechercher() 9: Résultat()
10: Résultat() 36: SELECT()
11: [Si avis technique défavorable]:: Demande rejetée()

37: Résultat()
[SUPPRIMER] 38: Résultat()
39: Affichage du résultat()
40: Sélectionner le site minier à supprimer() 12: Résu ltat()
41:13: Résulatat()
Supprimer()
14: [Sinon]:: Exploiter sites miniers() 42: DELETE()

43: Résultat()
44: Résultat()
45: Message de confirmation()

iagramme de séquence conception Gérer sites miniers

 [42]

ADMINISTRATEUR
Page Menus Page Utilisatuers
Ctrl Utilisateurs UTILISATEURS
1: Lancer page système()
2: Lancer page ()

3: Create form()
4: Affichage de la page()

Opt 5: Saisir données du user()

6: Valider saisie()
7: Valider()
8: INSE RT()
[ENREGISTRER]

9: Résultat()
10: Résultat()
11: M essage de confirmation()

Opt 12: Saisir l'identifiant()

13: Lancer la recherche()

14: Rechercher()
15: SE LECT()
[RECHERCHE R]

16: Résu ltat()

17: Résulatat()
18: M essage de confirmation()

Opt 19: Saisir l'identifiant()

20: Lancer la recherche()

21: Rechercher()
22: SE LECT()

23: Résu ltat()

24: Résultat()
25: Affichage du résultat()
[M ODIF IER] 26: Saisir nou velles données()

27: Valider saisie()

28: Valider()
29: UPDATE()

30: Résu ltat()

31: Résultat()
32: M essage de confirmation()

Opt 33: Saisir l'identifiant()

34: Lancer la recherche()

35: Rechercher()
36: SE LECT()

37: Résultat()
[SUPPRIME R] 38: Résultat()
39: Affichage du résultat()
40: Sélectionner le user à supprimer()
41: Supprimer()
42: DELETE()

43: Résultat()
44: Résultat()
45: M essage de confirmation()

5. Diagramme de séquence conception Gérer utilisateurs

 [43]

UTILISATEURS
Page Menus Page Authentification
Ctrl Authentification UTILISATEURS
1: Ouvrir page Authentification()
2: Ouvrir page ()

3: Create form()
4: Affichage de la page()

Loop 5: Saisir login()

6: Saisir pass word()

7: Valider saisie()
8: Valider()
9: SELECT()

Alt
10: Résultat()
11: Résultat()
12: Message d'erreur()

13: Résultat()
14: Résultat()
15: Affichage de la page de Menus()

6. Diagramme de séquence conception s‘authentifier

 [44]

III.4.2. DIAGRAMME DE CLASSES DE CONCEPTION

 [45]

III.5. CONCEPTION DES ARCHITECTURES DU LOGICIEL

III.5.1. CHOIX DES ARCHITECTURES LOGICIELLES
L’architecture logicielle décrit d’une manière symbolique et
schématique les différents éléments d’un ou de plusieurs systèmes
informatiques, leurs interrelations et leurs interactions. Contrairement aux
spécifications produites par l’analyse fonctionnelle, le modèle d'architecture,
produit lors de la phase de conception, ne décrit pas ce que doit réaliser un
système informatique, mais plutôt comment il doit être conçu de manière à
répondre aux spécifications.

Dans notre cas, nous travaillons avec l’architecture trois tiers.

Également appelée architecture à trois (3) niveaux ou à trois couches,
l’architecture trois tiers est une architecture client-serveur dans laquelle
coexistent des modules indépendants permettant le rendu d’une interface
utilisateur, les process logiques, fonctionnels et métiers ainsi que l’accès aux
données. Ainsi, cette architecture est composée de trois niveaux ou couches
que sont :

La couche de présentation (premier niveau) : c’est la première

couche qui compose l’infrastructure trois tiers. Elle correspond à la partie
visible et interactive de l’application pour les utilisateurs. On parle d’interface
homme-machine. Elle peut être représentée en HTML, CSS, JavaScript, etc.,
pour être exploitée par un navigateur web.

La couche métier ou fonctionnelle (deuxième niveau) : c’est la

seconde couche qui compose l’infrastructure trois tiers. Elle correspond à un
ensemble de composants métiers qui permettent de traiter un ensemble
d’actions sur un serveur, et de faire éventuellement appel à des services
externes pour envoyer des réponses aux requêtes envoyées par le client via
l’interface graphique (la couche présentation). Les langages serveurs les plus
utilisés sont : le PHP, le Ruby, le C/C++, etc.

La couche d’accès aux données (troisième niveau) : c’est la

troisième couche qui compose l’infrastructure trois tiers. Elle correspond au
serveur de la base de données. Il s’agit aussi de la couche d’accès aux
données. Sur ce troisième tiers, un SGBD est installé, comme par exemple
MySQL ou PostgreSQL.
 [46]

La

figure ci-dessous représente l’architecture 3 tiers.

III.5.2. DIAGRAMME DE DÉPLOIEMENT

Le diagramme de déploiement permet de représenter les outils
sur lesquels s’exécute l’application. Ces outils comprennent des nœuds
correspondant aux supports physiques (serveurs, routeurs) ainsi que la
répartition des artefacts logiciels (bibliothèques, exécutables) sur ces nœuds.
Ce, faisant notre application, sera déployée sur un serveur dédiée et
emprunte le réseau internet pour être accessible aux clients.
 [47]

Chapitre Quatrième : IMPLÉMENTATION DE LA

SOLUTION NOUVELLE
L’objectif de ce présent chapitre est de faire la description du
processus qui nous a permis de parvenir à l’implémentation d’une application
web. Ce processus a commencé par une implémentation de la base de
données destinée à contenir les données utilisées par le futur système. À la
suite de cela, nous essayerons de montrer quelques bouts de code réalisés
avec le langage PHP qui nous ont permis d’implémenter la plateforme. Et
enfin nous montrerons les principales interfaces et fenêtres de l’application
ainsi que les codes.

IV.1. DESCRIPTION DES OUTILS ET PLATEFORMES

Pour développer l’application liée à la gestion des sites miniers
au sein de la division provinciale des mines, nous avons utilisé plusieurs
outils et nous allons faire une petite présentation de ces derniers.

IV.1.1. CHOIX DE L’OUTIL DE MODÉLISATION

Un outil de modélisation est un logiciel qui permet de

modéliser des diagrammes, comme les diagrammes de cas d’utilisation, de
classes, de séquences, etc. UML DIAGRAMME EDGE Diagrammer est un des
logiciels de conception ou de modélisation parmi tant d’autres (ArgoUML,
Papyrus, UML Designer, etc.).
 [48]

C’est un outil d’UML et de génie logiciel assisté par ordinateur.

Le modeleur prend en charge tous les 14 types de diagramme spécifiés dans
UML 2.4. Il supporte également entre autres les diagrammes et standards,
comme les organigrammes, les diagrammes de flux de données, etc.

IV.1.2. CHOIX DE L’OUTIL DE DÉVELOPPEMENT

L’outil pour le développement de l’application en mode local
est le logiciel XAMPP version 3.2.2 X32.

Un serveur web est spécifiquement un serveur multi-service

utilisé pour publier des sites web sur Internet ou un intranet. XAMPP (X
(cross) Apache MariaDB Perl PHP) est un serveur web parmi tant d’autres
(EasyPHP, WAMP, etc.). C’est un ensemble de logiciels permettant de mettre
en place facilement un serveur Web local, un serveur FTP et un serveur de
messagerie électronique. Il offre une bonne souplesse d'utilisation, réputée
pour son installation simple et rapide.

IV.2. OUTILS DE DÉVELOPPEMENT

IV.2.1. LE FRAMEWORK PHP : CODEIGNITER
CodeIgniter est un Framework MVC (Model-View-Controller)
écrit en PHP. Initialement développé par la société américaine EllisLab, sa
première version remonte à 2006. Depuis 2013, c’est le BCIT (British
Columbia Institute of Technologie), université canadienne, qui en assure le
développement. Aujourd'hui en version 3, CodeIgniter continue d'évoluer
régulièrement en gardant sa philosophie initiale : être un Framework très
léger et rapide à l'exécution.

Notre choix porte sur ce Framework pour sa maturité ; nous

apprécions beaucoup la clarté de sa documentation et sa prise en main
rapide. La courbe d’apprentissage est excellente. Mais ce que nous aimons
par-dessus tout, c’est sa légèreté, sa rapidité et sa souplesse.

CodeIgniter encourage fortement l'utilisation de l'architecture

Model-Vue-Contrôleur. Le Framework est compatible avec PHP 5 à partir de la
version 2.0.0. Une liste non exhaustive des principales caractéristiques de
CodeIgniter pourrait être celle-ci : Gestion des bases de données avec
support de plusieurs plateformes, Envoi de mails supportant les pièces
jointes, Gestion des sessions, Validation des données et des formulaires,
Sécurité et filtres XSS, Cryptage des données, Classe de gestion des tests
unitaires, etc.16

16
https://codeigniter.com, Consulté le 09 Novembre 2022 à 19h4
 [49]

Voici un schéma très bien fait extrait de la documentation. Il

illustre le fonctionnement de CodeIgniter.

IV.2.2. LE FRAMEWORK CSS : BOOTSTRAP

Bootstrap est une collection d'outils utile à la création du
design de sites et d'applications web.

C'est un ensemble qui contient des codes HTML et CSS, des

formulaires, boutons, outils de navigation et autres éléments interactifs, ainsi
que des extensions JavaScript en option.

IV.2.3. LE FRAMEWORK JAVASCRIPT : jQuery

JQuery est une bibliothèque JavaScript libre et multiplateforme
créée pour faciliter l'écriture de scripts côté client dans le code HTML des
pages web.
[50]
 [51]

IV.3. PRÉSENTATION DES INTERFACES DU SYSTÈME

INFORMATIQUE
LA PAGE D’ACCUEIL

INTERFACE D’AJOUT DES EXPLOITANTS

 [52]

VUE D’ENSEMBLE DES EXPLOITANTS DISPONIBLES

PRÉSENTATION DES CODES SOURCES

<?php
namespace App\Controllers;
use App\Models\ModelExploitant;
{
public function index()
{
return view('index');
}
public function exploitant()
{
return view('exploitant');
}
1. ENREGISTRER
public function AjouterF()
{
$ModelExploitant=new ModelExploitant();
$num=$_POST['TIdexploitant'];
$nom=$_POST['TNomexploitant'];
$sexe=$_POST['TSexeexploitant'];
$age=$_POST['TAgeexploitant'];
$adresse=$_POST['TAdresseexploitant'];
$tel=$_POST['TTelexploitant'];
 [53]

$tab=['IdexploitantE'=>$num,'NomexploitantE'=>$nom,'SexeexploitantE'=
>$sexe,'AgeexploitantE'=>$age,'AdresseexploitantE'=>$adresse,'Telexploit
antE'=>$tel];
$ModelExploitant->insert($tab);
}

public function Fajouterexploitant()

{
return view('Fajouterexploitant');
}
2. MODIFIER
public function Fmodifierexploitant()
{
return view('Fmodifierexploitant');
}
public function ModifierF()
{
$ModelExploitant=new ModelExploitant();
$numero=$_POST['TIdexploitant'];
$nom=$_POST['TNomexploitant'];
$sexe=$_POST['TSexeexploitant'];
$age=$_POST['TAgeexploitant'];
$adresse=$_POST['TAdresseexploitant'];
$tel=$_POST['TTelexploitant'];

$tab=['NomexploitantE'=>$nom,'SexeexploitantE'=>$sexe,'AgeexploitantE'
=>$age,'AdresseexploitantE'=>$adresse,'TelexploitantE'=>$tel];
$ModelExploitant->update($numero,$tab);
}
3. SUPPRIMER
public function Fsupprimerexploitant()
{
return view('Fsupprimerexploitant');
}
public function SupprimerF()
{
$ModelExploitant=new ModelExploitant();
$num=$_POST['TIdexploitant'];
$ModelExploitant->delete($num);
}
4. RECHERCHER
public function Frechercherexploitant()
{
$ModelExploitant=new ModelExploitant();
$resultat['cle']=$ModelExploitant->findAll();
return view("Frechercherexploitant",$resultat);
}
 [54]

CONCLUSION
Mieux vaut la fin d’une chose que son entame, dit-on. Après ce
large tour d’horizon, dont nous sommes arrivés à la fin de notre recherche
qui s’aurait focalisée sur la conception et implémentation d’une application
web de gestion des sites miniers au sein d’une division provinciale de
mine dont la division provinciale des mines de Kamina est prise en
l’occurrence.

En effet, notre but est d’implémenter une application

informatique qui gérerait tous les sites miniers en rapport avec les
exploitants au sien de la division provinciale des mines de Kamina.

Outre l’introduction générale qui paraphrase notre travail, et la

conclusion générale qui le boucle, ce travail serait constitué de quatre (4)
chapitres :

 Le premier s’intitulerait DEFINITION DES CONCEPTS ET

CONSIDERATIONS THEORIQUES, où il aurait été question de
présenter l’ensemble de théorie nécessaire pour aborder ce travail en
donnant les définitions en rapport avec le sujet d’étude, en suite de
donner les théories nécessaires sur le système d’information et la
méthode utilisée, enfin le langage de programmation et la gestion de
données.
 Le deuxième ayant comme titre PRESENTATION DE L’EXISTANT,
SPECIFICATION DES BESOINS ET ANALYSE DU METIER, où nous
aurions présenté notre champ d’étude puis toute son analyse.
 Le troisième parlerait de la CONCEPTION DU SYSTEME
INFORMATIQUE, d’où, la principale préoccupation aurait été celle du
développement pratique du nouveau système d’information qui sera
implémenté dans la dernière partie de notre projet.
 Le quatrième se baserait sur IMPLÉMENTATION DE LA SOLUTION
NOUVELLE, où il aurait été question de la mise en place d’une
application informatique qui tournera selon les améliorations obtenues
dans le chapitre précédant.

En effet, pour parvenir à développer le système d’information

pour la gestion des sites miniers, vu les problèmes vécus dans notre champ
d’investigation, qui est la division provinciale des mines, le présent travail
aurait soulevé une problématique, qui s’est présentée de la manière
suivante :
 [55]

 Quelles sont les nécessités pour aboutir à l’implémentation et

comment va-t-elle fonctionner au sein de la division de mine
concernant la problématique.
 Comment résoudre le problème de la mise à jour des sites, ce qui
engendre des conflits miniers dans la distribution des sites.

À l’égard de ce qui précède, pour arriver à résoudre les

problèmes prépondérants de cette étude, nous aurions utilisé la méthode UP
attachée au langage de modélisation UML, et le langage de programmation
utilisé pour la concrétisation de la recherche aurait été le PHP avec le XAMPP
comme base de données.

Nous tenons à confirmer l’hypothèse formulée dans

l’introduction générale de ce travail que cela aurait été vrai pour pallier au
problème que rencontre la division provinciale des mines, il aurait fallu que
nous développions une application de gestion des sites miniers, et en
concevant une base de données, qui stockerait toutes les informations utiles
à cette dernière, et qui sera capable de restituer les données dans un temps
raisonnable, en cas d’une recherche quelconque.
 [56]

BIBLIOGRAPHIE
I. OUVRAGES
 Pascal Roques, Franck Vallée, UML 2 en action de l’analyse des besoins
à la conception, éd. Eyrolles, 4eme édition, 2007, p.12.

 Pascal Roques, les Cahiers du programmeur UML2 modéliser une

application web, 4e éd. Eyrolles, paris 2004, p.4
 Laurent AUDIBERT, UML 2.0, Institut Universitaire de Technologie de
Villetaneuse, département informatique, 1ère année, 2007, p.22
 P. Roques et F. Vallée, UML 2 en action de l’analyse des besoins à la
conception, 4e Ed. EYROLLES, paris 2007, p. 51
 Pascal Roques, UML 2.5 par la pratique, Études de cas et exercices
corrigés, 8è édition Eyrolles, p.24.

II. NOTES DES COURS

 Ir Trésor MWAMBA, Cours informatique générale G1 INFO/UNIKAM

2019, inédit.
 Ir Valery KABONGO, séminaire G3 INFO/UNIKAM 2022, inédit.

III. DICTIONNAIRES

 LE PETIT ROBERT POUR TOUS, édition 2010

IV. SITES INTERNET

 http://www.wikipedia.com/fr.m.wiktionary.org/methode, Consulté le 24/06/2022,

13h42
 http://wiktionary.org/dictionnaire/conception/ (consulté le 01/07/2022 à 11h22)
 http://wiktionary.org/dictionnaire/implementation/ (consulté le 01/07/2022 à 11h30)
 http://www.astuce-aide-informatique.info, 08/07/2022 à 13h40’
 www.wikipedia.com, Consulté le 22 Mai 2022 à 09h41’.
 https://codeigniter.com, Consulté le 09 Novembre 2022 à 19h4
 [57]

TABLE DES MATIERES

EPIGRAPHE........................................................................................................I
DEDICACE.........................................................................................................II
AVANT-PROPOS...............................................................................................III
INTRODUCTION GENERALE...............................................................................1
1. PRESENTATION DU SUJET..........................................................................1
2. ETAT DE LA QUESTION..............................................................................2
3. PROBLEMATIQUE.......................................................................................3
4. HYPOTHESE...............................................................................................3
5. CHOIX ET INTERET DU SUJET.....................................................................3
5.1. CHOIX DU SUJET..................................................................................3
5.2 INTERET DU SUJET................................................................................3
6. DELIMITATION DU SUJET............................................................................4
7. METHODOLOGIE ET TECHNIQUE................................................................4
7.1 METHODOLOGIE...................................................................................4
7.2 TECHNIQUE...........................................................................................5
8. SUBDIVISION DU TRAVAIL.........................................................................6
Chapitre premier : DEFINITION DES CONCEPTS ET CONSIDERATIONS
THEORIQUES....................................................................................................7
I.1. DEFINITION DES CONCEPTS..................................................................7
I.2. CONSIDETATIONS THEORIQUES..............................................................8
I.2.1. PRESENTATION DU PROCESSUS UNIFIE.............................................8
I.2.2. LE PROCESSUS UNIFIE EST CONDUIT PAR LES CAS D'UTILISATION...8
I.2.3. LE PROCESSUS UNIFIE EST CENTRE SUR L'ARCHITECTURE...............8
I.2.4. LE PROCESSUS UNIFIE EST ITERATIF ET INCREMENTAL.....................8
I.2.5. LE PROCESSUS UNIFIE EST PILOTE PAR LES RISQUES.......................9
I.2.6. LE CYCLE DE VIE DU PROCESSUS UNIFIE...........................................9
I.2.7. ETAPES DE LA METHODE UP............................................................10
I.2.8. PRESENTATION DU LANGAGE UML..................................................10
I.3. LANGAGE DE PROGRAMMATION............................................................12
I.3.1. LANGAGE INFORMATIQUE................................................................12
I.3.2. AVANTAGES DE LANGAGES INFORMATIQUES..................................13
I.3.3. CHOIX DU LANGAGE DE PROGRAMMATION.....................................13
 [58]

Chapitre Deuxième : PRESENTATION DE L’EXISTANT, SPECIFICATION DES

BESOINS ET ANALYSE DU METIER..................................................................14
II.1. GENERALITE........................................................................................14
II.2 PRESENTATION DE L’ENTREPRISE.........................................................14
II.2.1 HISTORIQUE.....................................................................................14
II.2.2 SITUATION GEOGRRAPHIQUE..........................................................15
II.2.3. OBJECTIF.........................................................................................15
II.2.4. STRUCTURE FONCTIONNELLE DE L’ENTREPRISE............................15
I.2.5. ORGANIGRAMME DE LA DIVISION PROVINCIALE DES MINES ET
GEOLOGIE DU HAUT-LOMAMI...................................................................24
II.3 ANALYSE DU METIER.............................................................................26
II.3.1 DESCRIPTION DU METIER.................................................................26
II.3.2 ETUDE PRELIMINAIRE.......................................................................26
a. DESCRIPTION TEXTUELLE DE PROCESSUS METIER..........................26
b. BESOIN EXPRIME..............................................................................26
c. INDENTIFICATION DES ACTEURS......................................................26
d. DIAGRAMME DE CONTEXTE STATIQUE.............................................27
e. DIAGRAMME D’ACTIVITE..................................................................28
II.3.3. CONTRAINTES FONCTIONNELLES...................................................29
II.3.4. CAPTURE DES BESOINS FONCTIONNELS.........................................29
a. IDENTIFICATION DE CAS D’UTILISATION DU METIER........................29
b. FICHE DE DESCRIPTION DES CAS D’UTILISATION/ SCENARIO..........29
Chapitre Troisième : CONCEPTION DU SYSTEME INFORMATIQUE..................32
III.1. INTRODUCTION................................................................................32
III.2. CAPTURE DES BESOINS DU SYSTÈME INFORMATIQUE.........................32
III.2.1. ACTEURS DU SYSTÈME INFORMATIQUE.........................................32
III.3. ANALYSE DU SYSTÈME INFORMATIQUE...............................................33
III.3.1. DIAGRAMME DES CAS D’UTILISATION DE CONCEPTION................33
III.3.2. DIAGRAMME DES CLASSES PARTICIPANTES DE CONCEPTION.......35
III.4. CONCEPTION DES INTERACTIONS SYSTÈMES......................................39
III.4.1. DIAGRAMME DE SÉQUENCE DÉTAILLÉE DU SYSTÈME....................39
III.4.2. DIAGRAMME DE CLASSES DE CONCEPTION...................................44
III.5. CONCEPTION DES ARCHITECTURES DU LOGICIEL...............................45
III.5.1. CHOIX DES ARCHITECTURES LOGICIELLES....................................45
III.5.2. DIAGRAMME DE DÉPLOIEMENT..............................................................................................46
Chapitre Quatrième : IMPLÉMENTATION DE LA SOLUTION NOUVELLE..............................................47
 [59]

IV.1. DESCRIPTION DES OUTILS ET PLATEFORMES..........................................................................47

IV.1.1. CHOIX DE L’OUTIL DE MODÉLISATION.....................................................................................47
IV.1.2. CHOIX DE L’OUTIL DE DÉVELOPPEMENT.................................................................................47
IV.2. OUTILS DE DÉVELOPPEMENT..................................................................................................48
IV.2.1. LE FRAMEWORK PHP : CODEIGNITER......................................................................................48
IV.2.2. LE FRAMEWORK CSS : BOOTSTRAP.........................................................................................49
IV.2.3. LE FRAMEWORK JAVASCRIPT : jQuery.....................................................................................49
IV.3. PRÉSENTATION DES INTERFACES DU SYSTÈME INFORMATIQUE...................................................50
CONCLUSION..............................................................................................................................................53
BIBLIOGRAPHIE..........................................................................................................................................55
TABLE DES MATIERES.................................................................................................................................56