Etude et conception d'une application de gestion des équipements

EPIGRAPHE

UN TRAVAIL BIEN FAIT SI HUMBLE SOIT-IL EST NOBLE

ANONYME

DEDICACE

A Dieu Le Tout Miséricordieux, ton amour, ta miséricorde et Tes grâces à mon égard m'ont fortifié dans la persévérance et l'ardeur au travail.

A celui qui m'a indiqué la bonne voie en me rappelant que la volonté fait toujours les grands hommes...
A mon Père Moïse MANDE LENGE KITENGE.
A celle qui a attendu avec patience les fruits de sa bonne éducation...
A ma Mère Thalie KAT TSHIBANG.

Je dédie ce travail.

Moïse LENGE KITENGE

AVANT-PROPOS

Après une longue période d'endurance, nous tenons à exprimer à travers les quelques lignes nos profonds sentiments de reconnaissance aux uns et aux autres pour leur soutien tant moral que matériel pour notre obtention du titre de gradué en sciences informatiques.

Nous tenons sincèrement à remercier de tout coeur notre directeur, l'assistant Vicky LUKUSA qui, malgré ses multiples occupations, a accepté de diriger ce travail.

Nous témoignons notre gratitude à l'administration et au corps professoral et académique de l'université protestante de Lubumbashi.

A mes frères et soeurs : Roddie MANDE, Carine MANDE, Daniella MANDE, Huguette MANDE, Thalie MANDE, Célestine MANDE, LENGE MANDE, Gaby MANDE, Thalie KAT, Erick KAYEMBE, Daniel KADIATA, nous disons merci.

A mes neveux et nièces : Jonathan MUTOMBO, Moïse MANDE, Châtie KUTEKEMENA, Thalie KAT, Deborah BUPANKISHI, nous témoignons notre gratitude.

A tous mes compagnons de lutte vous qui de loin ou de près, nous aviez si bien soutenu pendant la période de notre formation, il nous sera difficile de passer sous silence vos noms: Francis KABUYA, Lebon TSHIMANGA, LONGWA DALI, Saddam MUKABE, Gaston NSHIMBA, Nelson LONGWA, BARACKA BASHIMBE, Erick BIDWAYA, Sylvain KABEMBA, Derrick KILUKA, Bob YABAKULA, Olivier NKULU, Prince MUTOMBO, Grace KAVIRA, Flavie NZEBA, KISS KISENGA, Vieux John et Henry NDALA.

Moïse LENGE KITENGE

INTRODUCTION GENERALE

L'informatique étant un élément essentiel pour la survie de presque toute organisation en ce 21^ème siècle, son but principal dans une organisation est la réduction possible ou la facilitation du temps d'exécution d'une ou de différentes tâches au sein de cette organisation ou entreprise.

En effet, pour ce faire, cela demande d'associer les efforts de l'homme à ceux de la machine.

Ainsi les avantages qu'amène l'informatique dans une entreprise ont poussé AFRIMA de se doter d'un système informatique pour la gestion des équipements (Pièces de rechange).

C'est ainsi que nous avons pensé qu'il sera impérieux de développer ou de mettre en place une application de gestion desdites pièces au sein de cet Etablissement et ce, dans le cadre de notre travail de fin de cycle en sciences informatiques qui est intitulé : « Analyse et conception d'une application informatique de gestion des équipements », avec comme cas particulier AFRIMA.

1. Choix et intérêt du sujet

Cette étude a été choisie par rapport à notre désire de contribuer à la gestion des équipements par des moyens automatisés a l'issue de notre premier cycle de formation en informatique. Elle permettra au gestionnaire du magasin de connaître rapidement la quantité des équipements stockés.

En détail l'application que nous mettrons en place sera capable de générer une liste de tous les équipements que contient le magasin.

2. Problématique

La problématique est l'art d'élaborer et de poser clairement le problème et aussi de répondre en suivant leur transformation dans la réflexion scientifique^1(*).

Selon KANT, la problématique est une proposition exprimant une possibilité à résoudre, soit sur un résultat inconnu à travers et à partir des certaines données, soit sur la détermination de la méthode à suivre pour obtenir un résultat supposé connu.^2(*)

Étant donné que le nombre des équipements ne cesse d'accroître au jour le jour par le fait que l'entreprise AFRIMA est devenue inondée des véhicules de toutes marques, il s'avère un peu plus complexe de bien gérer les équipements d'autant plus que tout se fait manuellement.

De ce fait beaucoup de risques sont à signaler :

· Perte des documents d'enregistrement ;

· La lenteur dans la recherche d'un document ;

· La lenteur dans l'établissement du document ;

· Le contrôle des équipements difficiles ;

Pour ne citer que ceux-ci...

Par conséquent nous nous sommes posé quelques questions à ce sujet :

Ø Comment peut-on garantir la sécurité des documents d'enregistrement des équipements ?

Ø Que faudra-t-il faire pour rendre rapide la recherche d'un document ?

Ø Comment rendre rapide l'établissement d'un document ?

3. Hypothèse

L'hypothèse est définie par Ronger comme « la proposition des réponses aux questions que l'on se pose à propos de l'objet de la recherche formulée en termes tels que l'observation et l'analyse puisse fournir une réponse ».

De notre côté nous définissons l'hypothèse du travail comme étant une idée directrice, une tentative d'explication des faits formulés au début de la recherche destinée à guider l'investigation et à être abandonnée ou maintenue d'après les résultats de l'observation.

Comme hypothèse ou solution aux questions que nous nous sommes posés ci -haut nous disons que la création d'une base de données couplée avec une application pourra conserver et restituer les données de l'AFRIMA en temps voulu.

L'application fera en sorte qu'il n'y ait presque plus d'erreurs d'enregistrement et de minimiser le temps de recherche des documents.

4. Méthodes et techniques utilisées

a. Méthodes

Une méthode, c'est l'ensemble de règles pour conduire raisonnablement, logiquement nos pensées. En d'autres mots, c'est la voie à suivre pour atteindre le but qu'on s'est fixé.

M.GRAWITZ et R.PINTO, définissent la méthode comme un ensemble d'opérations intellectuelles par lesquelles une discipline cherche à atteindre les vérités^3(*).

Dans ce travail de recherche, nous avons adopté Merise comme démarche d'analyse et des projets informatiques afin d'atteindre, de démontrer ou d'approuver différentes étapes du travail.

La force de la méthode Merise est de structurer les besoins des décideurs de façon simple et compréhensibles. Merise améliore la communication entre les différents acteurs du processus de développement. Cette méthode, grâce à ses modèles, encadre le projet et de ce fait protège les intervenants d'un possible développement hors sujet.

Suivre ce cheminement intellectuel peut aussi aider l'entreprise à mieux se connaître, mieux se comprendre et ainsi mieux communiquer.

Le projet Merise s'articule autour d'un schéma directeur qui détermine et planifie le projet et ses enchainements.

b. Techniques

Les techniques des recherches sont considérées comme des moyens ou outil mis à la disposition des méthodes pour faciliter la recherche.

Les techniques suivantes se sont montrées utiles et avantageuses dans la collecte des informations :

v Observation

Nous avons pris du temps à nous tenir debout comme un client en train d'observer comment les informations sont échangées en vue de réaliser notre travail.

v Questionnaire

Dans le but d'obtenir des données plus sures et plus exactes, nous avons élaboré un questionnaire et avons remis à l'enquêté (gestionnaire du magasin).

5. Délimitation du sujet

Dans l'espace nous nous sommes engagés de nous limiter juste à informatiser AFRIMA dans la gestion des équipements. Cette entreprise est située à Lubumbashi au n^o 22 de l'avenue des savonniers dans la ville de Lubumbashi, commune de Kampemba au quartier Bel-Air.

Dans le temps, nous avons pris en compte les procédures et fonctionnement à partir du mois de janvier 2014 et signalons que notre application que nous mettrons en place sera toujours d'actualité tant que ces procédures resteront inchangées.

6. Subdivision du travail

Hormis l'introduction et la conclusion générale, notre travail est structuré ou subdivisé en deux grandes parties :

o Première partie : APPROCHE THEORIQUE

· Chapitre 1 : GENERALITES

· Chapitre 2 : PRESENTATION DU CHAMP D'ETUDE ET ANALYSEDE L'EXISTANT

o Deuxième partie : APPROCHE PRATIQUE

· Chapitre 3 : Conception de la base de données

· Chapitre 4 : Implémentation.

PREMIERE PARTIE : APPROCHE THEORIQUE

Chapitre I : GENERALITES

I.1. Cadre conceptuel

Entité Relation^4(*)

· ENTITE : l'entité est l'objet réel ou abstrait que l'on veut décrire à l'aide d'un ensemble de propriétés. Notons aussi que l'entité doit aussi répondre à un besoin de gestion.

· PROPRIETE : C'est le plus petit élément d'information, c'est-à-dire une information atomique non décomposable et qui correspond à un besoin de gestion.

· IDENTIFIANT D'UNE ENTITE : C'est le plus petit sous-ensemble des propriétés qui identifie de façon unique une occurrence de l'entité.

· OCCURRENCE DE l'ENTITE : C'est l'ensemble des occurrences de propriétés qui définissent l'entité, une réaction de l'entité.

· RELATION : Est un lien sémantique entre ou encore, un ensemble des identifiants des entités qui sont reliées par l'association.

Traitement^5(*)

· EVENEMENT : C'est un fait dont l'apparition va déclencher une réaction au sein de l'organisation ou dans un domaine l'occurrence (la réalisation) de l'événement entraîne le déroulement d'activités ou d'opérations.

· OPERATION : C'est l'ensemble d'action déclenchée pour réagir à un événement ou à plusieurs événements.

· RESULTAT : C'est un produit par l'exécution d'une opération, le résultat est produit à la fin de l'exécution d'une opération.

· PROCESSUS : c'est un enchaînement d'opérations relatives à un même domaine d'activité.

· SYNCHRONISATION : exprime sous forme d'une proposition logique le fait que l'opération peut être déclenchée ou non. Elle est exprimée par une expression booléenne (logique) liant les événements déclenchant l'opération.

· REGLE D'EMISSION DES RESULTATS : C'est une forme d'expression logique qui définit la condition à laquelle est soumise l'émission de plusieurs résultats par une opération.

I.2. Cadre théorique6(*)

Dans cette partie, nous allons présenter la méthode de conduite du projet utilisée : MERISE.

I.2.1. Historique de la méthode MERISE

MERISE est un acronyme signifiant méthode d'étude et de réalisation informatique par les sous-ensembles ou pour les systèmes d'entreprise. La méthode MERISE a comme objectif d'aider de guide les SSII (Société de Services et d'ingénierie Informatique), dans leurs phases d'analyses, de conception et de développement de l'applicatif.

Nous devons la création de l'étude et de la mise en place de cette méthode à une équipe de chercheurs et d'ingénieurs Aixois (Jean-Louis le Moigne, Hubert Tardieu, Dominique Nancy, Henry Heckenroth, Daniel Pasco, Bernard Espinasse) qui en posèrent les bases dans le milieu des années 1970.

Le ministère de l'industrie vit en cette méthode un excellent moyen pour standardiser les rapports existant entre les administrations et leurs sous-traitants.

C'est pourquoi il finance quelque temps les recherches sur la méthode MERISE.

Le challenge était de pouvoir proposer des outils ou des méthodologies permettant aux donneurs d'ordres et aux développeurs de se comprendre et ainsi de mieux appréhender chacun de leur côté avec leur propre culture professionnelle, l'ensemble du système d'information.

La méthode MERISE présente comme avantage indéniable de permettre une définition claire et précise de l'ensemble du système d'information et d'en définir correctement le périmètre.

Cette méthode est actuellement enseignée aux étudiants se dirigeant vers des études informatiques, mais aussi aux étudiants voulant suivre des études comptables.

Nous retrouvons là le besoin qui avait poussé le ministre de l'industrie à investir dans cette méthode.

En effet, dans les petites et moyennes entreprises qui n'ont souvent pas de service informatique c'est le comptable qui est l'interlocuteur privilégié entre l'entreprise et le prestataire des services d'information. Dominique Nancy et Henry Heckenroth rejoignirent Bernard Cohen, créateur de la société CECIMA distributrice du logiciel Win design qui permet de concevoir les différentes phases d'un projet piloté par la méthode MERISE qui est caractérisée par :

· Une approche systématique en ayant une vue de l'entreprise en terme de système.

Un système est défini selon Larousse comme une combinaison des parties qui se coordonnent pour concourir à un résultat, de manière à former un ensemble.

Dans le cadre de ce travail, nous retenons qu'un système est un élément fini dont le périmètre est une frontière qui le sépare de son environnement (n), il interagit avec son environnement grâce à des flux d'informations entrantes, qu'il va traiter et restituer à l'environnement sous forme de flux d'informations sortantes.

Le système va générer des informations qui rendent compte de son comportement à la fois au sein de l'environnement, mais aussi pour son propre compte. Un système communique.

Un système a besoin, pour prendre des décisions, de stocker et de traiter des informations.

I.2.2. La représentation schématique des systèmes de l'entreprise

Si nous reprenons l'analogie anatomique, et si nous comparons l'entreprise à un corps humain, nous pouvons réduire l'entreprise à un cerveau qui pilote, nos muscles qui opère et des nerfs qui font transiter l'information. Voici le schéma ci-dessous qui simplifie le système d'information.

Système de Pilotage

Système d'information

Système Opérant

Information

Mémorisée

Information à mémoriser

Information

Mémorisée

Information à mémoriser

Flux de données sortant

Flux de données entrant

On a :

· Le système de pilotage qui définit les missions et les objets des travaux

· Le système d'information qui est l'ensemble des ressources humaines, techniques et financières qui fournissent et distribuent l'information de l'organisation.

· Le système opérant qui est l'ensemble de moyens humains, matériels du système de pilotage.

· Une séparation de données et de traitement. Dans cette étape nous avons les données et les différents types d'informations. Une approche systémique en ayant une vue de l'entreprise en terme de système.

· Les données (ou information), est l'émission ou la réception de signaux oraux ou écrits, sonores, visuels ou multimédias dont le but est de déclencher les processus alimentant l'échange, base naturelle et indispensable de l'animation de l'organisation.

1) Les différents types d'informations

Les informations élémentaires sont des informations dont les valeurs ne peuvent pas être inventées, elles ne sont pas déductibles d'autres informations.

Par exemple, un nom de client ou sa raison sociale ne peuvent pas être inventée.

Une quantité commandée ne peut pas non plus être inventée.

Une information doit être atomique, c'est-à-dire non décomposable.

Les informations calculées sont déductibles des informations élémentaires.

2) Les traitements

Ils sont collectés comme les informations via un processus d'interview et d'étude des documents. Ils peuvent être de deux sortes, automatiques et manuelles.

Ils sont déclenchés par l'arrivée d'événements.

La gestion des traitements sert identifier les fonctionnalités selon une approche qui va du général au particulier et qui définit leur découpage et leur enchainement.

Une approche par niveaux

Nous avons trois niveaux :

a) Niveau conceptuel

Le niveau conceptuel consiste à concevoir le système d'information en faisant abstraction de toutes les contraintes techniques ou organisationnelles et cela tant au niveau de données que de traitement. Le formalisme MERISE employé sera : le modèle conceptuel de données et le modèle conceptuel logique de traitements.

b) Niveau organisationnel

Il a comme mission d'intégrer dans l'analyse de critères liés à l'organisation étudiée le formalisme sera : le modèle logique de données, le modèle logique de traitements.

c) Niveau physique

Ce niveau permet de définir l'organisation réelle (physique) de données. Le formalisme : le modèle physique de données, le modèle opérationnel et physique de traitement.

Tableau récapitulatif

Niveaux	Données	Traitements
Conceptuel	Modèle conceptuel de données	Modèle conceptuel des traitements
Organisationnel	Modèle organisationnel de données	Modèle organisationnel des traitements
Logique	Modèle logique des données	Modèle logique de traitement
Physique	Modèle physique de données	Modèle opérationnel et physique des traitements

I.2.3. Les apports de merise

La force de la méthode MERISE est de structurer les besoins des décideurs de façon simple et compréhensible. MERISE améliore la communication entre les différents acteurs du processus de développement. Cette méthode, grâce à ses modèles, encadre le projet d'étude, ce fait protège les intervenants d'un possible développement hors sujet.

CHAPITRE II : PRESENTATION DU CHAMP D'ETUDE ET ANALYSE DE L'EXISTANT

II.1. Présentation de l'AFRIMA

II.1.1. Présentation Géographique

L'AFRIMA est située à Lubumbashi au n^o 22 de l'avenue des savonniers dans la ville de Lubumbashi et dans la commune de Kampemba au quartier Bel-Air.

II.1.2. Historique

II.1.2.1. Historique du groupe

Depuis plus de 125 ans, la Compagnie Française de l'Afrique Occidentale, CFAO en sigle, conjugue avec succès l'audace du précurseur et la perspicacité de l'expert de terrain.

Le Groupe a su traverser toutes les crises internationales et afficher une constante capacité à se réinventer, s'appuyant sur ses facultés d'adaptation et d'anticipation.

En 1887, les Établissements Verminck, créés à Marseille en 1845, prennent le nom de CFAO.

Le Groupe faisait alors le commerce de produits alimentaires et de consommation courante tels que les arachides, le cacao, le savon, les huiles, le caoutchouc, le café ou encore le cuir, le tabac et l'alcool. Dès cette époque, le Groupe rompt avec la tradition du simple commerce de produits de base et importe sur le continent africain une vision moderne de la distribution de produits manufacturés. Devenu le premier fournisseur de l'Afrique occidentale, il contribue à son développement et s'étend progressivement en Afrique équatoriale puis dans les Collectivités et Territoires d'Outre-mer.

En 1913, le groupe démarre son activité de distribution automobile en Afrique. Au cours des trois décennies qui suivent, CFAO se diversifie dans la production industrielle.

Entre 1950 et 1980, le Groupe a significativement développé son activité de distribution automobile mais s'est aussi diversifié parallèlement dans d'autres domaines, comme la distribution de produits en plastique ou encore l'exploitation de supermarchés en Afrique et en France. Au milieu des années 1970, le Groupe est devenu un acteur multinational présent sur 3 continents (Afrique, Europe et Etats-Unis) avec un portefeuille diversifié d'activités et son chiffre d'affaires avoisine alors les 4 milliards de francs (soit environ 610 millions d'euros).

L'année 1990 est marquée par la prise de contrôle par offre publique du Groupe par Pinault SA (devenue ultérieurement Pinault Printemps Redoute puis PPR), à la suite de laquelle le Groupe devient une branche de Pinault SA centrée sur les activités africaines. Le Groupe entame alors une réorganisation de ses activités dans un contexte économique difficile.

En 1994, le Groupe a surmonté la crise du franc CFA (dévalué de 50 % par rapport au franc en janvier), qui déstabilisa profondément les économies de l'ensemble de la région et entraîna des difficultés sérieuses pour de nombreux acteurs. Le Groupe entreprend par la suite de se renforcer dans ses métiers et ses zones d'activité clés. Ainsi, en 1996, CFAO rachète SCOA, un de ses concurrents historiques, dont la filiale de distribution pharmaceutique, Eurapharma, sera intégrée avec succès au sein du Groupe.

Depuis 2000, le Groupe a accéléré son expansion géographique : il s'est implanté dans 15 nouveaux pays, dont le Maghreb, région à fort potentiel de croissance.

Depuis le 3 décembre 2009 a eu lieu l'introduction à la Bourse de Paris du titre CFAO après une période d'absence des marchés financiers de près de 20 ans.

L'année 2012 voit la prise de contrôle par offre publique du Groupe par Toyota Tsusho Corporation.

II.1.2.2. CFAO en quelques dates clés

Depuis la création du Groupe en 1887, son logo a connu de multiples évolutions.

Le logo CFAO reflète le parcours d'un groupe audacieux qui s'est hissé aux premiers rangs de la distribution spécialisée en Afrique.

2010

CFAO se dote d'un nouveau logo. La nouvelle identité corporate de CFAO devient marque ombrelle pour l'ensemble des divisions du Groupe et permet de marquer l'arrimage et l'appartenance des différentes divisions à un groupe unique. Le gris et le bleu lui confèrent une grande sobriété à l'ensemble et permettent aux différents métiers de se doter d'une communication corporate plus cohérente. Les nouvelles couleurs et la signature « valeur d'expérience, valeur d'avenir » témoignent de la volonté du Groupe d'ouvrir une nouvelle page de son histoire tournée vers l'avenir.

2003

Le Groupe souhaite franchir un pas supplémentaire dans l'affirmation de la force de sa marque, afin de valoriser son leadership, son expertise, l'étendue unique de son réseau, et, plus généralement, son dynamisme commercial au service de ses clients. Redessiné, le logo gagne en visibilité sur le terrain. 

1996

Sur l'initiative de François Henri Pinault, alors PDG de CFAO, le Groupe se dote d'une nouvelle charte graphique : un nouveau logo et un système identitaire appliqué aux filiales et à ses départements. Symbole d'une identité commune, elle a pour objectif de clarifier l'organisation par métier et de professionnaliser l'image du Groupe et de ses filiales.

1925

La C.F.A.O. adopte cette enseigne commerciale bleu, blanc, rouge et jaune traitée dans le style du logo de la SNCF de l'époque.

1913

Le 20 novembre, l'enseigne F.A.O. est déposée par F. Bohn. Elle est utilisée pour la distribution de la majorité des articles vendus en exclusivité par C.F.A.O. Elle complète les enseignes précédentes.

1887 -- 1890

F. Bohn crée la société C.F.A.O. Très rapidement C.F.A.O. utilise ce blason, emblème de la première marque commerciale de la multinationale. Il représente une étoile dont chaque branche pointe vers un centre d'achat de C.F.A.O. et en son centre le Sphinx, cher au dirigeant de C.F.A.O., Monsieur Verminck, un passionné d'égyptologie. Par la suite, le motif central évolue avec les produits distribués.

II.1.2.3. Historique du logo CFAO

CFAO bénéficie sur le continent africain d'une histoire unique.

Depuis sa création, le Groupe s'est profondément développé et transformé.

2012

Acquisition par Toyota Tsusho Corporation

2011

Lancement de LOXEA

2010

Lancement de CFAO Équipement

2009

Introduction en bourse

2007

Installation au Vietnam

2002

Création de CFAO Technologies

2000

Installation en Afrique de l'Est et au Maghreb : Kenya, Tanzanie et Maroc

1998

Premier contrat General Motors

1996

Acquisition d'Eurapharma

1994

Création de la Joint Venture avec Heineken

1991

Premier contrat Nissan

1990

Acquisition par Pinault SA (futur PPR)

1970

Premier contrat Toyota

1960

Premier contrat Peugeot

1952

Premier contrat avec Bic

1913

Contrat de distribution Ford

1887

Création de CFAO

Structure fonctionnelle

Pour assurer le bon fonctionnement des activités, AFRIMA possède la structure fonctionnelle suivante :

ORGANIGRAMME DE L'AFRIMA

Comptabilité

Relation Administrative

Commercial

Assistant chef d'Agence

Magasin

Atelier

Transite

Délégué Commercial

Assistant Commercial

Assistant Atelier

Chef d'Agence

Date : 14 Mai 2014

Source : Mme Lisette, assistante commerciale

I : Chef d'agence : Il est l'organe supérieur qui supervise toutes les activités de l'agence. Il prend toutes les décisions sur les objectifs, sur le personnel, ainsi que sur les produits.

II : Transite : Il s'occupe de la sécurité du produit dès son embarquement jusqu'à sa destination.

III : Commercial : Il s'occupe du marketing des produits de l'agence.

IV : Assistant commercial : Il s'occupe d'établir les documents des véhicules et s'assure que le client obtienne son produit commandé.

V : Déléguer commercial : Il cherche les acheteurs des véhicules.

VI : Atelier : il s'occupe de la maintenance des véhicules.

VII : Magasin : il s'occupe de la gestion de stocks des équipements ainsi que de leurs ventes.

VIII : Comptabilité : Il s'occupe de la comptabilité de l'agence ainsi que de la paye des agents.

NB : Tous les assistants jouent le rôle des conseiller dans la prise des décisions des leurs titulaires respectifs.

II.2. Analyse de l'existant

II.2.1. Documents utilisés

Le magasin utilise les documents ci-après pour la circulation des informations :

· La facture

· La fiche de stock

· Le bon d'entrée

1) La facture : c'est le document qui est remis au client après achat et payement d'un ou de plusieurs articles. Il reprend les informations suivantes :

Ø Le numéro de la facture

Ø La date

Ø Le nom du client

Ø La désignation du produit

Ø La quantité achetée

Ø Le prix unitaire

Ø Le prix total

Ø Le montant total de la facture

2) La fiche de stock : C'est un document qui retrace l'historique des mouvements de stock d'un produit. Il comprend les informations suivantes :

Ø Le numéro de la fiche

Ø Le code du produit

Ø La désignation du produit

Ø L'unité de stockage

Ø La date du mouvement de stock

Ø La quantité entrée

Ø La quantité sortie

Ø Le solde

3) Le bon de réquisition : C'est un document établi par le magasinier qui décrit la liste des produits en rupture de stock ou demandés par les clients. Il reprend les informations ci-dessous :

Ø La date

Ø La désignation du produit

Ø La quantité souhaitée du produit

4) Le bon d'entrée : C'est un document qui reprend les produits approvisionnés et livrés au magasin. Il comprend les informations ci-après :

Ø Le numéro du bon

Ø La date

Ø La désignation du produit

Ø La quantité approvisionnée

Ø Le nom du livreur

Ø Le nom du récepteur

a. Inventaire des rubriques

Toutes les informations présentées sur les différents documents peuvent être regroupées dans le tableau suivant :

Tableau n^o 1. Inventaire des rubriques

N^o	Propriétés	Facture	Fiche de stock	Bon de réquisition	Bon d'entrée
1.	Le numéro de la facture	X
2.	La date	X
3.	Le nom du client	X
4.	La désignation du produit	X
5.	La quantité achetée	X
6.	Le prix unitaire	X
7.	Le prix total	X
8.	Le montant total	X
9.	Le numéro de la fiche		X
10.	La désignation du produit		X
11.	L'unité de stockage		X
12.	La date du mouvement de stock		X
13.	La quantité entrée		X
14.	La quantité sortie		X
15.	Solde		X
16.	La date de réquisition			X
17.	La désignation du produit			X
18.	La quantité souhaitée du produit			X
19.	Le numéro du bon d'entrée				X
20.	La date du bon d'entrée				X
21.	La désignation du produit				X
22.	La quantité approvisionnée				X
23.	Le nom du livreur				X
24.	Le nom du récepteur				X

b. Modèle de circulation de l'information

v Scénario de vente

Le circuit d'informations se rapportant à la vente des articles se déroule actuellement de la manière suivante :

Le client désireux de se procurer un ou plusieurs produits se présente dans le magasin et recherche ses produits dans les rayons en s'informant auprès du magasinier commis à cette tâche. Ayant trouvé les articles, le client se présente alors au guichet de facturation pour faire établir la facture y afférente. Le préposé à la facturation s'assure que le produit est bel et bien disponible en stock et établit ainsi la facture. Il communique le total de la facture et le client paie. L'agent compte et vérifie l'argent lui remis, l'enregistre dans son journal, scelle la facture et en remet une copie au client. Avec cette copie, le client se présente au magasin pour le retrait des articles achetés et avant de sortir, il y a un service de sécurité qui vérifie la conformité de la marchandise livrée et donne l'autorisation de sortie.

A la fin de la journée, l'agent calcule le total des ventes journalières pour trouver le montant final. Quant au chargé de stock, il comptabilise le total des quantités vendues à partir des factures et le déduit du stock. Par rapport à la disponibilité de ce stock, le chargé de stock peut rédiger une réquisition des produits à commander. Dès que les articles commandés sont livrés au magasin à partir d'un bon d'entrée, le chargé de stock effectue la mise à jour de son stock.

Il se dégage de cette description de processus :

· La vente

· L'approvisionnement

b. Les acteurs

Un acteur est une personne physique ou morale ayant un rôle important à jouer dans le système observé^7(*). Il peut être interne ou externe au système et est représenté par une ellipse ; s'il est externe, l'ellipse sera hachurée.

En observant la description du circuit d'informations ci-dessous, nous pouvons isoler les acteurs suivants :

· Le client : acteur externe

· Le facturier : acteur interne

· Le chargé de stock (Magasinier) : acteur interne

· La sécurité : acteur interne

c. Le graphe des flux

Un flux représente un échange d'informations entre deux acteurs du système. Ainsi le graphe de flux est un schéma représentatif de la circulation d'informations entre différents acteurs du domaine d'étude constituant notre cadre de recherche.

Il peut être représenté comme suit :

1. Sécurité

4

3

Client

Magasinier

Facturier

1

2

7

8

5

6

Processus de vente

(1) Recherche d'article

(2) Renseignement

(3) Commande

(4) Facturation

(5) Paiement

(6) Livraison article

(7) Vérification

(8) Autorisation de sortie

2. Processus Approvisionnement

Chargé de stock

Dépôt

Chef d'atelier

1

2

3

4

Fig. II

(1) Bon de réquisition

(2) Bon de commande

(3) Bon d'approvisionnement

(4) Bon de réception

II.3. Description des postes de travail

II.3.1. Le facturier

Mission : établir les factures, calculer les totaux, percevoir et vérifier l'argent des clients

Personnel : 1 agent

Matériel : Matériel de bureau

Info en entrée

Désignation	Support	Fréquence	Poste d'origine
Nom du client Nom et prix du produit Quantité du produit	- Tarification des articles	N fois par jour N fois par jour	Client

Info en sortie

Désignation	Support	Fréquence	Poste de désignation
Facture	papier	N fois	Caisse

Traitements effectués

Tâches	Fréquence
Vérification de disponibilité des articles	N fois par jour
Etablissement de facture	N fois par jour
Calcul du montant total	N fois par jour
Calcul du montant final	N fois par jour
Perception des frais	N fois par jour

II.3.2. La sécurité

Mission : Vérifier les articles des clients sur présentation des copies des factures à la sortie

Personnel : 1 agent

Info en entrée

Désignation	Support	Fréquence	Poste d'origine
Facture payée	Papier	N fois par jour	Caisse

Info en sortie

Désignation	Support	Fréquence	Poste de destination
Facture livrée	Papier	N fois par jour	Client

Traitements effectués

Tâche	Fréquence
Collecte des articles d'une facture	N fois par jour
Remise des articles	N fois par jour

II.3.3. Le chargé de stock

Mission : Mettre à jour les fiches de stocks des articles

Personnel : 1 agent

Matériel : Matériel de bureau, fiche de stock, stylos, calculatrice

Info en entrée

Désignation	Support	Fréquence	Poste d'origine
Bon d'approvisionnement	Papier	N fois par mois	Dépôt
Bon d'entrée	Papier	N fois par mois	Magasin

Info en sortie

Désignation	Support	Fréquence	Poste de destination
Facture	Papier	N fois par jour	Gérant
Fiche de stock à jour	Papier	N fois par jour	Gérant
Réquisition	Papier	1 par jour	Gérant

Traitements effectués

Tache	Fréquence
Soustraire les sorties du stock	N par jour
Ajouter les entrées en stock	N par mois
Etablir les inventaires	N par an

Diagnostique de l'existant

A l'issue de cette étude du système existant, il nous revient maintenant de le critiquer afin d'en ressortir les points forts ainsi que les points à améliorer.

Points forts

· Bonne organisation de travail

· Bonne circulation de l'information

· Enregistrement des informations nécessaires au stockage des équipements

Points à améliorer

· Enregistrement manuel des informations avec possibilité d'erreur de transcription ou d'omission d'informations capitales

· Lenteur dans l'établissement des factures

· Possibilité d'erreur de calcul pour les factures

· Recherche peu aisée des informations antérieures

· Mise à jour fastidieuse des certaines fiches de stock par jour

II.3.4. Etude des solutions nouvelles

Au regard des points à améliorer relevés ci-haut, nous pensons que la solution efficace et appropriée à ces problèmes demeure la mise au point d'une base de données couplée d'une application qui permettra de gérer le mouvement des stocks au magasin.

Cette solution informatique préconisée est appelée « système de base des données » et offre une stabilité, un partage simultané de données, une cohérence, un contrôle de la redondance des données ainsi qu'un minimum de sécurité de fonctionnement. Ces fonctionnalités sont celles d'un système de gestion de bases de données auquel nous allons recourir pour créer notre structure canonique de base de données.

La solution développée à l'issue de cette étude préalable établit l'opportunité de recourir à l'automatisation des tâches et permettra, comme déjà dit dans l'introduction, de :

Ø conserver et de restituer les données de l'AFRIMA en temps voulu ;

Ø réduire les erreurs d'enregistrement ;

Ø minimiser le temps de recherche des documents.

Tableau N⁰ 1. Dictionnaire épuré des données

N^0	Propriété	signification	Type	Longueur
1	codeprod	Code du produit	AN	5
2	Desiprod	Désignation du produit	AN	15
3	Prixunit	Prix unitaire	N	Entier
4	Unité	Unité de stockage du produit	AN	10
5	Typeprod	Type de produit	AN	15
6	Stockprod	Stock du produit	N	Entier
7	Numfact	Numéro de la facture	N	4
8	Datefact	Date de la facture	D	8
9	Nomclient	Nom du client	AN	15
10	Qteach	Quantité achetée du produit	N	Entier
11	Numbon	Numéro du bon d'entrée	N	Entier
12	Datebon	Date du bon d'entrée	D	8
13	Nomlivr	Nom du livreur	AN	15
14	Qteappr	Quantité approvisionnée	N	Entier

Dépendances fonctionnelles

La notion de dépendance fonctionnelle fut introduite par CODD afin de caractériser des relations qui peuvent être décomposées sans perte d'information^8(*).

Un attribut (ou un groupe d'attribut) Y dépend fonctionnellement d'un autre attribut (un groupe d'attribut) X si la connaissance d'une valeur de X lui fait correspondre une valeur unique de Y^9(*).

Nous pouvons ainsi établir :

· La matrice de dépendances fonctionnelles à source simple

· La matrice de dépendances fonctionnelles à composées

DEUXIEME PARTIE : APPROCHE PRATIQUE

CHAPITRE III : CONCEPTION D'UNE BASE DE DONNEES

Après avoir diagnostiqué l'existant et relevé les points à améliorer du système en place, maintenant nous allons passer à la conception de l'ébauche de la solution future.

Nous allons nous servir de la méthode MERISE pour concevoir la base de données.

III .1. Le résumé sur la base de données ainsi que sur la méthode MERISE

III.1.1. Base de données

Définition et historique succincte, une base de données ; généralement notée par l'abréviation BD, est un ensemble de données structuré et organisé, généralement de grande taille, stocké sur un support informatique. Ce stockage permet l'exploitation des données :

· Ajout

· Suppression

· Modification

· Recherche d'information

III.1.2. La méthode MERISE

Merise est un acronyme signifiant Méthode d'Etude et de Réalisation Informatique par les Sous-Ensembles ou Pour les Systèmes d'Entreprises.

La méthode MERISE est issue d'une initiative de la Mission informatique du Ministère de l'industrie qui, de 1977 à 1980, réunit dans un groupe de projet des chercheurs et des praticiens des Systèmes d'Information Informatisés(SII) pour élaborer une méthode unifiée pour la conception des systèmes d'information, avec pour premier objectif de mettre cette méthode en oeuvre dans les projets de l'Administration et d'inciter les grandes entreprises à y adhérer. Ce groupe :

ü Reprend les travaux de recherche de l'équipe d'Hubert Tardieu développés depuis 1974 et qui proposaient un ensemble de modélisations pour la conception d'un système d'information ainsi que des prototypes d'outils,

ü Elabore une démarche de mise en oeuvre issue de la pratique des SII (Etude préalable, Etude détaillée, Etude Technique, Réalisation,...)

ü Propose un cadre d'organisation et de conduite de projet (maitrise d'ouvrage/maitrise d'oeuvre, principaux rôles)

ü Définit les fonctions des outils associés (interface graphique, référentiel, règles et transformations, ...)

Les travaux se concrétisent de 1979 à 1981 par des publications de fascicules du Ministère.

L'année 1983 marque la diffusion publique de la méthode MERISE ainsi que le début de son expansion au travers de la parution du livre « La méthode MERISE, Tome 1 : Principes et outils » par TARDIEU et al.

La méthode MERISE d'analyse et de conception propose une démarche articulée sur trois niveaux de préoccupation. Cet étagement en 3 niveaux a pour objectif de hiérarchiser les questions auxquelles répondre et de ne pas biaiser les réponses apportées au niveau conceptuel par des choix de technique ou d'organisation (ou de réorganisation). Nous allons étudier ces trois niveaux successivement.

III.1.3. Le niveau conceptuel

Pour simplifier l'abord de ce niveau, il est possible de le résumer à l'obtention d'un Modèle Conceptuel de Donnée (ou MCD), schéma représentant la structure du système d'information du point de vue des données, c'est -à-dire les dépendances ou relations entre les différentes données du système d'information.

En théorie, à cette étape est également constitué le Modèle conceptuel des Traitements (ou MCT), schéma représentant les traitements, en réponse aux événements à traiter (par exemple la commande d'un client dans une base de données de commande et de facturation). Pour notre application nous nous intéresserons uniquement au développement du MCD.

Le MCD repose sur les notions d'entité et de relation :

L'entité : l'entité est définie comme un objet de gestion considéré d'intérêt pour représenter l'activité à modéliser (ex : entité « pays »), chaque entité est porteuse d'une ou plusieurs propriétés simples, dites « atomiques » (ex : code, nom, capitale, population, superficie) dont l'une, unique et discriminante, est désignée comme identifiant (ex : code).

L'entité se décline en occurrences (ex :(RDC, République Démocratique du Congo, Kinshasa, 64 millions hab., 2 345 409 Km²). Par conséquent, le MCD impose que toutes les propriétés d'une entité doivent être renseignées (pas de propriété « facultative »).

Le MCD doit, de préférence, ne contenir que le coeur des informations strictement nécessaires pour réaliser les traitements conceptuels : les informations calculées (ex : montant TTC d'une facture ou déductibles (ex : densité démographique (population/superficie) ne doivent pas y figurer).

La relation : la relation est un lien sémantique entre une ou plusieurs entités. Elle peut être réflexive, de préférence binaire (ex : une usine « est implantée » dans un pays), parfois ternaire, voire de dimension supérieure. Elle peut également être porteuse d'une ou plusieurs propriétés (ex : « date d'implantation » d'une usine dans un pays)

Cette description sémantique est enrichie par la notion de cardinalité. Celle-ci indique le nombre minimum (0 ou 1) et maximum (1 ou n) de fois ou une occurrence quelconque d'une entité peut participer à une relation (ex : une usine est implantée dans un (cardinal min.) et un seul (cardinal max.) pays ; et réciproquement un pays peut faire l'objet soit d'aucune (cardinal min.) implantation d'usine soit de plusieurs (cardinal max.).

III.1.4. Le niveau organisationnel

A ce niveau de préoccupation, les modèles conceptuels sont précisés et font l'objet de choix organisationnels. Un Modèle Logique des Données (ou MLD) il reprend le contenu du MCD précédent, et précise la structure et l'organisation des données telle qu'elles pourront être implémentées. Par exemple, à ce stade, il est possible de connaitre la liste exhaustive des tables qui seront à créer dans une base de données relationnelle. Le MLD est donc la traduction exacte de l'ensemble des tables qui vont exister dans la base de données, avec l'ensemble de leurs champs, notamment ceux qui seront impliqués dans des relations.

De la même façon, plus en détail, un Modèle Logique des Traitements (ou MLT) peut être construit et fait écho au MCT. Le MLT précise les acteurs et les moyens qui seront mis en oeuvre.

La transcription d'un MCD en MLD s'effectue selon quelques règles simples qui consistent d'abord à transformer toute entité en table, avec l'identifiant comme clé primaire, puis à observer les valeurs prises par les cardinalités maximum de chaque association pour représenter celle-ci par l'ajout d'une clé étrangère dans une table existante.

III.1.5. Le niveau physique

Le niveau physique correspond à l'implémentation du MLD dans le SGBD retenu pour le développement de l'application. Il ne fait donc que traduire le MLD pour qu'il puisse être réalisé avec les outils proposés par le logiciel choisi pour le développement du projet.

C'est à ce niveau de préoccupation que peuvent être créées les tables qui serviront à recevoir les données.

III.2. Formalisation conceptuelle

La formalisation conceptuelle est la première étape de l'élaboration d'un projet informatique avec MERISE. Elle reprend une description statique et dynamique du système observé en formalisant les informations à utiliser et la structure canonique des données et des traitements à effectuer sur ces données10(*). Elle met en évidence deux modèles :

· Le modèle conceptuel des données (MCD)

· Le modèle conceptuel des traitements (MCT)

III.2.1. Modèle conceptuel des données

Le MCD repose sur le schéma entité association et est une description statique du système observé. Il représente la structure sémantique des objets que modélise ce schéma. Il est établi à travers les étapes ci-dessous :

1. Règles de gestion

· Une facture concerne un seul client

· Sur une facture, il peut y figurer un ou plusieurs produits

2. Dictionnaire des données

Le dictionnaire des données comprend les propriétés utilisées dans le modèle, leurs significations et leurs types. Il ne doit contenir que les propriétés élémentaires, donc pas de champs calculés ni concaténés. Il peut être représenté par le tableau suivant :

III.2.1.1. Dictionnaire de données

N^0	Nom données	signification	Type	Domaine de définition	Règle de gestion
1	CodeEq	Code l'équipement	NC	AN, 5
2	Designation	Désignation	NC	AN, 20
3	Qtestock	Quantité d'équipement en stock	NC	N, 10
4	QteMinstock	Quantité minimale d'équipement en stock	NC	N, 3
5	DateCreation	Date du mouvement de stock	NC	Date, 10
6	NumFact	Numéro de la facture	NC	N, 3
7	NomCl	Nom du client	NC	AN, 25
8	QteAch	Quantité achetée
9	DateFact	Date d'établissement de la facture	NC	Date, 10

III.2.1.2. Matrice de dépendances à source simple

Il s'agit d'une matrice carrée dans laquelle on représente la clé par le caractère(*) et la dépendance par le chiffre 1. Voici la matrice :

N^0	But Source	1	2	3	4	5	6	7	8	9
1	codeEq	*
2	Designation	1
3	Qtestock	1
4	QteMinstock	1
5	dateCreation	1
6	Numfact						*
7	NomCl						1
8	Datefact						1
9	QteAch						1

III.2.1.3. Matrice des clés

N°	Propriétés	1	2
1	NumFact	*
2	CodEq	1

III.2.1.4. Structure d'accès théoriques

NumFact

- NomCl

- DateFact

- QteAch

CodeEq

- Designation

- QteStock

- QteMinstock

- Datecreation

III.2.2. Modèle conceptuel des données

NumFact

- NomCl

- DateFact

- QteAch

-CodeEq#

CodeEq

- Designation

- QteStock

- QteMinstock

- Datecreation

Concerner

CIF

EQUIPEMENT

(1, 1)

(1, n)

FACTURE

NumFact

- NomCl

- DateFact

- QteAch

-CodeEq#

CodeEq

- Designation

- QteStock

- QteMinstock

- Datecreation

FACTURE

EQUIPEMENT

(1, 1)

(1, n)

III.2.3. Modèle Logique des Données

III.2.4Modèle Organisationnel des traitements

Ii consiste à répondre aux questions : Qui ? Où ? Quand ? Et même comment ? À partir du MCT. En fait, il représente une organisation de tous les traitements en intégrant les acteurs, les lieux, le temps et même la nature des traitements (procédure).

Le MOT appelé aussi MLT (Modèle Logique des Traitements) décrit avec précision l'organisation à mettre en place pour réaliser une, ou le cas échéant plusieurs, opérations figurant dans le MCT : C'est-à-dire qui fait quoi, où, quand, comment. A un MCT correspondent donc généralement plusieurs MOT.

1. Concepts utilisés

Pour établir le MOT, nous allons utiliser les concepts de poste (station) de travail et de procédure fonctionnelle (PF).

Un poste de travail est caractérisé par :

Un type de lieu : il représente l'ensemble des lieux où les actions d'une opération pourront s'effectuer.

Des ressources : moyens permettant de réaliser certaines actions d'une opération. Il peut s'agir essentiellement :

v Des hommes

v Des programmes

v Des machines

v Des hommes et des machines

v Des fichiers

La procédure fonctionnelle (PF) est un regroupement de phases, équivalent organisationnel des notions d'opération et d'actions conceptuelles, mais se déroulant sur une période de temps homogène et à un poste de travail

La nature d'une PF est son degré d'automatisation. Une PF est automatisée si elle comporte des traitements automatisés. Dans le cas contraire, elle est manuelle.

Le déroulement d'une PF comporte :

v L'instant où commence la PF (cet instant peut être parfaitement déterminé par une heure fixe ou encore par un intervalle de temps)

v La durée maximum d'exécution de la PF.

2. Construction du MOT

Nous allons construire notre Méthode Organisationnelle des Traitements :

Ø Le processus vente

Ø Le processus approvisionnement

a) processus vente

Temps	Phases	Nature	Poste de travail
			Lieu	Responsable	Ressources

Préposé

Demande des produits

Vérification stock

Existant

Inexistant

Produit disponible

Demande en attente

PF1

Facturation

Toujours

PF2

Facture établie

Payement

Toujours

PF3

Facture payée

Livraison

Toujours

PF4

Produit livrés

30 Sec

2 min

2 min

1 min

Interactive

Facturation

Préposé

Interactive

Facturation

-Préposé

-PC

-Imprimante

-Préposé

-PC

-Préposé

-Sceau

Manuel

Facturation

Manuel

Sécurité

Garde

Garde

 

Nous constatons que dans le processus, seules deux procédures sont automatisables : la vérification du stock et la facturation qui s'effectuent au même poste de travail (facturation).

b) Processus approvisionnement

Temps	Phases	Nature	Poste de travail
			Lieu	Responsable	Ressources

Demande en attente

Requête lancée

Toujours

PF1

Requête lancée

Etablissement bon d'entrée

Toujours

PF2

Bon d'entrée établi

Approvisionnement

Toujours

PF3

Produit disponible

5 min

1 min

X min

Manuel

Chargé de stock

Matériel de bureau

Chargé de stock

Manuel

Chargé de stock

Chargé de stock

Magasinier

 

Interactive

Chargé de stock

Chargé de Stock

-Chargé de stock

-PC

-Imprimante

 

Nous constatons que dans ce processus, une seule procédure est automatisable : l'établissement du bon d'entrée qui s'effectue au poste du gestionnaire de stock.

CHAPITRE IV : IMPLEMENTATION

Dans ce chapitre, nous allons déterminer le système de gestion de base de données (SGBD) et le langage de programmation choisis pour l'implémentation de l'application qui permet de répondre tant soit peu aux problèmes soulevé au niveau de la problématique.

Nous proposerons aussi le type de matériel qui pourra s'adapter et permettre l'application présentée de pouvoir fonctionner dans un environnement adéquat et de façon optimale.

IV.1. Présentation de SGBD Microsoft Access

IV.1.1. Définition du SGBD

Un SGBD ou Système de Gestion de Base de données sont les couches logicielles qui permettent l'interaction avec les informations enregistrées dans la base de données.

Lorsque le SGBD travaille avec une base de données ; on utilise le terme de système de gestion de base de données.

Le SGBD assure plusieurs fonctions :

· Ajout des données : un SGBD doit permettre l'ajout de données. Pour cela, il est tout d'abord nécessaire de pouvoir décrire les données avec un langage de description de données (LDD). Une fois les données décrites, on peut ajouter des valeurs qui correspondent à la description qu'on en a faite par le biais d'un langage de manipulation de données (LMD).

· Modification de données : Les données doivent être modifiables. on doit pouvoir changer la définition des données et les valeurs des données grâce au LDD et LMD respectivement.

· Recherche des données : La recherche des données est un point crucial. Il faut que le SGBD puisse restituer les données rapidement.

IV.1.2. Principe de fonctionnement d'un SGBD

Le SGBD permet de stocker et d'organiser une grande quantité d'information. Les SGBD permettent de naviguer dans les données et d'extraire (ou de mettre à jour) les informations voulues au moyen d'une requête.

Les données apparaissent comme stockées dans les tables qu'on nomme également relations.

Les entêtes de ces tables représentent les données que la base de données peut stocker. Ce modèle conduit à :

· Une grande simplicité d'usage

· Une transparence pour l'utilisation de toute réorganisation technique de base

· Une facilité de combinaison du contenu de plusieurs tables

Les tables possèdent un certain nombre d'attributs permettant de décrire un enregistrement. La non-duplication (absence de redondance) des enregistrements et assurée par le SGBD.

Dans les tables, il est possible de définir un type de clé. Une clé primaire permet d'identifier un seul enregistrement. Deux enregistrements ne peuvent donc avoir la même clé primaire.

IV.1.3. Possibilités offertes par le SGBD Microsoft Access

Lors du développement de notre projet, la question s'est posée du choix du SGBD. Il nous a semblé opportun d'opter pour un logiciel largement diffusé, possédant une notice technique importante ainsi qu'une grande communauté de développeurs, afin de pouvoir en tirés aides et conseils durant le cheminement de l'élaboration du projet.

Microsoft Access répond parfaitement à ces besoins. En effet, il possède derrière lui de nombreuses années de développement et d'améliorations, et c'est un SGBD profondément ancré, dans le milieu de l'entreprise.

De nombreux sites web d'entraide entre développeurs existent étant permis l'amélioration rapide de notre application.

IV.1.4. Création d'une base de données sous Microsoft Access

Si nous voulons créer une base de données sous Microsoft Access nous devons l'installer sur la machine pour pourvoir avoir l'accès à son environnement.

Nous allons voir ci-après comment créer une base de données dans l'environnement Microsoft Access :

· Pour commencer nous allons double-cliquer sur l'icône de Microsoft Access, nous aurons la fenêtre ci-dessous.

Cliquer de nouveau

Fig.1

· En cliquant sur Base de données Vide nous aurons la fenêtre suivante.

1. Saisissez le nom de votre base de données

2. Cliquer sur le bouton Créer

Fig.2

· En cliquant sur le bouton Créer nous aurons la possibilité de choisir l'emplacement de notre base de données sur le disque dure ainsi que son extension.

Sur se combo box nous avons la possibilité de choisir l'extension de la base de données

Fig.3

Voilà notre base de données qui vient d'être créée, nous pouvons maintenant passer à la création des différentes tables.

Fig.4

IV.1.5. Manipulation de données

Comme dit plus haut les SGBD servent d'interface entre l'utilisateur et la base de données, manipulable grâce à un langage d'accès, généralement le SQL. Microsoft Access ne déroge pas à la règle jusqu'une interface graphique nous permet de créer facilement les tables dont nous avons besoin pour stocker les données, et les requêtes qui nous servent à interroger ces tables.

La création d'une table peut s'effectuer de la manière suivante:

· L'opérateur choisit soit de décrire chaque champ de la table, sa taille, le type de données qu'il va contenir ... : c'est le mode « création ». 

Saisissez les noms des champs de la Table

A chaque champ correspond un type de données

Nous pouvons changer les propriétés d'un champ

Nous pouvons saisir les informations en rapport avec les noms des champs

Fig.5

IV.2. Présentation du langage de programmation Visual Basic Studio

Bon nombre de langages peuvent être utilisés pour réaliser une application pouvant répondre aux difficultés de gestion. Nous avons choisi pour notre part le Visual Basic Studio.

Ce choix se justifie par le fait qu'il est un langage conçu pour compléter des fonctionnalités des logiciels de l'office offert par Microsoft et qu'il est déjà intégré dans le système de Gestion des Bases des données Access pour la création des modules et d'autres fonctionnalités logicielles.

IV.2.1. Interface de Visual Basic Studio

Pour utiliser Visual Basic Studio vous devez l'installer sur la machine, après installation vous aurez un icône sur le bureau qui vous permettra de lancer le programme. En Double-cliquant dessus, nous aurons la page que nous montre la figure 6 se trouvant en dessous.

Fig.6

Fig.7 en cliquant sur OK nous aurons un projet de Visual basic démarrer

IV.2.2. Choix du matériel

A ce niveau nous proposons le minimum du matériel et du logiciel requis pour notre application, bref l'environnement dans lequel peut bien fonctionner l'application conçue à l'issue de notre travail. Nous pensons qu'un pentium II peut déjà suffire à faire tourner l'application. Mais pour plus de performance, nous préconisons un matériel aux caractéristiques ci-après :

· Um microprocesseur Pentium III 733MHZ pour un traitement rapide des données ;

· Un disque dur de 50 Giga Octets de capacité ;

· Une mémoire RAM de 256 Méga Octets ;

· Une imprimante laser pour la raison de faible cout d'exploitation ;

· Un lecteur CD ou DVD pour l'installation des programmes et périphériques ;

· Un produit office pour générer la base de données ;

· Un système d'exploitation de version Windows de 32 bits ;

· Un logiciel antivirus pour la sécurité de l'ordinateur.

IV.2.3. Estimation des couts

La mise en oeuvre de la solution préconisée dans le présent travail peut être évaluée de la manière chiffrée que voici (en dollars Américains) :

a. Matériel :

- un ordinateur de bureau  : 500 USD

- Une imprimante : 300 USD

- un stabilisateur : 100 USD

- Un onduleur : 100 USD

b. Application : 500 USD

Soit un minimum de 1500 USD (mille cinq cents dollars américains) non compris le frais d'apprentissage de l'application ainsi que ceux de son installation.

IV.2.4. Quelques interfaces de notre application

A. Au démarrage du programme nous avons cette interface

B. Pour accéder à la base de données vous devez avoir l'autorisation, vous devez détenir un numéro matricule et un mot de passe valide.

C. Est une partie de la base de données où nous enregistrons toutes les entrées des équipements.

D. Est la partie de la base de données utilisateurs où s'effectue la mise à jour des identités des utilisateurs.

E. Est la partie de la base de données où s'effectue toutes les sorties sur les équipements.

Pour effectuer une recherche vous devez saisir dans cette zone le code de l'équipement.

CONCLUSION PARTIELLE

Dans ce chapitre, nous avons décrit brièvement le processus de réalisation de notre application Gestion des équipements en spécifiant l'environnement de développement, l'implémentation de la base des données et la démarche suivie pour la réalisation. En effet, nous avons achevé l'implémentation, tout en respectant la conception élaborée. En d'autres termes, nous détenons la version finale du logiciel, installée dans notre environnement de développement. Ainsi que nous avons prévenu la plateforme sous laquelle le système sera installé dans l'environnement de l'utilisateur.

CONCLUSION GENERALE

La phase de conception du projet a duré plus que nous l'avions prévue. En effet, il nous a fallu un mois et demi pour analyser le contexte auquel s'attache notre travail, et concevoir le futur système.

Dans ce travail, il a été question d'analyser le domaine de gestion des entrées et des sorties des équipements au sein de l'AFRIMA en vue de proposer une solution informatique efficace. Pour y arriver, nous avons recouru à la méthodologie proposée par MERISE en nous appuyant sur les différents modèles conceptuels, organisationnels et opérationnels.

Nous sommes parti de la présentation de l'existant qui nous a permis de poser le diagnostic du système existant en ressortissant les points à améliorer et aussi en recueillant les besoins des utilisateurs.

Dans la phase d'analyse et de conception de la nouvelle solution informatique, nous avons modélisé notre système à l'aide du modèle logique des données comme structure de notre base de données et du modèle organisationnel des traitements.

Pour couronner notre étude, nous avons implémenté notre solution informatique en Access 2007 comme gestionnaire de base de données et avons personnalisé notre application à l'aide du Visual Basic for Applications (VBA).

Nous ne pouvons pas prétendre avoir présenté un travail complet, mais nous nous sommes néanmoins efforcé d'apporter une première solution orientée vers une base de données. En tant que chercheur scientifique, nous restons ouvert à toutes critiques et remarques susceptibles de parfaire le présent travail.

BIBLIOGRAPHIE

A. Livres

1. GARDARIN G., Bases de données, Ed. Eyrolles, Paris, 2005, P. 238

2. M.GRAWITZ et R.PINTO, Méthodes des sciences sociales, Dalloz, Paris, P. 450

3. REDOUIN P., Merise, Comprendre et pratique, Ed. Edites 1989, P. 237

B. Cours

4. BAVUEZA D., Cours de méthodes d'analyse informatique II, G3 info/upl, 2013-2014

5. KASONGA Patrick, Cours de Visual Basic for applications, G2 info/upl, 2012-2013

C. Sites web

1. http://[vb6] accès à une base de données Access en ado.htm

2. http://www.code-vb6.blogspot.com

3. http://www.commentçamarche.net/merise

4. http://www.wikipedia.org/merise

TABLE DES MATIERES

EPIGRAPHE I

DEDICACE II

AVANT-PROPOS II

INTRODUCTION GENERALE 2

1. CHOIX ET INTÉRÊT DU SUJET 2

2. PROBLÉMATIQUE 2

3. HYPOTHÈSE 2

4. MÉTHODES ET TECHNIQUES UTILISÉES 2

a. Méthodes 2

b. Techniques 2

5. DÉLIMITATION DU SUJET 2

6. SUBDIVISION DU TRAVAIL 2

PREMIERE PARTIE : APPROCHE THEORIQUE 2

CHAPITRE I : GENERALITES 2

I.1. CADRE CONCEPTUEL 2

I.2. CADRE THÉORIQUE 2

I.2.1. Historique de la méthode MERISE 2

I.2.2. La représentation schématique des systèmes de l'entreprise 2

I.2.3. Les apports de merise 2

CHAPITRE II : PRESENTATION DU CHAMP D'ETUDE ET ANALYSE DE L'EXISTANT 2

II.1. PRÉSENTATION DE L'AFRIMA 2

II.1.1. Présentation Géographique 2

II.1.2. Historique 2

II.1.2.1. Historique du groupe 2

II.1.2.2. CFAO en quelques dates clés 2

II.1.2.3. Historique du logo CFAO 2

ORGANIGRAMME DE L'AFRIMA 2

II.2. ANALYSE DE L'EXISTANT 2

II.2.1. Documents utilisés 2

II.3. DESCRIPTION DES POSTES DE TRAVAIL 2

II.3.1. Le facturier 2

II.3.2. La sécurité 2

II.3.3. Le chargé de stock 2

II.3.4. Etude des solutions nouvelles 2

DEUXIEME PARTIE : APPROCHE PRATIQUE 2

CHAPITRE III : CONCEPTION D'UNE BASE DE DONNEES 2

III .1. LE RÉSUMÉ SUR LA BASE DE DONNÉES AINSI QUE SUR LA MÉTHODE MERISE 2

III.1.1. Base de données 2

III.1.2. La méthode MERISE 2

III.1.3. Le niveau conceptuel 2

III.1.4. Le niveau organisationnel 2

III.1.5. Le niveau physique 2

III.2. FORMALISATION CONCEPTUELLE 2

III.2.1. Modèle conceptuel des données 2

III.2.1.1. Dictionnaire de données 2

III.2.1.2. Matrice de dépendances à source simple 2

III.2.1.3. Matrice des clés 2

III.2.1.4. Structure d'accès théoriques 2

III.2.2. Modèle conceptuel des données 2

III.2.3. Modèle Logique des Données 2

CHAPITRE IV : IMPLEMENTATION 2

IV.1. PRÉSENTATION DE SGBD MICROSOFT ACCESS 2

IV.1.1. Définition du SGBD 2

IV.1.2. Principe de fonctionnement d'un SGBD 2

IV.1.3. Possibilités offertes par le SGBD Microsoft Access 2

IV.1.4. Création d'une base de données sous Microsoft Access 2

IV.1.5. Manipulation de données 2

IV.2. PRÉSENTATION DU LANGAGE DE PROGRAMMATION VISUAL BASIC STUDIO 2

IV.2.1. Interface de Visual Basic Studio 2

IV.2.2. Choix du matériel 2

IV.2.3. Estimation des couts 2

IV.2.4. Quelques interfaces de notre application 2

CONCLUSION PARTIELLE 2

CONCLUSION GENERALE 2

BIBLIOGRAPHIE 2

A. LIVRES 2

B. COURS 2

C. SITES WEB 2

TABLE DES MATIERES 2

* ¹ MBUYU MUSOMBO ; Cours des méthodes et des recherches scientifiques, UNILU, 1990

* ² KANT, dictionnaire petit robert, 11eme Edition, paris 2000, p300

* ³ M.GRAWITZ et R.PINTO, méthode des sciences sociales, Dalloz, Paris, p450

* ⁴ BAVUEZ MUNSANA Daniel, cours de MAI 1, G2 Info, 2011

* ⁵ Idem

* ⁶ JEAN LUC BATISTE, MERISE GUIDE PRATIQUE, nouvelle édition, page 4

* ⁷ Professeur BAVWEZA, Cours de Méthode d'analyse informatique I, G2 info/jour UPL 2012-2013

* ⁸ www.commentçamarche.net/merise/

* ⁹ GARDARIN G., Bases de données, Ed. Eyrolles, Paris, 2005, Eyrolles, paris, 1994, p. 238.

* ¹⁰ www.wikipedia.org/Merise