Conception et implantation d'une base de données pour la gestion du charroi automobile de Vodacom Congo au Katanga

O. INTRODUCTION GENERALE

0.1. Choix du sujet

En avril 2009, nous avons effectué un stage de professionnalisation au sein de l'entreprise de télécommunication Vodacom Congo à Lubumbashi. Parmi différents services rendus pendant ce stage, une de nos tâches était d'élaborer des rapports de gestion du charroi automobile de cette entreprise. Pour rédiger de tels rapports souvent chiffrés avec des illustrations graphiques sur Excel, il nous fallait chaque fois rassembler des données stockées dans des archives, les saisir puis les présenter selon les attentes de notre encadreur de stage. Cette manière de faire coûtait énormément en temps et en énergie. Et quand certaines archives sont introuvables ou inaccessibles, le travail devient d'autant plus difficile et les données elles- mêmes deviennent peu fiables.

Disposer d'un système informatique qui l'aide à gérer son charroi automobile, ne serait-ce pas ce dont Vodacom Congo a besoin ? Le présent travail tente donc de satisfaire ce besoin. C'est à juste titre que nous l'intitulons : « Conception et implantation d'une base de données pour la gestion du charroi automobile de Vodacom Congo au Katanga ».

0.2. Définition d'une base de données

Une base de données est un ensemble de données modélisant les objets d'une partie du monde réel et servant de support à une application informatique. Pour mériter le terme de base de données, un ensemble de données non indépendantes doit être interrogeable par le contenu. Les données doivent être interrogeables selon n'importe quel critère. Il doit être possible de retrouver leur structure [GARD 03, p. 3].

Un Système de Gestion de Base de Données (SGBD), quant à lui, peut être perçu comme un ensemble de logiciels systèmes permettant aux utilisateurs d'insérer, de modifier et de rechercher efficacement des données spécifiques dans une grande masse d'informations partagées par de multiples utilisateurs. Les informations sont stockées sur mémoires secondaires, en général des disques magnétiques. Les recherches peuvent être exécutées à partir de la valeur d'une donnée désignée par un nom dans un ensemble, mais aussi à partir de

relations entre objets [GARD 03, p. 3]. Parmi les logiciels de gestion des bases de données nous pouvons citer : Oracle, Ingres, SQL Server, DB2, Access, My SQL, PostGre...

0.3. Problématique

Vodacom accorde une attention particulière à la gestion de son charroi automobile. Des informations nécessaires à cette gestion sont régulièrement notées. Des documents sont mis à jour et consultés ; ce qui permet de connaître l'état de chaque véhicule et de veiller à son approvisionnement en carburant.

Cependant, un problème se pose : ce système de gestion n'est pas informatisé ; ce qui le rend obsolète. Elaborer un rapport de gestion des véhicules dans ces conditions coûte énormément en temps et en énergie. On recourt absolument aux documents d'archives qui peuvent par ailleurs se perdre ou se détériorer. Les données présentées en dernier ressort sur Excel sont recueillies après un lourd travail de recherche des données dans les archives. Ce travail est déjà lent lorsqu'il ne concerne que la trentaine de véhicules dont dispose Vodacom pour le moment. Si le nombre de véhicules venait à augmenter, on aurait sans doute besoin d'une main d'oeuvre supplémentaire.

Non-informatisation du système et, par conséquent, lenteur, lourdeur de ce même système, tel est le problème majeur auquel est butée la gestion du charroi automobile de Vodacom que la présente étude tente de résoudre.

0.4. Intérêt du sujet

Les bases de données sont actuellement au coeur du système d'information des entreprises. Elles ont pris une place importante en informatique, et particulièrement en gestion. En concevant une base de données pour la gestion du charroi automobile de Vodacom au Katanga, cette étude comporte un intérêt majeur du fait qu'après analyse, elle propose des solutions à des problèmes diagnostiqués dans ce domaine.

0.5. Approche méthodologique et division du travail

0.5.1. Approche méthodologique

La conception d'un système d'information n'est pas évidente car, il faut réfléchir à l'ensemble de l'organisation que l'on doit mettre en place. La phase de conception nécessite des méthodes permettant de mettre en place un modèle (une description) sur lequel on va s'appuyer. La modélisation consiste à créer une représentation virtuelle d'une réalité de telle façon à faire ressortir les points auxquels on s'intéresse. Ce type de méthode est appelé analyse [DIGA 01, p.5].

Il est aussi difficile de modéliser un domaine sous une forme directement utilisable par un SGBD. Une ou plusieurs modélisations intermédiaires sont donc utiles, le modèle entitésassociations constitue l'une des premières et des plus courantes. Ce modèle permet une description naturelle du monde réel à partir des concepts d'entité et d'association. Basé sur la théorie des ensembles et des relations, ce modèle se veut universel et répond à l'objectif d'indépendance données-programmes. Ce modèle, utilisé pour la phase de conception, s'inscrit notamment dans le cadre d'une méthode, plus générale et très répandue, appelée MERISE et que nous utilisons dans la présente étude.

MERISE est un sigle qui signifie : Méthode d'Études et de Réalisations Informatiques par Sous-Ensemble. La méthode MERISE sépare les données et les traitements. Cette méthode est parfaitement adaptée à la modélisation des problèmes abordés d'un point de vue fonctionnel. Les données représentent la statique du système d'information et les traitements sa dynamique. MERISE propose une démarche par niveaux. Ces niveaux de modélisation sont organisés dans une double approche données - traitements.

Niveaux	Analyse des données	Analyse des traitements
Conceptuel	Quelles informations manipule-t-on ?	Que veut-on faire ?
Logique	Comment structurer ces données ?	Qui fait quoi, où, quand ?
Physique	Où les stocker ?	Comment ?

Pour répondre aux questions répertoriées dans le tableau ci-haut, la méthode MERISE produit les modèles suivants :

Niveaux	Analyse des données	Analyse des traitements
Conceptuel	Modèle Conceptuel des Données MCD)	Modèle Conceptuel des Traitements (MCT)
Logique	Modèle Logique des Données (MLD)	Modèle Organisationnel des Traitements (MOT)
Physique	Modèle Physique des Données (MPD)	Modèle Opérationnel des Traitements (MOPT)

0.5.2. Division du travail

Outre l'introduction générale et la conclusion générale, notre travail est organisé en deux parties.

La première partie, subdivisée en deux chapitres, est une étude préalable du projet informatique qui nous préoccupe dans ce travail. Le premier chapitre présente l'existant. Le deuxième chapitre fait une analyse de l'existant. Cette analyse, en même temps qu'elle aide à bien connaître comment fonctionne l'existant, elle aide aussi à découvrir les problèmes liés à ce fonctionnement.

La deuxième partie, pour sa part, tente de concevoir des solutions aux problèmes recensés dans la première partie. Pour ce faire, elle comporte aussi deux chapitres. Le premier chapitre construit le modèle logique des traitements et le modèle logique des données. Le deuxième chapitre propose, au niveau physique, l'implantation de la base de données dans un S.G.B.D. A cet effet, nous utilisons le logiciel Microsoft Access.

Première partie : ETUDE PREALABLE

0. Introduction

0.1. Présentation de la première partie

La première partie de ce travail est une étude préalable du projet. Cette étude, nous la présentons en deux chapitres. Le premier chapitre est une représentation de l'existant et le deuxième chapitre, une analyse de l'existant. Nous définissons d'abord la mission avant de développer les deux chapitres.

0.2. Définition de la mission

0.2.1. Problème de gestion

Pour la gestion de son charroi automobile, Vodacom contrôle régulièrement l'utilisation de carburant, l'évolution du kilométrage et l'entretien des véhicules.

Cependant, quelques problèmes se posent :

· Les données sont conservées dans des archives pas très sécurisées. Il y a risque de perdre des informations importantes.

· L'élaboration des rapports sur Excel n'est pas simple. Elle prend beaucoup de temps. Par exemple, on a besoin de trois jours de travail, ou plus, pour enregistrer les données avant de réfléchir à la manière de les présenter.

· L'interrogation de données en Excel ne produit pas de résultats détaillés. En plus, Excel n'est pas fait pour gérer les bases de données composées de plusieurs tables à moins de passer par des procédures lourdes et complexes.

0.2.2. Améliorations attendues

Grâce à cette étude, nous voulons doter Vodacom d'une base de données pour la gestion de son charroi automobile.

Cet outil informatique permettra :

· La protection de données contre tout incident.

· De passer moins de temps à l'élaboration des rapports.

· L'interrogation, la recherche et la mise en forme de données de manière très détaillée.

0.2.3. Point de départ et point d'arrêt de l'étude

L'étude portera sur l'analyse préalable et la conception détaillée des solutions aux problèmes recensés. A cet effet, une base de données sera créée et implantée à l'aide du logiciel Microsoft Access.

0.2.4. Champs de l'étude

A. Qui ?

L'étude concerne la gestion du charroi automobile de Vodacom Congo au Katanga. Sont impliqués dans ce domaine : le Warehouse Supervisor (Gestionnaire de Stocks), le Finance Manager (Chargé des Finances), le Head of Region (Directeur Provincial).

B. Quoi ? Les fonctions couvertes par cette étude sont essentiellement :

· La gestion de carburant

· La gestion des entretiens.

Chapitre premier : Présentation de l'existant1

I.1. Description de l'organisation

A. Historique

La société VODACOM-CONGO, créée en octobre 2001 sous la forme d'une société à responsabilité limitée, SPRL en sigle, est le fruit d'un accord de partenariat conclu entre Vodacom International Ltd et Congolese Wireless Network (CWN) sprl, oeuvre de monsieur A.B.M. CONTEH, chairman de la société.

L'objectif social de la société VODACOM-CONGO est principalement l'exploitation de la télécommunication cellulaire sur toute l'étendue de la République Démocratique du Congo.

Sans précédent dans l'histoire des télécommunications en République Démocratique du Congo, son réseau cellulaire a démarré le 1er mai 2002 couvrant simultanément les villes de Kinshasa, Lubumbashi et Mbuji Mayi. En janvier 2005, le réseau couvre 115 villes et agglomérations du pays. Aujourd'hui, il a quatre millions d'abonnés.

B. Couverture Nationale

Vodacom est un réseau en perpétuelle expansion. La liste de villes couvertes ci-dessous augmente au fil des jours. Le tableau ci-dessous donne en détail cette expansion.

¹ L'existent dont il est question ici, c'est l'entreprise Vodacom.

REGIONS	VILLES
KINSHASA	Kinshasa, Maluku.
BANDUNDU	Bandundu, Bongo, Bulungu, Chiet, Idiofa, Inongo, Isaka, Isanzondo, Isongo, Kahemba, Kasongo-Lunda, Kenge, Kipuku, Kikwit, Laba, Masimanimba, Mawangu, Mpata Mbalu, Nioki, Nzati Mwandi, Panzi, Tembo.
BAS CONGO	Banana, Boma, Inga, Inkisi, Kamba, Kasi, Kasangulu, Kimpese, Kinzamvuete, Kiobokwimba, Kitona, Kizulu, Kongo dia Kati, Kwilu Ngongo, Loanda, Lukala, Luozi, Luvangasa, Madimba, Matadi, Mbanza Ngungu, Moanda, Mt Muba, Nkandu, Nsansda Kizulu, Nzadi Kongo, Songololo, Tshela, Yema.
EQUATEUR	Basankusu, Boende, Bokungu, Bumba, Gbadolite, Gemena, Lisala, Mbandaka, Yakoma, Zongo.
KASAI OCCIDENTAL	Bakwa Samba, Demba, Diboko, Ilebo, Kamonia, Kananga, Luebo, Mweka, Sumbula, Tshikapa, Zapo Zapo, Mikalayi.
KASAI ORIENTAL	Boya, Djoko-Punda, Kabinda, Kakoma, Kakulu, Kaniki, Lodja, Lubao, Lukalaba, Lusambo, Mbuji Mayi, Miabi, Mwene Ditu, Ngandajika, Senga Senga, Tshala, Tshibombo, Tshumbe, Winkong.
KATANGA	Bukama, Dilolo, Fungurume, Kabalo, Kabumba, Kakanda, Kakontwe, Kalemie, Kambove, Kamina, Kaniama, Kapanga, Kasumbalesa, Katenga, Kipushi, Kolwezi, Kongolo, Likasi, Lubudi, Lubumbashi, Luena, Luisha, Luita, Malemba Nkulu, Manono, Moba, Mokambo, Pumpi, Renatelsat, Sakania, Thumbwe.
MANIEMA	Kalima, Kasongo, Kiliba, Kindu, Punia.
NORD KIVU		Beni, Butembo, Goma, Idjwi, Kanyabayonga, Kasindi, Kyavinyonge, Lubero, Masisi, Minova, Nyamilima, Oicha, Rusthuru, Sake, Vitshumbi, Walikale
PROVINCE ORIENTALE		Ariwara, Aru, Bambu, Basoko, Bogoro, Bondo, Bunia, Buta, Dungu, Durba, Ingbokolo, Isangi, Isiro, Kasenyi, Kilo Mine, Kisangani, Kobu, Kpandruma, Lukutu, Mahagi, Mbidjo, Mungwalu, Pluto, Tchomia, Ubundu, Watsha.
SUD KIVU		Baraka, Bukavu, Fizi, Kalehe, Kamanyola, Kamituga, Katana, Kavimvira, Kavumu, Kibombo, Nyabibwe, Nyabiondo, Shabunda, Uvira, Walungu.

Tableau 1.1.

C. Siège Social

Le siège social de Vodacom - Congo est situé à l'immeuble CORPORATE PARK, au numéro 3157 sur le boulevard du 30 Juin, dans la commune de la GOMBE à Kinshasa.

A Lubumbashi, le bureau de Vodacom est situé sur 1046, Chaussée Laurent-Desire Kabila (Ex Avenue Mobutu).

D. Ligne de conduite de Vodacom (Vodacom way)

Le groupe Vodacom dispose d'une ligne de conduite qu'il appelle « la voie Vodacom » dont les principaux traits sont :

1° Etre une équipe dont la concurrence est le spot, où chacun est empreint de la volonté de gagner et d'une passion dans tout ce qu'il fait d'être meilleur, de ne jamais abandonner, de travailler plus que tous les autres.

2° Avoir comme pierre angulaire de la manière de conduire les affaires l'honnêteté, la confiance, la bonne foi et le professionnalisme. Et, traiter tout le monde d'égal à égal, en toute loyauté. Bref une société respectueuse.

(avec bienveillance) de tout ce qu'on fait à chaque minute de chaque jour et qui vit de cette façon : LA BIENVEILLANCE.

4° Etre une société qui améliore la vie des gens et leur offre des opportunités en rendant possible pour toutes les personnes d'Afrique l'accès aux télécommunications mobiles. Une société qui a la volonté et les moyens de le faire et qui s'efforce de le mettre en pratique de manière judiciaire. Une société qui va « démocratiser » le téléphone, c'est-à-dire accroître la télé densité en couvrant la population vivant dans les zones les plus reculées pour leur permettre de communiquer et de se rapprocher du monde. Le slogan « VODACOM, leader dans le monde cellulaire » ou être numéro 1 des télécommunications en RDC reste l'ambition première de Vodacom : LA CROISSANCE.

5° Demeurer le plus compétent et le plus innovateur, non seulement pour que chaque rêve se réalise, mais aussi pour « réaliser ses rêves » utiliser sa passion et son bon sens pour faire l'impossible.

VODACOM s'attelle tant à des investissements sociaux d'ensemble (Corporate sociale investissement : CSI) parce que :

1° C'est la chose la plus juste à faire, contribuer au développement des populations dont ont tire ses affaires. C'est donc un impératif moral.

2° Il serait inacceptable de jouir des fruits ou du succès sans pour autant investir dans la qualité de vie des populations qui rendent cela possible.

E. Organigramme de Vodacom au Katanga (Figure 1.1., Source : Direction des Ressources Humaines Vodacom Katanga)

Head of Region

Administrative Secretary

Warehouse
Supervisor

Technicians

Installation
Coordinator

Account
Executives

Marketing and Roll
out Supervisor

Public Phone
EVD Specialist

Senior
Accountant
Cashier

Accountant

Super Dealer
Post paid
accountant

Acquisition
Corporate
Manager

Vodashop
Corporate
Manager

Operation
Manager

Finance
Manager

Coordinator
Corporate

Vodashop
Supervisors

Switch
Specialist

Property
Manager

N.T.
Manager

Radio Planning
Specialist

Vodacom
Managers
Pool

Vodashop
Assistants

Technical
Officers

Technical
Officers

Vodacom
Managers

Commercial
Manager

Commercial
Support

Customer
Administrator

F. Organigramme du domaine étudié

Head of Region

Administrative Secretary
H.R. Support

Finance
Manager

Warehouse
Supervisor

Figure 1.2., Source : Direction des Ressources Humaines Vodacom Katanga

G. Tableau des acteurs

Nous procédons au recensement des différents acteurs selon qu'il s'agit de carburant ou d'envoi d'un véhicule en entretien. A cet effet, deux tableaux sont respectivement présentés.

1) Gestion de carburant

N°	Nom		Type		Signification
1.	Drive Dispatch		Externe		Le Drive Dispatch (le Dispatcheur des chauffeurs) prépare le Trip Log Sheet (T.L.S.) qui est un document de bord du véhicule, le transmet au Warehouse Supervisor avec un bon de réquisition (Fuel_requisition) pour la demande de carburant.			2.
Warehouse Supervisor	Interne		Le Warehouse Supervisor (gestionnaire de stocks) contrôle les informations se trouvant dans le T.L.S. pour légitimer le Fuel_requisition avec quelques annotations, avant de l'envoyer au Finance Manager.		3.
Finance Manager	Interne		Le Finance Manager (Chargé des Finances) reçoit le Fuel_requisition, examine
							minutieusement si la dépense à engager est budgétisée avant de marquer son approbation par une signature et transférer le document au Head of Region.
4.		Head of region		Interne			Le Head of Region (Directeur Provincial) valide en dernière instance le Fuel_requisition après avoir vérifié les annotations du Warehouse Supervisor légitimant la demande et celles du Finance Manager soulignant la conformité de la demande aux prévisions budgétaires

Tableau 1.2.

2) Entretien des véhicules

N°	Nom	Type	Signification
1.	Drive Dispatch	Externe	Le Drive Dispatch (Dispatcheur des chauffeurs) prépare le rapport d'inspection journalière du véhicule (R.I.J.V.) qui lui a été transmis en prenant soin de vérifier si les informations qu'il contient sont correctes puis le transmet avec un Bon de Commande pour Entretien (B.C.E.) au Warehouse Supervisor.		2.
Warehouse Supervisor	Interne	Le Warehouse Supervisor (Gestionnaire des stocks) contrôle les informations se trouvant dans le R.I.J.V. pour légitimer le B.C.E qu'il signe avec quelques annotations, avant de l'envoyer au Finance Manager	3.
Finance Manager	Interne	Le Finance Manager (Chargé des Finances) reçoit le B.C.E., examine minutieusement si la dépense à engager est budgétisée avant de marquer son approbation par une signature et transférer le document au Head of Region.	4.
Head of Region	Interne	Le Head of Region (Directeur Provincial) valide en dernière instance le B.C.E. après avoir vérifié les annotations du Warehouse Supervisor légitimant la demande et celles du Finance Manager soulignant la conformité de la dépense aux prévisions budgétaires.

Tableau 1.3.

H. Graphe de flux

Puisque cette étude couvre deux fonctions, nous établissons deux graphes de flux. 1) Gestion de carburant

Figure 1.3.

T.L.S.: Trip Log Sheet

2) Gestion des entretiens

Figure 1.4.

R.I.J.V. : Rapport d'Inspection Journalière du Véhicule B.C.E. : Bon de Commande pour Entretien

I. Matrice des flux

1) Gestion de carburant

		Récepteur
		Drive Dispatch	Warehouse Supervisor	Finance Manager	Head of region
Emetteur	Drive Dispatch		-T.L.S. -Fuel requisition
	Warehouse Supervisor	-T.L.S. rejeté -Fuel requisition rejeté 1	T.L.S. accepté	Fuel requisition accepté 1
	Finance Manager		Fuel requisition rejeté 2		Fuel requisition accepté 2
	Head of Region	Fuel requisition approuvé		Fuel requisition rejeté 3

Tableau 1.4.

T.L.S.: Trip Log Sheet

2) Gestion des entretiens

		Récepteur
		Drive Dispatch	Warehouse Supervisor	Finance Manager	Head of region
Emetteur	Drive Dispatch		- R.I.J .V. - B.C.E.
	Warehouse Supervisor	-R.I.J.V. rejeté -B.C.E. rejeté 1	R.I.J.V. accepté	B.C.E. accepté 1
	Finance Manager		B.C.E. rejeté 2		B.C.E.accepté 2
	Head Of Region	B.C.E. approuvé		B.C.E. rejeté 3

Tableau 1.5.

R.I.J.V. : Rapport d'Inspection Journalière du Véhicule B.C.E. : Bon de Commande pour Entretien

J. Tableau des flux

1) Gestion de carburant

N°	Noms flux	Emetteur	Récepteur	Données	Signification
1.	T.L.S.	Driver Dispatch	Warehouse supervisor	-immatriculation -Fleet Number(FN) -Marque -Destination -Kilométrage -Time out -Time in -Fuel level -Passenger Name -Date -Driver Name	Le Trip Log Sheet (T.L.S.) est un document qui est préparé par le Driver Dispatch qui donne entre autre des informations sur le besoin en carburant d'un véhicule
2.	Fuel requisition	Drive Dispatch	Warehouse supervisor	-Numéro document -Fleet Number(FN) -Date -Driver Name -immatriculation -User Name - Type fuel	Bon émis par le Drive Dispatch pour la demande de carburant après avoir préparé le T.L.S.
3.	T.L.S. rejeté	Warehouse supervisor	Driver Dispatch	-immatriculation -Fleet Number(FN) -Marque -Destination -Kilométrage -Time out -Time in -Fuel level -Passenger Name -Date -Driver Name	T.L.S. rejeté contrôlé et transmis au Drive Dispatch par le Warehouse Supervisor après contrôle.
4.	T.L.S. accepté	Warehouse Supervisor	Warehouse Supervisor	-immatriculation -Fleet Number(FN) -Marque -Destination -Kilométrage -Time out -Time in -Fuel level -Passenger Name -Date -Driver Name	T.L.S. accepté par le Warehouse Supervisor après contrôle				5.
Fuel requisition rejeté 1	Warehouse Supervisor	Drive Dispatch	-Numéro document -Fleet Number(FN) -Date -Driver Name	Fuel requisition rejeté par le Warehouse Supervisor et
				-immatriculation -User Name - Type fuel	remis au Drive Dispatch s'il n'est pas conforme au T.L.S accepté
6.	Fuel requisition accepté 1	Warehouse Supervisor	Finance Manager	-Numéro document -Fllet Number(FN) -Date -Driver Name -immatriculation -User Name - Type fuel	Fuel requisition accepté par le Warehouse Supervisor et transféré au Finance Manager pour examen si conforme au budget					7.
Fuel requisition rejeté 2	Finance Manager	Warehouse Supervisor	Numéro document -Fllet Number(FN) -Date -Driver Name -immatriculation -User Name - Type fuel	Fuel requisition rejeté par le Finance Manager si le budget ne permet pas la dépense	8.
Fuel requisition accepté 2	Finance Manager	Head of region	-Numéro document -Fleet Number(FN) -Date -Driver Name -immatriculation -User Name - Type fuel	Fuel requisition accepté et transféré au Head of Region pour approbation du retrait de carburant
9.	Fuel requisition rejeté 3	Head of Region	Finance Manager	-Numéro document -Fleet Number(FN) -Date -Driver Name -immatriculation -User Name - Type fuel	Fuel requisition rejeté par le Head of Region après l'avoir examiné						10.
Fuel requisition approuvé	Head of Region	Driver Dispatch	-Numéro document -Fleet Number(FN) -Date -Driver Name -immatriculation -User Name - Type fuel	Fuel requisition approuvé par le Head of Region pour le retrait de carburant

Tableau 1.6.

2) Entretien des véhicules

N°	Noms flux	Emetteur	Récepteur	Données	Signification
1.	R.I.J.V.	Drive Dispatch	Warehouse Supervisor	-Numéro rapport -Date -Heure -kilométrage -dégâts matériels -Nom chauffeur -Num_ordre_vehi	Le Rapport d'Inspection Journalière du Véhicule (R.I.J.V.) est préparé par le Driver Dispatch lorsqu'un véhicule nécessite un entretien.			2.
B.C.E.	Drive Dispatch	Warehouse supervisor	-Numéro bon -Nom garage -Marque vehi -immatri -Num_ordre_vehi -Kilométrage -Type entretien -Nom préparateur -Nom vérificateur -Nom approbation	Le Bon de Commande pour Entretien (B.C.E.) est émis par le Drive Dispatch et est transmis au Warehouse Supervisor	3.
R.I.J.V. rejeté	Warehouse Supervisor	Drive Dispatch	-Numéro rapport -Date -Heure -kilométrage -dégâts matériels -Nom chauffeur -Num_ordre_vehi	Rapport d'Inspection Journalière du Véhicule rejeté et transmis au Drive Dispatch par le Warehouse Supervisor après contrôle	4.
R.I.J.V. accepté	Warehouse Supervisor	Warehouse Supervisor	-Numéro rapport -Date -Heure -kilométrage -dégâts matériels -Nom chauffeur -Num_ordre_vehi	R.I.J.V. accepté par le Warehouse Supervisor après contrôle	5.
B.C.E rejeté 1	Warehouse Supervisor	Drive Dsipatch	-Numéro bon -Nom garage -Marque vehi -immatri -Num_ordre_vehi -Kilométrage -Type entretien -Nom préparateur -Nom vérificateur -Nom approbation	B.C.E. rejeté par le Warehouse Supervisor et remis au Drive Dispatch s'il n'est pas conforme au R.I.J.V.
6.	B.C.E. accepté 1	Warehouse Supervisor	Finance Manager	-Numéro bon -Nom garage -Marque vehi -immatri -Num_ordre_vehi -Kilométrage -Type entretien -Nom préparateur -Nom vérificateur -Nom approbation	B.C.E. contrôlé par le Warehouse Supervisor et transféré au Finance Manager
7.	B .C.E. rejeté 2	Finance Manager	Warehouse Supervisor	-Numéro bon -Nom garage -Marque vehi -immatri -Num_ordre_vehi -Kilométrage -Type entretien -Nom préparateur -Nom vérificateur -Nom approbation	B.C.E. rejeté et transmis au Warehouse Supervisor par le Finance Manager après l'avoir examiné				8.
B.C.E. accepté 2	Finance Manager	Head of region	-Numéro bon -Nom garage -Marque vehi -immatri -Num_ordre_vehi -Kilométrage -Type entretien -Nom préparateur -Nom vérificateur -Nom approbation	B.C.E.examiné par le Finance Manager et accepté puis transféré au Head of Region pour approbation	9.
B.C.E. rejeté 3	Head of Region	Finance Manager	-Numéro bon -Nom garage -Marque vehi -immatri -Num_ordre_vehi -Kilométrage -Type entretien -Nom préparateur -Nom vérificateur -Nom approbation	B.C.E. rejeté et transmis au Finance Manager par le Head of Region après l'avoir vérifié
10.	B.C.E. approuvé	Head of Region	Driver Dispatch	-Numéro bon -Nom garage -Marque vehi -immatri -Num_ordre_vehi -Kilométrage -Type entretien -Nom préparateur -Nom vérificateur	B.C.E. approuvé par le Head of Region et remis au Drive Dispatch pour l'envoi du véhicule en entretien

-Nom approbation

Tableau 1.7.

K. Listes des postes de travail

N°	INTITULE	FONCTION
1.	Warehouse Supervisor	Gestionnaire des stocks		2.
Finance Manager	Gestionnaire des finances	3.
Head of Region	Directeur Provincial

Tableau 1.8.

L. Description de chaque poste

FICHE D'ANALYSE DE STATION N°1

IDENTIFICATION Désignation : Warehouse Supervisor Responsable : Mr MUNGULULA Hubert Mission générale : Gestion du charroi automobile Lieu d'implantation : Vodacom

MOYENS UTILISES Matériel : Ordinateur connecté à internet, Scanner, autre matériel de bureau

INFORMATIONS EN ENTREE

N°

Désignation

Support

Fréquence

Poste d'origine

1.

Rapport d'Inspection Journalière du Véhicule(R.I.J.V)

Papier

Variable

Drive Dispatch

2.

Vehicle Trip Log Sheet (T.L.S.)

Papier

30 à 40/ semaine

Drive Dispatch

3.

Bon de commande pour entretien (B.C.E.)

Papier

Variable

Drive Dispatch

4.

Fuel requisition

Papier

30 à 40/ semaine

Drive Dispatch

5.

Fuel requisition rejeté 2

Papier

variable

Finance Manager

6.

T.L.S. accepté

Papier

30 à 40/semaine

Warehouse Supervisor

INFORMATIONS EN SORTIE

N°

Désignation

Support

Fréquence

Poste destination

1.

B.C.E. accepté 1

Papier

Variable

Finance Manager

2.

Fuel requisition accepté 1

Papier

30 à 40/semaine

Finance Manager

3.

R.I.J.V. rejeté

Papier

variable

Drive Dispatch

4.

T.L.S. rejeté

Papier

Variable

Drive Dispatch

5.

Fuel requisition rejeté 1

Papier

Variable

Drive Dispatch

6.

T.L.S. accepté

Papier

30 à 40/semaine

Warehouse Supervisor

TRAITEMENTS EFFECTUES

N°

Description des tâches

Temps unitaire moyen

Fréquence

1.

Contrôler le T.L.S.

1 min.

30 à 40/semaine

2.

Contrôler le R.I.J.V.

1 min.

Variable

3.

Justifier le fuel requisition

1 min.

30 à 40/semaine

4.

Justifier le B.C.E.

1 min.

Variable

Tableau 1.9.

FICHE D'ANALYSE DE STATION N°2
IDENTIFICATION Désignation : Finance Manager Responsable : Mr Liévin Mission générale : Gestion financière et suivi budgétaire Lieu d'implantation : Vodacom
MOYENS UTILISES Matériel : Ordinateur connecté à internet, Scanner, autre matériel de bureau
INFORMATIONS EN ENTREE
N°	Désignation	Support	Fréquence	Poste d'origine
1.	Fuel Requisition accepté 1	Papier	30 à 40/semaine	Warehouse Supervisor
2.	B.C.E accepté 1	Papier	30 à 40/semaine	Warehouse Supervisor
3.	Fuel Requisition rejeté 3	Papier	Variable	Head of Region				4.
B.C.E. rejeté 3	Papier	Variable	Head of Region
INFORMATIONS EN SORTIE
N°	Désignation	Support	Fréquence	Poste destination
1.	Fuel requisition accepté 2	Papier	30 à 40/semaine	Head of region					2.
B.C.E. accepté 2	Papier	30 à 40/semaine	Head of region	3.
Fuel Requisition rejeté 2	Papier	Variable	Warehouse Supervisor
4.	B.C.E. rejeté 2	Papier	Variable	Warehouse Supervisor
TRAITEMENTS EFFECTUES
N°	Description des tâches		Temps unitaire moyen	Fréquence
1.	Examiner le Fuel requisition (*)		1 min.	30 à 40/semaine						2.
Examiner le B.C.E. (**)	1 min.		30 à 40/semaine

Tableau 1.10.

(*) : Examiner en consultant les prévisions budgétaires pour les dépenses en carburant.

(**) : Examiner en consultant les prévisions budgétaires pour les dépenses d'entretien des véhicules.

FICHE D'ANALYSE DE STATION N°3
IDENTIFICATION Désignation : Head of region Responsable : Mr René Mission générale : Autoriser le retrait de carburant et l'envoi des véhicules en entretien Lieu d'implantation : Vodacom
MOYENS UTILISES Matériel : Ordinateur connecté à internet, Scanner, autre matériel de bureau
INFORMATIONS EN ENTREE
N°	Désignation	Support	Fréquence	Poste d'origine
1.	Fuel requisition accepté 2	Papier	30 à 40/semaine	Finance Manager				2.
B.C.E. accepté 2	Papier	30 à 40/semaine	Finance Manager
INFORMATIONS EN SORTIE
N°	Désignation	Support	Fréquence	Poste destination
1.	Fuel requisition approuvé	Papier	30 à 40/semaine	Driver Dispatch					2.
B.C.E. approuvé	Papier	30 à 40/semaine	Driver Dispatch	3.
Fuel requisition rejeté 3	Papier	Variable	Finance Manager	4.
B.C.E. rejeté 3	Papier	Variable	Finance Manager
TRAITEMENTS EFFECTUES
N°	Description des tâches		Temps unitaire moyen	Fréquence
1.	Vérifier le Fuel requisition (*)		2 min.	30 à 40/semaine						2.
Vérifier le B.C.E. (**)	2 min.		30 à 40/semaine

Tableau 1.11.

(*) et (**) : Vérifier s'il y a accord du Warehouse Supervisor et du Finance Manager en considérant les explications données par eux avant d'approuver le Fuel requisition.

· T.L.S. : Trip Log Sheet : Document de bord du Véhicule.

· R.I.J.V : Rapport d'Inspection Journalière du Véhicule.

· B.C.E : Bon de Commande pour Entretien.

I.2. Description des données

I.2.1. Inventaire des lots d'information

Les informations dont nous disposons pour cette étude nous viennent essentiellement de cinq documents que nous présentons dans le tableau suivant :

N°	IDENTIFIANT	DESIGNATION
1.	Fuel Requisition	bon qui autorise l'approvisionnement en carburant		2.
R.I.J.V.	Rapport d'Inspection Journalière du Véhicule	3.
T.L.S.	Trip Log Sheet : document de bord du véhicule	4.
B.C.E.	Bon de Commande pour Entretien du véhicule	5.
Certificat d'assurance	Certificat attestant que le véhicule est assuré	6.
Carte grise	Carte d'identité du véhicule

Tableau 1.12.

I.2.2. Inventaire des rubriques

N°

Nom

Fuel Requisition

R.I.J.V.

T.L.S.

B.C.E.

Certificat assurance

Carte grise

1.

Date_Fuel

*

2.

Qte_Fuel_reçu

*

3.

Num_bon_Fuel

*

4.

Kilometrage

*

*

5.

Date_km

*

6.

Type_Fuel

*

7.

Destination_voy

*

8.

Num_voy

*

9.

Motif_voyage

*

10.

Nom_conducteur

*

*

11.

Num_conducteur

12.

Date_depart

*

13.

Date_retour

*

14.

Num_imma_vehi

*

*

*

*

15.

Num_ordre_vehi

*

*

*

*

16.

Num_chassie

*

17.

Marque

*

*

*

18.

Année_Fabri

*

19.

Nom_Service

*

20.

Num_service

21.

Nom_assureur

*

22.

Date_ass

*

23.

Date_exp_ass

*

24.

Num_ass

*

25.

Date_entr

*

26.

Num_entr

*

27.

Nom_garage

*

28.

Date_inspection

*

29.

Heure_inspection

*

30.

Nom_Inspecteur

*

31.

Km_inspection

*

32.

Prochainkmentr

*

33.

Num_police

*

34.

Nom_verificateur

*

35.

Date_retour_entr

*

36.

Quantite_fuel

*

37.

Nompassager

*

38.

Num_T.L.S.

*

39.

Heure

*

40.

Km_entretien

*

*

41.

Niveau_reservoir

*

*

42.

Degats_materiels

*

43.

Type entretien

*

44.

Puissance fiscal

*

45.

Nom_proprietaire

*

46.

Adresse_propr

*

47.

Date_enregis

*

48.

Usage

*

49.

Num_propri

*

50.

Date_mise_en_cir culation

*

Tableau 1.13.

I.2.3. Dictionnaire des données

Le tableau ci-dessous présente le dictionnaire simplifié de données qui ne contient que les informations strictement nécessaires aux traitements. C'est ainsi que les éléments suivants ont été écartés :

· Les données calculées ou déduites : kilomètre prochain entretien (Km_prochain_entr).

· Les données ayant le même sens (synonymes) : Quantité_fuel, agence assurance, km_inspection, date inspection.

· Des données qui ne sont pas de données de gestion : num_police, nom_vérificateur, date_retour_entr, num_T.L.S., heure_inspection, nom_inspecteur, Niveau_reservoir, Degats_materiels, Type_entretien, Puissance fiscal, Nom_proprietaire, Adresse_propr Date_enregistrement, Usage, Num_proprietaire, Date_mise_en_circulation.

N°	Nom	Type	Domaine	Contrôle	Signification
1.	Date_Fuel	NC	Date, 8	= date du jour	Date à laquelle le carburant a été pris
2.	Qte_Fuel_reçu	NC	Entier court	> 0	Quantité de carburant mis dans le réservoir du véhicule à une certaine date			3.
Num_bon_Fuel	NC	AN, 10	Unique	Numéro du bon de livraison de carburant	4.
Kilometrage	NC	Entier court	Existe	Kilométrage actuel du véhicule tel que lit sur l'odomètre	5.
Date	NC	Date, 8	= date du jour	date à laquelle le kilométrage a été prélevé	6.
Type_Fuel	NC	AN, 10	Existe	Type de carburant utilisé par un véhicule (petrol, diesel, oil...)	7.
Destination_voy	NC	AN, 20	Existe	La destination vers laquelle est allé un véhicule qui voyage en dehors de Lubumbashi
8.	Num_voy	NC	AN, 10	Unique	Numéro du voyage				9.
Motif_voyage	NC	AN, 50	Existe	Le motif du voyage	10.
Nom_conducteur	NC	AN, 30	Existe	Le nom du conducteur	11.
Num_conducteur		AN, 12	Unique	Numéro de permis de conduire du conducteur	12.
Date_depart	NC	Date, 8	= date du jour	La date de départ pour le voyage	13.
Date_retour	NC	Date, 8	= Date départ	La date de retour du voyage	14.
Num_imma_vehi	NC	AN, 8	Unique	Numéro d'immatriculation du véhicule	15.
Num_ordre_vehi	NC	Entier court	Unique	Numéro d'ordre du véhicule chez Vodacom	16.
Num_chassie	NC	AN, 20	Unique	Numéro de chassie du véhicule	17.
Marque	NC	AN, 20	Existe	Marque du véhicule	18.
Annee_Fabri	NC	N, 4	Existe	Année de fabrication du véhicule	19.
Nom_Service	NC	AN, 20	Existe	Nom du service qui utilise le véhicule	20.
Num_service	NC	N, 1	Unique	Numéro du service utilisant le véhicule	21.
Nom_assureur	NC	AN, 20	Existe	Nom de la société d'assurance	22.
Date_ass	NC	Date, 8	= date du jour	Date de payement de l'assurance	23.
Date_exp_ass	NC	Date, 8	< Date_ass	Date d'expiration de l'assurance	24.
Num_ass	NC	AN, 20	Unique	Numéro de l'assurance	25.
Date_entretien	NC	Date, 8	= date du jour	Date de l'entretien du véhicule	26.
Num_entretien	NC	AN, 10	Unique	Numéro de l'entretien du véhicule	27.
Nom_garage	NC	AN, 20	Existe	Nom du garage	28.
Km_entretien	NC	Entier court	>0	Km d'entretien du véhicule	29.
Type_entretien	NC	AN, 100	Existe	Détail sur l'entretien effectué sur le véhicule

Tableau 1.14.

I.3. Description des traitements

Pour chaque véhicule, on désire d'abord connaître :

· Son utilisation de carburant(Fuel) : les différentes dates de retrait de carburant, la consommation de carburant après une période donnée. Chaque fois qu'un véhicule est alimenté en carburant, une date est marquée ainsi que la quantité de carburant prise à cette date.

· La manière dont il est entretenu et à quel rythme. Un entretien est caractérisé par

un numéro du bon d'entretien, le kilométrage à l'entretien et le nom du garage ^oül'entretien a été effectué.

Tels sont les principaux traitements à effectuer. Par ailleurs, on pourrait aussi cherche à connaître, pour chaque véhicule :

· la quantité de carburant(Fuel) consommée en litre après une certaine période (entre deux dates).

Contrainte : la première date introduite doit être inférieure ou égale à la deuxième. Formule : additionner toutes les quantités de carburant prises entre deux dates pour trouver la consommation de cette période.

· les kilomètres parcourus après une certaine période (entre deux dates). Le kilométrage du véhicule est prélevé à une certaine date.

Contrainte : la première date introduite doit être inférieure ou égale à la deuxième. Formule : soustraire le kilométrage prélevé à la première date au kilométrage prélevé à la deuxième date pour obtenir le kilométrage parcouru pendant cette période.

· le kilométrage du prochain entretien.

Contrainte : le kilométrage du prochain entretien doit être inférieur ou égale au kilométrage du prochain entretien.

Formule : ajouter au kilométrage prélevé à l'entretien en cours, le nombre de kilomètre que le véhicule doit parcourir avant le prochain entretien.

· le type de carburant(Fuel) utilisé (Petrol, Diesel, Oil...) ;

· les voyages effectués en dehors de Lubumbashi (s'il y en a). Pour un voyage donné, on connaît : le véhicule concernée, sa destination (lieu), le motif du voyage, le nom du conducteur, la date de départ de Lubumbashi ainsi que la date de retour à Lubumbashi.

I.3.1. Diagramme des procédures

Nous présentons ci-dessous l'organisation tâches-utilisateurs (OTU) : A. Gestion de carburant

Temps	Driver Dispatch	Warehouse Supervisor				Finance Manager				Head of Region	Jour J (souvent vendredi dans la matinée)

10 minutes plus tard

Tableau 1.15.

B. Entretien des véhicules

Temps

Driver Dispatch

Warehouse Supervisor

Finance Manager

Head of Region

Jour J (besoin entretien) 10 mininutes plus tard 1 minute plus tard 10 minutes plus tard

10 minutes plus tard

Tableau 1.16.

I.3.2. Règles de gestion
Chaque véhicule a :

· un numéro d'immatriculation qui est unique ;

· un numéro d'ordre du véhicule qui est unique (Fleet Number : FN) ;

· un numéro de chassie qui est unique ;

· une marque ;

· une année de fabrication ;

· une date d'achat ;

· un coût à l'achat ;

· un service qui l'utilise chez Vodacom (user name) ;

· une assurance payée à la SONAS, allant du 1^er janvier au 31 décembre de chaque année.

Selon qu'il s'agit de gestion de carburant ou de gestion des entretiens, les règles de gestion suivantes sont aussi prises en compte :

A. Gestion de carburant

Une fois par semaine, Vodacom procède à l'approvisionnement de ses véhicules en carburant. C'est un quota hebdomadaire. Cette opération se fait de la manière suivante : Le Drive Dispatch prépare le Trip Log Sheet (T.L.S.) qui est le document de bord du véhicule et, émet un bon de réquisition(fuel requisition) pour demander le carburant au Warehouse Supervisor qui contrôle le T.L.S. avant de justifier le fuel requisition (demande de carburant). Le Fuel requisition est alors envoyé au Finance Manager qui examine si ses prévisions budgétaires autorisent cette dépense de carburant. S'il n'y a aucun inconvénient, il transmet le même document avec son point de vue au Head of Region qui lui, en dernière instance, valide le fuel requisition après avoir vérifié les explications du Warehouse Supervisor et celles du Finance Manager.

B. Entretien des véhicules

Les véhicules sont envoyés au Garage pour entretien lorsque le kilométrage d'entretien est atteint ou lorsque le Driver (conducteur) utilisant le véhicule constate une panne. Lorsque le kilométrage d'entretien est atteint, le Drive Dispatch transmet le Rapport d'Inspection

Journalière du Véhicule (R.I.J.V.) au Warehouse Supervisor en même temps que le Bon de Commande pour Entretien (B.C.E.). Le Warehouse Supervisor contrôle le R.I.J.V. pour justifier le B.C.E. Celui-ci est alors envoyé au Finance Manager qui examine si ses prévisions budgétaires autorisent d'envoyer le véhicule au garage pour entretien. S'il n'y a aucun inconvénient, il transmet le même document avec son point de vue au Head of Region qui lui, en dernière instance, valide le B.C.E. après avoir vérifié les explications du Warehouse Supervisor et celles du Finance Manager.

I.3.3. Tableau des évènements

A. Gestion de carburant

N°

Noms Evènement

Type

Emetteur

Récepteur

Données

Signification

1.

T.L.S.

Externe

Driver Dispatch

Warehouse Supervisor

-immatriculation -Num_ordre_véhi -Marque -Destination -Kilométrage -Time out -Time in -Fuel level -Passenger Name -Date -Driver Name

Pour justifier la demande de carburant, le Drive Dispatch prépare le T.L.S. et le transmet au Warehouse Supervisor qui va le contrôler

2.

Fuel requisition

Externe

Drive Dispatch

Warehouse supervisor

-Numéro document -Num_ordre_vehi -Date -Driver Name -immatriculation -User Name -Type fuel

Le Drive Dispatch émet le fuel requisition qu'il transmet au Warehouse Supervisor qui le contrôle en même temps que le T.L.S. pour légitimer la demande de carburant

3.

T.L.S. accepté

Interne

Warehous e Supervisor

Warehouse Supervisor

-immatriculation -Num_ordre_véhi -Marque -Destination -Kilométrage -Time out -Time in

T.L.S. accepté par le Warehouse Supervisor et utilisé par lui- même pour justifier le fuel

-Fuel level -Passenger Name -Date -Driver Name

requisition

4.

Fuel requisition accepté 1

Interne

Warehous e Supervisor

Finance Manager

-Numéro document -Num_ordre_vehi -Date -Driver Name -immatriculation -User Name -Type fuel

Le Warehouse Supervisor transmet le fuel requisition contrôlé au Finance Manager qui l'examine pour voir si la demande est conforme au budget

5.

Fuel requisition accepté 2

Interne

Finance Manager

Head of region

-Numéro document -Num_ordre_vehi -Date -Driver Name -immatriculation -User Name -Type fuel

Le Finance Manager transmet le fuel requisition examiné et annoté au Head of region qui vérifie les justifications du warehouse Supervisor et celles du Finance Manager avant d'approuver la demande de carburant

Tableau 1.17.

B. Entretien des véhicules

N°	Noms Evènement	Type	Emetteur	Récepteur	Données	Signification
1.	R.I.J .V.	Externe	Drive Dispatch	Warehouse supervisor	-Numéro rapport -Date -Heure -kilométrage -dégâts matériels -Nom chauffeur -Num_ordre_vehi	Pour justifier la demande d'entretien, le Drive Dispatch prépare le R.I.J.V. et le transmet au
						Warehouse Supervisor qui va le contrôler
2.	B.C.E.	Externe	Drive Dispatch	Warehouse supervisor	-Numéro bon -Nom garage -Marque_vehi -immatri -Num_ordre_vehi -Kilométrage -Type entretien -Nom préparateur -Nom vérificateur -Nom approbation	Le Driver Dispatch Le Drive Dispatch émet le B.C.E. qu'il transmet au Warehouse Supervisor qui le contrôle en même temps que le R.I.J.V. pour légitimer la demande d'entretien		3.
R.I.J.V. accepté	Interne	Warehouse supervisor	Warehouse supervisor	-Numéro rapport -Date -Heure -kilométrage -dégâts matériels -Nom chauffeur -Num_ordre_vehi	Après avoir accepté le R.I.J.V., le Warehouse Supervisor l'utilise pour justifier le B.C.E.	4.
B.C.E. accepté 1	Interne	Warehouse Supervisor	Finance Manager	-Numéro bon -Nom garage -Marque_vehi -immatri -Num_ordre_vehi -Kilométrage -Type entretien -Nom préparateur -Nom vérificateur -Nom approbation	Le Warehouse Supervisor transmet B.C.E. contrôlé au Finance Manager qui l'examine pour voir si la demande est nécessaire et conforme au budget	5.
B.C.E. accepté 2	Interne	Finance Manager	Head of region	-Numéro bon -Nom garage -Marque_vehi -immatri -Num_ordre_vehi -Kilométrage -Type entretien -Nom préparateur -Nom vérificateur -Nom approbation	Le Finance Manager transmet le B.C.E. examiné et annoté au Head of region qui vérifie les justifications du Warehouse Supervisor et celles du
						Finance
						Manager avant d'approuver la demande d'entretien

Tableau 1.18.

I.3.4. Tableau des actions induites

A. Gestion de carburant

N°	Noms Evènement	Récepteur	Action	Résultat	Signification
1.	T.L.S.	Warehouse Supervisor	Contrôler T.L.S. avec Fuel requisition	-T.L.S. accepté -T.L.S. rejeté	Le Warehouse Supervisor contrôle les informations du T.LS.
2.	Fuel requisition	Warehouse supervisor	Justifier Fuel requisition	-Fuel requisition accepté 1 -Fuel requisition rejeté 1	Le Warehouse Supervisor justifie le Fuel le requisition à partir du T.L.S. accepté			3.
T.L.S. accepté	Warehouse Supervisor	Justifier fuel requisition	-Fuel requisition accepté 1 -Fuel requisition rejeté 1	Le Warehouse Supervisor justifie le Fuel requisition à partir du T.L.S. accepté
4.	Fuel requisition accepté 1	Finance Manager	Examiner Fuel requisition accepté 1	-Fuel requisition accepté 2 -Fuel requisition rejeté 2	Le Finance Manager examine le fuel requisition conformément au budget				5.
Fuel requisition accepté 2	Head of region	Vérifier Fuel requisition accepté 2	-Fuel requisition approuvé -Fuel requisition rejeté 3	Le Head of Region vérifie le Fuel requisition sur base des explications fournies par le Warehouse Supervisor et le Finance Manager

Tableau 1.19.

B. Entretien des véhicules

N°	Noms Evènement	Récepteur	Action	Résultat	Signification
1.	R.I.J .V.	Warehouse supervisor	Contrôler R.I.J .V.	-R.I.J.V. accepté -R.I.J.V. rejeté	Le Warehouse Supervisor contrôle les informations du R.I.J.V.
2.	B.C.E.	Warehouse supervisor	Justifier B.C.E.	-B.C.E. accepté 1 -B.C.E. rejeté	Le Warehouse supervisor contrôle les informations du B.C.E. à partir du R.I.J.V. accepté
3.	R.I.J.V. accepté	Warehouse Supervisor	Justifier B.C.E.	-B.C.E. accepté 1 -B.C.E. rejeté 1	Le Warehouse Supervisor utilise le R.I.J.V. accepté pour justifier le B.C.E.
4.	B.C.E. accepté 1	Finance Manager	Examiner B.C.E. accepté 1	-B.C.E. accepté 2 -B.C.E. rejeté 2	Le Finance Manager examine le B.C.E. conformément au budget
5.	B.C.E. accepté 2	Head of region	Vérifier B.C.E. accepté 2	-B.C.E. approuvé -B.C.E. rejeté 3	Le Head of Region vérifie le B.C.E. sur base des explications fournies par le Warehouse Supervisor et le Finance Manager

Tableau 1.20.

I.3.5. Tableau des opérations

A. Gestion de carburant

N°

Nom Opération

Evènement(s) déclencheur(s)

Actions

Résultat

Signification

1.

Contrôle T.LS.

T.L.S.

Contrôler T.L.S.

-T.L.S. accepté -T.L.S. rejeté

Le Warehouse Supervisor contrôle le T.L.S. qui lui est transmis pour la

demande de carburant

2.

Justification Fuel requisition

-T.L.S. accepté - -Fuel requisition

Justifier fuel requisition

-Fuel requisition accepté 1 -Fuel requisition rejeté 1

Le Warehouse Supervisor justifie le fuel requisition en le confrontant au T.LS. accepté

3.

Examen Fuel requisition

Fuel requisition accepté 1

Examiner fuel requistion

-Fuel requisition accepté 2 -Fuel requisition rejeté 2

Le Finance Manager examine le Fuel requisition en rapport avec le budget

4.

Vérification Fuel requisition

Fuel requisition accepté 2

Vérifier Fuel requisition

-Fuel requisition approuvé -Fuel requisition rejeté 3

Le Head of Region vérifie le Fuel requisition avant de l'approuver

Tableau 1.21.

B. Entretien des véhicules

N°	Nom Opération	Evènement(s) déclencheur(s)	Actions	Résultat	Signification
1.	Contrôle R.IJ.V.	R.I.J.V	Contrôler R.I.J.V	- R.I.J.V accepté - R.I.J.V rejeté	Le Warehouse Supervisor contrôle le R.I.J.V qui lui est transmis pour la demande d'entretien		2.
Justification B.C.E.	-R.I.J.V. accepté -B.C.E.	Justifier B.C.E.	-B.C.E.accepté 1 -B.C.E. rejeté 1	Le Warehouse Supervisor justifie le B.C.E. en le confrontant au R.I.J.V accepté	3.
Examen B.C.E.	B.C.E.accepté 1	Examiner B.C.E.	-B.C.E.accepté 2 -B.C.E.rejeté 2	Le Finance Manager examine le B.C.E. en rapport avec le budget	4.
Vérification B.C.E.	B.C.E. accepté 2	Vérifier B.C.E.	-Fuel B.C.E. approuvé - B.C.E. rejeté 3	Le Head of Region vérifie le B.C.E. avant de l'approuver

I.3.6. Tableau des synchronisations

A. Gestion de carburant

N°	Nom- Synchronisation	Opération	Synchronisation	Evènement	Signification
1	S1	Justification Fuel requisition	A et B	A : T.L.S. accepté B : Fuel requisition	L'opération justification fuel requisition est déclenchée si les évènements T.L.S. accepté et Fuel requisition se produisent simultanément

Tableau 1.23.

B. Entretien des véhicules

N°	Nom- Synchronisation	Opération	Synchronisation	Evènement	Signification
1	S1	Justification B.C.E.	A et B	A : R.I.J.V. accepté B : B.C.E.	L'opération justification B.C.E. est déclenchée si les évènements R.I.J.V. accepté et B.C.E. se produisent simultanément

Tableau 1.24. I.3.7. Les règles d'Emission des résultats

A. Gestion de carburant

N°	Nom-RER	RER	Résultats	Signification
RER1	Contrôle T.L.S.	T.L.S. normal	Vrai : T.L.S. accepté Faux : T.L.S. rejeté	L'opération contrôle T.L.S. produit T.L.S. accepté lorsque le T.L.S. est sans irrégularités et T.L.S. rejeté dans le cas contraire
RER2	Justification	Fuel requisition	Vrai : Fuel	L'opération justification
	fuel requisition	conforme au T.L.S.	requisition accepté 1 Faux : Fuel requisition rejeté 1	fuel requisition produit fuel requisition accepté 1 si le fuel requisition est conforme au T.L.S accepté, sinon elle produit fuel requisition rejeté 1
RER3	Examen Fuel	Dépense	Vrai : Fuel	L'opération examen Fuel
	requisition	budgétisée	requisition accepté 2 Faux : Fuel requisition rejeté 2	requisition produit Fuel requisition accepté 2 si le budget permet la dépense et Fuel requisition rejeté 2 dans le cas contraire.
RER4	Vérification	Toutes les	Vrai : Fuel	L'opération vérification fuel
	Fuel requisition	justifications	requisition	requisition produit Fuel
		valables	approuvé Faux : Fuel requisition rejeté	requisition approuvé si les justifications du Warehouse Supervisor et celles du
			3	Fiance Manager sont valables au cas contraire on a Fuel requisition rejeté 3

Tableau 1.25.

B. Entretien des véhicules

N°	Nom-RER	RER	Résultats	Signification
RER1	Contrôle R.I.J.V.	R.I.J.V. normal	Vrai : R.I.J.V. accepté Faux : R.I.J.V. rejeté	L'opération contrôle R.I.J.V. produit R.I.J.V. accepté lorsque le R.I.J.V. est sans irrégularités et R.I.J.V. rejeté dans le cas contraire
RER2	Justification B.C.E.	Fuel requisition conforme au R.I.J.V.	Vrai : B.C.E. accepté 1 Faux : B.C.E. rejeté 1	L'opération justification B.C.E. produit B.C.E. accepté 1 si le B.C.E. est conforme au R.I.J.V. accepté, sinon elle produit fuel requisition rejeté 1
RER3	Examen B.C.E.	Dépense budgétisée	Vrai : B.C.E. accepté 2 Faux : B.C.E. rejeté 2	L'opération examen B.C.E. produit B.C.E. accepté 2 si le budget permet la dépense et B.C.E. rejeté 2 dans le cas contraire.
RER4	Vérification B.C.E.	Toutes les justifications valables	Vrai : B.C.E. approuvé Faux : B.C.E. rejeté 3	L'opération vérification B.C.E. produit B.C.E. approuvé si les justifications du Warehouse Supervisor et celles du Fiance Manager sont valables au cas contraire on a B.C.E. rejeté

3

Tableau 1.26.

Chapitre deuxième : Analyse de l'existant

II.1. Construction du modèle conceptuel des traitements (MCT)

Le modèle conceptuel des traitements (MCT) décrit ce qui doit être fait (QUOI) sans considérer l'organisation de l'entreprise. Ici, seuls les événements indépendants de l'organisation sont pris en compte.

Les traitements qui figurent dans le MCT sont appelés « opérations conceptuelles » (ce sont des opérations qui résultent de la décomposition ultime des activités) [SORN03, 98].

Nous présentons ici deux schémas conceptuels de traitements : l'un pour la gestion de carburant et l'autre pour la gestion des entretiens des véhicules.

A. Gestion de carburant

1) Le graphe d'ordonnancement des évènements

2) Le modèle conceptuel de traitement

T.L.S.

Contrôle T.L.S.
RER 1	RER 1

Fuel requisition

T.L.S. rejeté

T.L.S. accepté

A et B

Justification Fuel
requisition

RER 2

RER 2

Fuel requisition.
accepté 1

Fuel requisition
rejeté 1

Examen Fuel requisition

RER 3

RER 3

Fuel requistion accepté 2

Fuel requisition
rejeté 2

Vérification Fuel
requisition

RER 4

RER 4

Fuel requisition
approuvé

Fuel requisition
rejeté 3

B. Entretien des véhicules

1) Graphe d'Ordonnancements des évènements

Figure 1.7.

2) Modèle Conceptuel des Traitements (MCT)

B.C.E.

A et B

R.I.J.V. rejeté

R.I.J.V. accepté

Contrôle R.I.J.V.
RER 1	RER 1

R.I.J.V.

Justification B.C.E.

RER 2
			RER 2

B.C.E. accepté 1

B.C.E. rejeté 1

Examen B.C.E.

RER 3

RER 3

B.C.E. accepté 2

B.C.E. rejeté 2

Vérification B.C.E.

B.C.E. approuvé

B.C.E. rejeté 3

RER 4

		RER 4

II.2. Construction du Modèle conceptuel de données (MCD)

II.2.1. Tableau de dépendance fonctionnelle à source simple

SOURCES BUTS		1	2	3	4	5	6	7	8	9	10	11	12	13	14
1.	Date_Fuel			1													2.
Qte_Fuel_reçu			1												3.
Num_bon_Fuel			*												4.
Kilometrage															5.
Date															6.
Type_Fuel			1												7.
Destination_voy								1							8.
Num_voy								*							9.
Motif_voyage								1							10.
Nom_conducteur											1				11.
Num_conducteur								1			*				12.
Date_depart								1							13.
Date_retour								1							14.
Num_imma_vehi			1					1						*	15.
Num_ordre_vehi														1	16.
Num_chassie														1	17.
Marque														1	18.
Annee_Fabri														1	19.
Nom_Service															20.
Num_service														1	21.
Nom_assureur															22.
Date_ass															23.
Date_exp_ass															24.
Num_ass															25.
Date_entretien															26.
Num_entretien															27.
Nom_garage															28.
Km_entretien															29.
Type_entretien

Tableau 1.27.

Le tableau des dépendances fonctionnelles à source composée donné ci-dessous est composé des sources des dépendances fonctionnelles simples et des propriétés non utilisées dans la matrice de dépendance fonctionnelle à source simple.

Les sources des dépendances fonctionnelles simples sont : Num_bon_Fuel, Date, Num_voy, Num_conducteur, Num_imma_vehi, Num_service, Num_ass, Num_entretien.

La seule propriété non utilisée est : Kilométrage.

II.2.2. Tableau de dépendance fonctionnelle à source composée

N°	Propriétés	Df1
1.	Num_bon_Fuel			2.
Date	G	3.
Num_voy		4.
Num_conducteur		5.
Num_imma_vehi	G	6.
Num_service		7.
Num_ass		8.
Num_entretien		9.
Kilometrage	D

Tableau 1.28.

Nous analysons les dépendances fonctionnelles entre identifiants dans la matrice des clés puis dans le graphe des clés que nous reprenons ci-dessous :

II.2.3. Matrice des clés

SOURCES BUTS		1	2	3	4	5	6	7	8
1.	Num_bon_Fuel	*										2.
Date									3.
Num_voy			*						4.
Num_conducteur			1						5.
Num_imma_vehi	1		1		*		1	1
6.	Num_service					1							7.
Num_ass							*		8.
Num_entretien								*

Tableau 1.29.

II.2.4. Graphe des clés

Figure 1.9.

La structure de données (Structure d'Accès Théorique : SAT) est établie en ajoutant au graphe des clés les différentes propriétés en dépendance fonctionnelle avec les identifiants. On construit donc le graphe des dépendances fonctionnelles que nous reprenons ci-dessous :

52 II.2.5. Structure d'Accès Théorique (SAT)

Figure 1.10.

II.2.6. Modèle Conceptuel des données

Figure 1.11.

II.2.7. Tableau des cardinalités

N°	ASSOCIATION	ENTITE	CARDINALITE	EXPLICATION
1.	AVOIR	VEHICULE	(1, 1)	Un véhicule a une et une seule assurance		2.
AVOIR	ASSURANCE	(1, 1)	Une assurance appartient à un et un seul véhicule	3.
ETRE AFFECTE	VEHICULE	(1, 1)	Un véhicule est affecté à un et un seul service	4.
ETRE AFFECTE	SERVICE	(1, n)	Un service peut avoir un ou plusieurs véhicules qui lui sont affectés	5.
PRELEVER	VEHICULE	(1, 1)	Le kilométrage d'un véhicule est prélevé une fois à une date (à la fin de la journée) sur l'odomètre.	6.
PRELEVER	DATE_KM	(1, n)	A une date, on prélève le kilométrage d'un ou de plusieurs véhicules	7.
ETRE EFFECTUE	ENTRETIEN	(1, 1)	Un entretien est effectué sur un et un seul véhicule	8.
ETRE EFFECTUE	VEHICULE	(1, n)	On peut entretenir un véhicule une ou plusieurs fois	9.
DISPOSER	BON_FUEL	(1, 1)	Le Bon_Fuel est mis à la disposition d'un et d'un seul véhicule	10.
DISPOSER	VEHICULE	(1, n)	Un véhicule peut disposer d'un ou plusieurs bon_fuel	11.
ACCOMPLIR	VOYAGE	(1, 1)	Un voyage est effectué par un et un seul véhicule	12.
ACCOMPLIR	VEHICULE	(1, n)	Un véhicule effectue un ou plusieurs voyages	13.
REALISER	CONDUCTEUR	(1, n)	Un conducteur réalise un ou plusieurs voyages
14.	REALISER	VOYAGE	(1, 1)	Un voyage est réalisé par un et un seul conducteur

Tableau 1.30.

II.3. Evaluation de l'intérêt du changement

II.3.1. Diagnostic

L'analyse de l'existant ainsi faite nous permet de passer au diagnostic. Celui-ci se fait en trois points. D'abord, nous recensons les différents problèmes et dysfonctionnements. Ensuite, les problèmes sont hiérarchisés afin d'aider à la conception de la solution axée autour de la résolution de ces dysfonctionnements. Ce diagnostic se termine par l'identification des points forts de la situation actuelle afin de se baser sur une situation cohérente pour la conception de la solution proposée.

A. Inventaire des problèmes

Les problèmes majeurs auxquels la gestion du charroi automobile de Vodacom fait face sont essentiellement :

· des problèmes liés à la sécurité :

- mauvais archivage avec risque de détérioration des documents - informations non facilement accessibles

- perte de certaines fiches importantes

· des problèmes liés à l'élaboration des rapports :

- perte de temps pour la saisie et la présentation de données

- difficulté d'avoir des résultats détaillés en interrogeant les données

B. Hiérarchie des problèmes

Les problèmes majeurs étant la faible sécurité de données et la difficulté d'élaborer des rapports, on peut tirer le réseau-conséquence suivant :

Figure 2.1.

C. Les points forts de la situation actuelle

· L'existence et la tenue des documents pour la gestion.

· Une bonne organisation.

· Une bonne répartition des tâches.

· Existence des ordinateurs à tous les postes.

· Connexion internet assurée.

II.3.2. Orientation de la solution

Le diagnostic de la situation actuelle permet d'avoir une vision à la fois globale et détaillée des dysfonctionnements actuels causant les problèmes majeurs cités de la gestion du charroi automobile de Vodacom. C'est dans le but de pallier à ces problèmes qu'une solution ont été pensée. Cette solution consiste essentiellement à l'introduction de l'outil informatique.

· Présentation :

Cette solution informatise la gestion de carburant et la gestion des entretiens des véhicules.

· Principe de la solution : Cette solution repose principalement sur :

- Une base de données pour la gestion de carburant et des entretiens. Dans cette base de données, on a accès en temps réel aux informations sur la consommation de carburant et l'entretien de chaque véhicule. Ces informations saisies sont automatiquement consultable au niveau de tous les services du domaine.

- La suppression de tous les documents papier internes à l'entreprise. Les règles de gestion et de contrôles peuvent être visualisées à partir de l'ordinateur, à chaque poste de travail. Le Warehouse Supervisor pourrait faire saisir tout ce qui concerne les règles de gestion et autres contrôles, après acceptation de la règle par le Head of Region, bien entendu. La saisie de données dans la base de données peut se faire au niveau du Warehouse Supervisor. A cet effet, il a besoin d'une main d'oeuvre supplémentaire pour ce travail (un secrétaire ou un stagiaire).

- Le transfert des documents par le réseau : à partir du Warehouse Supervisor les Fuel requisition et les Bons de Commande pour Entretien (B.C.E) sont transférés par le réseau. Puisque le réseau existe déjà, cela ne posera aucun problème en termes d'investissement.

- La conservation des Fuel requisition approuvés et des B.C.E. approuvés à l'état papier (on les imprime donc) pour le retrait de carburant et pour l'envoi en entretien des véhicules. La secrétaire du Head of Region se chargera des impressions.

· Evolution par rapport à la situation actuelle :

Plus personne ne doit se déplacer pour les informations qu'il désire. La direction a un accès immédiat à toutes les informations concernant la gestion du charroi automobile. Les rapports sont alors élaborés plus facilement par le Warehouse Supervisor pour la hiérarchie.

· Evaluation :

- Problèmes résolus :

9 Ce système répond aux attentes des utilisateurs. L'introduction de

l'informatique pour automatiser une partie du travail facilite le travail de

chaque acteur du domaine. On se concentre sur des problèmes de fond.

9 Le système, par le fait de gérer toutes les étapes en temps réel, permet de

réduire les délais avant qu'une demande n'obtienne de réponse. 9 La rétention ou la perte d'information est quasiment impossible. 9 Le système permet à tous les postes d'accéder à toutes les informations

dont ils ont besoin ; ces informations étant mises à jour en temps réel.

9 Puisqu'il n'y a presque plus de documents internes, il n'y a quasiment plus

de perte de documents.

9 On a éliminé la redondance des informations et les erreurs de saisie, dues aux nombreuses cases à remplir des documents.

9 Le système autorise et facilite la consultation des archives.

- Investissements :

9 Un secrétaire ou un stagiaire au Warehouse Supervisor 9 Logiciels

v' Implantation de la base de données

v' Formation du personnel (1/2 journée par service)

Note :

Ces données auraient pu être chiffrées pour évaluer le coût total de l'investissement. Nous ne le faisons pas ici par manque de précisions sur prix. L'entreprise pourra toujours soumettre ces données à une évaluation chiffrée avant la réalisation du projet.

· Rapport d'étude préalable

Voici, repris dans le tableau ci-dessous, le résumé de la solution proposée :

Critères		Solution	Principe
Informatisation de la gestion du charroi automobile par une base de données		Problèmes résolus
Amélioration des délais, réduction de la paperasserie, travail facilité		Investissement
Coût à préciser plus tard		Praticabilité organisationnel
Moyen		Sécurité
Très bon		Mise en place
Court terme

Tableau 2.1.

III. Conclusion partielle

L'étude préalable faite dans cette première partie nous a aidé à en savoir plus sur l'existant. Après l'avoir présenté, nous l'avons analysé. Cette analyse nous a permis de diagnostiquer quelques problèmes auxquels nous avons proposé une solution. La conception détaillée de cette solution se fait dans le chapitre suivant.

Deuxième partie : CONCEPTION DETAILLEE DE LA SOLUTION

0. Introduction

Avec cette deuxième partie, nous entrons dans la phase de conception de la solution aux problèmes recensés dans la première partie. Cette conception de solution nous la rendons effective en présentant le modèle organisationnel des traitements et le modèle logique des données de la solution puis, nous implantons les données dans un modèle physique de données.

Chapitre premier : Niveau logique des traitements et des données

I.1. Modèle organisationnel de traitements (MOT)

I.1.1. Ancien Modèle Conceptuel de Traitement et les nouvelles activités

Voici le MCT de la solution proposée :

A. Gestion de carburant

B. Entretien des véhicules

C. Elaboration des rapports

Figure 2.4.

I.1.2. Niveau d'automatisation

Les tableaux ci-dessous donnent les différents niveaux d'automatisation des opérations pour la gestion de carburant, pour la gestion des entretiens et pour l'élaboration des rapports.

A. Gestion de carburant

Opérations	Signification	Caractéristiques		Choix proposé	Contrôle T.L.S.
Le Warehouse Supervisor contrôle contrôle le T.L.S. qui lui est transmis pour la demande carburant.	Peu formalisable, degré d'urgence variable	Traitement Manuel		Justification Fuel requisition
Le Warehouse Supervisor justifie le Fuel requisition en le confrontant au T.L.S. accepté.	Peu formalisable, degré d'urgence variable	Traitement Manuel		Saisie Fuel requisition
Le Warehouse Supervisor saisi le fuel requisition. La Secrétaire met à jour la base de données.	Formalisable, degré d'urgence élevé	Traitement automatisé en mode conversationnel		Envoi Fuel requisition
Le Warehouse Supervisor envoie par mail le Fuel requistion saisi au Finance Manager	Formalisable, degré d'urgence élevé	Traitement automatisé en mode conversationnel		Consultation budget
En recevant le Fuel requisition, le Finance Manager la situation	Formalisable, degré d'urgence	Traitement automatisé en

	budgétaire de l'approvisionnement en carburant	élevé		mode conversationnel	Validation fuel requisition
Le Finance Manager valide le fuel requisition	Formalisable, degré d'urgence élevé	Traitement automatisé en mode conversationnel		Envoi fuel requisition validé
Le Finance Manager envoie par mail le Fuel requisition au Head of Region après l'avoir validé	Formalisable, degré d'urgence élevé	Traitement automatisé en mode conversationnel		Vérification fuel requisition
Le Finance Manager vérifie le fuel requisition	Formalisable, degré d'urgence élevé	Traitement automatisé en mode conversationnel		Approbation fuel requisition
Le Finance Manager approuve le Fuel requisition	Formalisable, degré d'urgence élevé	Traitement automatisé en mode conversationnel		Edition fuel requisition
La secrétaire du Head of Region imprime le lot des Fuel requisition approuvés	Formalisable, degré d'urgence faible	Traitement automatisé en mode différé

Tableau 2.2.

B. Gestion des entretiens

Opérations	Signification	Caractéristiques		Choix proposé	Contrôle R.I.J.V.
Le Warehouse Supervisor contrôle contrôle le R.I.J.V. qui lui est transmis pour la demande d'entretien	Peu formalisable, degré d'urgence variable	Traitement Manuel		Justification B.C.E.
Le Warehouse Supervisor justifie le B.C.E. en le confrontant au R.I.J.V. accepté.	Peu formalisable, degré d'urgence variable	Traitement Manuel		Saisie B.C.E.
Le Warehouse Supervisor saisi le B.C.E. La Secrétaire met à jour la base de données.	Formalisable, degré d'urgence élevé	Traitement automatisé en mode conversationnel		Envoi B.C.E.
Le Warehouse Supervisor envoie par mail B.C.E. saisi au Finance Manager	Formalisable, degré d'urgence élevé	Traitement automatisé en mode conversationnel		Consultation budget
En recevant le B.C.E., le Finance Manager la situation budgétaire des entretiens	Formalisable, degré d'urgence élevé	Traitement automatisé en mode conversationnel		Validation B.C.E.
Le Finance Manager valide le B.C.E.	Formalisable, degré d'urgence	Traitement automatisé en

		élevé		mode conversationnel	Envoi B.C.E. validé
Le Finance Manager envoie par mail le B.C.E. au Head of Region après l'avoir validé	Formalisable, degré d'urgence élevé	Traitement automatisé en mode conversationnel		Vérification B.C.E.
Le Finance Manager vérifie le B.C.E.	Formalisable, degré d'urgence élevé	Traitement automatisé en mode conversationnel		Approbation B.C.E.
Le Finance Manager approuve le B.C.E.	Formalisable, degré d'urgence élevé	Traitement automatisé en mode conversationnel		Edition B.C.E.
La secrétaire du Head of Region imprime le lot des B.C.E. approuvés	Formalisable, degré d'urgence faible	Traitement automatisé en mode différé

Tableau 2.3.

C. Elaboration des rapports

Opérations	Signification	Caractéristiques		Choix proposé	Edition requête entretien
La Secrétaire du Warehouse Supervisor fait une requête sur les entretiens dans la base de données pour élaborer le rapport des entretiens	Formalisable, degré d'urgence élevé	Traitement automatisé en mode conversationnel		Edition requête carburant
La Secrétaire du Warehouse Supervisor fait une requête sur le carburant dans la base de données pour élaborer le rapport des entretiens	Formalisable, degré d'urgence élevé	Traitement automatisé en mode conversationnel

Tableau 2.4.

I.1.3. Diagramme d'enchainement des procédures

Nous présentons le diagramme d'enchainement des procédures qui traduit directement au niveau organisationnel le nouveau modèle conceptuel de traitements présenté plus haut. Ce diagramme indique de manière explicite :

· La chronologie des traitements (date début et durée d'une opération)

· Les postes de travail concernés

· Le type de traitement (manuel, automatisé de type interactif, automatisé différé)

A. Gestion de carburant

Temps

Phases

Type traitement

Postes de travail

Date début : jour j pour demande de carburant (vendredi dans la matinée) Durée : 1 minute

Traitement manuel

Warehouse Supervisor Lieu : Bureau Warehouse Supervisor Ressources : Le Warehouse Supervisor,

1 minute plus tard Durée : 1 minute

Traitement manuel

Warehouse Supervisor Lieu : Bureau Warehouse Supervisor Ressources : Le Warehouse Supervisor,

10 secondes plus tard Durée : 2 minutes

Traitement automatisé en mode conversationnel

Warehouse Supervisor Lieu : Bureau Warehouse Supervisor Ressources : Le Warehouse Supervisor, 1 secretaire, 1 PC

30 secondes plus tard Durée variable (entre quelques secondes et quelques minutes)

Traitement automatisé en mode conversationnel

Warehouse Supervisor Lieu : Bureau Warehouse Supervisor Ressources : Le Warehouse Supervisor, 1 PC, Internet

30 secondes plus tard Durée : 1 minute

Traitement automatisé en mode conversationnel

Finance Manager Lieu : Bureau Finance Manager Ressources : Le Finance Manager, 1 PC

1 minute plus tard Durée : 1 minute

Traitement automatisé en mode conversationnel

Finance Manager Lieu : Bureau Finance Manager Ressources : Le Finance Manager, 1 PC

30 secondes plus tard Durée variable (entre quelques secondes et quelques minutes)

Traitement automatisé en mode conversationnel

Finance Manager Lieu : Bureau Finance Manager Ressources : Le Finance Manager, 1 PC, Internet

30 minutes plus tard Durée : 1 minute

Traitement automatisé en mode conversationnel

Head of Region Lieu : Bureau Head of Region Ressources : Le Head of Region, 1 PC

30 secondes plus tard Durée : 1 minute

Traitement automatisé en mode conversationnel

Head of Region Lieu : Bureau Head of Region Ressources : Le Head of Region, 1 PC

30 secondes plus tard Durée : 2 minutes

Traitement automatisé en mode différé

Head of Region Lieu : Bureau Head of Region Ressources : 1 secrétaire, 1 PC, 1 imprimante

Moment d'élaborer le rapport Durée : quelques secondes

Traitement automatisé en mode conversationnel

Warehouse supervisor Lieu : Bureau Warehouse Supervisor Ressources : 1 secrétaire, 1 PC

Tableau 2.5.

B. Entretien des véhicules

Temps	Phases								Type traitement	Postes de travail
Date début : variable : jour j pour demande d'entretien Durée : 1 minute									Traitement manuel	Warehouse Supervisor Lieu : Bureau Warehouse Supervisor Ressources : Le Warehouse Supervisor,
1 minute plus tard Durée : 1 minute									Traitement automatisé en mode conversationnel	Warehouse Supervisor Lieu : Bureau Warehouse Supervisor Ressources : Le Warehouse Supervisor,
10 secondes plus tard Durée : 2 minutes									Traitement automatisé en mode conversationnel	Warehouse Supervisor Lieu : Bureau Warehouse Supervisor Ressources : Le Warehouse Supervisor, 1 secretaire, 1 PC
30 secondes plus tard Durée variable (entre quelques secondes et quelques minutes)									Traitement automatisé en mode conversationnel	Warehouse Supervisor Lieu : Bureau Warehouse Supervisor Ressources : Le Warehouse Supervisor, 1 PC, Internet
30 secondes plus tard Durée : 1 minute									Traitement automatisé en mode conversationnel	Finance Manager Lieu : Bureau Finance Manager Ressources : Le Finance Manager, 1 PC
1 minute plus tard Durée : 1 minute									Traitement automatisé en mode conversationnel	Finance Manager Lieu : Bureau Finance Manager Ressources : Le Finance Manager, 1 PC
30 secondes plus tard Durée variable (entre quelques secondes et quelques minutes)									Traitement automatisé en mode conversationnel	Finance Manager Lieu : Bureau Finance Manager Ressources : Le Finance Manager, 1 PC, Internet
30 minutes plus tard Durée : 1 minute									Traitement automatisé en mode conversationnel	Head of Region Lieu : Bureau Head of Region Ressources : Le Head of Region, 1 PC
30 secondes plus tard Durée : 1 minute									Traitement automatisé en mode conversationnel	Head of Region Lieu : Bureau Head of Region Ressources : Le Head of Region, 1 PC
30 secondes plus tard Durée : 5 minutes									Traitement automatisé en mode différé	Head of Region Lieu : Bureau Head of Region Ressources : 1 secrétaire, 1 PC, 1 imprimante
Moment d'élaborer le rapport Durée : quelques secondes									Traitement automatisé en mode conversationnel	Warehouse supervisor Lieu : Bureau Warehouse Supervisor Ressources : 1 secrétaire, 1 PC

Tableau 2.6.

I.1.4. Diagramme descriptif des phases

Le diagramme descriptif des phases donne la répartition de tâches entre l'homme et la machine. Il concerne les phases qui sont automatisées. Ici, nous ne présentons ce diagramme que pour les phases 3 et 11 de la gestion de carburant et de la gestion des entretiens.

A. Gestion de carburant

Phase 3 : Saisie Fuel requisition

N°

Tâches

Homme

Machine

1 2 3 4 5 6

Entrer valeurs Contrôler Numéro immatr. Afficher erreur Insérer dans la table BON_FUEL Afficher erreur Afficher Fuel requisition saisi

Tableau 2.7.

Commentaires :

La phase 3 concerne la saisie du fuel requisition. C'est aussi une saisie dans la base de données. La tâche « contrôle Num_imma_vehi » se fait de la manière suivante : SELECT FROM VEHICULE WHERE VEHICULE.Num_imma_vehi =

BON FUEL.Num imma vehi

_ _ _

La tâche insérer dans la table BON_FUEL est une insertion automatique des tuples dans la table la table BON_FUEL.

Phase 11 : Edition « requête carburant » Le problème :

En entrant le numéro d'immatriculation d'un véhicule, afficher ses différentes date de retrait de carburant. La liste comprend : le Numéro d'immatriculation, la marque du véhicule, la quantité de carburant reçu et la date de retrait.

La solution en SQL :

SELECT VEHICULE.Num_imma_vehi, VEHICULE.Marque, BON_FUEL.Qté_fuel_reçu, BON_FUEL.Date_Fuel

FROM VEHICULE, BON_FUEL

WHERE (VEHICULE.Num_imma_vehi = BON_FUEL.Num_imma_vehi) and

(VEHICULE.Num_imma_vehi) = [entrer immatriculation]);

N°

Tâches

Homme

Machine

1 2 3 4 5 6 7

Saisir << requête carburant » Contrôler << requête carburant » Afficher erreur Saisir immatriculation Contrôler immatriculation Afficher erreur Afficher rapport carburant

Tableau 2.8

Commentaires : La phase 11 aide à l'élaboration des rapports sur le carburant. Elle donne comme résultat un état sur une requête << requête carburant ». On saisit << requête carburant » et un contrôle est fait sur le nom de la requête puis sur le numéro d'immatriculation du véhicule inséré. Si tout est correct, on a le << rapport carburant ».

B. Gestion des entretiens

Phase 3 : Saisie B.C.E.

N°

Tâches

Homme

Machine

1 2 3 4 5 6

Entrer valeurs Contrôler Numéro immatr. Afficher erreur Insérer dans la table ENTRETIEN Afficher erreur Afficher B.C.E. saisi

Tableau 2.9.

Commentaires :

La phase 3 concerne la saisie du B.C.E. C'est aussi une saisie dans la base de données. La tâche « contrôle Num_imma_vehi » se fait de la manière suivante : SELECT FROM VEHICULE WHERE VEHICULE.Num_imma_vehi = ENTRETIEN.Num_imma_vehi

La tâche insérer dans la table ENTRETIEN est une insertion automatique des tuples dans la table la table ENTRETIEN.

Phase 11 : Edition « requête entretien » Le problème :

En entrant le numéro d'immatriculation d'un véhicule, afficher les différentes date d'entretien de ce véhicule et le type d'entretiens connu à ces dates. La liste comprend : le Numéro d'immatriculation, la marque du véhicule, le type d'entretien connu et la date d'entretien.

La solution en SQL :

SELECT VEHICULE.Num_imma_vehi, VEHICULE.Marque, ENTRETIEN.Type _entretien, ENTRETIEN.Date_entretien

FROM VEHICULE, ENTRETIEN

WHERE (VEHICULE.Num_imma_vehi = ENTRETIEN.Num_imma_vehi) and (VEHICULE.Num_imma_vehi) = [entrer immatriculation]);

N°

Tâches

Homme

Machine

1 2 3 4 5 6 7

Saisir << requête entretien » Contrôler << requête entretien» Afficher erreur Saisir immatriculation Contrôler immatriculation Afficher erreur Afficher rapport entretien

Tableau 2.10.

Commentaires : La phase 11 aide à l'élaboration des rapports sur les entretiens. Elle donne comme résultat un état sur une requête << requête entretien ». On saisit << requête entretien » et un contrôle est fait sur le nom de la requête puis sur le numéro d'immatriculation du véhicule inséré. Si tout est correct, on a le << rapport entretien ».

I.2. Modèle logique des données (MLD)

I.2.1. Nouvelles données pour la gestion de carburant et pour les entretiens.

Avant de présenter le MLD, signalons qu'avec la solution adoptée, la quantité de données contenues dans le Fuel requisition et celles contenues dans le Bon de Commande pour Entretien (B.C.E.) a été sensiblement réduite. Ainsi nous avons le tableau suivant :

N°	Nom	Fuel Requisition	B.C.E.
1.	Date_Fuel	*			2.
Qte_Fuel_reçu	*		3.
Num_bon_Fuel	*		4.
Type_Fuel	*		5.
Num_imma_vehi	*	*	6.
Num_entretien		*	7.
Nom_garage		*	8.
Date_entretien		*	9.
Km_entretien		*	10.
Type_entretien		*

Tableau 2.11.

I.2.2. Représentation schématique du modèle logique de données

ASSURANCE

Num_ass Num_imma_vehi # Nom_assureur Date_ass

Date_exp_ass

(1,1)

(1,1)

(1,n)

SERVICE

VEHICULE

Num_service

ENTRETIEN

(1,1)

Nom_service

Num_entretien

Num_imma_vehi

Num_imma_vehi

#

(1,1) (1,n)

Num_service #

Nom_garage

Num_chassie

Date _entretien

Marque

(1,1)

Km_entretien

(1,n)

Annee_Fabri

Type_entretien

Num_ordre_vehi

(1,1)

PRELEVER

(1,n)

BON_FUEL

Num_imma_vehi #

Num _bon_fuel

Num_imma_vehi #

Date #

Qte_fuel_reçu

(1,1)

Kilometrage

Date _fuel

(1,1)

Type_fuel

(1,1)

VOYAGE

Num_voy

CONDUCTEUR

Num_imma_vehi

#

(1,n)

Num_conducteur

(1,n)

Num_conducteur # Destination_voy Motif_voy

DATE_KM

(1,1)

Nom_conducteur

Date

Date_depart

Date_retour

Figure 2.5.

Voici ci-dessous le tableau des contraintes d'intégrité référentielle

N°	Foreign Key (FK)	Relation référençante	Relation référencée	Primary key
1.	Num_service	VEHICULE	SERVICE	Num_service		2.
Num_imma_vehi	ASSURANCE	VEHICULE	Num_imma_vehi	3.
Num_imma_vehi	ENTRETIEN	VEHICULE	Num_imma_vehi	4.
Num_imma_vehi	PRELEVER	VEHICULE	Num_imma_vehi	5.
Date	PRELEVER	DATE_KM	Date	6.
Num_imma_vehi	BON_FUEL	VEHICULE	Num_imm_vehi	7.
Num_imma_vehi	VOYAGE	VEHICULE	Num_imma_vehi	8.
Num_conducteur	VOYAGE	CONDUCTEUR	Num_conducteur

Tableau 2.12.

Chapitre deuxième : Modèle physique de données

II.0. Introduction

L'implantation des données elles-mêmes qui est réalisée au niveau physique, c'est-àdire le chargement de la base, nécessite que soient fixés les choix en matière de structuration de données dans la mémoire de l'ordinateur. A cette étape, nous faisons appel à un nouveau modèle qualifié de modèle physique. Nous utilisons à cet effet le logiciel Microsoft Access 2007.

II.1. Création des tables

Pour notre base de données, nous avons au total neufs tables. Nous les créons en utilisant ici le langage de description de données SQL (Strutured Query Language).

1) Table « SERVICE »

CREATE TABLE SERVICE

(Num_service INTEGER PRIMARY KEY, Nom_service CHAR (20) NOT NULL);

2) Table « VEHICULE »

CREATE TABLE VEHICULE

(Num_imma_vehi CHAR (8) PRIMARY KEY,

Num_service INTEGER REFERENCES SERVICE (Num_service), Num_chassie CHAR(20) UNIQUE,

Marque CHAR(20) NOT NULL,

Annee_Fabri INTEGER NOT NULL,

Num_ordre_vehi INTEGER UNIQUE);

3) Table « ASSURANCE »

CREATE TABLE ASSURANCE

(Num_ass CHAR (20) PRIMARY KEY,

Num_imma_vehi CHAR (8) REFERENCES VEHICULE (Num_imma_vehi), Nom_assureur CHAR (20) NOT NULL,

Date_ass DATE CHECK (VALUE >=CURRENT DATE),

Date_exp_ass DATE CHECK ( Date_exp < Date_ass)) ;

4) Table « ENTRETIEN >

CREATE TABLE ENTRETIEN

(Num_entr CHAR (5) PRIMARY KEY,

Num_imma_vehi CHAR (8) REFERENCES VEHICULE (Num_imma_vehi), Nom_garage CHAR (20),

Date_entretien DATE CHECK (VALUE >=CURRENT DATE),

Km_entretien INTEGER NOT NULL CHECK (VALUE >0),

Type_entretien CHAR (100) NOT NULL);

5) Table « CONDUCTEUR >

CREATE TABLE CONDUCTEUR

(Num_conducteur CHAR (12) PRIMARY KEY, Nom_conducteur CHAR (20) NOT NULL);

6) Table « DATE_KM >

CREATE TABLE DATE_KM

(Date DATE CHECK (VALUE >= CURRENT DATE));

7) Table « VOYAGE >

CREATE TABLE VOYAGE

(Num_voy INTEGER PRIMARY KEY,

Num_imma_vehi CHAR (8) REFERENCES VEHICULE (Num_imma_vehi), Num_conducteur CHAR (12) REFERENCES CONDUCTEUR (Num_conducteur), Destination_voy CHAR (20) NOT NULL,

Motif_voy CHAR (50) NOT NULL,

Date_départ DATE CHECK (VALUE >= CURRENT DATE),

Date_retour DATE CHECK (VALUE >= Date_départ));

8) Table « PRELEVER >

CREATE TABLE PRELEVER

(Num_imma_vehi CHAR (8) REFERENCES VEHICULE (Num_imma_vehi), Date DATE REFERENCES DATE_KM (Date),

PRIMARY KEY (Num_imma_vehi, Date), Kilometrage INTEGER NOT NULL);

9) Table « BON_FUEL »

CREATE TABLE BON_FUEL

(Num_bon_fuel INTEGER PRIMARY KEY,

Num_imma_vehi CHAR (8) REFERENCES VEHICULE (Num_imma_vehi), Qte_fuel_reçu INTEGER CHECK (VALUE >0),

Date_fuel DATE CHECK (VALUE >=CURRENT DATE),

Type_fuel CHAR (10) NOT NULL);

II.2. Calcul de l'encombrement de la base de données

N°	TABLE		Nbre moyen	TUPLE	TYPE	OCTETS
						Tuple	Table	Total
1.	SERVICE		4	Num_service	Entier	2	22	88
				Nom_service	Char	20
2.	VEHICULE		40	Num_imma_vehi	Char	8	58	2320
				Num_service	Entier	2
				Num_chassie	Char	20
				Marque	Char	20
				Annee_Fabri	Entier	2
				Coût_achat	Entier(L)	4
				Num_ordre_vehi	Entier	2
3.	ASSURANCE		40	Num_ass	Char	20	68	2720
				Num_imma_vehi	Char	8
				Nom_assureur	Char	20
				Date_ass	Date	8
				Montant_ass	Entier(L)	4
				Date_exp	Date	8
4.	ENTRETIEN		200	Num_entr	Char	5	43	8600
				Num_imma_vehi	Char	8
				Nom_garage	Char	20
				Date_entr	Date	8
				Cout_entr	Entier	2
5.	CONDUCTEUR		40	Num_conducteur	Char	12	32	1280
				Nom_conducteur	Char	20
6.	DATE_KM		14600	Date	Date	8	8	116800
	ENTRETIEN		480	Num_entr	Char	5	123	59040
				Num_imma_vehi	Char	8
				Type_panne	Char	50
				Date_panne	Date	8
				Num_accident	Entier	2
				Dommage	Char	50
N°		TABLE	Nbre moyen	TUPLE	TYPE	OCTETS
						Tuple	Table	Total
10.		VOYAGE	60	Num_voy	Entier	2	110	6600
				Num_imma_vehi	Char	8
				Num_conducteur	Char	12
				Destination_voy	Char	20
				Motif_voy CHAR	Char	50
				Date_départ	Date	8
				Date_retour	Date	8
				Frais_mission	Entier	2
11.		PRELEVER	14600	Num_imma_vehi	Char	8	20	292000
				Date	Date	8
				Kilometrage	Entier(L)	4
12.		BON_FUEL	2080	Num_bon_fuel	Entier	2	30	62400
				Num_imma_vehi	Char	8
				Qte_fuel_reçu	Entier	2
				Date_fuel	Date	8
				Type_fuel	Char	10
Total général						551848

Tableau 2.13. Calcul de la capacité des index (les clés) :

Clés	Type	Octets
Num_service	Entier (court)	2
Num_imma_vehi	Char	8
Num_ass	Char	20
Num_entrentien	Char	5
Num_conducteur	Char	12
Date	Date	8
Num_voy	Entier (court)	2
Num_imma_vehi, Date	Char	16
TOTAL		73

Tableau 2.14.

Le nombre moyen pour une année est calculé de la manière suivante :

· SERVICE : il y a 4 services ;

· VEHICULE : On a en moyenne 40 véhicules ;

· ASSURANCE : chaque véhicule a une assurance par an ;

· ENTRETIEN : un entretien par véhicule par mois

· CONDUCTEUR : en estimant que chaque véhicule a un conducteur : 40

· DATE_KM : à la fin de chaque journée, on prélève le kilométrage de chaque véhicule. Pour les 40 véhicules on aura : 365 fois 40 soit 14600

· VOYAGE : en estimant 5 voyages par mois dans l'ensemble, on aura 60 voyages pour une année.

· BON_FUEL : 1 bon est établi chaque semaine pour chaque véhicule. Pour toute une année : 52 semaines fois 40 véhicules. On a : 2080

II.3. Conclusion partielle

Avec cette deuxième partie, ce travail a atteint son point culminant. L'implantation de la base de données au niveau physique à l'aide d'un langage de description de données puis, la manipulation de ces données, tels sont les objectifs que cette étude se proposait d'atteindre. Plusieurs requêtes peuvent être formulées dans la manipulation de données. Nous n'avons retenu que deux dont les résultats sont repris en annexe.

III. CONCLUSION GENERALE

III.1. Reprise

Toute la démarche suivie dans ce travail consistait à faire une étude qui avait pour objectif de doter Vodacom d'une base de données qui lui permettrait de bien gérer son charroi automobile. Pour ce faire, nous avons utilisé la méthode MERISE.

Cette étude s'est faite en deux parties. La première partie était une étude préalable du projet. Elle nous a permis de fixer nos idées sur l'organisation et particulièrement sur le domaine étudié avant d'analyser l'existant. Une analyse aussi approfondie ne pouvait que nous conduire à recenser des problèmes que la deuxième partie s'est proposé de résoudre avec la schématisation des traitements et des données au niveau logique. L'implantation d'une base de données au niveau physique grâce au logiciel Microsoft Access a couronné tous les efforts fournis par cette étude.

L'expérience faite, en menant cette étude, nous laisse soutenir que l'« élaboration d'une solution informatique dans n'importe quel domaine passe par une série d'étapes qui donnent toutes lieu à des choix difficiles et complexes à effectuer » [PANT 96, p. 14]. Nous avons donc eu à faire des choix pour répondre aux nombreux problèmes qui se sont manifestés au niveau conceptuel, logique et physique. Nous osons croire que nos différents choix ont permis tout de même à aboutir à un modèle cohérent ainsi qu'à une solution claire et logique. Cependant, reconnaissons que tout ne s'arrête pas là. Cette étude mérite d'être poursuivie, approfondie, mise en application et améliorée.

III.2. Limites de ce travail

Les méthodes traditionnelles, composées d'étapes menées séquentiellement depuis l'analyse du besoin jusqu'à la recette, présentent l'inconvénient d'être rigides et peu réactives. C'est ce qui est notamment reproché à la méthode MERISE utilisée dans ce travail. Celle-ci propose une démarche dite non-évolutive, fixe, rigide, qui ne s'adapte pas au projet.

MERISE n'est pas orientée objet. Ses diagrammes peuvent être lourds. Ce n'est pas une méthode cognitive mais une méthode technique très bien adaptée aux bases de données conventionnelles. Par ailleurs, cette méthode est encore très utilisée et fait ses preuves.

III.3. Prospectives

Pour l'implantation de notre base de données, nous avons utilisé le logiciel Microsoft Access. Cette application est incomplète. Elle ne peut pas être livrée à l'utilisateur telle quelle. C'est ainsi que nous en sommes resté au niveau des simulations. Pour la rendre complète et utilisable, nous avons besoin notamment du langage Visual Basic for Application (VBA) qui, intégré à Access, permet de créer des applications de gestion complètes, livrées avec un programme d'installation qui gère automatiquement la mise en place éventuelle d'un « runtime » (temps d'exécution) d'Access, et dont le code source est protégé dans une version semi-exécutable des fichiers (mdb : Microsoft Database). Ceci permettra aussi d'avoir une interface appropriée pour l'utilisateur.

Par ailleurs, la décennie 90 a vu le développement des entrepôts de données (Datawarehouse). Un entrepôt de données est un ensemble de données historicisées variant dans le temps, organisé par sujets, agrégé dans une base de données unique, géré dans un environnement de stockage particulier, aidant à la prise de décision dans l'entreprise. Trois fonctions essentielles sont prises en compte par ces nouveaux systèmes décisionnels : la collecte de données à partir de bases existantes et le chargement de l'entrepôt, la gestion et l'organisation des données dans l'entrepôt, l'analyse de données pour la prise de décision en interaction avec les analystes.

Notre travail pourrait donc s'enrichir s'il s'ouvrait à cette fouille de données qui déboucherait sur une base de données décisionnelle. Une étude menée jusqu'à un tel niveau aiderait davantage les décideurs à prendre des décisions qui conviennent pour une meilleure gestion.

ANNEXES

I. Exemplaire de formulaire d'enregistrement de données

II. Requête carburant

III. Requête entretien

IV. Rapport d'Inspection Journalière du Véhicule (R.I.J.V.)

V. Vehicle Trip Log Sheet (T.L.S.)

VI. Fuel requisition

VII. Bon de Commande pour entretien (B.C.E.)

BIBLIOGRAPHIE

[HAIN 00] J.- L. HAINAUT. Bases de données et modèles de calcul, Dunod, Paris, 2000. [GARD 03] G. GARDARIN. Bases de données, Eyrolles, Paris, 2003.

[MATH 02] J.- P. MATHERON. Comprendre Merise : Outils conceptuels et organisationnels, Eyrolles, Paris 2002.

[REBO 97] G. REBOUL. Informatique de gestion. Analyse et modèle relationnel, Dunod, Paris, 1997.

[SORN 03] J. SORNET. Informatique de gestion. Analyse et partage des bases de données, Dunod, Paris, 2003.

[PANT 96] D. PANTAZIS, J.-P. DONNAY. La conception de SIG. Méthode et formalisme, Hermès, Paris, 1996.

[DIGA 01] F. DI GALLO. Méthodologie des systèmes d'information - MERISE, Cours du Cycle Probatoire, CNAM ANGOULEME 2000-2001, http://fdigallo.online.fr/cours/merise.pdf

[AUDI 08] L. AUDIBERT. Base de Données et Langage SQL, notes de cours, Date de 02/2007, Date de mise à jour : 14/02/2008, http://laurentaudibert.developpez.com/Cours-BD/

[GRUA 05] C. GRUAU. Conception d'une base de données, notes de cours, Octobre 2005, ftp://ftp-developpez.com/cyril-gruau/ConceptionBD.pdf

[BAVU] D. BAVUEZA. Méthodes d'analyse informatique 1, Faculté des Sciences,

UNILU, 2008 - 2009, cours, inédit.

TABLE DES MATIERES

O. INTRODUCTION GENERALE 1

0.1. Choix du sujet 1

0.2. Définition d'une base de données 1

0.3. Problématique 2

0.4. Intérêt du sujet 2

0.5. Approche méthodologique et division du travail 3

0.5.1. Approche méthodologique 3

0.5.2. Division du travail 4

Première partie : ETUDE PREALABLE 5

0. Introduction 5

0.1. Présentation de la première partie 5

0.2. Définition de la mission 5

0.2.1. Problème de gestion 5

0.2.2. Améliorations attendues 5

0.2.3. Point de départ et point d'arrêt de l'étude 6

0.2.4. Champs de l'étude 6

Chapitre premier : Présentation de l'existant 7

I.1. Description de l'organisation 7

I.2. Description des données 25

I.2.1. Inventaire des lots d'information 25

I.2.2. Inventaire des rubriques 26

I.2.3. Dictionnaire des données 27

I.3. Description des traitements 29

I.3.1. Diagramme des procédures 30

I.3.2. Règles de gestion 34

I.3.3. Tableau des évènements 35

I.3.4. Tableau des actions induites 39

I.3.5. Tableau des opérations 40

I.3.6. Tableau des synchronisations 42

I.3.7. Les règles d'Emission des résultats 42

Chapitre deuxième : Analyse de l'existant 45

II.1. Construction du modèle conceptuel des traitements (MCT) 45

II.2. Construction du Modèle conceptuel de données (MCD) 49

II.2.1. Tableau de dépendance fonctionnelle à source simple 49

II.2.2. Tableau de dépendance fonctionnelle à source composée 50

II.2.3. Matrice des clés 50

II.2.4. Graphe des clés 51

II.2.5. Structure d'Accès Théorique (SAT) 52

II.2.6. Modèle Conceptuel des données 53

II.2.7. Tableau des cardinalités 54

II.3. Evaluation de l'intérêt du changement 55

II.3.1. Diagnostic 55

II.3.2. Orientation de la solution 57

III. Conclusion partielle 59

Deuxième partie : CONCEPTION DETAILLEE DE LA SOLUTION 60

0. Introduction 60

Chapitre premier : Niveau logique des traitements et des données .... 61

I.1. Modèle organisationnel de traitements (MOT) 61

I.1.1. Ancien Modèle Conceptuel de Traitement et les nouvelles activités 61

I.1.2. Niveau d'automatisation 64

I.1.3. Diagramme d'enchainement des procédures 66

I.1.4. Diagramme descriptif des phases 74

I.2. Modèle logique des données (MLD) 81

I.2.1. Nouvelles données pour la gestion de carburant et pour les entretiens. 81

I.2.2. Représentation schématique du modèle logique de données 82

Chapitre deuxième : Modèle physique de données 84

II.0. Introduction 84

II.1. Création des tables 84

II.2. Calcul de l'encombrement de la base de données 87

II.3. Conclusion partielle 89

III. CONCLUSION GENERALE 90

III.1. Reprise 90

III.2. Limites de ce travail 90

III.3. Prospectives 91

ANNEXES 92

BIBLIOGRAPHIE 98

TABLE DES MATIERES 99