Rapport de Stage

Gestion des approvisionnements
SOMMAIRE
DEDICACE…………………………………………………………………………..
I
REMERCIEMENTS………………………………………………………………….
II
SOMMAIRE………………………………………………………………………….
III
LISTE DES FIGURES………………………………………………………………..
V
LISTE DES TABLEAUX……………………………………………………………
VI
AVANT PROPOS……………………………………………………………………...
VII
INTRODUCTION……………………………………………………………………..
1
PROBLEMATIQUE………………………………………………………………….
2
PARTIE 1 : GENERALITES………………………………………………………
3
CHAPITRE 1 : PRESENTATION DE LA SOGB………………………………..
4
I - L’ENTREPRISE ET SES ACTIVITES.........................................................................
LICENCE INFORMATIQUE DE GESTION 3ème ANNEE

4
I-1-Historique....................................................................................................................
4
I-2-Situation géographique……………………………...................................................
4
I-3-Activités......................................................................................................................
5
II-CONSTITUTION ………………………..............................................................
5
II-1- ROLE DES DIFFERENTES DIRECTIONS
II-2- ORGANIGRAMME DE LA S.O.G.B ……………………………………… 5
III-INFRASTRUCTURES INFORMATIQUES ………………............................... 6
III.1- Environnement matériel et Logiciel......................................................................
6
III-2- Présentation du réseau informatique....................................................................
CHAPITRE2 : PRESENTATION ET CHOIX DE LA METHODE…………
9
D’ANALYSE
I- OBJECTIFS..................................................................................................................
9
I-1- Objectifs généraux....................................................................................................
9
I-2- Objectifs spécifiques...................................…..........................................................
9
II- CHOIX DE LA METHODE D’ANALYSE……………...........................................
9
II-1- présentation des méthodes d’analyse ……………………………………………..
9
II-2- Méthode retenue………………………………………………………………...

14
2-2- La séparation des données et des traitements……………………………… 14
2-3- Une approche par niveau…..................................................................................... 14
PARTIE2 : MODELISATION DU SYSTEME D’INFORMATION …………………...15
CHAPITRE3 : CONCEPTION DU SYSTEME D’INFORMATION ……………........16
ORGANISATIONNEL
I-Etude de l’existant………………………………...………
16
I-1- DESCRIPTION DES ACTIVITES ACTUELLES……………………………………………. 16
II - DIAGNOSTIC DE L’EXISTANT
II-1- LE RECENSEMENT DES PROBLEMES
II-2- ANALYSE DES PROBLEMES

III- SOLUTIONS PROPOSEES
IV- CONSTRUCTION DU MODEL CONCEPTUEL DES TRAITEMENTS (MCT)
V- CONSTRUCTION DU MODELE CONCEPTUEL DES DONNEES (MCD)
PARTIE3 : ETUDE TECHNIQUE ET REALISATION………………………………..67
CHAPITRE5 : ETUDE TECHNIQUE……………………………………………..........68
I- PRESENTATION GENERALE DE L’APPLICATION………..................................68
I-1- Choix de l’architecture du système.............................................................................68
I-2- Choix du système d’exploitation…………….............................................................69
II- CHOIX DES OUTILS DE REALISATION…………………………………………69
II-1- Choix du système de gestion de base de données (SGBD)………………………...69
II-2- Choix de l’environnement de développement………………………………………70
CHAPITRE6 : REALISATION………………..................................................................71
I- PRESENTATION DE QUELQUES ECRANS DE L’APPLICATION………............71
I-1-Présentation de la Page d’accueil du logiciel ………………………………………...71
I-2- Page d’authentification ….……………………………………………………………72
I-3- Enregistrement d’une parcelle………………………………………………………..72
II-METHODE DE SECURITE……………………………………………………………72
II-1- Accès à l’application………………………………………………………………...72
II-2-Protection antivirus…………………………………………………………………...72
III-ETUDE DE L’IMPACT DU PROJET ………………………………………………..73
II-1- Formation des utilisateurs……………………………………………………………73
IV- COUT DU PROJET…………………………………………………………………...73
CONCLUSION……………………………………………………………………..........74
BIBLIOGRAPHIE……………………………………………………………………….75
ANNEXES………………………………………………………………………………...76

DEDICACE
Ce dit mémoire est dédicacé à mes parents, toute ma famille et amis qui me soutiennent de
loin comme de près dans le courant de ma vie

REMERCIMENT
Nous adressons nos vifs remerciements au personnel de la SOGB, qui par son
assistance et sa disponibilité a contribué à l'aboutissement de ce mémoire.
Nous remercions particulièrement:
 M. Olivier MARTIN, le Directeur général de la SOGB ;
 M.Jean READ, le Directeur financier et de la comptabilité ;
 M.YAO André, le Chef du département informatique ;
 M.DOSSO Youssouf, le Chef de département de la Comptabilité analytique ;
Tout le personnel du département Informatique à savoir
M.KOIDIO Jean Claude (maitre de stage) ;

M.BROU Isidore ;
M. GAGNIE Justin ;
M.TAPE Sylvanus.
M.KOUAME Aimé ;
Ainsi que tout le corps professoral de l’institut cerco cote d’ivoire, particulièrement
 M. Charles eric N’Zebo (directeur de mémoire)
Et tous ceux qui de près ou de loin ont participé à l’élaboration de ce mémoire.

AVANT-PROPOS

INTRODUCTION
Le monde du travail actuel tend à migrer vers l'automatisation des tâches par le
biais de l'informatisation. Le besoin de facilité, efficacité et fiabilité dans la résolution des
problèmes et dans la réalisation des tâches est devenu énorme et pousse les entrepreneurs à
doter de leurs entreprises des systèmes de gestion automatisés.
Ainsi, consciente des possibilités offertes par cet outil pour une gestion efficace de ses
activités agricoles, la SOGB a décidé de profiter de cette avancée technologique en
informatisant ses dites activités. C’est dans ce cadre que le thème : «Conception et
Réalisation d’une application GESTION DES APPROVISIONNEMENTS » nous a été
confié.
L’objet de ce mémoire est donc de présenter le fruit de notre travail et cela
s’articulera autour de trois axes. Dans la première partie intitulée ‘généralités‘, nous
présenterons la SOGB et par la suite nous choisirons la méthode d’analyse informatique
adaptée à notre travail. La deuxième partie, ‘modélisation du système d’informations’, a
pour objet de présenter les différentes modélisations du futur système à l’aide de la méthode
d’analyse et de conception choisie. La troisième partie, qui a pour titre ‘étude technique et
réalisation’, expose les choix techniques opérés. Elle fait également une description de
l’application obtenue par la présentation de quelques écrans et indique le coût de réalisation
du projet.

PREMIERE
PARTIE
GENERALITE

CHAPITRE 1 : PRESENTATION DE LA SOGB
I - L’ENTREPRISE ET SES ACTIVITES

I-1- Historique
Depuis son accession en 1960 à l’indépendance, la Côte d’Ivoire a poursuivi des
stratégies de croissance économique fondées sur le développement de l’Agriculture.
L’avènement de l’hévéaculture et son introduction dans le cadre d’un programme de
diversification des cultures a constitué un maillon essentiel de cette stratégie. Le but étant
d’accroître la stabilité des recettes provenant des exportations.
Le gouvernement a créé, pour mener à bien ce programme, en association avec la
Compagnie Générale des établissements Michelin (CGEM), en 1970, la SO.G.B sous les
appellations SODEHEVEA et SOCATCI.
La SOGB fut créée le 22 mars 1979 par les décrets 79.223 du 22/03/79 et 79.289 du 17/04/79
et inscrite au registre de commerce sous le numéro 1622 du tribunal de Sassandra.
A la suite d’une augmentation de son capital en avril 1984 la SOGB devient
propriétaire de la plantation de GRAND BEREBY et de toutes ses infrastructures. Le capital
était alors partagé entre l’Etat (95%) et Michelin (5%).
En 1995, la SOGB dont le capital social s’élevait alors à 21.601.840.000 F CFA a été
privatisée. L’Etat n’en a conservé que 15%. En 2006, l’Etat se désengage entièrement en
cédant ses parts. La nouvelle composition de l’actionnariat de la SOGB se présente donc
comme suit :
 Béréby finance 15.803.970.469 soit 73,16% du capital.
 Les autres actionnaires: 5.797.870.000 soit 26,84% du capital social.
A la suite d’une augmentation de capital en avril 1984, la SO.G.B est devenue

propriétaire de la plantation de Grand-Béréby et de toutes ses infrastructures. Le capital
était alors partagé entre l’Etat (95%) et Michelin (5%).
Le partage est illustré pas le schéma suivant :
Béréby finanace 65%
BVA 20%
Etat ivoirien 15%

La SOGB gère différentes infrastructures sociales dont 19 villages appelés divisions,

un hôpital moderne, des écoles et des dispensaires dans chaque village. La population de la
SOGB est estimée à environ 30.000 habitants et bénéficie de tout le confort d’une ville
moderne : électricité, eau courante, habitats modernes, dispensaires, terrains de jeu, écoles
primaires, etc...
I-2-Situation géographique
La SOGB est localisée au sud-ouest de la Côte d’Ivoire, dans la région du Bas-

Sassandra, plus précisément dans le département de Grand-Béréby. Elle est située à environ
soixante kilomètres de San-Pedro et à 25 kilomètres de Grand-Béréby.
I-3- Activités
I-3-1 Activité d’Hévéa
La concession totale du complexe agro-industriel de la SOGB s’étend sur environ
34.712 hectares dont 16.500 hectares plantés en hévéa.
L’activité principale de la SOGB demeure la création et la gestion des plantations d’hévéa
ainsi que la fabrication et la commercialisation du caoutchouc naturel. En plus de ses propres
plantations qu’elle gère, la SOGB encadre plus de 11.000 planteurs villageois de Grand-
Béréby et de Tabou grâce aux financements accordés par des organismes internationaux de
projets de développement tels que le Fonds Ivoiro-Suisse pour le Développement Economique
et sociale (FISDES), et la Compagnie Allemande d’Investissement (DEG).
La SOGB intervient également dans le conseil agricole et l’encadrement des planteurs
d’hévéa dans les régions suivantes : Grabo, Soubré, Méagui, Touhi et Guiglo, localités qui
sont toutes situées au-delà de 80 kilomètres de ses installations.
I-3-2- Activité du Palmier à huile
Afin de prévenir les fluctuations des cours mondiaux, la SOGB a opté pour la
diversification de ses activités. C’est ainsi qu’en 1998 un vaste projet de plantations de
palmier à huile a été mis en place. Les bas-fonds, surfaces inadaptées à la pratique de
l’hévéaculture ont été exploités pour la création de palmeraies dont la superficie totale est de
6.500 hectares.
Pour la réalisation de ce vaste projet, la SOGB a investi plus d’une vingtaine de
milliards de francs CFA aussi bien pour la création, l’entretien et l’exploitation des
plantations, que pour la construction de l’huilerie en vue de la transformation de sa production
de graine.
Aujourd’hui, la SO.G.B se lance dans un vaste projet de ses activités. Ce projet prévoit le
planting de 500 ha de palmier à huile et 2500 ha d’hévéa par an.
II- CONSTITUTION
1- ROLE DES DIFFERENTES DIRECTIONS

Pour assurer un meilleur suivi des activités de l’entreprise, la SO.G.B est subdivisée en
plusieurs directions :
 DIRECTION DE L’ADMINISTRATION ET DES RESSOURCES HUMAINES (DARH)

Elle s’occupe de l’administration et des ressources humaines.

 DIRECTION FINANCIERE ET COMPTABLE (DFC)
Elle est chargée du contrôle et du financement des activités de l’entreprise.
 DIRECTION DE LA LOGISTIQUE ET D’INVESTISSEMENT (DLI)
Elle intervient dans tous les secteurs d’activités techniques du complexe à savoir :
l’usine, l’entretien et la gestion des bâtiments, l’entretien et la gestion du parc automobiles
et engins de la société.
 DIRECTION DE L’EXPLOITATION AGRICOLE (DEA)
Elle est chargée de l’exploitation de toutes les plantations plantées en hévéa.
 DIRECTION DE L’AUDIT ET DE L’ORGANISATION (DAO)
Elle a pour rôle le contrôle, l’audit et l’organisation de toutes les activités agricoles et
industrielles du complexe.
 DIRECTION DES TECHNIQUES AGRICOLES DE L’AMENAGEMENT ET DE
L’ORGANISATION (DTA AO)
Elle est chargée de la production du matériel végétal, et de la recherche du
développement. Elle est équipée d’un laboratoire d’analyse agronomique.
 DIRECTION DE L’AMÉNAGEMENT ET DES TRAVAUX AGRICOLES (DATA)
Elle intervient dans tous les travaux d’aménagement agricole du complexe ; à savoir les
travaux d’aménagement de planting et d’entretien des plantations, les cultures annuelles
telles que le café, le riz et l’élevage des bovins.
 DIRECTION DES PLANTATIONS VILLAGEOISES (DPV)
Elle joue un rôle fondamental dans le cadre du projet pour le développement
Hévéïcole car elle développe les programmes des plantations villageoises conformément à la
stratégie des projets hévéïcoles et favorise la privatisation de ce secteur. On a ainsi les projets
DEG, FISDES, PVH.
 DIRECTION DES RELATIONS EXTERIEURES (DRE)

Située à Abidjan, elle a pour mission la gestion des relations avec les partenaires de la
SO.G.B dont la grande partie se trouve à Abidjan et à l’extérieur du pays.
2-ORGANIGRAMME DE LA SO.G.B
DIRECTEUR
GENERAL
DTA DPV DLI DARH DRE DAO DFC DAT DEA
DEP
INFO DEPA

III- INFRASTRUCTURES INFORMATIQUES

III.1- Environnement matériel et logiciel
La SOGB possède quatre serveurs installés dans une salle appelée « salle serveur». Ce
sont :
 SOGBDATA : serveur qui sert de contrôleur de domaine ;
 SOGB 3 : serveur de messagerie, d’impression et d’application ;
 SRV2003 : serveur de Base de Données et de fichier ;
 SRV2008 : serveur de Base de Données et de fichier ;
La SOGB dispose également de deux cent dix (210) machines pour les utilisateurs
dont cent quatre-vingt-dix-huit (198) sur le réseau et douze (12) en division, quatre-vingt-
douze (92) imprimantes qui sont repartis dans les différents services et les divisions.
 Les systèmes d’exploitation
Les systèmes d’exploitation utilisés pour les micro-ordinateurs sont Windows XP

professionnel (Service Pack 2, Service Pack 3) et Windows 7 Professionnel .Quant aux
serveurs ils utilisent Windows server 2003, Windows 2008.
 Les logiciels d’application
La SOGB possède un antivirus nommé NOD32 qui est installé sur tous les micro-
ordinateurs et sur un serveur où il est mis à jour automatiquement grâce à l’accès à internet.Il
existe vingt-sept (27) applications dans l’entreprise pour la gestion des activités telles que :
 GESFARC (Gestion de la facturation des règlements et des caisses) ;
 HERMES (Gestion des projets de commande) ;
 GATP (Gestion Administrative et Technique des Plantations) ;
 MISPALMIER (Gestion Administrative et Technique des Plantations)
 MISDPE (Gestion Administrative et Technique des Plantations)
 Suite bureautique: Microsoft Office etc.
DIRECTIONS MATERIELS
Direction Finance et Comptabilité (DFC)  72 Ordinateurs HP
Ram : 2 Go
Disque dur : 457 Go
Processeur : Intel Pentium (R) dual core 2.80 GHz
 6 Imprimantes HP Laser ND
 1 Switch Catalyst 2960 series a 24 ports
 2 Switch Dlinq 100 Mb à 12 ports RJ45
Direction Générale (DG)  2 Ordinateurs HP
Ram : 2 Go
Disque dur : 150 Go
 1 Imprimante HP Laser ND

La Direction de l’Aménagement et des Travaux  11 Ordinateurs HP

Agricoles (DATA) Ram : 2 Go
Disque dur : 150 Go
Processeur : Intel Pentium ® dual core 2.80 GHz
Direction de l’Exploitation Agricole (DEA)  22 Ordinateurs HP
Ram : 2 Go
Disque dur : 150 Go
Processeur : Intel Pentium ® dual core 2.80 GHz
Les divisions  12 Ordinateurs HP Compaq
Ram : 2 Go
Disque dur : 150 Go
 9 Imprimantes HP Laser Jet P1566
 9 Switch Dlinq 100 Mb à 8 ports RJ 45
Tableau1 : Infrastructures matérielles des services concernés par l’étude
III-2- Présentation du réseau informatique

Le réseau informatique de la SOGB est un réseau de type Fast Ethernet (Ethernet
tournant à 100 Mbits/s). Il est essentiellement constitué de la fibre optique et de la paire
torsadée (câble RJ45). Ce réseau est articulé autour d’une topologie en étoile. Elle dispose
aussi d’un wifi établit par l’entreprise aviso.
CHAPITRE2 : PRESENTATION ET CHOIX DE LA METHODE D’ANALYSE

I- OBJECTIFS
I-1- Objectifs généraux
Le projet soumis à notre étude a pour objectifs :
 La conception d’une base de données intégrant les activités agricoles de la SOGB
 réalisation d’une application de gestion des approvisionnements de la SOGB;
 L’implémentation de ce système dans un environnement client/serveur.
I-2- Objectifs spécifiques
Les objectifs à atteindre pour la SOGB sont de plusieurs ordres. Il s’agit de fournir les
services suivants :
 Possibilité de gérer de manière efficace les demandes d’approvisionnement et le stock
disponible en client/serveur;

 Possibilité de retracer les demandes de commande et connaitre les différentes

commandes effectuées durant le mois ou l’année;
 Possibilité de suivre l’évolution d’une parcelle depuis son planting jusqu’à
l’exploitation ;
 Possibilité de faire des statistiques mensuelles et annuelles de passation de commande
pour chaque département ;
II-CHOIX DE LA METHODE D’ANALYSE
II-1- présentation des méthodes d’analyse
Une méthode d'analyse informatique a pour objectif de permettre de formaliser les

étapes préliminaires du développement d'un système afin de rendre ce développement plus
fidèle aux besoins du client. Pour ce faire, on part d'un énoncé informel, ainsi que de l'analyse
de l'existant éventuel (c'est-à-dire la manière dont les processus à traiter par le système se
déroulent actuellement chez le client).
De nos jours, En l’informatique on distingue trois (3) approches méthodiques de
construction de système informatique qui sont : les méthodes systémiques, les méthodes
cartésiennes et les méthodes objets.
II-1-1- méthodes Cartésiens
Les méthodes cartésiennes analytiques sont issues de la programmation structurée. Elles

décomposent hiérarchiquement un problème pour en maîtriser la complexité.
Ses points faibles sont :
 Effort sur les objectifs fonctionnels au détriment de données ;
 Règles de décomposition non explicites ;
Ses points forts sont :

 Simplicité et bon sens ;
 Adéquation à capturer les besoins des utilisateurs ;
 Capacité à produire des solutions à plusieurs niveaux d’abstractions ;
Comme exemple, nous avons les méthodes telle que : Yourdon, SADT, Jackson…etc.
II-1-2- Méthodes systémiques

Elles sont inspirées de la théorie systémique des organisations, ces méthodes
considèrent les systèmes d’information comme un objet complexe actif dont il faut décrire la

structure (architecture) et les objectifs fonctionnels (fonctions). Elles préconisent la

modélisation des données et des traitements.
Leurs points forts sont :
 Grande cohérence des données
 Niveau d’abstraction bien défini: Niveau externe, niveau conceptuel, niveau interne.
Leurinconvénient est la faiblesse de la modélisation des traitements, mélange des contraintes

et des contrôles.
Comme exemple, nous avons les méthodes telles que Merise, AXIAL.
II-1-3- Méthodes objets

L’approche orientée objet est une évolution de l’approche systémique vers uneplus
grande cohérence entre les données et leurs comportements. Ici le système d’information est
vu comme un ensemble d’objets avec leurs opérations. Ces objets sont considérés de façon
statiques (ce que le système est : données) et dynamique (ce que le système fait : fonctions).
Notons aussi qu’avec la méthode orientée objet, une évolution fonctionnelle est possible sans
remise en cause de la structure statique du logiciel. A titre d’exemple nous pouvons citer
UP/UML. Les avantages et les inconvénients de l’approche objet sont :Leurs points forts sont
Avantages
Ce sont :
 Capacité à modéliser des objets complexes
 Réduction des distorsions entre système informatique et monde réel
 Intégration des traitements aux données
 Encapsulation
Inconvénients
 objet difficile à appréhender

 Aspect fonctionnel mal représenté
Comme exemple, nous avons : OMT (Object Modeling Technique).
 MERISE
MERISE, Méthode d’Etude et de Réalisation Informatique par Sous-Ensembles, est

une méthode qui propose l’analyse des projets informatiques selon trois cycles intimement
liés. Le cycle de vie qui présente les étapes à suivre, le cycle d’abstraction qui indique le
raisonnement à faire et le cycle de décision qui propose les étapes et le processus de
validation des étapes et du raisonnement.
MERISE est une démarche qui permet d’assurer le cycle de vie d’une application en six
étapes :
 l’étude préalable,
 l’étude détaillée,
 l’étude technique,

 la réalisation,
 la mise en œuvre,
 la maintenance.
En d’autres termes, la méthode MERISE décrit le système d’information en fonction de trois

niveaux d’abstractions que sont :
 le niveau conceptuel où la question posée est « quoi faire ? »,
 le niveau organisationnel ou logique : la question est « qui fait, quand et où ? »,
 le niveau physique : la question posée est « comment faire ? ».
Ces trois niveaux d’abstraction sont élaborés selon deux vues complémentaires que sont les
données et les traitements.
Une validation permet de vérifier que tous les traitements nécessaires à l’acquisition des
données sont prévus et que toutes les données utiles à la réalisation des traitements sont
présentes dans l’objectif d’assurer une cohérence entre les données et les traitements.
MERISE, comme toutes autres méthodes elle a des avantages et des inconvénients.
Les avantages :
- méthode d’analyse avec des étapes bien définies,
- distinction entre les données et les traitements pendant la modélisation mais avec une
interaction profonde du fait de la validation des données par les traitements et vice
versa.
Les inconvénients :
- méthode non adaptée à la modélisation orienté objet,
- méthode moins adaptée aux grands projets nécessitant des résolutions partielles et
évolutives.
UML et le Processus Unifié
UML (UnifiedModelingLangage), langage de modélisation unifié en français, est né

de la fusion des trois méthodes qui ont le plus influencé la modélisation objet au milieu des
années 90. Ces méthodes sont OMT (Object Modeling Technique) de James Rumbaugh,
BOOCH ou OOD (Object Oriented Design) de GradyBooch et OOSE (Object Oriented
Software Engineering) d’Ivar Jacobson.
UML est un langage graphique qui permet de représenter les divers aspects du système
d’information. Il se décompose en plusieurs sous-ensembles :
– Les vues sont les observables du système. Elles décrivent le système d'un point de vue
donné, qui peut être organisationnel, dynamique, temporel, architectural,
géographique, logique. En combinant toutes ces vues, il est possible de définir (ou
retrouver) le système complet ;

– Les diagrammes sont des éléments graphiques. Ceux-ci décrivent le contenu des vues,
qui sont des notions abstraites;
– Les modèles d'élément sont les briques des diagrammes UML. Ces modèles sont
utilisés dans plusieurs types de diagramme. Exemples d'élément : cas d'utilisation,
classe, association.
UML 1.0 apparut en 1995 nous proposait neuf diagrammes. Depuis UML 2.0 apparut en
2003, nous sommes à treize diagrammes qui sont :
– Les diagrammes structurels ou statiques:
o Le diagramme de classes représente les classes intervenant dans le système.

Une classe est un ensemble d’individus ayant les mêmes caractéristiques et les
mêmes comportements;
o Le diagramme d'objets (objet : instance d’une classe) sert à représenter les

instances de classes utilisées dans le système ;
o Le diagramme de composants permet de montrer les composants du système

d'un point de vue physique, tels qu'ils sont mis en œuvre (fichiers,
bibliothèques, bases de données) ;
o Le diagramme de déploiement sert à représenter les éléments matériels

(ordinateurs, périphériques, réseaux, systèmes de stockage) et la manière dont
les composants du système sont répartis sur ces éléments matériels et
interagissent entre eux ;
o Le diagramme des paquetages : un paquetage étant un conteneur logique

permettant de regrouper et d'organiser les éléments dans le modèle UML, le
diagramme de paquetage sert à représenter les dépendances entre paquetages,
c’est-à-dire les dépendances entre ensembles de définitions ;
o Le diagramme de structure composite permet de décrire sous forme de boîte

blanche les relations entre composants d'une classe.
o Les diagrammes comportementaux :
o Le diagramme des cas d'utilisation permet de représenter les besoins des

utilisateurs par rapport au système. Il permet d’indiquer toutes les
fonctionnalités que doit fournir le système ;
o Le diagramme d’états-transitions permet de décrire sous forme de machine à
états finis le comportement du système ou de ses composants ;
o Le diagramme d'activités permet de décrire sous forme de flux ou
d'enchaînement d'activités le comportement du système
o Les diagrammes d’interactions

o Le diagramme de séquence permet la représentation séquentielle du

déroulement des traitements et des interactions entre les éléments du système
et/ou de ses acteurs ;
o Le diagramme de communication permet la représentation simplifiée d'un
diagramme de séquence se concentrant sur les échanges de messages entre les
objets ;
o le diagramme global d'interaction permet de décrire les enchaînements
possibles entre les scénarios préalablement identifiés sous forme de
diagrammes de séquences (variante du diagramme d'activité) ;
o le diagramme de temps permet de décrire les variations d'une donnée au cours
du temps.
Le Processus Unifié(PU) est une démarche de développement logiciel itérative, centrée sur
l’architecture, pilotée par les cas d’utilisation et orientée sur la diminution des risques.
L’objectif du PU est de maîtriser la complexité des projets informatiques en diminuant les
risques. Le PU est un ensemble de principes génériques adaptés en fonction des spécificités
des projets.
Le PU gère le processus de développement par deux axes :

– L’axe vertical représente les principaux enchainements d’activités, qui regroupent les
activités selon leur nature. Cette dimension rend compte de l’aspect statique qui
s’exprime en termes de composants, de processus, d’activités, d’enchainements et de
travailleurs ;
– L’axe horizontal représente le temps et montre le déroulement du cycle de vie du
processus. Cette dimension rend compte de l’aspect dynamique du processus qui
s’exprime en termes de cycles, de phases, d’itérations, de jalons.
II-2- Méthode retenue
La modélisation du système futur s’appuyant sur une approche systémique, la méthode

MERISE est donc notre choix. Mis à part ce critère crucial d’autres éléments justifient ce
choix. En effet, MERISE est visiblement beaucoup plus accessible qu’UML avec des modèles
plus rapidement assimilables. Aussi en matière de projet informatique, c’est une méthode
permettant une bonne conduite de projet et une bonne représentation de l’existant.
2.2. La séparation des données et des traitements
Pour les concepteurs de la méthode, la séparation des données représente l’aspect stable,
statique du système d’information et les traitements représentent son aspect dynamique.
2.3. Une approche par niveau
Lors de la conception du système d’information, nous serons amenés à considérer trois

(3) niveaux d’abstraction :

 Le niveau conceptuel ;
 Le niveau organisationnel ;
 Le niveau opérationnel.
Au niveau conceptuel, il s’agit de traduire les problèmes de gestion, de répondre à la
question Quoi ? (Que faire avec quelles données) sans préjuger de l’organisation et des
moyens à mettre en œuvre. Ce niveau décrit à travers des règles de gestion les objectifs et les
contraintes de l’entreprise.
Au niveau organisationnel, on se pose les questions Qui ? Quand ? Et Où ?, c’est-à-dire
qu’il faudra définir les postes de travail, la chronologie des opérations et le niveau
d’automatisation des tâches. L’objectif, ici, est de définir l’organisation qu’il est souhaitable
de mettre en place pour atteindre les objectifs visés.
Au niveau opérationnel ou physique, les choix techniques sont intégrés.
Tant en ce qui concerne les données que les traitements, il faut répondre à la question
COMMENT ? : Quel matériel, logiciel, programme mettre en œuvre ?
Ces trois (3) niveaux seront modélisés différemment pour les données et les traitements. Le
tableau suivant indique les modèles auxquels on aboutit dans la représentation du système
d’information :
NIVEAUX DONNEES TRAITEMENTS CHOIX QUESTION

Modèle Modèle Conceptuel Quoi ?
CONCEPTUEL Conceptuel des des Traitements De gestion
Données (MCD) (MCT)
Modèle Logique Modèle Qui ? Quand ?
ORGANISATIONNEL des Données Organisationnel des D’organisation Où ?
(MLD) Traitements (MOT)
Modèle Physique Modèle Techniques Comment ?
OPERATIONNEL des Données Opérationnel des
(MPD) Traitements
(MOpT)

DEUXIEME
PARTIE
MODELISATION
DU SYSTEME
D’INFORMATION

CHAPITRE3 : CONCEPTION DU SYSTEME D’INFORMATION

ORGANISATIONNEL
I- ETUDE DE L’EXISTANT
1- DESCRIPTION DES ACTIVITES ACTUELLES
Pour son fonctionnement, le service achat a besoin d’un élément propulseur qu’est le
P.J.C (projet de commande). Pour se faire, le P.J.C doit remplir certaines conditions. Pour
connaître donc le fonctionnement de ce service, nous essayerons de suivre le circuit de ce
projet exigé par le personnel de ce service dans la mesure où ce dit fonctionnement en dépend.
1.1. La conception du projet de commande (P.J.C)
Le P.J.C ou Projet de commande, est produit par un service demandeur ou utilisateur

de la société pour exprimer un besoin.
Avant que ce projet n’arrive au service achat, il suit des étapes successives à savoir : M.C
(magasin central), D.L.I (direction de la logistique et de l’ingénierie), D.F.C (direction
financière et comptable) et D.G (direction générale) pour signature puis au service achat pour
son traitement. Avant traitement, le responsable du service achat confirme ou infirme sa
fiabilité en insistant sur les éléments suivants :
- le nom et le service de l’utilisateur ayant établi le P.J.C
- la signature du responsable du service de l’émetteur
- les signatures des responsables du : M.C ; D.L.I ; D.F.C ; D.G
- le numéro du PJC et les numéros des codes articles donnés au magasin central.
En cas d’anomalie, il est retourné au service qui fait défaut. Dans le cas contraire il est remis à
un acheteur pour l’enregistrement du P.J.C.
La numérotation des PJC

Cette numérotation est de type alphanumérique. Elle permet d’identifier les différents
projets des commandes. Pour illustrer cela, nous prendrons l’exemple du n° N11/124.
Le N indicatif du service ayant établi le projet ; le nombre onze (11) indique le mois de
l’année en cours (onzième mois de l’année en cours) et le nombre 124 le numéro d’ordre du
dossier.
Cependant lorsque, le numéro du P.J.C est précédé d’une lettre par exemple R11/124 T cela
signifie qu’un service R fait la demande pour le compte d’un autre service T.
Le planeur saisi les différents renseignements constituant le P.J.C au micro-ordinateur,
dans le fichier intitulé « suivi PJC ». Ainsi le projet sera suivi suivant les différentes étapes
qu’il subira c’est à dire : en cotation ; en signature ; livré en partie ou soldé… puis lui attribut
un numéro d’ordre de série, la date d’enregistrement et le classe.

1.2. La Demande de prix
Avant l’établissement des demandes de cotations par le planeur, les P.J.C saisis, seront
remis à l’acheteur pour rechercher les fournisseurs potentiels. Ces demandes seront alors
faxées aux différents fournisseurs retenus après le visa du chef de service. Lorsque les
cotations sont reçues, elles sont jointes à leurs P.J.C et remis au responsable de service pour le
choix du fournisseur. Il faut noter que ce choix est opéré après une confrontation des
différentes cotations sur les délais de livraison, et les remises, favorables à l’entreprise. Ainsi
l’on envisagera la passation des commandes.
1.3. La passation des commandes

Pour la passation des commandes, il est important de noter que la secrétaire établit le
bon de commande en faisant quatre (4) exemplaires. Ces bons comportent :
- le numéro interne donner par le planeur C2/XXX… ; C3/YYY… (XXX=numéro d’ordre)
- un numéro de commande en fonction des années, A04 =année 2004,
A05 =année 2005 ainsi de suite suivi du numéro d’ordre.
- le délai de livraison du fournisseur ou celui proposé par l’acheteur.
- la date de réception du P.J.C.
- les désignations des articles dont la saisie est facilitée par les numéros de code article.
- le numéro du P.J.C, les remises, les quantités, les prix unitaires et les prix T.T.C.
Ces commandes sont ensuite transmises pour signature successivement au bureau du chef de
service achat, à celui de l’utilisateur, à celui du D.F.C puis au D.G. De retour par voie de
transmission au service achat, elles sont dépouillées. Ainsi l’original sera faxée ou
communiquée au fournisseur par téléphone puis envoyer lors desenlèvements, une première
copie reste au service achat chez le planeur concerné pour le suivi des livraisons, la
seconde chez l’agent du magasin central pour des contrôles lors des livraisons et la dernière
copie au service de l’émetteur.
Ainsi, le projet de commande permet d’acquérir des articles nécessaires au bon
fonctionnement des activités d’un service. Il doit donc être traité rapidement car l’article est
souvent indispensable pour la poursuite d’une activité. Pour pallier à ce problème, la direction
financière et comptable, en collaboration avec le département informatique a décidé
d’informatiser ce processus. C’est dans ce cadre qu’il nous a été confié, dans le cadre de notre
stage de fin de cycle ce projet intitulé « GESTION DES APPROVISIONNEMENTS ».
Tenterons nous donc au terme de notre stage de mettre en place cette application afin
d’apporter notre contribution à l’informatisation de ce système.
II - DIAGNOSTIC DE L’EXISTANT

L’étude du système existant constitue une base de référence pour le développement du

système futur. Il est donc indispensable d’en distinguer les insuffisances (les points
faibles), et essayer d’utiliser au mieux les points forts, de ne pas les amoindrir dans la
solution nouvelle.
1)- LE RECENSEMENT DES PROBLEMES
Compte - rendu d’entretiens

Plusieurs personnes ont été rencontrées. Les points essentiels soulevés lors de ces
entretiens sont condensés ci-après :
 Agent du Magasin Central

« On ne connaît pas exactement les projets de commande qu’on traite. De plus, compte tenu
des opérations manuelles à effectuer, le travail est lent et les demandes s’accumulent. Des
erreurs sur les codes des pièces entraînent des retours ou des retentions inutiles. Pour les
corrections des codes, il faut parcourir une longue liste de code si bien que les erreurs sont
très fréquentes. Les fiches et registres sont conservés pendant 6 ans (et parfois plus) dans des
cartons pour des mesures de sécurité. En cas d’ambiguïté sur un projet de commande on se
réfère à ces registres. Si tout cela était informatisé, on éviterait beaucoup de papiers et
beaucoup d’erreurs. »
 Représentant du Service Achat

« Nous traitons plusieurs projets de commande par jour et toutes les opérations sont
manuelles. Pour élaborer un état, il faut consulter les enregistrements concernés de sorte à
retenir les informations utiles avant d’effectuer les différentes opérations. Il serait intéressant
de trouver par interrogation directe, toutes les informations concernant un fournisseur ou un
article et d’avoir aussi les états désirés. Cela accélérait le processus d’achat. »
Les entretiens et les observations ont fait émerger des critiques ; Ceux-ci relèvent en
général de manque d’efficience (faiblesse des performances).
Le système existant à des performances insuffisantes eu égard aux objectifs qui lui sont
assignés. On note :
- Temps de réponse élevé

Les articles demandés n’arrivent pas dans les délais escomptés. Le temps de réponse
s’allonge. Le projet de commande fait parfois 20 jours avant de se retrouver au Service
Approvisionnement. Les employés s’impatientent.
- Sécurité insuffisante
Le suivi des projets de commande est actuellement assuré manuellement : On tient les
enregistrements dans des registres. L’accès au code des articles est pénible. Ces solutions
manuelles acceptables lorsque les volumes étaient faibles se révèlent de plus en plus
inadaptées. En outre, les registres, très encombrant peuvent être modifiés sans qu’un contrôle

soit possible. Aussi, les demandes émises parcourent trop d’étapes ce qui accroît le risque de
pertes.
- Procédure fastidieuse
La procédure est jugée complexe et malaisée par ceux chargés de l’appliquer ; la
conséquence est un allongement des temps de traitement et un accroissement des risques
d’erreurs qui aboutissent la plupart du temps à des retards dans les traitements.
2)- ANALYSE DES PROBLEMES
2.1)- les points faibles

Il n’existe pas de logiciel actuellement pour gérer les projets de commande. Les
calculs sont faits sur calculatrice ou dans le tableur EXCEL.
La solution actuellement utilisée se révèle inadaptée pour des raisons d’organisation. On
constate une centralisation trop forte : le contrôle de tous les projets de commande par le
Directeur Financier et Comptable, peu disponible, entraîne des retards.
La circulation des documents et des informations crée des retards : le traitement du projet de
commande décrit un long circuit qui rend le délai de réponse plus long.
2.2)- les points forts

L’entreprise utilise déjà l’informatique pour les applications les plus classiques tels
que la paye, le personnel, comptabilité, la facturation, gestion des stocks,… Pour des raisons
d’évolutions technologiques (amélioration des performances), elle s’est dotée de matériels
informatiques de qualité non négligeable. (Voir ci-dessus la liste du matériel informatique
utilisé par les services intervenants dans le suivi des projets de commande).
Les services intervenants dans le circuit du projet de commande utilisent déjà le progiciel
SUNSYSTEMS et sont tous en réseau. SUNSYSTEMS est actuellement utilisé pour gérer les
commandes et la réception d’articles. Notre application devrait pouvoir gérer les projets de
commande depuis leur création jusqu’à l’impression du bon de commande évitant ainsi
l’utilisation des prés imprimés sur SUNSYSTEMS.
III- SOLUTIONS PROPOSEES

Les solutions proposées sont vues sous trois (3) niveaux :
 Niveau Conceptuel
 Niveau Organisationnel
 Niveau Technique
 Procédures
La procédure d’achat en vigueur à la SOGB est décrite par le schéma ci dessous.

Procédure d’achat de la So.G.B

Utilisateur Chef de service Adj Chef de service Agent Magasin Chef de service
Utilisateur Magasin central Central Magasin Central
Émission
Signature Signature Codification Signature
Directeur Général Directeur Financier et Comptable

Signature Signature
Chef de service
Achat Planeur Service Acheteur Service Planeur Service
Achat Achat Achat
Signature
Enregistrement Proposition de Rédaction
Attribution aux
fournisseur demande de prix
équipes
Chef de service Secrétaire Acheteur Service Chef de service Achat

Achat Service Achat Achat
Signature
Signature Saisie bon de Report de cotation
Émission des demandes
commande sur PJC
Approbation des cotations
Planeur Service Secrétaire Service

Chef de service Secrétaire Service
Achat Achat
utilisateur Achat
Enregistrement Envoi pour
Vérification Envoi pour signature
vérification
Directeur Général Directeur Financier et Comptable
Signature Signature
Planeur Service Achat Planeur Service Achat

Chauffeur
Chef de service
Enregistrement Enregistrement
Achat Acheminement
Dépouillement des bons de
Émission fax
Assist. Chef Service Achat commandes
Répartition des copies
Enregistrement
Planeur Service Achat Réceptionniste Chauffeur Fournisseur

Enregistrement des Traitement des Enlèvement des biens Réception des bons
Livraisons livraisons
Livraison sur le complexe Livraisons des articles
IV. CONSTRUCTION DU MODELE CONCEPTUEL DES TRAITEMENTS (MCT)
Le MCT permet de présenter l’activité d’un système d’information indépendamment des

choix et des moyens d’organisation et des moyens d’exécution des traitements de ce
système. On s’intéresse ici au « QUOI FAIRE » sans se préoccuper de « QUI LE FAIT »
ni « COMMENT LE FAIRE ».

Le MCT est basé sur les concepts suivants :

Evénement : c’est la représentation de la perception d’un fait
Synchronisation : les événements externes ou internes peuvent être combinés selon une
expression logique pour une opération.
Opération : ensemble cohérent d’action, manipulant des données, déclenchées par des
événements, produisant des résultats, en exploitant des règles de gestion formalisées des
entités du domaine.
Résultat : le résultat est le produit de l’opération.
A B Evenement contributif
A et B Synchronisation
Temps OPERATION
TRAITEMENTS
C
Resultat
Eléments de base du processus

4.1Diagramme des flux
a) Détermination des acteurs
 les acteurs internes (matérialisés par des rectangles en traits continus)

Emetteur
Agent magasin central
Adjoint chef magasin central
Chef magasin central
Secrétaire service achat
Planeur
DG
DFC
Chef service achat
Acheteur
 les acteurs externes (matérialisés par des rectangles en traits interrompus)

Fournisseur
b) Diagramme des flux
1 2
Emetteur Ajoint Chef Mag asi n Central Agent Mag asi n Central
4 Chef Mag asin Centr al
DFC
18 19
17 20
5A
DG
5B 21
6 planeur
SÚcrÚtar iat Ser vice
Achat 9 8
15
14 22
Chef Service
Achat 23
24
11
12
10
Four nisseur
13
Acheteur
16

c) Description du diagramme de flux
1. Envoi du PJC visé

2. Envoi pour codification
3. Envoi pour signature
5A Envoi pour approbation
5B Envoi pour signature
6. attribution aux équipes
7. Enregistrement du PJC, proposition de fournisseurs
8. Rédaction des demandes de prix
10. Envoi des demandes de prix
11. Réception des réponses fournisseurs (factures proforma) et cotation
12. Report des cotations sur les PJC
13. Saisie des bons de commande
15. Enregistrement des bons de commande
16. Envoi pour vérification
17. Envoi pour vérification
18. Résultat de la vérification
21. Mise à jour, dépouillement et répartition des copies
22. Emission des fax
23. Mise à jour des données
24. Acheminement

4.2Modèle conceptuel de traitement
besoin d'
article
et
Elabor ation demande
Remplir fiche
Editer demande
Controle visas
Controle raison
Controle nombre exemplaire
Transmettre demande
Demande non vali de Demande val ide
agent
magasin
central
Demande
reçue
Demande
rej etée
et
Traitement
Attri bution N°PJC
Mise à jour des codes
visa depot
Approbati on DFC
Approuvé Non Approuvé
Péri ode de
A la repartition PJC visé
demande (b) (a)
(c)
PJC
rejeté
ab ou ac
Péri ode d'
A la Repartition des exemplaires
enquête de
demande pri x Detachement
(b) (d) Autres 1ere Copie 2e Copie
Informations
complémentair es
(e)
documents
transferés retour
(c)
bc ou cd ou ae classement
Enquête de prix
verififcation
Signature
Attribution code acheteur
enregistrement
proposi tion de fournisseur
redaction des demandes de prix
approbation
non visée Visée
demande
rejetée
(a) demande
appr ouvée

demande fournisseur
approuvée disponible
et
Choix du fournisseur
enregistrement demande
Envoi demande de prix
reception reponse
cotation
reponse retenu Non retenu
fournisseur
(b)
Informations fournisseur
complémentaires retenu
(d) (a)
proposition
rejetée
ab ou cd
Etablissement commande achat
report de cotation
enregistrement cotation
edition bon commande
signature
enregistrement bon
confrontation bon PJC
conforme Non conforme
Heure de
signature
(b) demande
A la demande
non
demande conforme
conforme
(c) (a)
ab ou ac
Approbation DG
Approbation
Non Approuvé Approuvé
Commande
rejetée
(c)
Commande
visée
(a) Période d'
A la envoi
Demande (b)
(c)
ab ou ac
Envoi de la commmande
signature DFC
signature DG
enregistrement
détachement
Original 2e copie 1ere copie
Emission
de fax Ajout au
dossier
Transfert Transfert

V. CONSTRUCTION DU MODELE CONCEPTUEL DES DONNEES (MCD)
Le modèle conceptuel de données (MCD) a pour objectif de définir les concepts manipulés
par l’activité étudiée. Il exprime les données manipulées et les relations existant entre elles.
Cette représentation statique sera confrontée ensuite à la vision dynamique donnée par les
modèles de traitements. Le MCD doit donc respecter les règles suivantes :
Règle 1 (1FN) : Toutes les données doivent être élémentaires et toutes les dépendances
doivent être fonctionnelles.
Règle 2 (2FN) : Toutes les dépendances entre les propriétés doivent être élémentaires.
Règle 3(3FN) : Dans une entité, Toutes les dépendances doivent être élémentaires directes
- Les éléments du MCD
Nom Description Formalisme MERISE

Entité C’est la représentation d’un PERSONNE
objet du monde réel.

Attribut Un attribut est une PERSONNE
caractéristique d’une entité ; il Nom
est rattaché à une et une seule

entité.
Identifiant Un identifiant d’une entité est la
clé pour cette entité. Il détermine PERSONNE
Matricule
de manière unique une
occurrence de cette entité
Relation Une relation n-aire est une
n-aire relation au sens mathématique du Exemple de relation binaire
terme. Elle découle de
l’association de 2 ou plusieurs PERSONNE Possède
VEHICULE
Matricule NumMatri
entités. Par exemple : un étudiant
emprunte un livre ; la relation
emprunt se crée à partir des
entités étudiant et livre-
Cardinalit Une cardinalité pour une relation
é s’exprime sous forme de couple
(n, m) et se place de chaque coté PERSONNE Possède
VEHICULE
Matricule 0,n 0,n NumMatri

des entités. Elle stipule le
nombre de fois minimum (n) et
maximum (m) qu’une occurrence
de l’entité apparaît dans la
relation. En fait, la cardinalité
schématise la prise en compte
des règles de gestion des
données.

5.1Dictionnaire actuel des données
Le dictionnaire des données est un tableau dont les lignes représentent les différentes
propriétés.
En vue d’éviter un certain nombre d’anomalies sur les données retenues, les considérations
relatives à la structure et à la nature, des propriétés sont à prendre en considération. Nous
avons donc :
 Les données de situation qui sont des données qui évoluent avec le temps et suivant les
périodes ;
 Les données mouvement qui résultent de circonstances spécifiques, leur existence est
liée à un événement ;
 Les données signalétiques ou stables qui demeurent généralement inchangées quelque
que soient les circonstances. Il s’agit de données ni de mouvement ni de situation ;
 Les données élémentaires qui sont des données qui ne résultent pas de concaténation
de propriétés ;
 Les données calculées qui proviennent d’un calcul ;
 Les données concaténées qui proviennent de la concaténation de propriétés.
Tout au long de la phase de recueil des informations, nous avons tenu un dictionnaire des
données où ont été portées les différentes propriétés (rubriques) relevées dans les documents
ou citées par les utilisateurs.
Pour chaque source, il a été relevé la liste des propriétés nécessaires et ajoutée au dictionnaire
ci dessous
CODE DESIGNATION TYPE TAILLE NATURE OBSERVATION

CodDir Code direction AN 6 E/SIG
LibDir Libellé direction A 15 E/SIG
CodDept Code département AN 6 E/SIG
LibDept Libelle département A 15 E/SIG
CodServ Code service AN 6 E/SIG
LibServ Libellé service A 15 E/SIG
Matricule Matricule employé N 6 E/SIG
Nom Nom employé A 15 E/SIG
Prenom Prénom employé A 25 E/SIG
Sexe Genre employé A 1 E/SIG M ou F
DatNais Date naissance AN 10 E/SIG JJ/MM/AAAA
SitFam Situation familiale A 1 E/SIT M ou C ou D…
DatEmbosh Date d’embauche AN 10 E/SIG AAAA/MM/JJ
NumCNPS Numéro CNPS AN 12 E/SIG
Fonction Fonction employé A 15 E/SIT
Adresse Adresse employé AN 20 E/SIT

CodTypCde Code type de A 1 E/SIG

commande
LibTypCde Libellé type de A 10 E/SIG
commande
NumPJC Numéro projet AN 8 E/SIG
commande
DatPJC Date édition PJC AN 10 E/SIG JJ/MM/AAAA
RaisonPJC Raison édition PJC A 50 E/SIG
CodArticle Code article AN 4 E/SIG
LibArticle Libellé article A 15 E/SIG
PrixUArticle Prix unitaire article M 8 E/SIT
StockArticle Quantité stock article N 4 E/SIT
UGArticle Unité de gestion article A 3 E/SIG
RefArtPJC Référence de l’article AN 4 E/SIG
du PJC
LibArtPJC Libellé de l’article du A 10 E/SIG
PJC
QteArtPJC Quantité de l’article du N 4 E/SIG
PJC
CodFour Code fournisseur AN 9 E/SIG
NomFour Nom fournisseur A 15 E/SIG
AdressFour Adresse fournisseur AN 20 E/SIG
StatutFour Statut fournisseur A 1 E/SIT
TelFour Tél. fournisseur N 8 E/SIT
FaxFour Fax fournisseur N 8 E/SIT
CodCorresp Code du correspondant AN 6 E/SIG
NomCorresp Nom du A 15 E/SIG
Correspondant
TelCorresp Téléphone du N 8 E/SIT
correspondant
AdrCorresp Adresse du AN 20 E/SIT
correspondant
EmailCorresp Email du AN 20 E/SIT
correspondant
FaxCorresp Fax du correspondant N 8 E/SIT
NumCot Numéro demande prix AN 6 E/SIG
DatCot Date édition demande AN 10 E/SIG JJ/MM/AAAA
prix
QteCot Quantité article N 4 E/SIG
demande prix
RefArtCot Référence de l’article à AN 4 E/SIG
coter
LibArtCot Libellé de l’article à A 10 E/SIG
coter
PUArtCot Prix Unitaire de N 8 E/SIG
l’article à coter

RemArtCot Remise sur l’article à N 5 E/SIG

coter
UGArtCot Unité de gestion de A 3 E/SIG
l’article à coter
QteArtCot Quantité de l’article à N 4 E/SIG
coter
NumBonCde Numéro bon de AN 9 E/SIG
commande
DatBonCde Date bon de AN 10 E/SIG JJ/MM/AAAA
commande
NumProf Numéro réponse AN 5 E/SIG
fournisseur
DatProf Date réponse AN 10 E/SIG JJ/MM/AAAA
fournisseur
PrixFour Prix fournisseur pour M 8 E/SIG
un article
RemisFour Remise fournisseur N 3 E/SIG
CodFamil Code famille article A 2 E/SIG
LibFamil Libellé famille article A 15 E/SIG
CodSFamil Code sous famille AN 4 E/SIG
article
LibSFamil Libellé sous famille A 15 E/SIG
article
CodDepot Code dépôt AN 5 E/SIG
LibDepot Désignation dépôt A 15 E/SIG
TelDepot Téléphone dépôt N 8 E/SIT
A : Alphabétique M : Monétaire

AN : Alphanumérique MVT: Mouvement
SIG: Signalétique SIT: Situation
E: Elémentaire
5.2Règles de gestion actuelle
C’est l’ensemble des principes élaborés pour gérer. Les documents cités par les utilisateurs et
les interviews nous ont permis de ressortir les règles de gestions suivantes :
1. Une direction comprend plusieurs départements par contre un département appartient

à une seule direction
2. Un département comprend plusieurs services par contre un service appartient à un seul
département
3. Un employé travaille dans un seul service et un service peut utiliser plusieurs
employés
4. Un employé appartient à une seule classe et une classe peut comporter plusieurs
employés

5. Un PJC est émis au nom d’un seul employé

6. Un employé peut émettre plusieurs PJC
7. Un PJC doit comporter un ou plusieurs articles
8. Un PJC peut être accepté donc aboutir à une demande de prix ou rejeté
9. Une demande de prix est émise par un seul acheteur
10. Un acheteur peut émettre plusieurs demandes de prix
11. Une demande de prix est adressée à un seul fournisseur
12. Une demande de prix doit comporter un ou plusieurs articles
13. Une demande de prix doit concerner un ou plusieurs PJC
14. Une réponse fournisseur peut être retenue et aboutir à une commande d’achat ou
rejetée
15. Une réponse fournisseur doit comporter un ou plusieurs articles
16. Une réponse fournisseur est liée à une seule demande de prix
17. Une commande d’achat est adressée à un seul fournisseur
18. Une commande d’achat doit comporter un ou plusieurs articles
19. Une commande d’achat doit être liée à une ou plusieurs réponses fournisseur
20. Un article peut faire l’objet de plusieurs commandes
Direction
CodDir
21. Un article estDepartement
d’un seul sous famille d’article Service 1,n CIF 1,1 Employe
1,n CodServ Matricule
LibDir
22. Une sous1,1
famille
CodDept
LibDept
d’article
1,nest liée à une seule famille
1,1 LibServ
Nom
Prenom
23. Un article peut être livré par plusieursCIF fournisseurs Sexe
CIF DatNais
24. Un fournisseur peut livrer plusieurs articles DatEmbosh
Fonction
Est adressee par Adresse
Cotation 0,n NumCNPS
NumCot 1,1
SitFam
DatCot
1,n 0,n
PJC emis
etre objet de 1,1
1,n NumPJC
0,n 1,n DatPJC
1,1 RaisonPJC 0,n
1,n Four Poss
Detail PJC
RefArtPJC
DetailsCotation LibArtPJC
RefArtCot QteDemArt
CIF LibArtCot
PUArtCot
0,n
QteArtCot
Adressee a RemArtCot Article
UGArtCot CodArticle
0,n LibArticle
1,1 0,n PrixUArticle
Proforma
StockArticle
NumProf UGArticle
0,n DatProf
RemisFour 1,1
Correspondant
CodCorresp CIF 1,10,n
NomCorresp 5.3Modèle
0,n Conceptuel de données actuel CIF
AdrCorresp
Donne droit 0,n
TelCorresp
FaxCorresp
EmailCorresp 1,n
1,n Sous famille
1,1 Bon commande CodSFamil
NumBonCde LibSFamil
datBonCde
CIF 1,1
1,1
CIF CIF
0,n
1,n
0,n
Fournisseur Famille
T ype Commande
CodFour CodFamil
NomSociete CodT ypCde
LibFamil
AdrFour
LICENCE INFORMATIQUE DE GESTION
LibT ypCde 3ème ANNEE
TelFour
EmailFour
FaxFour 0,n
1. MODELE CONCEPTUEL DE DONNEES (MCD FUTUR)
La solution conceptuelle est composée d’un ensemble de fonctions devant constituer la base
de l’application. Il importe alors de lui associer un ensemble de ressources devant être
manipulées par celle-ci. En d’autres termes, il s’agit d’élaborer un modèle conceptuel de
données futur.
LES GRANDES FONCTIONS
Les fonctions devant faire l'objet de traitements sont:

 La mise à jour des données de la base,
 La consultation des données de la base.
Mise à jour de la base

Les données de la base seront en lecture seule pour la plupart des utilisateurs. L’accès en
lecture/écriture sera un mode privilégié, autorisé selon le profil accordé à l’utilisateur de la
base de données. Les données pourront être modifiées et de nouvelles données ajoutées.
Consultation des données de la base
La consultation devra permettre à tout utilisateur ordinaire d’accéder à la base de données

et de rechercher au moyen d’un certain nombre de requêtes prédéfinies et paramétrables, les
informations qui l’intéressent. Ces requêtes sont de plusieurs natures. Noter que la définition
de plusieurs types de requêtes vise à prendre en compte la multiplicité des profils et des
habitudes envisageables pour l’ensemble des utilisateurs potentiels.

1.1 Dictionnaire des données futur
Ce dictionnaire des données a été établi à partir des documents recensés et des
informations recueillies. Il nous permettra d’élaborer le MCD futur et d’en déduire le modèle
logique des données (MLD).
CODE DESIGNATION TYPE TAILL NATURE OBSERVATIO

E N
CodDir Code direction AN 6 E/SIG
LibDir Libellé direction A 15 E/SIG
CodDept Code département AN 6 E/SIG
LibDept Libelle département A 15 E/SIG
CodServ Code service AN 6 E/SIG
LibServ Libellé service A 15 E/SIG
CodUser Code de l’utilisateur AN 5 E/SIG
Matricule Matricule N 6 E/SIG
Nom Nom A 15 E/SIG
Prenom Prenom A 20 E/SIG
NumOrdre Numéro Ordre AN 8 E/SIG
NumPJC Numéro projet commande AN 8 E/SIG
DatPJC Date édition PJC D 10 E/SIG
RaisonPJC Raison du PJC A 50 E/SIG
DelaiPJC Délai du PJC D 10 E/SIG
CodTypAch Code type achat A 1 E/SIG
LibTypAch Libellé type achat A 15 E/SIG
NumFour Numéro fournisseur AN 9 E/SIG
NomSociété Nom Société A 15 E/SIG
TelFour Téléphone Fournisseur AN 10 E/SIG
AdressFour Adresse fournisseur AN 20 E/SIG
StatutFour Statut fournisseur A 1 E/SIT
PUProposé Prix Unitaire en vigueur M 8 E/SIT
pour l’article
Rang Rang pour l’article N 1 E/SIT
VilleFour Ville Fournisseur A 15 E/SIT
EmailFour Email fournisseur AN 20 E/SIT
CodArticle Code article AN 6 E/SIG
LibArticle Libellé article A 15 E/SIG
PUArticle Prix unitaire article M 8 E/SIT
StockArticle Quantité stock article N 4 E/SIT
UGArticle Unité de gestion article A 3 E/SIG
NumCde Numéro commande achat AN 9 E/SIG
DatCde Date commande achat D 10 E/SIG
QteCde Quantité article commandée N 4 E/SIG
NumCot Numéro cotation AN 5 E/SIG
DatCot Date édition cotation D 10 E/SIG
NumIntern Numéro interne proforma AN 6 E/SIG
NumProf Numéro proforma AN 9 E/SIG

DatProf Date proforma D 10 E/SIG

CodFamille Code famille article A 2 E/SIG
LibFamille Libellé famille article A 15 E/SIG
CodSFamille Code sous famille article AN 4 E/SIG
LibSFamille Libellé sous famille article A 15 E/SIG
CodTypCde Code type de commande AN 5 E/SIG
LibTypCde Type de commande A 10 E/SIG
NumDetPJC Numéro détails PJC N 2 E/SIG
RefArtPJC Référence de l’article AN 4 E/SIG
demandé par l’émetteur
DesArtPJC Désignation de l’article AN 15 E/SIG
demandé
QteArtPJC Quantité de l’article N 4 E/SIG
UGArtPJC Unité de gestion de l’article A 3 E/SIG
demandé
PUArtPJC Prix unitaire de l’article M 8 E/SIG
demandé
Date Date de validation PJC D 10 E/SIG
Heure Heure de validation PJC H 5 E/SIG ## : ##
CodEtape Code de l’étape du PJC AN 8 E/SIG
OrdreEtape Numéro de l’étape N 1 E/SIG
EtapePJC Etape du PJC A 10 E/SIG
NumDetCot Numéro détails Cotation N 2 E/SIG
RefACot Référence de l’article à AN 4 E/SIG
coter
LibACot Libellé de l’article à coter A 15 E/SIG
QteACot Quantité de l’article à coter N 8 E/SIG
UGACot Unité de gestion de l’article A 3 E/SIG
à coter
RemACot Remise de l’article à coter N 5 E/SIG
PUACot Prix unitaire de l’article à M 8 E/SIG
quotter
GarantACot Garantie de l’article à coter A 20 E/SIG
LignProf Ligne de la proforma N 2 E/SIG
CodCondition Code de la condition AN 4 E/SIG
LibCondition Libellé de la condition A 20 E/SIG
CodEtlig Code de l’état de la ligne AN 3 E/SIG
EtatLig Etat de la ligne A 10 E/SIG
NumCorresp Numéro du correspondant AN 5 E/SIG
NomCorresp Nom du correspondant A 15 E/SIG

AdressCorresp Adresse du correspondant AN 20 E/SIT
TelCorresp Téléphone du correspondant N 8 E/SIT
FaxCorresp Fax du correspondant N 8 E/SIT
EmailCorresp E mail du correspondant AN 15 E/SIT
DatDeb Date début validité D 10 E/SIG
DatFin Date fin validité D 10 E/SIG

CodDepot Code dépôt AN 5 E/SIG

LibDepot Désignation dépôt A 15 E/SIG
TelDepot Téléphone dépôt N 8 E/SIT
NumIntLiv Numéro interne de livraison AN 5 E/SIG
NumLiv Numéro livraison AN 9 E/SIG
fournisseur
DatLiv Date de livraison D 10 E/SIG
Designation Désignation de l’article A 15 E/SIG
livré
QteArtLiv Quantité d’article livré N 4 E/SIG
LigLiv Ligne de livraison N 2 E/SIG
StatutArt Statut de l’article A 2 E/SIT C ou NC
NouvLig Nouvelle Ligne AN 8 E/SIG
NouvRef Nouvelle référence article AN 4 E/SIG
NouvDesig Nouvelle désignation article A 15 E/SIG
NouvUG Nouvelle UG article A 3 E/SIG
NouvPU Nouveau Prix Unitaire M 8 E/SIG
CodModReg Code mode de règlement AN 2 E/SIG
Modregle Mode de règlement A 10 E/SIG
NumCircuit Numéro circuit N 2 E/SIG
LibCircuit Désignation du niveau du A 10 E/SIG
circuit
DatVCde Date de validation de D 10 E/SIG
commande
HeureVCde Heure de validation H 5 E/SIG
commande
EtatCde Etat de la commande A 10 E/SIG
CodPeriode Code de la période AN 5 E/SIG
LibPeriode Libellé de la période A 10 E/SIG
A : Alphabétique M : Monétaire

AN : Alphanumérique MVT: Mouvement
SIG: Signalétique SIT: Situation
E : élémentaire D : Date
1.2-Règles de gestion future
1. Une direction comprend plusieurs départements par contre un département appartient

à une seule direction.
2. Un département comprend plusieurs services mais un service appartient à un seul
département.
3. Un utilisateurtravaille dans un seul service et un service peut avoir plusieurs
utilisateurs.
4. Une demande de cotation doit comporter un ou plusieurs articles.
5. UnPJC doit correspondre à un seul type d’achat.

6. Un PJC doit comporter un ou plusieurs articles.

7. A une date donnée plusieurs PJC peuvent être validés par plusieurs utilisateurs.
8. Une demande de cotation est adressée à un seul fournisseur.
9. Une demande de cotation doit concerner un ou plusieurs PJC pour une période
donnée.
10. Une réponse fournisseur (pro forma) peut être retenue et aboutir à une commande
d’achat ou rejetée.
11. Une réponse fournisseur (pro forma) doit comporter un ou plusieurs articles.
12. Sur une Pro forma peut figurer plusieurs détails PJC alors qu’un détail PJC ne peut
figurer que sur une seule pro forma.
13. Un article est d’une seule sous famille d’article.
14. Une sous famille d’article est liée à une seule famille.
15. Un fournisseur peut livrer plusieurs articles.
16. Le statut d’un fournisseur est lié à l’article livré
17. Un PJC peut être validé à différents niveaux dans un même service
18. Une proforma peut être liée à une condition de règlement.
19. Un PJC ne peut être validé au sein d’un service que par les personnes habilitées à le
faire.
20. Un correspondant ne représente qu’un fournisseur à la fois.
21. Pour une période donnée, il est prévu par service une quantité d’article stockée dans
un dépôt.
22. Tout article ayant fait l’objet de cotation annuelle ne peut faire l’objet d’autre cotation.
23. Une commande concerne un et un seul type de commande.
24. Une commande ne concerne qu’un seul mode de règlement.

1.3-Structure d’accès théorique (SAT)

1.4-Construction du modèle conceptuel des données

2) MODELE CONCEPTUEL DE TRAITEMENTS (MCT FUTUR)
2.1. Diagramme des flux
a) Détermination des acteurs

 les acteurs internes
Agent magasin central
Chef magasin central
Secrétaire service achat
Chef service achat
Secrétaire du DFC
DG (Directeur Général)
DFC (Directeur Financier et de la Comptabilité)
Acheteur
 les acteurs externes

Fournisseur
Emetteur
b) Diagramme de circulation des flux
1
Emetteur Agent Magasin Central 13
2
Chef Magasin Central
4A
4B
4
DFC
DG 10 Responsable Servi ce Achat
7
5 8 9
6
11
Acheteur Fournisseur
12

c)Légende Du Diagramme Des Flux
1. Transmission de la demande d’achat

2. Envoi pour approbation
4. Transmission PJC + rapport de validation
5. Transmission des cotations
6. Envoi des demandes de prix
7. Réception des pro formas
8. Transmission des pro formas
9. Envoi des commandes achats
10. Envoi des commandes d’achat
11. Transmission des commandes signées
12. Envoi des commandes
13. Livraison des articles
4A Envoi pour approbation
4B Transmission PJC +rapport de validation
A. Relance demande de prix
B. Relance commande d’achat
2.2. Modèle Conceptuel de Traitements
On note pour la mise en place du MCT, la prise en compte des différents types d’achat :
 L’achat courant
IL est applicable aux achats courants de fournitures et pièces de rechange
d’approvisionnements et de réapprovisionnements des dépôts principaux que sont : le
magasin central, le magasin phytosanitaire et la pharmacie de l’hôpital.
 L’achat d’investissement
IL est applicable aux achats d’équipements qui sont prévus au budget d’exercice de
l’année en cours.
 L’achat Guidé
. Elle est applicable aux achats de fournitures et pièces de rechange qui sont livrés sans
bon de commande préalable.
 L’achat contrat
IL est applicable en particulier aux commandes annuelles de fournitures de bureau et de
produits phytosanitaires en fonction des prévisions de consommations préalablement
déterminées par les utilisateurs.
MODELE CONCEPTUEL DE TRAITEMENTS (MCT) FUTUR


Procédure d’achat Courant

Procedure Achat Courant
Besoin d'
article(s)
ou
Elaboration demande
Saisie demande
Saisie suspendue Saisie OK
Heure de
signature
(b)
Demande A la
élaborée demande
Demande (a) (c)
en cours
ab ou ac
Signature Demande
Vérification désignation
Vérifcation raison
Demande
Rejeté Signé A modifier à modifier
Demande Ordre de
rejetée Demande Heure de
tratement
signée traitement
(b)
(a) (c)
ab ou ac
Traitement Demande
Vérification des mentions
Génération du N°PJC
Edition PJC
Ordre de Heure de
Signature
Besoin d' signature signature
informations Infos iincomplètes OK (c) Infos
(b)
supplementaires complementaires
(e)
PJC édités
(a)
ab ou ac ou de
A la
demande Signature PJC
(b) Transfert
Approbation
Heure de Approuvé Rejeté Mise en attente
consolidation
(c) PJC signés
(a)
PJC en
PJC attente
ac ou ab
rejeté (d)
Consolidation PJC
Consolidation PJC
Repartition Cotation Acheteur
TOUJOURS
Liste des
Cotation Fournisseurs
OK
et
Traitement Cotations
Affectation Fournisseurs
repartition des codes aux acheteurs
Edition demandes de prix
TOUJOURS Demandes
de prix 1/2
éditées

Demande de
prix éditées Coordonnées
(a) fournisseur
(b)
ab ou bc
Suivie des demandes
Enregistrement demandes
Envoi des demandes
Rep Conforme Art substitution Pas reponse Rep N Conform
Commande
non effectuée
(c)
Reponse non
Avis conforme delai
Proposition (b) reponse
favorable
substitution épuisé
Emetteur
(d)
Pas de
et
réponse
Modification PJC (a)
acd ou bc
Modification PJC
Reponse Relance
TOUJOURS
conforme Relance demande de prix
(a)
TOUJOURS
Ordre de
commande PJC modifié
(c) (b) Demande
Nbre reponse
relancée
>=3
Informations (c)
(d)
complémentaires
(i)
ad ou ac ou bd ou bc ou im
Commande d'Achat
Dépouillement
Choix du type de commande
Edition commande achat
TOUJOURS
Commandes PJC modifié

éditées (b) PJC signés
(a) (c)
ab ou ac
Signature commande
Approbation
Signée Rejetée A modifier
Commande
Commande à modifier
validée (m)
Commande
rejetée
2/2

Procédure d’achat d’Investissement
Procedure Achat d'Investissement

Période d'
achat
ou
Elaboration demande
Saisie demande
Heure de
signature
(b)
A la
Demande demande
élaborée (c)
Demande (a)
en cours
ab ou ac
Validation Demande
Vérifcation raison
Demande
Rejeté Valider A modifier à modifier
Ordre de
tratement
Demande (b) Heure de
rejetée Demande
traitement
Validée
(c)
(a)
ab ou ac
Traitement Demande
Signature
Besoin d' Infos incomplètes OK
informations
supplementaires
A la Heure de PJC
demande consolidation élaborée
(b) (c) (a)
ac ou ab
Consolidation PJC
Consolidation PJC
TOUJOURS
PJC d'
Invetisement Liste des
(G) Fournisseurs
et
Traitement Cotations
Edition demandes de prix
TOUJOURS
Demandes
de prix
éditées
(a)
1/3

Demande de Coordonnées
prix éditées fournisseur
(a) (b)
ab ou bc
Suivie des demandes
Envoi des demandes
Rep Conforme Art substitution Pas reponse Rep N Conform
Reponse
Avis Depouillement
Proposition non
favorable non effectué
substitution conforme delai
Emetteur (c)
(b)
reponse
épuisé
et (d)
Modification PJC
Modification PJC
Pas de
TOUJOURS réponse
(a)
acd ou bc
Relance
Relance demande de prix
PJC
Date de TOUJOURS
modifié
PJC d' dépouillement (d)
Investissement (b)
(G) Demande
Reponse relancée
conforme Ordre de (c)
(a) dépouillement
(c)
abG ou acG ou adG ou acd

Infos
Depouillement Heure de complementaires
Depouillement Ordre de signature (e)
Choix du type de commande signature (c)
(b)
Offre Defavorable Offre Favorable
PJC d'
Investissement
(G)
Proposition
retenue
Proposition (P)
rejetée
PbG ou PcG ou de
Signature PJC
Transfert
Approbation
Modifié Approuvé Rejeté Mise en attente
PJC PJC en
PJC validés
modifié PJC attente
(a)
(b) rejeté (d)
2/3

PJC PJC validés

Proposition modifiés Informations
(a)
retenue (b) complémentaires
(P) (i)
aP ou bP ou im
Commande d'Achat
Enregistrement des cotations
Enregistrement du PJC
TOUJOURS
PJC
Commandes modifié
éditées (b)
(c) PJC validés
(a)
ab ou ac
Signature commande
Approbation
Rejetée Signée A modifier
Commande
rejetée Commande
à modifier
(m)
Commande
validée
Procedure de livraison
3/3

Procédure d’achat Contrat

Période d' Procédure Achat Contrat

Informations expression
complementaires des besoins
(i) (b)
Date de
traitement
(d)
Besoins
b ou im validés Ordre de
(b) traitement
Expression des besoins
(o)
Saisie des besoins annuels
Validation saisie
A modifier Saisie validée
Saisie à
modifier bd ou bo
(m) Traitement des besoins
Analyse des besoins
Regroupement des besoins
Confrontation besoins stock
Redaction de la demande annuelle
Determination de la périodicité des commandes
TOUJOURS
Période d' Ordre Information

prevision d'
appel d'offre (c) complémentaire
achat
(a) (i)
(b)
ab ou bc ou im
Appel d'offre
Edition des demandes de prix
Coordonnées Enregistrement des demandes de prix
des fournisseurs DEMANDE OK A Modifier
possibles
(b) Demande à
modifier
Demande de (m)
prix éditée
(a)
ab ou bc
Suivie des demandes
Envoi des demandes
Pas reponse Rep N Conform Rep Conforme Art substitution
Avis
favorable
Période d' Emetteur
Pas de appel d'offre Reponse Proposition
réponse (c) non substitution
(a) conforme
(b) et
Substitution Article
ac ou bc Modification PJC
Relance TOUJOURS
Relance demande de prix
TOUJOURS
Demande Reponse Article
relancée conforme remplacé
(c) 1/3

Période d'
Nbre
appel d'offre
reponse >=
épuisée
3 Article
(c)
(d) remplacé
Reponse
conforme (b)
(a)
ac ou bc oe ad ou cd
Depouillement
Depouillement des cotations
Retenue Rejetée
Prévision d' Ordre Période d'

achat (c) achat
(a) Fournisseurs Proposition
(b)
potentiels rejetée
(P)
ab ou ac ou bc ou bd ou be ou cd
Elaboration demande
Saisie demande
Validation demande
Saisie suspendue Demande élaborée
Demande
en cours
(d)
Date de Demande
signature validée
(a) (b)
ordre de
Prevision d'
signature
achat
(d)
(c)
abc ou bcd
Signature demande
Analyse demande
Signature
Demande Rejetée Signée A modifier Demande
rejetée à modifier
(e)
Heure de Demande
signée A la
traitement
(a) demande
(c)
(b)
ab ou ac
Traitement Demande
Signature
Besoin d' Infos incomplètes OK PJC
informations élaboré
supplementaires (a)
2/3

Ordre de Prévision Heure de

PJC élaboré Infos
signature achat signature
(a) complementaires
(b) (f) (c)
(e)
abf ou acf ou def

Signature PJC
Approbation
Approuvé Modifié Rejeté Mise en attente
Fournisseurs
potentiels PJC validé
(P) (a)
PJC en
PJC
attente
modifié (d)
(b)
aP ou bP
Traitement Cotations PJC
rejeté
repartition des codes aux acheteurs
Confrontation des cotations
Rejetée Retenue
Fournisseur
en attente
Fournisseur
definitif
(b)
Informations
PJC complémentaires
validé (i)
(a)
ab ou im
Commande d'Achat
TOUJOURS
Commandes
éditées PJC validé
(c) (a)
ab ou ac
Signature commande
Approbation
Rejetée Signée A modifier
Commande
à modifier
Commande (m)
rejetée Commande
validée
3/3

Procédure de Livraison
Commande Coordonnées
validée Fournisseur
(c) (f)
cf ou fr
Suivie des commandes
Enregistrement commande
Envoi des commandes
TOUJOURS
Commande
Articles
validée Articles
Commande (b)
(v) complémentaires
Bordereau de envoyée (e)
livraison (a)
(c)
abv ou cdev
Suivie des livraison
Enregistrement des livraisons
Etat des livraisons
Livraison partielle Livraison totale Commande non livrée Livraison excedent
Ordre de
Livraison
Articles traitement
partielle dossier
(d) en excès
PJC
classé
Commande
Ordre de et
non livrée
relance
Delai de Traitement
livraison Analyse des besoins
épuisé
Retour Regularisation
et
Relance commande
Relance de la commande
Procedure de
TOUJOURS Retour
regularisation
Articles
Commande
relancée
(r)
1/1

Procédure d’achat Guidé

PJC de
regularisation
PJC achat (R) Heure de
(A) signature
(c)
Infos
Ordre de
complementaires
signature
(e)
(b)
ab ou ac ou Rb ou Rc ou de
Signature PJC
Transfert
Approbation
PJC R approuvé PJC A appprouvé Mise en attente
PJC en
attente
(d)
Fournisseur
PJC achat imposé Informations
PJC complementaires
regularisation signés (b)
(c) (i)
Signé
(a)
ab ou bc ou im
Commande
Elaboration bon de commande
Edition bon de commande
TOUJOURS
PJC de
regularisation PJC achat
signé signé
(a) Bon de (b)
commande
édité
(c)
et et
Signature commande regularisation Signature commande achat
Signature Signature
TOUJOURS Rejetée Signée A modifier
Commande Commande
de Commande à modifier
regularisation Commande (m)
achat signée
signée rejetée
2/2

Procedure Achat Guidé
Besoin d'
achat Besoin de
regularisation
ou
Elaboration demande
Saisie demande
Demande
en cours
Demande
élaborée
(a) Heure de
signature
(b) A la
demande
(c)
ab ou ac
Signature Demande
Vérifcation raison
Rejeté Signé A modifier
Demande
à modifier
Demande
rejetée
Ordre de
traitement Heure de
Demande (b) traitement
signée
(c)
(a)
ab ou ac
Traitement Demande
Signature
PJC Achat PJC de regularisation Infos incomplètes
PJC de Besoin d'

PJC achat regularisation informations
(A) (R) supplementaires
1/2

PJC de
regularisation
PJC achat (R) Heure de
(A) signature
(c)
Infos
Ordre de
complementaires
signature
(e)
(b)
ab ou ac ou Rb ou Rc ou de
Signature PJC
Transfert
Approbation
PJC R approuvé PJC A appprouvé Mise en attente
PJC en
attente
(d)
Fournisseur
PJC achat imposé Informations
PJC complementaires
regularisation signés (b)
(c) (i)
Signé
(a)
ab ou bc ou im
Commande
Elaboration bon de commande
Edition bon de commande
TOUJOURS
PJC de
regularisation PJC achat
signé signé
(a) Bon de (b)
commande
édité
(c)
et et
Signature commande regularisation Signature commande achat
Signature Signature
TOUJOURS Rejetée Signée A modifier
Commande Commande
de Commande à modifier
regularisation Commande (m)
achat signée
signée rejetée
2/2

1) MODELE ORGANISATIONNEL DE TRAITEMENTS
Si au niveau conceptuel nous nous sommes intéressés à l’organisation des données sans nous
soucier des moyens utilisés pour leur réalisation, le niveau organisationnel nous impose de
savoir :
Qui exécutera les traitements, Comment et Quand les exécutera t’il.
La réponse à ces trois questions aboutira au modèle organisationnel des traitements présenté
sous forme de procédures fonctionnelles, chacune des ces procédures indiquant comment la
solution informatique s’insère dans le fonctionnement du système.
DIAGRAMME D’ENCHAINEMENT DES PROCEDURES FONCTIONNELLES
Pour le diagramme d’enchaînement des procédures fonctionnelles, nous aurons :
 Procédure d’achat courant ;

 Procédure d’achat d’investissement ;
 Procédure d’achat guidé.
 Procédure d’achat contrat ;
 Procédure de livraison.

Procédure d’achat courant
Période Enchainement des taches Poste Responsable Ressources Type
Besoin d'article
ou
Elaboration demande Chef service
bureau emetteur Homme+PC Interactif
7h00-17h30 emetteur
Saisie demande
Demande
Demande
en cours
élaborée
Heure de
A la
signature
demande
a
b c
ab ou ac
bureau chef Chef service
7h00-17h30 Signature demande
service emtteur emetteur Homme+PC Interactif
Vérification articles
Vérification raison
Rejeté Approuvé A modifier
demande
Demande à
rejetée
Demande modifier
signée
Heure de Ordre de
traitement traitement
b
a
c
ab ou bc
Elaboration PJC
7h00-17h30 Bureau Agent
Vérification des mentions Chef magasin Homme+PC
magasin Interactif
Génération N° PJC
Infos incomplètes OK
PJC
Bésoin Heure de élaboré
d'informations validation
complément
et
Bureau chef
Validation PJC magasin Chef magasin Homme+PC Interactif
7h00-17h30
Signature
Edition PJC
TOUJOURS
PJC
édités

Heure de
PJC Ordre de
signature
édités signature
PJC
Infos c a b
complémentaires
e
ab ou ac ou de
Signature PJC
Approbation Bureau DFC DFC Homme+PC
7h00-17h30 Interactif
d
Approuvé Rejeté Mise en attente
PJC
rejetés
PJC en
attente
Demande de
ccnsolidation Heure de
PJC
signés consolidation
a b
cf
ab ou ac
Consolidation
7h00-17h30 Consolidation des PJC Bureau Chef Chef Sce
Repartition Cotations Acheteurs Sce Achat Achat Homme+PC Interactif
TOUJOURS
Liste des
fournisseurs
Cotation
OK
et
traitement des Cotations Chef sce
7h00-17h30 Bureau cheteur Homme+PC Interactif
Affectation fournisseurs Achat
Elaboration des demandes de prix
TOUJOURS
Demande
de prix
éditées
Coordonnées
Fournisseurs
a
b
ab ou bc
Suivie des Demandes
Chef sce
7h00-17h30 Envoi demandes Bureau acheteur Homme+PC Interactif
Achat
Rep Conforme Art substitution pas Reponse Rep N conforme
Proposition Reponse
Reponse de non
Pas de
Conforme substitution conforme
reponse

Avis
favorable Proposition
Emetteur Substitution
et
Modification PJC
Chef sce
7h00-17h30 Modification PJC Bueau acheteur Achat Homme+PC
Interactif
TOUJOURS
Commande
Reponse non
Pas de non effectuée
reponse conforme
delai de Ordre de
reponse relance
épuisé a
c
b
d e
acd ou bc ou ae ou be
Relance
Chef Sce
7h00-17h30 relance demande de prix Bureau acheteur Homme+PC Interactif
Achat
PJC
modifiés TOUJOURS
Demande
relancée
Nbre Informations
reponse>=3 complémentaires
Ordre de Reponse
commande d favorable
i
c a
b Dépuoillement
Dépouillement
7h00-17h30
Choix du type de commande Bureau Chef Chef sce
Homme+PC Interactif
Elaboration comande d'achat sce achat achat
validation commande
TOUJOURS
Commande
éditée m
PJC signés
a
c
ab ou ac
Signature commande
confrontation Bureau DG DG Homme Manuel
7h00-17h30
Signée rejetée A modifier
Commande à
Commande
modifier
validée Commande
rejetée

Procédure d’achat d’investissement

Période d'achat
ou
Elaboration demande Chef service
bureau emetteur Homme+PC Interactif
7h00-17h30 emetteur
Saisie demande
Demande Demande
en cours élaborée
Heure de A la
signature a demande
b c
ab ou ac
Signature demande
bureau chef Chef service Homme+PC
7h00-17h30 Vérification articles Interactif
service emtteur emetteur
demande
rejetée Demande à
Demande modifier
signée
Ordre de
Heure de traitement
traitement
b
c
a
ab ou bc
Elaboration PJC
Vérification des mentions Bureau Agent DLI Homme+PC
7h00-17h30 Interactif
Génération N° PJC DLI
Bésoin
d'informations PJC
complément Heure de d'investissement
validation élaboré
et
Validation PJC
DLI Homme+PC Interactif
Signature Bureau DLI
7h00-17h30
Edition PJC
TOUJOURS
PJC d'investissement
validé

Demande de
PJC d'investissement consolidation Heure de
signés consolidation
a c
ab ou ac
Consolidation
7h00-17h30
Consolidation des PJC Bureau DLI DLI Homme+PC Interactif
Repartition Cotations Acheteurs
TOUJOURS
Liste des
fournisseurs Cotation
OK
et
traitement des Cotations
Affectation fournisseurs Bureau agent DLI Homme+PC Interactif
7h00-17h30 DLI
Elaboration des demandes de prix
TOUJOURS
Coordonnées
Demande Fournisseurs
de prix
éditées
b
a
ab ou bc
Suivie des Demandes
Envoi demandes
Bureau agent DLI Homme+PC Interactif
7h00-17h30 Rep Conforme Art substitution pas Reponse Rep N conforme
DLI
Reponse
Conforme
Reponse
non
Proposition Pas de conforme
de reponse
substitution

Avis
favorable Proposition
Emetteur Substitution
et
Modification PJC
7h00-17h30 Modification PJC Bueau agent Homme+PC
DLI Interactif
TOUJOURS DLI
Reponse Commande
non non
Pas de
conforme effectuée
reponse
delai de
Ordre de
reponse
b relance
épuisé c
a
d e
Relance
7h00-17h30 relance demande de prix Bureau agent DLI Homme+PC Interactif
DLI
TOUJOURS
PJC
modifiés Demande
relancée
Date de
PJC
dépouillement
d'investissement
b
Ordre de
Reponse
dépouillement d
favorable
i
c a
adi ou aci ou bdi ou bci

Dépuoillement
7h00-17h30 Dépouillement Bureau DLI DLI Homme+PC Interactif
offre defavorable Offre favorable
Proposition Proposition
rejetée retenue

Ordre de heure de PJC

signature signature d'investissement
PJC modifié
Proposition
retenue
Infos
O H A
complémentaires
B
P
I
APH ou APO ou BPH ou BPO ou IE
10h ou 15h Signature PJC

Bureau DFC DFC Homme+PC Interactif
Confrontation PJC Proposition
Approbation
E
Modifié Approuvé Rejeté En attente
P
PJC rejetés
PJC en
attente
PJC PJC
Modifés signés Informations
complémentaires
A
B
I
AP ou BP ou IM
Commande d'achat
Elaboration commande d'achat Bureau Chef Chef sce Interactif
7h00-17h30 Homme+PC
validation commande sce achat achat
TOUJOURS
Commande
PJC PJC
éditée
modifies signes
M
a
b c
ab ou ac
Signature commande
confrontation
7h00-17h30 Bureau DG DG Homme
Signée rejetée A modifier Manuel
Commande
validée Commande à
Commande modifier
rejetée

Procédure achat guidé

Bésoin de regularisation
Bésoin d'achat
ou
Elaboration demande
7h00-17h30 Saisie demande bureau emetteur Chef service Homme+PC Interactif
emetteur
Demande
en cours
Demande
élaborée
A la
Heure de demande
signature
a
c
b
ab ou ac
Signature demande
7h00-17h30 Vérification articles bureau chef Chef service

Vérification raison service emtteur emetteur Homme+PC Interactif
demande
Demande à
rejetée Demande modifier
signée
Heure de
traitement Ordre de
traitement
b
a
c
ab ou bc
Elaboration PJC
Bureau Agent
Génération N° PJC Chef magasin Homme+PC Interactif
7h00-17h30 magasin
Infos incomplètes PJC de regularisation PJC achat
Bésoin PJC de PJC

d'informations regularisation d'achat
complément
Heure de b
validation c
a
ab ou ac
Validation PJC
Bureau chef
7h00-17h30 Signature Chef magasin Homme+PC Interactif
magasin
TOUJOURS
PJC d'achat PJC de regularisation

édités édités


PJC de
Heure de PJC d'achat
regularisation
signature édités Ordre de
édités
PJC signature
Infos
complémentaires c r a b
e d
ab ou ac ou rb ourc ou de
Signature PJC
Approbation Bureau DFC DFC Homme+PC Interactif
10h ou 15h
PJC regularisation Approuvé PJC achat aprouvé Mise en attente
PJC en
attente
Fournisseurs
imposés
PJC de
regularisation Informations
PJC achat
approuvé complémentaires
approuvé
Ordre de b
commande
a i
c
Dépouillement
7h00-17h30 Elaboration comande d'achat

validation commande Bureau Chef Chef sce
Homme+PC Interactif
sce achat achat
Commande d'achat Commande de regularisation
Commande de PJC d'achat

m regularisation signés
et
Signature commande achat
confrontation
7h00-17h30 A modifier Signée rejetée Bureau DG DG Homme Manuel
Commande Commande
Commande à
signée rejetée
modifier
PJC de Commande
regularisation de
signés regularisation
et
Signature cde de regularisation
7h00-17h30 Signaturre Bureau DG DG Homme Manuel
TOUJOURS
Commande de
regularisation
signé

Procédure achat contrat

Informations Période d'expression

complémentaires des besoins
i
b
b ou im
Expression des besoins
bureau Chef Chef service
7h00-17h30 Saisie demande Service emetteur
m emetteur Homme+PC Interactif
Date de Bésoins
Saisie à
traitement validés Ordre de
modifier
traitement
d b o
bd ou bo
Traitement des besoins
Analyse des besoins
Bureau agent Chef magasin
7h00-17h30 Regroupement Homme+PC Interactif
magasin central central
Confrontation besoin/Stock
Redaction demande annuelle
TOUJOURS
Prévision
Heure de achat Ordre de
validation elaborée validation
H D O
DH ou HO
7h00-17h30 Validation demande Bureau chef Chef Magasin
Magasin Central Central Homme+PC Interactif
Signature
TOUJOURS
Prévision
achat validée
Période d'appel Ordre d'appel
d'offre d'offre
Liste des
fournisseurs
a
possibles
p o
F
afp ou afo Homme+PC Interactif

Bureau Chef Chef Sce
7h00-17h30 Appel d'offre Achat
Sce Achat
Elaboration demandes de prix
Determination de périodicité achat
TOUJOURS
Demande de
prix éditée

Demande Coordonnées
de prix Fournisseur
éditées possible
b
a
ab ou bc
Suivie des Demandes
Chef sce
Envoi demandes Homme+PC Interactif
7h00-17h30 Bureau acheteur Achat
Rep ConformeArt substitutionpas ReponseRep N conforme
Reponse
Conforme
Avis Proposition
favorable de
emetteur substitution
Reponse
non
et conforme c
Modification PJC Chef sce
Bueau acheteur Homme+PC Interactif
7h00-17h30 delai de Commande Achat
Modification PJC
reponse non
TOUJOURS épuisé effectuée
Pas de b
reponse Ordre de
relance
d c
a
e
Relance
relance demande de prix Bureau acheteur Chef Sce Interactif
7h00-17h30 Homme+PC
Achat
TOUJOURS
PJC
modifiés Nbre
reponse>=3
Période
d'appel d'offre Demande
épuisée relancée
Ordre de Reponse
dépouillement d favorable
b
i
a
c
ac ou ai ou ad ou bc ou bi ou bd
Dépouillement Bureau Chef Chef sce
7h00-17h30 sce achat Homme+PC Interactif
Dépouillement achat
Retenue Rejetée
Fournisseur
potentiel Proposition
rejetée

Prévision d'achat Ordre d'achat Période d'achat Informatons

complémentaires
a c b i
ab ou ac oubc ou bd ou be ou cd
Elaboration demande bureau acheteur Chef service
7h00-17h30 Homme+PC Interactif
d Saisie demande Achat
Demande
en cours prevision
Demande
d'achat
élaborée
e
Heure de
A la
signature
demande
d a
b c
abd ou acd
bureau chef Chef service Interactif
7h00-17h30 Signature demande Homme+PC
service Achat Achat
f Vérification articles
demande Demande à
rejetée modifier
Demande
signée
Heure de Ordre de
traitement b traitement
a c
ab ou bc
Elaboration PJC
7h00-17h30 Bureau Agent
Vérification des mentions Chef magasin Homme+PC Interactif
magasin central
Génération N° PJC central
Bésoin
d'informations
complément Demande de PJC
validation élaboré Heure de
validation
a
b
c
ab ou ac
Validation PJC Chef magasin
Bureau chef Interactif
7h00-17h30 Homme+PC
Validation magasin central central
Edition PJC
TOUJOURS
PJC
édité


Heure de PJC Ordre de
signature édités signature
PJC Prevision
d'achat
Infos
complémentaires c
a b
P
e
abP ou acP ou de
Signature PJC
Approbation d
10h ou 15h Bureau DFC DFC Homme+PC Interactif
Approuvé ModifiéRejetéMise en attente
PJC PJC en
rejetés attente
PJC
PJC
modifie fournisseurs
signé
potentiels
b
c
a
ab ou ac
traitement des Cotations
Affectation fournisseurs Chef sce Homme+PC Interactif
7h00-17h30 Bureau Acheteur
repartiton des codes PJC Achat
Confrontation cotations modifié
Cotation rejetéeCotation retenue
PJC
Fournisseur signe Infos
Prévision définitif e complémentaire
Fournisseur d'achat
en
attente b
c a d
abc ou aec ou im
Commande d'achat
Elaboration comande d'achat Bureau Chef Chef sce
7h00-17h30 c
validation commande Homme+PC Interactif
sce achat achat
TOUJOURS
PJC
modifiés Commande
m
éditée PJC signés
d a
b
abc ou acd
Signature commande
7h00-17h30 Manuel
confrontation Bureau DG DG Homme
Signée rejetée A modifier

Commande
Commande à
validée Commande
modifier
rejetée

Procédure de livraison
Coordonnées
fournisseur Commande
validé
f c
cf ou fr
Suivie commande Bureau Acheteur Chef Sce
7h00-17h30 Homme+PC+fax Interactif
Achat
Enregistrement commande
Envoi commande
TOUJOURS
v
Articles
Articles Commande complémentaires
commandés envoyée
Bordereau de
b e livraison
a
c
abv ou cdev
Suivie des livraisons
Enregistrement des articles livrés
7h00-17h30 Depot conserné Chef magasin Homme+PC Interactif
d Etat de la livraison
r
Livraison PartielleLivraison TotaleCommande Non LivréeLivraison Excedant
Livraison
Dossier
partielle
PJC
classé
Ordre de
relance
Delai de Commande
livraison épuisé non livrée
c
a b
ab ou bc
7h00-17h30 Relance commande Chef sce
Bureau Acheteur Homme+PC+fax Interactif
Relance de la commande achat
TOUJOURS
Commande
Ordre de Articles
relancée
traitement en excès
et
Traitement Bureau chef Chef sce
7h00-17h30 sce achat Homme+PC Interactif
Analyse des bésoins achat
Retour Conservation
Procedure
Retour des de
articles regularisation

2) MODELE LOGIQUE DES DONNEES (MLD)
Le modèle conceptuel des données fournit une représentation des données sans souci
d’implémentation en machine. Son formalisme est commode pour les utilisateurs et sa
structure n’est pas remise en cause par un changement matériel ou logiciel.
La transformation du MCD en MLD implique donc le choix d’un formalisme de référence
pour la description des données au niveau logique. Actuellement, en matière de logiciel de
base de données, nous assistons à une mutation vers les logiciels dits « relationnels ». Etant
donné que le département informatique dispose du SGBD (Système de gestion de Base de
Données) Microsoft SQL Server2000, de type relationnel, nous passerons au MLD
relationnel.
Les règles de passage sont les suivantes :
Une propriété du MCD devient un attribut du schéma relationnel

Une entité du MCD devient une relation (Table). L’identifiant de l’entité devient la
Clé primaire.
Une association binaire, non porteuse de propriétés, traduisant une dépendance
fonctionnelle, se traduit par un attribut supplémentaire de la relation cible.
Une association binaire, porteuse de propriétés se transforme en relation.
L’identifiant de la relation est obtenue par concaténation des identifiants qui
participent à la relation.

Modèle Logique de Données

3) MODELE PHYSIQUE DES DONNEES (MPD)

Le modèle physique des données nous permettra d’avoir une vue détaillée des différentes
tables et d’évaluer le volume de notre base de données.
Description des tables
Table : FOURNISSEUR Taille (Caractères) : 90

Rôle : Enregistrement des fournisseurs Nombre d’occurrence : 2500
Clé primaire : NumFour
Clé secondaire :
Code Type Taille Observation
NumFour AN 9
NomSociete AN 15
TelFour N 8
AdressFour AN 20
EmailFour AN 15
FaxFour N 8
VilleFour A 15
Table : DEMANDEPRIX Taille (Caractères) : 7

Rôle : permet d’avoir des informations Nombre d’occurrence : 16000
sur l’article dont on demande le prix
Clé primaire :
Clé secondaire : NumCot+NumDetPJC
NumCot AN 5
NumDetPJC N 2
Table : PROPOSECONTRAT Taille (Caractères) : 54

Rôle : Enregistrement des fournisseurs Nombre d’occurrence : 150
retenus pour les achats contrats
Clé primaire :
Clé secondaire : NumFour+CodArt+DatDeb
NumFour AN 9
CodArt AN 6
DatDeb D 10
StatutFour A 1
Rang N 1
PUPropose M 8
NumProf AN 9
DateFin D 10
Table : CORRESPONDANT Taille (Caractères) : 80

Rôle : Enregistrement des correspondants Nombre d’occurrence : 2500
Clé primaire : NumCorresp

Clé secondaire : NumFour

NumCorresp AN 5
NumFour AN 9
NomCorresp A 15
AdressCorresp AN 20
TelCorresp N 8
FaxCorresp N 8
EmailCorresp AN 15
Table : ETATCDE Taille (Caractères) : 36

Rôle : Savoir l’état d’une commande Nombre d’occurrence : 4000 x 2
à un niveau et à une date donnée
Clé primaire :
Clé secondaire : NumCde+NumCircuit
NumCde AN 9
NumCircuit N 2
DatVCde D 10
HeureVCde H 5
EtatCde A 10
Table : COMMANDE Taille (Caractères) : 26

Rôle : Enregistrement des commandes Nombre d’occurrence : 4000
Clé primaire : NumCde
Clé secondaire : CodReglement + CodeTypCde
NumCde AN 9
CodeTypCde AN 5
CodReglement AN 2
DatCde D 10
Table : LIVRER Taille (Caractères) : 43

Rôle : Enregistrement des articles de livraison Nombre d’occurrence : 8000
Clé primaire :
Clé secondaire : NumCde+LigLiv+NumIntLiv+ CodArt
NumCde AN 9
LigLiv N 2
NumIntLiv AN 5
CodArt AN 6
Designation A 15
QteArtLiv N 4
StatutArt A 2
Table : DETAILSCOTATION Taille (Caractères) : 81
Rôle : Enregistrement des articles Nombre d’occurrence : 16000 x 6
de cotation
Clé primaire : NumDetCot

Clé secondaire : NumCot+NumIntern+ CodArt+CodEtLig

NumCot AN 5
NumIntern AN 5
CodArt AN 4
CodEtLig N 2
NumDetCot N 2
CodArt AN 4
RefACot AN 4
LibACot A 15
QteACot N 4
UGACot A 3
RemACot N 5
PUACot M 8
GarantACot A 20
Table : DETAILSPJC Taille (Caractères) : 58

Rôle : Enregistrement des articles Nombre d’occurrence : 6000 x 6
pour un PJC
Clé primaire : NumDetPJC
Clé secondaire : NumOrdre +CodArt+ NouvLig
NumDetPJC N 2
NumOrdre N 8
CodArt AN 6
NouvLig AN 8
RefArtPJC AN 4
DesArtPJC A 15
QteArtPJC N 4
UGArtPJC A 3
PUArtPJC M 8
Table : VALIDERPJC Taille (Caractères) : 28

Rôle :Pour la validation du Nombre d’occurrence : 6000 x 5
PJC
Clé primaire :
Clé secondaire : NumOrdre+CodUser
NumOrdre N 8
CodUser N 5
Date D 10 jj/mm/aaaa
Heure H 5 HH :mm
Table : CIRCUITCDE Taille (Caractères) : 12

Rôle : Différentes étapes Nombre d’occurrence : 4000 x 2
d’une commande

Clé primaire : NumCircuit

Clé secondaire :
NumCircuit N 2
LibCircuit A 10
Table : UTILISATEUR Taille (Caractères) : 52

Rôle : Enregistrement des utilisateurs Nombre d’occurrence : 115 x 3
par service
Clé primaire : CodUser
Clé secondaire : CodServ
CodUser AN 5
CodServ AN 6
Matricule N 6
Nom A 15
Prenom A 20
Table : VALIDITER Taille (Caractères) : 13

Rôle : Nombre d’occurrence : 4
Clé primaire :
Clé secondaire : CodUser+CodEtape
Code Type Taill Observation
e
CodUser AN 5
CodEtap AN 8
e
Table : PREVOIT Taille (Caractères) : 26

Rôle : Saisie des prévisions annuelles par service Nombre d’occurrence : 115
Clé primaire :
Clé secondaire : CodArt+CodPeriode+CodServ+CodDepot
CodArt AN 6
CodPeriode AN 5
CodServ AN 6
CodDepot AN 5
QtePrevue N 4
Table : ARTICLE Taille (Caractères) : 40

Rôle : Saisie des articles Nombre d’occurrence : 15000
Clé primaire : CodArt
Clé secondaire : CodSFamille
CodArt AN 6

CodSFamille AN 4
LibArt A 15
PUArt M 8
StockArt N 4
UGArt A 3
Table : ETAPEPJC Taille (Caractères) : 20

Rôle : Enregistrement des étapes Nombre d’occurrence : 6000 x 5
possibles pour un PJC
Clé primaire : CodEtape
Clé secondaire : CodTypAch
CodEtape AN 8
CodTypAch A 1
OrdreEtape N 1
EtapePJC A 10
Table : SERVICE Taille (Caractères) : 27

Rôle : Enregistrement des différents services Nombre d’occurrence : 115
Clé primaire : CodServ
Clé secondaire : CodDept
CodServ AN 6
CodDept AN 6
LibServ A 15
Table : DEPOT Taille (Caractères) : 28

Rôle : Enregistrement des dépôts Nombre d’occurrence : 6
Clé primaire : CodDepot
Clé secondaire :
CodDepot AN 5
LibDepot A 15
TelDepot N 8
Table : SOUSFAMILLE Taille (Caractères) : 21

Rôle : Enregistrement des sous famille Nombre d’occurrence : 700
Clé primaire : CodSFamille
Clé secondaire : CodFamille
CodSFamille AN 4
CodFamille AN 2
LibSFamille A 15
Table : LIVRAISON Taille (Caractères) : 24

Rôle : Enregistrement des livraisons Nombre d’occurrence : 8000
Clé primaire : NumIntLiv
Clé secondaire :


NumIntLiv AN 5
NumLiv AN 9
DatLiv D 10
Table : DEPARTEMENT Taille (Caractères) : 27

Rôle : Enregistrement des différents départements Nombre d’occurrence : 19
Clé primaire : CodDept
Clé secondaire : CodDir
CodDept AN 6
CodDir AN 6
LibDept A 15
Table : FAMILLE Taille (Caractères) : 17

Rôle : Enregistrement des différentes familles Nombre d’occurrence : 108
d’article
Clé primaire : CodFamille
Clé secondaire :
CodFamille AN 2
LibFamille A 15
Table : DIRECTION Taille (Caractères) : 21

Rôle : Enregistrement des différentes directions Nombre d’occurrence : 15
Clé primaire : CodDir
Clé secondaire :
Code Type Taill Observation
e
CodDir AN 6
LibDir A 15
Table : TYPEACHAT Taille (Caractères) : 16

Rôle : Enregistrement des types d’achat Nombre d’occurrence : 4
Clé primaire : CodTypAch
Clé secondaire :
CodTypAch A 1
LibTypAch A 15
Table : ETATLIGN Taille (Caractères) : 13

Rôle : Enregistrement des états possibles Nombre d’occurrence : 2
pour un article de cotation
Clé primaire : CodEtLig
Clé secondaire :
CodEtLig N 3
EtatLig A 10

Table : DATE Taille (Caractères) : 10

Rôle : Enregistrement des dates de début d’exercice Nombre d’occurrence : 115x2
+150
Clé primaire : DateDeb
Clé secondaire :
DatDeb D 10
Table : COTATION Taille (Caractères) : 20

Rôle : Enregistrement des cotations Nombre d’occurrence :
16000
Clé primaire : NumCot
Clé secondaire :NumCorresp
NumCot AN 5
DatCot D 10
NumCorresp AN 5
Table : NOUVLIG Taille (Caractères) : 39

Rôle : Enregistrement des lignes des Nombre d’occurrence : 6000x6x2
articles de remplacement
Clé primaire : NouvLig
Clé secondaire :
NouvLig AN 8
NouvRefe AN 4
NouvDesig A 15
NouvUG A 3
NouvPU M 8
Choix A 1
Table : CONDITION Taille (Caractères) : 24

Rôle : Enregistrement des conditions Nombre d’occurrence : 160
pour une proforma
Clé primaire : CodCondition
Clé secondaire :
CodCondition AN 4
LibCondition A 20
Table : ACCEPTER Taille (Caractères) : 8

Rôle : Enregistrement de l’état d’une ligne Nombre d’occurrence : 1600

de proforma
Clé primaire :
Clé secondaire : NumIntern++LigProf
NumIntern AN 6
LigProf N 2
Table : MODREGLEMENT Taille (Caractères) : 12

Rôle : Enregistrement des différents modes de Nombre d’occurrence : 2
règlement
Clé primaire : CodModRegl
Clé secondaire :
CodModRegl AN 2
LibReglement A 10
Table : PROJETCDE Taille (Caractères) : 98

Rôle : Enregistrement des projets de commande Nombre d’occurrence : 6000
Clé primaire : NumOrdre
Clé secondaire : CodServ+CodTypAch+ CodDepot
NumOrdre N 8
CodServ AN 6
CodTypAch A 1
CodDepot AN 5
NumPJC AN 8
DatPJC D 10
RaisonPJC AN 50
DelaiPJC D 10
Table : COMMANDER Taille (Caractères) : 15

Rôle : Enregistrement des informations relatives à un article Nombre d’occurrence : 4000
commandé
Clé primaire :
Clé secondaire : NumCde+NumDetCot
NumDetCot N 2
NumCde AN 9
QteCde N 4
Table : PROFORMA Taille (Caractères) : 34

Rôle : Enregistrement des proformas Nombre d’occurrence : 16000

Clé primaire : NumIntern

Clé secondaire : NumCorresp+ CodCondition
NumIntern AN 6
NumCorresp AN 5
CodCondition AN 4
NumProf AN 9
DatProf D 10
Table : TYPECDE Taille (Caractères) : 15

Rôle : Enregistrement des types de commande Nombre d’occurrence : 4
Clé primaire : CodTypCde
Clé secondaire :
CodTypCde AN 5
LibTypCde A 10
Table : CONCERNER Taille (Caractères) : 14

Rôle : Détermine un fournisseur par PJC à une date donnée Nombre d’occurrence : 600
Clé primaire :
Clé secondaire : NumOrdre,NumFour
NumOrdre N 5
NumFour AN 9
Table : LIGNEPROF Taille (Caractères) : 2

Rôle : Détermine un article par proforma Nombre d’occurrence : 1600
Clé primaire : LigneProf
Clé secondaire :
LigneProf N 2
Table : LIGLIV Taille (Caractères) : 2

Rôle : Détermine un article par livraison Nombre d’occurrence : 1600
Clé primaire : LigLiv
Clé secondaire :
LigLiv N 2
Table : PERIODE Taille (Caractères) : 15

Rôle : Enregistrement des périodes Nombre d’occurrence : 120
Clé primaire : CodPeriode
Clé secondaire :
CodPeriode AN 5
LibPeriode A 10

TROISIEME
PARTIE
CHAPITRE3 : ETUDE TECHNIQUE

La taille de la base de données est estimée à 19 663 569 caractères soit 37,50 Mo par an.
I- PRESENTATION GENERALE DE L’APPLICATION

L’application sera conjointement utilisée par différents services. Cela requiert donc une
formule de distribution des ressources qui contenterait tous les utilisateurs, aussi nombreux
soient-ils. Eu égard à ces exigences, nous optons pour une architecture client/serveur.
I-1- Choix de l’architecture du système
Le système sera utilisé par plusieurs utilisateurs, souvent simultanément. Ce qui
nécessite un système de partage de ressources qui garantit à tous les utilisateurs satisfaction,
quel que soit leur nombre. Vu les exigences du système, nous optons pour une architecture
client/serveur.
I-1-1- Fonctionnement de l’architecture client/serveur
L'environnement client-serveur désigne un mode de communication à travers un
réseau entre plusieurs programmes ou logiciels : l'un, qualifié de client, envoie des requêtes ;
l'autre ou les autres, qualifiés de serveurs, attendent les requêtes des clients et y répondent.
En général, les serveurs sont des ordinateurs dédiés au logiciel serveur qu'ils abritent.
Ils sont dotés de capacités supérieures à celles des ordinateurs personnels en termes de
puissance de calcul, d'entrées-sorties et de connexions réseau. Les clients sont souvent des
ordinateurs personnels ou des appareils individuels (téléphone, tablette), mais pas
systématiquement. Un serveur peut répondre aux requêtes d'un grand nombre de clients.
Le client émet une requête au serveur en passant par un port de l’ordinateur pour
recevoir des informations (exemple : port 25 pour les mails, port 80 pour le web et 21 pour le
FTP).
Le serveur lui envoie ensuite les informations grâce à l'adresse IP de la machine cliente.
Figure32 : Architecture client serveur

I-1-2- Avantage de l’architecture client/serveur
L’architecture client/serveur est particulièrement recommandée pour des réseaux nécessitant
un grand niveau de fiabilité, ses principaux avantages sont :
 des ressources centralisées : étant donné que le serveur est au centre du réseau, il
peut gérer des ressources communes à tous les utilisateurs, comme par exemple une base
de données centralisée, afin d'éviter les problèmes de redondance et de contradiction
 une meilleure sécurité : car le nombre de points d'entrée permettant l'accès aux
données est moins important
 une administration au niveau serveur : les clients ayant peu d'importance dans ce
modèle, ils ont moins besoin d'être administrés
 un réseau évolutif : grâce à cette architecture il est possible de supprimer ou rajouter
des clients sans perturber le fonctionnement du réseau et sans modification majeure.
Nous garderons l’architecture Ethernet existante vu qu’elle répond à nos différents
besoin d’interconnexion. Cette architecture est la Topologie en étoile. Tous les équipements
du réseau sont directement reliés à un Switch qui constitue le nœud central par lequel
transitent toutes les transmissions. Cette topologie facilite la gestion du réseau vu ses
avantages suivants :

 possibilité de l'ajout des nœuds facilement

 facilité de localisation des pannes
 débranchement d'une connexion sans incidence sur le reste du réseau
 simplicité des stations extérieures. (c'est le nœud central qui est intelligent)
Ainsi, les micro-ordinateurs des différents services et les imprimantes seront mis autour d’un
serveur. La base de données sera installée sur le serveur de base de données de l’entreprise et
le logiciel client sur les postes des différents utilisateurs.
I-1-3- Inconvénient de l’architecture client/serveur

L'architecture client/serveur a tout de même quelques lacunes parmi lesquelles :
 le coût est élevé à cause de la technicité du serveur

 un maillon faible : le serveur est le seul maillon faible du réseau client/serveur, étant
donné que tout le réseau est architecturé autour de lui. S’il est défaillant l’architecture
ne fonctionne plus.
I.2. Choix du système d’exploitation

Les systèmes d’exploitation choisis pour les clients sont Windows XP et Windows 7 et
pour les serveurs sont Windows server 2003 et Windows server 2008, car ceux-ci possèdent
tous les utilitaires pour permettre à notre application de fonctionner correctement. En plus, la
plate-forme Windows est la seule utilisée à la SOGB.
II- CHOIX DES OUTILS DE REALISATION

II-1- Choix du système de gestion de base de données (SGBD)
Le système de gestion de base de données choisi est SQL SERVER 2008R2 et cela pour
les raisons suivantes :
 SQL Server est un SGBD transactionnel. Il est capable de préparer des
modifications sur les données d'une base et de les valider ou de les annuler d'un
bloc. Ceci garantit l'intégrité des informations stockées dans la base.
 L'utilisation des procédures stockées pour : la transaction de traitements complexes,

la sécurité accrue, la réutilisation des plans compilés (contrairement aux vues) et la
possibilité de gérer les dépendances entre le code SQL et les objets du moteur.
 Une gestion accrue des droits des utilisateurs.
 SQL Server possède un processeur d'optimisation des requêtes et des possibilités de

connectivité fiables et évolutives.
 L’intégration parfaite avec les autres produits Microsoft.
II.2. Choix de l’environnement de développement

L’environnement de développement choisi est le Visual Basic 2010 (VB10 ou VB.net). Ce
choix se justifie par la capacité qu’offre cet environnement à développer des applications
robustes avec des performances optimales. En effet, VB10 propose les outils pour développer
des applications hautement performantes qui ciblent la plateforme nouvelle génération de
Microsoft pour la programmation distribuée et compatible Internet. Ce langage de
programmation est simple. Il sait s’adapter à la manière de travailler de chaque programmeur.
Il permet d’identifier et d’éliminer plus rapidement les bogues, à l’aide d’outil de débogage

prenant en charge la programmation multicoeur. Il est typiquement orienté objet ce qui offre
une meilleure structuration de l’architecture de la programmation
II-3- CHOIX TECHNIQUES

Les choix techniques portent sur les matériels et logiciels nécessaires pour la mise en place et
l’exploitation du logiciel de Gestion des Approvisionnements
CHAPITRE4 : REALISATION DE L’APPLICATION

Il s’agit ici de décrire de façon claire et concise l’application, d’indiquer la sécurité qui a été
prévue
I-PRESENTATION DE QUELQUES ECRANS DE L’APPLICATION

I.1.Présentation de la Page d’accueil du logiciel
…………………………………………………………………………………………………
…………………………………………………………………………………………………
…………………………………………………………………………………………………
…………………………………………………………………………………………………
…
CONCLUSION
Ce stage dont le but était la mise en œuvre d’une application pour la gestion des
approvisionnements se termine avec le bilan des travaux suivant : nous avons terminé
l’analyse effectuée avec MERISE, les travaux d’implémentation la base de données sous
SQL Server2000 et de développement de l’application sous VisualBasic.NET sont en
cours.
Nous sortons beaucoup enrichis de ce stage. En effet ce stage nous a permis de mettre
en pratique les connaissances théoriques acquises au cours de notre formation et de nous
imprégner des réalités de l’entreprise notamment les relations humaines et la prise de
décision ; ce qui nous a amené à collaborer avec des responsables du monde industriel et
donc d’acquérir de nouvelles connaissances et méthodes de travail.
Ce stage a enfin contribué à la compréhension de certains détails de la conception, de
la programmation et des exigences du monde professionnel.
Vu donc l’importance que revêt l’informatique, toute entreprise devrait en être dotée afin
de faire face spontanément et efficacement aux besoins de ses clients.

Rapport de Stage

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport de Stage

Transféré par

Droits d'auteur :

Formats disponibles

Gestion des approvisionnements

LICENCE INFORMATIQUE DE GESTION 3ème ANNEE

CHAPITRE2 : PRESENTATION ET CHOIX DE LA METHODE…………

LICENCE INFORMATIQUE DE GESTION 3ème ANNEE

II-2- ANALYSE DES PROBLEMES

LICENCE INFORMATIQUE DE GESTION 3ème ANNEE

LICENCE INFORMATIQUE DE GESTION 3ème ANNEE

Tout le personnel du département Informatique à savoir

M.KOIDIO Jean Claude (maitre de stage) ;

LICENCE INFORMATIQUE DE GESTION 3ème ANNEE

LICENCE INFORMATIQUE DE GESTION 3ème ANNEE

LICENCE INFORMATIQUE DE GESTION 3ème ANNEE

LICENCE INFORMATIQUE DE GESTION 3ème ANNEE

CHAPITRE 1 : PRESENTATION DE LA SOGB

I - L’ENTREPRISE ET SES ACTIVITES

A la suite d’une augmentation de capital en avril 1984, la SO.G.B est devenue

Béréby finanace 65%

Etat ivoirien 15%

LICENCE INFORMATIQUE DE GESTION 3ème ANNEE

La SOGB gère différentes infrastructures sociales dont 19 villages appelés divisions,

La SOGB est localisée au sud-ouest de la Côte d’Ivoire, dans la région du Bas-

1- ROLE DES DIFFERENTES DIRECTIONS

LICENCE INFORMATIQUE DE GESTION 3ème ANNEE

Elle s’occupe de l’administration et des ressources humaines.

 DIRECTION DES RELATIONS EXTERIEURES (DRE)

DTA DPV DLI DARH DRE DAO DFC DAT DEA

LICENCE INFORMATIQUE DE GESTION 3ème ANNEE

III- INFRASTRUCTURES INFORMATIQUES

 SOGB 3 : serveur de messagerie, d’impression et d’application ;

 SRV2003 : serveur de Base de Données et de fichier ;

 SRV2008 : serveur de Base de Données et de fichier ;

Les systèmes d’exploitation utilisés pour les micro-ordinateurs sont Windows XP

LICENCE INFORMATIQUE DE GESTION 3ème ANNEE

La Direction de l’Aménagement et des Travaux  11 Ordinateurs HP

Tableau1 : Infrastructures matérielles des services concernés par l’étude

III-2- Présentation du réseau informatique

CHAPITRE2 : PRESENTATION ET CHOIX DE LA METHODE D’ANALYSE

 réalisation d’une application de gestion des approvisionnements de la SOGB;

 L’implémentation de ce système dans un environnement client/serveur.

I-2- Objectifs spécifiques

LICENCE INFORMATIQUE DE GESTION 3ème ANNEE

 Possibilité de retracer les demandes de commande et connaitre les différentes

II-CHOIX DE LA METHODE D’ANALYSE

II-1- présentation des méthodes d’analyse

Une méthode d'analyse informatique a pour objectif de permettre de formaliser les

II-1-1- méthodes Cartésiens

Les méthodes cartésiennes analytiques sont issues de la programmation structurée. Elles

Ses points forts sont :

II-1-2- Méthodes systémiques

LICENCE INFORMATIQUE DE GESTION 3ème ANNEE

structure (architecture) et les objectifs fonctionnels (fonctions). Elles préconisent la

Leurinconvénient est la faiblesse de la modélisation des traitements, mélange des contraintes

II-1-3- Méthodes objets

 objet difficile à appréhender

MERISE, Méthode d’Etude et de Réalisation Informatique par Sous-Ensembles, est

LICENCE INFORMATIQUE DE GESTION 3ème ANNEE

En d’autres termes, la méthode MERISE décrit le système d’information en fonction de trois

UML et le Processus Unifié

UML (UnifiedModelingLangage), langage de modélisation unifié en français, est né

LICENCE INFORMATIQUE DE GESTION 3ème ANNEE

o Le diagramme de classes représente les classes intervenant dans le système.

o Le diagramme d'objets (objet : instance d’une classe) sert à représenter les

o Le diagramme de composants permet de montrer les composants du système