[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
1
appelé ordinateur , 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

2
raisonne pour résoudre un problème, pour démontrer un théorème.

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

 [5]

3
de faire quelque chose suivant certains principes et avec un certain ordre.

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.

3 [Link] Consulté le 24/06/2022, 13h42

 [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
 [7]

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.

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
[Link] (consulté le 01/07/2022 à 11h22)
5
[Link] (consulté le 01/07/2022 à 11h30)
6
[Link] 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

7
concourent à l’obtention d’un système logiciel ou à l’évolution d’un système existant.

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
8
cas d’utilisation et piloté par les risques.

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 en plusieurs parties qui sont autant de
mini-projets (Concept systémique de système et sous-systèmes).
7 eme
Pascal Roques, Franck Vallée, UML 2 en action de l’analyse des besoins à la conception, éd. Eyrolles, 4
édition, 2007, p.12.
8
Ir valery KABONGO, séminaire G3 INFO/UNIKAM 2022, inédit.
 [9]

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.

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

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

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) ;

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

 Diagramme de profils (profil diagram).

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
 [13]

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).

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é
11
de façon locale, en plus il est un langage impératif orienté objet .

11
[Link], 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 ;

 [15]

 Ministre de mine et affaire foncière 1969 ;

 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 :

 [16]

 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.

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 ;

 [17]

 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

 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

 [18]

 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.

 [19]

D. FONCTIONNEMENT

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.
 [20]

 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 ;

 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 Bureau Bureau Bureau

Gestion Administratio Bureau
Doc, d’Etude et
des Mines Géologi Carrière Protection Inspectio
n et Finances Arch. et Planificatio
Ressource e s de n Minière
NTIC n l’environne

Bureau Minier Isolé de Bureau Minier Isolé de

MALEMBA-NKULU BUKAMA

Antenne Minière
Antenne Minière Antenne Antenne Minière de Antenne Minière de
Rive GAUCHE Antenne Antenne
Rive DROITE Minière de KIKONDJA/KIPAM KIBANDA
MALEMBA- Minière de Minière de
MALEMBA-NKULU NKINDA/KIBUL BA
NKULU a KANIAMA KABONGO
a MULONGO A
MWANZA-SEYA
[25]
 [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

c. INDENTIFICATION DES ACTEURS

ACTEURS DEFINITION ROLE

Service de contrôle de matière Déposer avis technique,

SAEMAPE
première consulter les sites

Vérifier l’avis technique,

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

Responsable du bon
Consulter les sites, vérifier l’avis
SECRETARIAT fonctionnement des activités de
technique
l’entreprise
 [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 :

G E S T IO N D E S IT E S
M IN IE R S

SAEMAP
S E C R E T A R IA T

B U R E A U G E O L O G IE

 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]

SAE M AP SE C R E T AR IAT D IV IS IO N B UR E AU G E O L O G IE

D ép o se r a v is
te c h n i q u e

R é c e p t io n a v i s
te c h n i q u e

V é r i fie r a v i s
te c h n i q u e

R e fu s e r a v i s [S i V a li d e ]
te c h n i q u e [S in on ]

E n re g is tre r a v is
tech n iq u e
 [30]

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 :
 [31]

1. Saisir

SY ST E M E
SAE M AP
S a i s i r i n fo r m a t i o n s a v i s t e c h n i q u e

V a lid e r s a isie

E n r e g i s t r e r i n fo r m a t i o n s

e n v o y e r a v is te c h n iq u e

C o n fi r m e r e n v o i

M e s s a g e d e c o n fi r m a t i o n

informations avis technique.

2. Valider saisie

3. Enregistrer informations

4. Envoyer avis technique

 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

 [32]

8. Accorder avis favorable

S y st è m e

SAE M AP
d e t e r m in e r le s co o r d o n é e s ge o g r a p h iq u e

d e te r m in e r p e r m is d e r e ch e r c h e

d e te r m in e r le p e r m is d 'e x p lo it a tio n

ALT

[S i c o r d o n n é e s p e r m is d 'e x p l o it a t i o n e t d e r e c h e r c h e e x i s t e n t d é jà ]: : a r r e t e r p r o c e s s u s

[ s i n o n ] : : fo u i r n i r i n fo r m a t i o n

 Titre : TRAITER AVIS TECNHIQUE

 Objectif : Permettre Au bureau géologie de traiter l’avis technique.

 Acteurs : bureau géologie

 Pré conditions :
 [33]

 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

 [34]

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 et/ou modifier directement l’état du
système, en émettant et/ou en recevant des messages éventuellement porteurs de
données12.

Dans notre cas, les acteurs sont :

ACTEURS TYPE ROLE

Son rôle est de venir solliciter une possible exploitation

EXPLOITANT Externe
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 système,

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

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
 [35]

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 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-

13
Pascal Roques, UML 2.5 par la pratique, Etudes de cas et exercices corrigés, 8è édition Eyrolles, p.24.
14
Laurent AUDIBERT, [Link]., p.25.
 [36]

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 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.
 [37]

C O N SU L TE R PR O G R AM M E
E X P L O IT A T IO N

A D M IN IS T R A T E U R
E X PL O IT A N T G E R E R U T IL IS A T E U R

«i n c l u d e »

S O L L IC IT E R E X P L O IT A T I O N
«i n c l u d e »

«i n c l u d e »

S 'A U T H E N T IF IE R

«i n c l u d e »
G E R E R S IT E S M I N I E R S

«i n c l u d e »

G E O LO G U E
M E T T R E A J O U R PR O G R A M M E

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 ;

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.
 [38]

 Les classes entités possèdent en général des informations persistantes de

l’application.

1. Diagramme de classes participantes Consulter programme exploitation

2. Diagramme de classes participantes Mettre à jour programme

 [39]

«b o u n d a r y »
P a ge m e n u s

-M en u s

+ A f fi c h e r p a g e p r o g r a m m e ()
E X P L O ITA N T

«C o n t r o l » «e n t i t y »
C tr l A v is te c h n iq u e A V IS TE C H N IQ U E

- N u m r e fa v i s t e c h
+ A f f i c h e r p a g e p r o g r a m m e ()
- N o m e x p lo it a n t
+ E n r e g i s t r e r ()
- Ty p e e x p lo ita t io n
+ R e c h e r c h e r ()
- Z o n e g e o lo giq u e
+ M o d i f i e r ()
- P e r m is e x p lo it a tio n
+ S u p p r i m e r ()

«b o u n d a r y »
P a ge A v is te ch n iq u e
<
- N u m r e fa v i s t e c h
- N o m e x p lo it a n t
- Ty p e e x p lo ita t io n
- Z o n e g e o lo giq u e
- P e r m is e x p lo it a tio n

+ E n r e g i s t r e r ()
+ R e c h e r c h e r ()
+ M o d i f i e r ()
+ S u p p r i m e r ()

3. Diagramme de classes participantes solliciter exploitation

4. Diagramme de classes participantes Gérer sites miniers

 [40]

«b o u n d a r y »
Pa ge M e n u s

- M en u s
A D M IN IS TR A TE U R
+ L a n c e r p a g e ()

«e n t i t y »
«o n t r o l »
U tilisa t e u r s
C t r l U t ilisa te u r s
- Id _ u s er
- n o m _ u s er
- p r en o m _ u s e r
+ L a n c e r p a g e () - a ge _ u s er
+ I N S E R T () - s ex e_ u s er
+ S E L E C T () - s ta t u t _ u s er
+U PD ATE (
+ D E L E T E ()
+ I M P R I M E R ()
«b o u n d a r y »
P a ge U t ilisa te u r s

- Id _ u s er
- n o m _ u s er
- p r en om _ u s er
- a ge_ u s er
- s ex e_ u s e r
- s t a t u t _ u s er

+ I N S E R T ()
+ S E L E C T ()
+U PD A TE (
+ D E L E T E ()
+ I M P R I M E R ()

«b o u n d a r y »
P a ge M e n u s

- M en u s
«b o u n d a r y »
U TIL I S A TE U R S «e n t i t y »
P a ge m e n u s
+ O u v r i r p a g e () E X P L O ITA N T
-M en us

+ A ff i c h e r p a g e p r o g r a m m e ( )

A D M IN IS TR A TE U R
«c o n t r o l »
«e n t i t y »
C t r l A u t h e n t i fi c a t i o n
U t iliste u r s

- Id
+ O u v r i r p a g e () - L o g in
«C o n t r o l »
+ C o n n e c t e r () -Pass w ord
C t r l S ite m in ie r
+ A n n u l e r ()

«b o u n d a r y » + Q u i t t e r ()
+ A ffi c h e r p a g e p r o g r a m m e ()
«e n t i t y »
P a g e A u t h e n t i fi c a t i o n + E n r e g i s t r e r ()
S ITE S M IN IE R S
+ R e c h e r c h e r ()
-Id
+ M o d i fi e r () - N u m r e fs i t e
- L o g in
+ S u p p r i m e r () - N o m s ite
-P a s s w or d
- C a p a cite s ite
- N b r e e x p lo it a n t
+ C o n n e c t e r () - L o ca lis a tio n site

+ A n n u l e r () - D u r e e e x p lo it a tio n

+ Q u i t t e r ()
«b o u n d a r y »
Pa g e S ite m in ie r
<
- N u m r e fs i t e
- N o m site
- C a p a cit e site
- N b r e e x p lo it a n t
- L o c a lisa tio n sit e
«e n t i t y »
- D u r e e e x p lo ita tio n
PR O G R A M M E
+ E n r e g i s t r e r ()
+ R e c h e r c h e r ()
+ M o d i fi e r ( )
+ S u p p r i m e r ()

5. Diagramme de classes participantes Gérer utilisateurs

6. Diagramme de classes participantes s’authentifier

 [41]

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).
 [42]

1. Diagramme de séquence de conception consulter programme exploitation

2. Diagramme de séquence conception Mettre à jour programme

 [43]

3. Diagramme de séquence conception solliciter exploitation

 [44]

4. Diagramme de séquence conception Gérer sites miniers

 [45]

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

 [46]

6. Diagramme de séquence conception s‘authentifier

 [47]

III.4.2. DIAGRAMME DE CLASSES DE CONCEPTION

 [48]

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.
 [49]

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.
 [50]

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.

E X PLO ITA N T

«A r t i f a c t »
G es t io n d es s it es m in ier s . L in k

S erveu r w eb S erveu r d e b ase d e d on n ées

G E O LO G U E
«A r t i f a c t » «A r t i f a c t »
A p p l ic a t io n . p h p S c r ip t . s q l
«A r t i f a c t »
G es t io n d es s it es m in ier s . L in k

A D M INIS TR A TE U R

«A r t i f a c t »
G es t io n d es s it es m in ier s . L in k

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.).
 [51]

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
[Link] Consulté le 09 Novembre 2022 à 19h4
 [52]

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.
[53]
 [54]

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

INFORMATIQUE

LA PAGE D’ACCUEIL

INTERFACE D’AJOUT DES EXPLOITANTS

 [55]

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'];
 [56]

$adresse=$_POST['TAdresseexploitant'];
$tel=$_POST['TTelexploitant'];

$tab=['IdexploitantE'=>$num,'NomexploitantE'=>$nom,'SexeexploitantE'=>$sexe,'Ageexp
loitantE'=>$age,'AdresseexploitantE'=>$adresse,'TelexploitantE'=>$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,'Adres
seexploitantE'=>$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);
}
 [57]

4. RECHERCHER
public function Frechercherexploitant()
{
$ModelExploitant=new ModelExploitant();
$resultat['cle']=$ModelExploitant->findAll();
return view("Frechercherexploitant",$resultat);
}

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.
 [58]

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 :

 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.
 [59]

BIBLIOGRAPHIE
I. OUVRAGES

 Pascal Roques, Franck Vallée, UML 2 en action de l’analyse des besoins à la

eme
conception, éd. Eyrolles, 4 édition, 2007, p.12.

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

e
web, 4 é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

 [Link] Consulté le 24/06/2022, 13h42

 [Link] (consulté le 01/07/2022 à 11h22)

 [Link] (consulté le 01/07/2022 à 11h30)

 [60]

 [Link] 08/07/2022 à 13h40’

 [Link], Consulté le 22 Mai 2022 à 09h41’.

 [Link] Consulté le 09 Novembre 2022 à 19h4

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
 [61]

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
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
 [62]

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
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