Vous êtes sur la page 1sur 103

Rpublique Algrienne Dmocratique et Populaire

Ministre de l'enseignement suprieur et de la recherche scientifique


Universit Mouloud Mammeri de Tizi Ouzou
Facult de gnie lectrique et d'informatique
Dpartement d'informatique
Mmoire de fin d'tude
En vue de l'obtention du diplme
Master 2 en informatique.
Option: Conduite de Projet Informatique (CPI).


Thme
Conception et Ralisation dune application pilote pour la
gestion commerciale (cas : ELIT/SONELGAZ).


Encadrer par: Ralis par :
Mm TAOURI Dalila CHAMI - Mhand
Mr YOUSNADJ Boussad KHADRAOUI - Kamal

2013/2014

Sommaire :
Introduction... ...1
I. La phase dEtude ..1
I.1. Expression du besoin..1
I.2. Etude dOpportunit Analyse du ROI.2
I.2. Etude de Faisabilit ....2
II. La phase dInitialisation...3
II.1 Lancement du Projet...3
II.1. Organisation du Projet...4
III. La phase de Conception..4
III.1. Diagnostic de la situation 4
III.2. Recherche de Solutions ...5
III.3. Formalisation des Solutions.5
IV. La phase de Ralisation..6
IV.1. Prparation...6
IV.2. Excution.6
IV.3. Validation7
IV. La phase de Mise en uvre ...7
IV.1.Ralisation du site pilote...7
IV.2. Dploiement.8
IV.2. Assistance utilisateurs .8
Conclusion8
Chapitre II : ..9
Phase dEtude au sein dELIT..9
I. Organigramme de lentreprise 10
I.1.Prsentation de SONELGAZ ...10
I.2. Historique 11
I.3. Organisation du Groupe....12
I.4. Organisation de service commerciale au sein des socits SONELGAZ ...15
I.5. Prsentation de la structure daccueil : ELIT ...15
II. Etude dopportunit17
II.1. les bnfices en attendre 19
III. Etude de la faisabilit19
Conclusion..20
Chapitre III : ...21
Conception..21
I. Le Diagnostique...22
I.A. Approche par processus (Etude de lexistant) .22
I.A.1. Schma Gnrale de fonctionnement du service commercial ..22
I.A.3. Les diffrents Processus du Service Commerciale ...25
I.A.3.1. Tenu du fichier Client ....25
I.A.3.2. Prparation Commerciale ..25
I.A.3.3. Commande Client ..26
I.A.3.4. Facturation Client...26
I.A.3.5. Rglement client (Trsorerie) 27
I.A.3.4. Relance Client....27
I.A.5. Dtails des Fonctionnalits du service commercial ..28
I.A.5.1. Gestion des Clients 28
I.A.5.2. Edition des tats Clients ...29
I.A.5.3. Gestion des conventions cadre ..29
I.A.5.4. Gestion des avenants .30
I.A.5.5. Gestion des contrats de prestations ...30
I.A.5.6. Gestion des prestations/articles .31
I.A.5.7. Gestion des devis et des rvisions devis31
I.A.5.8. Gestion des Commandes32
I.A.5.9. Gestion des Factures Clients..32
I.A.5.10. Gestion des Relances Clients...33
II. Recherche des solutions et Objectifs..34
III. Description et Formalisation de la solution...35
III.a. Solution partag sous un rseau (intranet) .35
III.b. Modlisation de la solution ...36
III.b.1. Formalisation de laspect dynamique..36
III.b.1.1.Prsentation dUML..36
III.b.1.2.Prsentation du projet raliser37
III.b.1.3. Spcification des besoins & cas dutilisation ..37
III.b.1.3.1. Identification des acteurs..37
III.b.1.3.2. Identification des cas dutilisation ...38
III.b.1.4. Description cas dutilisation .......39
III.b.1.4.1. Gestion Des Clients...39
III.b.1.4.2. Gestion Des Commandes clients...40
III.b.1.4.3. Gestion des factures clients ..41
III.b.1.4.4. Gestion des produits 42
III.b.1.5. Les Diagramme de squences ..43
III.b.1.5.1. Diagramme de squence du cas dutilisation crer un client 44
III.b.1.5.2. Diagramme de squence du cas dutilisation modifier un client ..45
III.b.1.5.3.Diagramme de squence du cas dutilisation ajouter une commande46
III.b.1.5.4. Diagramme de squence du cas dutilisation ajouter un produit:..47
III.b.1.5.6 Diagramme de squence du cas dutilisation crer une facture.49
III.b.1.5.7 Diagramme de squence du cas dutilisation ajouter un utilisateur50
III.b.1.6.Diagrammes dactivit pour quelques cas dutilisation .51
III.b.2. Formalisation de la partie statique56
III.b.2.1. Prsentation du dictionnaire des donnes 56
III.b.2.2.Prsentation des classes association et methode 59
III.b.2.3. Diagramme de classe 61
Conclusion....63
Chapitre IV :.63
Realisation63
I. Prparation ...64
I.A. Mthode de Gestion de Projet SCRUM .64
I.A.1. Qu'est-ce que Scrum ?............................................................................................................64
I.A.2. Scrum, vue d'ensemble...65
I.A.3. Les rles dans Scrum..65
I.A.3.1.Le Product Owner65
I.A.3.2. Le scrummaster:..66
I.A.3.3.L'quipe...66
I.A.3. Le Backlog produit67
I.A.4. Le sprint:...68
I.B. Choix des outils technologiques ..68
I.B.1.Description des serveurs 68
I.B.1.1 Serveur de base de donnes.68
I.B.1.2 Serveur dApplication:68
I.B.2.JEE6 ..69
I.B.3.NetBeans IDE 7.4 .71
I.B.4. Frameworks de dveloppement71
I.B.4.1.Entreprise Java Bean : EJB 3.1 ..71
I.B.4.2.Java Persistance API : JPA.72
I.B.4.2.1 Dfinition ....72
I.B.4.2.2 les principaux services de lAPI JPA se sont ..72
I.B.4.2.3 certaines rgles qui doivent tre respect pour assurer la transformation des objets en
entits et ainsi devenir persistants ...73
I.B.4.3. Java Server Faces : JSF 2 .73
I.B.5. Architecture applicative74
II.Excution74
II.a. Application de la mthode SCRUM...75
II.b. Description de larchitecture de lapplication.77
II.b.1. les diffrents espaces...77
II.b.2 prsentation des fonctionnalits de lapplication .78
II.b.2.1. Commande et Facturation 79
II.b.2.2.Enregistrer les donnes de bases ...79
II.b.2.3. Facture .82
II.b.2.4. Edition de la facture .83
Conclusion .83

Remerciement

ous remercions Dieu le tout puissant qui nous a donn le courage et la volont
pour achever ce modeste travail
ous tenons remercier particulirement, notre promotrice Madame TAOURI
Dalila pour son aide, ses conseils, le suivi et lintrt quelle nous a apporte tout au
long de ce travail.
os remerciements vont galement tout le personnel dELIT de SONELGAZ,
particulirement Monsieur YOUSNADJ Boussad et Madame Bouali Nadia.
ous voudrions galement remercier vivement les membres du jury qui ont
aimablement accept dexaminer et estimer notre travail.
tous ceux qui nous ont conseills et encourags mais que nous navons pas pu
citer, quils trouvent ici lexpression de nos remerciements les plus sincres.

Ddicaces


Je ddie ce modeste travail :
A celle qui a berc mes rves : ma mre ;
A ce lui qui a nourri mes ambitions : mon pre ;
A mon ange gardien : mon frre ;
A celles qui ont soulev bien des fardeaux avec moi :
Mes surs ;
A ceux qui mont encourag et aid : mes amis ;
A celle qui sera fire de moi : ma famille ;
A mes collgues et leurs familles ;
A toute la promotion 2014 ;
Mhand
Ddicaces


Je ddie ce modeste travail :
A celle qui a berc mes rves : ma mre ;
A ce lui qui a nourri mes ambitions : mon pre ;
A mon ange gardien : mon frre ;
A celles qui ont soulev bien des fardeaux avec moi :
Mes surs ;
A ceux qui mont encourag et aid : mes amis ;
A celle qui sera fire de moi : ma famille ;
A mes collgues et leurs familles ;
A toute la promotion 2014 ;
Kamel




Liste des tableaux


Tableau 1: Schma Gnrale24
Tableau 2 : Fonctionnalits de Service Commercial27
Tableau 3 : fonctionnalit Gestion des Clients28
Tableau 4 : Edition des tats Clients29
Tableau 5 : Gestion des conventions cadre. 29
Tableau 6 : Gestion des avenants30
Tableau 7 : Gestion des contrats de prestation30
Tableau 8: Gestion des prestations/articles.31
Tableau 9 : Gestion des devis et des rvisions devis31
Tableau 10 : Gestion des commandes32
Tableau 11 : Gestion des Factures Clients33
Tableau12 : Gestion des relances Clients34
Tableau13 : Identification des acteurs37
Tableau14 : Liste des cas utilisations38
Tableau 15 : dictionnaire de donnes55
Tableau 16 : tableau association et methode..58





Listes des Figures

Figure1 : Les entres et sorties de la phase dtude..1
Figure2 : Les entres et sorties de la phase dinitialisation...3
Figure3 : Les entres et sorties de la phase de conception....4
Figure4 : Les entres et sorties de la phase de ralisation....6
Figure5 : Les entres et sorties de la phase mise en uvre ..7
Figure6 : Prsentation de SONELGAZ10
Figure7: Schma de lOrganisation..14
Figure8: Organisation de service commerciale15
Figure 9: Organigramme de la filiale ELIT16

Figure 10 : Organisation de la Direction Etudes et Dveloppement...17
Figure II : schma de larchitecture client/serveur 3 tiers...36
Figure13: Cas dutilisation Gestion des commandes clients...40
Figure14 : Cas dutilisation Gestion des factures clients.41
Figure 15: Cas dutilisation Gestion des produits42
Figure 16: Cas dutilisation Gestion des relances clients.43
Figure17: Diagramme de squence du cas dutilisation Crer un client 44





Figure18: Diagramme de squence du cas dutilisation Modifier un client45
Figure19: Diagramme de squence du cas dutilisation ajouter une commande.46
Figure20: Diagramme de squence du cas dutilisation ajouter un produit.47
Figure21: Diagramme de squence du cas dutilisation modifier un produit48
Figure22: Diagramme de squence du cas dutilisation crer une facture.49
Figure23: Diagramme de squence du cas dutilisation crer un utilisateur.50
Figure 24: Diagramme dactivit pour le cas dutilisation crer un client ..51
Figure 25: Diagramme dactivit pour le cas dutilisation modifier un client 52
Figure26 : Diagramme dactivit pour le cas dutilisation crer une commande.53
Figure27 : Diagramme dactivit pour le cas dutilisation crer un produit.54
Figure 28: Diagramme dactivit pour le cas dutilisation modifier un produit54
Figure 29: Diagramme dactivit pour le cas dutilisation crer une facture55
Figure30 : Diagramme de classe..61
Figure31 : Vue d'ensemble de Scrum65
Figure32 : le serveur java EE Glass Fish...69
Figure33 : Architecture dune application JEE..70
Figure 34: NETBEANZ 7.4...71
Figure35 : Architecture de SI GTR selon le design pattern MVC...74
Figure36 : Interface dauthentification...78



Figure37 : Interface Ecran daccueil des modules.78
Figure38: Interface module commande facturation...79
Figure39 : Interface Enregistrement de donnes de bases.79
Figure40 : Interface Ecran Gestion des clients 80
Figure41 : Interface Ecran ajout dun nouveau client80
Figure42 : Afficher dtails client81

Figure43 : Modification des informations client81

Figure44 : Interface module commande82
Figure45 : Interface module Facture..82
Figure46 : Edition de la facture ..83



Introduction Gnrale














Introduction Gnrale









Introduction Gnrale



De l'ge de la pierre nos jours, l'esprit perfectionniste de l'homme n'a cess de lui
permettre d'amliorer sa vie quotidienne. Le passage de la mcanique aux domaines
d'informatique, d'lectronique, d'automatique et de domotique a rvolutionn la vie
journalire de l'tre humain. Les nouvelles technologies de l'information et de communication
illustrent ce phnomne.
Aujourd'hui, vu l'intrt croissant de vouloir gagner du temps, de conserver les donnes, de
limiter le nombre d'employs et de plusieurs autres raisons, les petites, moyennes et grandes
entreprises se voulut pousses chercher des solutions informatiques capables de rpondre
leurs besoins.
Cest dans ce cadre destine tre gnralise par la suite dans dautres services. Sinscrit
notre projet de fin d'tudes qui consiste raliser une application pilote de gestion
commerciale pour le service commerciale dELIT (filiale de groupe SONELGAZ)
Pour atteindre notre objectif nous avons partag le travail comme suit :le premier chapitre
sagit de la pratique de la conduite de projet ,Le second chapitre s'agit de ltude qui compose
Spcification des besoins (organigramme daccueil)
Etude de lopportunit
Etude de faisabilit
Le troisime chapitre sera consacr la conception de l'application il s'agit des 3 phases
Diagnostique
Recherche des solutions
Et enfin formalisation des solutions
Pour de clore ce travail nous prsenterons les mthodes et outils utilises pour raliser
l'application et prsenter les rsultats obtenus dans le quatrime chapitre Ralisation.

Chapitre I Prsentation de la Conduite de Projet Informatique

1

Introduction
Un projet se compose de phases, elles-mmes dcoupes en tches, ou lots de travaux.
Chaque lot de travail se caractrise par la production dun livrable. Il en est de mme pour
chaque phase pour laquelle le livrable final valid par le sponsor permet dacter la russite de
celle-ci et de dcider le passage dans la phase suivante.
Rappelons que les diffrentes phases dun projet sont :
Phase 0 Etude
Phase 1 Initialisation
Phase 2 Conception
Phase 3 Ralisation
Phase 4 Mise en uvre
La ralisation de chaque lot de travail passe par lutilisation doutils techniques et de
livrables caractristiques.

I. La phase dEtude
Le succs de la phase dtude passe par la ralisation de trois tapes successives :
Expression du besoin
Etude dopportunit / Analyse du ROI
Etude de faisabilit


Figure 1 : les entres et les sorties de la phase dtude

I.1. Expression du besoin
Cette tape consiste traduire et formaliser lide de dpart en plan dactions concret. Cette
formalisation est ncessaire car elle permet de clarifier les objectifs du projet en :
Chapitre I Prsentation de la Conduite de Projet Informatique

2

Concrtisant lide de dpart, en la rendant comprhensible et accessible
tous.
Dgageant lintrt de lancer ltude en faisant apparatre ses avantages et
ses inconvnients pour les bnficiaires.
Dfinissant les consquences prvisibles des objectifs pour lenvironnement
interne ou externe lentreprise.
Cette formalisation doit tre le rsultat du travail du sponsor ou du matre douvrage : elle
prcde ltude dopportunit

I.2. Etude dOpportunit Analyse du ROI
Cette tape consiste dmontrer lintrt du projet, en termes de rentabilit conomique pour
lentreprise. Le besoin doit tre formalis au regard de lentreprise dans son environnement
concurrentiel et rglementaire.
La dmarche sarticule autour de sept questions selon le type de projet :
Le projet est-il stratgique pour lentreprise?
Que font le march et la concurrence?
Quelles sont les diffrentes contraintes pour lentreprise?
Quels gains en attendre (financier, image, service client, social)?
Pour quels cots?
Pour quel retour sur investissement?
Quels sont les risques faire le projet ou ne pas faire?
Une analyse du march est parfois ncessaire pour :
Analyser les conditions de mise sur le march;
Identifier les avantages concurrentiels de chaque acteur;
Evaluer la capacit du march absorber cette nouvelle offre.
I.2. Etude de Faisabilit
Ltude de faisabilit dun projet sapprcie sous plusieurs angles :
Technique : quelles sont les solutions techniques possibles?
Organisationnel : lentreprise dispose-t-elle des ressources humaines pour engager un
tel projet? La mobilisation des ressources en interne est-elle compatible avec les
missions oprationnelles de lentreprise?
Chapitre I Prsentation de la Conduite de Projet Informatique

3

Temporel : quelles sont les adhrences avec les projets en cours de droulement ou
planifis?
Systme dinformation et processus : en quoi le futur projet impacte-t-il le systme
dinformation actuel? les processus de pilotage? les processus oprationnels ? les
processus supports? Ltude de faisabilit permet ce stade didentifier et de dfinir
les scnarios de solution envisageables et dvaluer pour chaque scnario ses
avantages et inconvnients.
La dmarche de conduite dune tude de faisabilit sarticule autour de quatre tapes :
Analyse des impacts techniques, organisationnels, rglementaires, systme
dinformation, budgtaires;
Identification des scnarios possibles;
Choix dun scnario;
Recensement des lments de cots pour les premires estimations.

II. La phase dInitialisation
Le succs de la phase dinitialisation passe par la ralisation de deux tapes successives :
Le lancement du projet.
Lorganisation du projet.


Figure 2 : les entres et les sorties de la phase dinitialisation.

II.1 Lancement du Projet
Le lancement dun projet se fait partir dune note de lancement. Celle-ci officialise le
lancement du projet auprs de lensemble des responsables et des personnes concernes par le
projet dans lentreprise. La note de lancement est rdige et diffuse au dmarrage du projet.
Le document de lancement qui sera prsent lquipe projet doit reprendre les lments
suivants :
Chapitre I Prsentation de la Conduite de Projet Informatique

4

Le contexte du projet;
Le rappel des enjeux et de la problmatique;
Les objectifs fixs au projet;
Lorganisation du projet;
Les grandes tapes du projet;
Le budget;
Les facteurs cls de succs;
Les livrables pour chacun des acteurs impliqus sur le projet;
Les rgles et les mthodes qui seront utilises dans le cadre du projet.

II.1. Organisation du Projet
La manire de structurer le projet est capitale.

III. La phase de Conception
Le succs de la phase de conception passe par la ralisation de trois tapes successives :
Le diagnostic de la situation;
La recherche de solutions;
La formalisation des solutions.


Figure 3 : les entres et les sorties de la phase conception.

III.1. Diagnostic de la situation
Cette phase a pour objectif danalyser la situation existante afin didentifier, dans le cadre
dun projet de rorganisation, les diffrents axes damlioration. Dans cette perspective il est
Chapitre I Prsentation de la Conduite de Projet Informatique

5

important de bien comprendre le contexte et les enjeux pour lesquels la rorganisation est
souhaite par les dirigeants de lentreprise.
Le diagnostic doit permettre de recenser les forces et faiblesses de lorganisation existante et
den apprcier les effets quant la bonne marche de lentreprise ou de lentit concerne par
le diagnostic. Cette tape est capitale et conditionne la qualit des propositions de scnarios en
vue de lamlioration de lorganisation existante.
Elle permet didentifier les principaux processus en jeu et de dcliner ces processus en
activits afin de mieux comprendre les missions de chacun dans lorganisation.
Pour chaque activit il est utile didentifier et danalyser les dysfonctionnements.
Pour identifier et rsoudre les dysfonctionnements, ou problmes rencontrs, plusieurs
mthodes peuvent tre utilises :
La dmarche de rsolution de problme;
Lanalyse des causes/effets; chaque effet il convient de trouver la ou les causes
correspondantes. Les causes pouvant tre de plusieurs natures : humaines;
procdurales; culturelles; environnementales; organisationnelles

III.2. Recherche de Solutions
Le point dentre dans la recherche de solutions est le rsultat du diagnostic. Une bonne
connaissance de lexistant facilite la recherche de solutions. Les solutions retenues doivent
donner par ailleurs une rponse aux dysfonctionnements constats.
La rgle des 20/80 aide porter lattention sur limportance relative de diffrents faits en
mettant en vidence les enjeux majeurs.
La recherche de solutions demande souvent une certaine ouverture desprit et un travail
dquipe. Pour chaque solution, il est notamment ncessaire didentifier les impacts et
conditions de mise en uvre. Les principaux impacts sur lesquels il faut porter une attention
particulire sont les suivants :
Organisationnels : conditions de travail, structure, rattachement hirarchique ou
fonctionnel;
Humains : ncessit dune conduite du changement (formation, modification de
fonctions, communication interne ou externe, conditions de dploiement);
Systme dinformation : modification de certains processus, adaptation des outils de
production, refonte des procdures;
Juridique;
Chapitre I Prsentation de la Conduite de Projet Informatique

6

Logistique.

III.3. Formalisation des Solutions

Les solutions identifies doivent tre formalises dans un dossier de choix permettant de faire
le choix le plus adapt entre elles.
Les critres pris en compte sont souvent :
Le niveau thorique dadquation aux besoins exprims dans le cahier des charges;
Le retour sur investissement de chaque solution;
Un certain nombre de critres annexes :
Difficults techniques;
Attrait pour les utilisateurs, usagers, clients;
Facilit dentretien, de rparation, dvolutivit

IV. La phase de Ralisation
Le succs de la phase de ralisation passe par le droulement de deux tapes successives :
La prparation;
Lexcution.



Figure 4 : les entres et les sorties de la phase ralisation.

IV.1. Prparation
Cette tape comprend la planification des tches, la dfinition du programme et la
mobilisation des ressources.

IV.2. Excution
Cette tape consiste construire le produit fini qui rpondra aux objectifs assigns dans le
cahier des charges.

Chapitre I Prsentation de la Conduite de Projet Informatique

7

IV.3. Validation
Cette tape permet de sassurer de la conformit du produit du projet par rapport au cahier des
charges.
Il est ncessaire de prvoir dans la mesure du possible des sances de pr validation.


IV. La phase de Mise en uvre
Le succs de la phase de mise en uvre passe par la ralisation de huit tapes successives :
Lidentification des forces en prsence;
La stratgie de passage de gap;
La ralisation du site pilote;
Le dploiement;
Lassistance utilisateurs;
Les actions daccompagnement;
Les mesures de contournement;
La dissolution de la structure projet


Figure 5 : les entres et les sorties de la phase mise en uvre.


IV.1.Ralisation du site pilote

Dans les projets concernant de nombreux bnficiaires, il est prudent de procder un test
avant dploiement. Ce test appel site pilote permet dvaluer, en situation, la performance
Chapitre I Prsentation de la Conduite de Projet Informatique

8

du rsultat du projet et de raliser les ajustements ncessaires (favorisant le confort des
utilisateurs par exemple).

IV.2. Dploiement

Le dploiement intervient aprs que les rsultats du site pilote aient t valids par toutes les
parties prenantes. Il consiste installer dans chacun des sites concerns loutil, lorganisation,
les rgles de gestion dfinis dans le projet et tests dans le cadre du site pilote.
Le dploiement contient plusieurs aspects :
Aspects techniques : installation des machines, des matriels, des logiciels
Aspects humains : formation des utilisateurs, assistance sur place et/ou distance;
Aspects procdures : rdaction des guides de procdures, des rgles de contrle
interne

IV.2. Assistance utilisateurs

Lassistance utilisateurs consiste apporter une assistance distance grce au tlphone ou
Internet. Il est aussi possible la hot line de prendre la main sur le poste de travail
informatis des utilisateurs afin de raliser leur place certains paramtrages.


Conclusion
Dans ce chapitre nous avons prsent la conduite de projet informatique avec ces diffrentes
phases.







Chapitre II Etude

9






Chapitre II :
Phase dEtude au sein
dELIT










Chapitre II Etude

10

I. Organigramme de lentreprise
SONELGAZ est loprateur historique dans le domaine de la fourniture des nergies
lectriques et gazires en Algrie. Ses missions principales sont la production, le transport et
la distribution de llectricit ainsi que le transport et la distribution du gaz par canalisations.
Son nouveau statut lui donne la possibilit dintervenir dans dautres segments dactivits tels
que la commercialisation de llectricit et du gaz ltranger.
I.1.Prsentation de SONELGAZ
La restructuration de Sonelgaz en 2002 sest acheve avec la cration de la socit holding
Sonelgaz ainsi que lensemble des filiales. Sonelgaz est aujourdhui rig en Groupe
industriel compos de 35 filiales et 5 socits en participation.




Figure 6 : Prsentation de SONELGAZ.


Chapitre II Etude

11

I.2. Historique
Depuis sa cration le Groupe est pass par diffrentes phases dvolution dont nous
reprenons les principales dates :
1947 : Cration de lEtablissement Public National Electricit et Gaz dAlgrie, EGA
par le dcret du 5 juin 1947. Le 16 aot 1947, seize socits qui se partageaient les
concessions lectriques ont t transfres EGA. Ces socits dtenaient alors 90%
des proprits industrielles lectriques et gazires du pays.
1969 : Le 28 juillet 1969 la dissolution de lEGA et la cration de la nouvelle Socit
Nationale de lElectricit et du Gaz -SONELGAZ- fts dcrtes dans le cadre des
mesures de nationalisation des secteurs cls de lconomie nationale. Lordonnance
prcite a attribu la SONELGAZ le monopole de la production, du transport, de la
distribution, de limportation et de lexportation de llectricit et du gaz manufactur.
Lensemble des biens de lex EGA lui a t lgu.
1983 : Externalisation des activits de ralisation des travaux dans le cadre de la
restructuration de la SONELGAZ qui conduit la cration de six entreprises travaux
autonomes : KAHRIF pour llectrification; KAHRAKIB pour les travaux et montage
lectriques, KANAGAZ pour la ralisation des rseaux gaziers; INERGA pour la
ralisation des infrastructures, ETTERKIB pour le montage industriel et AMC pour la
fabrication de compteurs et appareils de mesure et de contrle.
2002 : Promulgation de la loi 02/01 le 5 fvrier 2002 relative llectricit et la
distribution du gaz par canalisations qui est venue supprimer le monopole exerc jusque-
l par SONELGAZ en ouvrant les activits de production et de distribution la
concurrence. En juin 2002, en vertu du dcret prsidentiel n02-195 le statut de
SONELGAZ passe dEPIC Socit Par Actions -SPA- dont le capital est dtenu par
lEtat.
2004 : Cration de trois filiales mtier de base : Sonelgaz Production Electricit SPE,
Gestionnaire Rseau Transport Electricit GRTE et celui du Gaz GRTG.
2006 : Cration de quatre socits de distribution : Alger SDA, Centre SDC, Est SDE
et Ouest SDO, et filialisation de lOprateur Systme OS.
2008 : Parachvement du processus de restructuration avec la filialisation des activits
Systmes dinformation ELIT, de lEngineering de llectricit et du gaz CEEG et la
gestion du patrimoine foncier SOPIEG.

Chapitre II Etude

12

I.3. Organisation du Groupe

SONELGAZ a toujours jou un rle prpondrant dans le dveloppement conomique et
social du pays. Afin de contribuer la concrtisation de la politique nergtique nationale,
elle a initi dimportants programmes en matire dlectrification rurale et de distribution
publique du gaz,qui ont permis de ramener le taux de couverture en lectricit 98% et celui
de pntration du gaz 43%.
Dtermine faire plus et mieux, la SONELGAZ a toujours mobilis des financements
importants afin de dvelopper et renforcer linfrastructure lectrique et gazire. Durant la
priode allant de 2005 2010, un programme dinvestissement exceptionnel a t mis en
oeuvre afin daugmenter ses capacits de production dlectricit, de densifier et rendre plus
robuste son rseau de transport et de moderniser ses services en faveur de la clientle.
Lambition de la
SONELGAZ est de devenir plus comptitif pour pouvoir faire face la concurrence et
compter parmi les meilleurs oprateurs du bassin mditerranen.
SONELGAZ a adapt son organisation aux principes et dispositions de la loi relative
llectricit et la distribution du gaz par canalisations. Elle sest restructure pour sadapter
au nouveau contexte. Ses organes de direction se sont renforcs pour mettre en oeuvre sa
stratgie et raliser ses objectifs.
SONELGAZ sest rige en Groupe Industriel compos de 40 socits dont 6 en
participation.
Le Groupe est constitu de la maison mre et des filiales. Ces dernires sont rparties par ple
de mtiers, savoir les filiales mtiers de base, les filiales mtiers priphriques et les filiales
travaux.
Ci-aprs les attributions, missions et principes dorganisation des diffrentes entits
constituant le Groupe :
Maison Mre : Elle est charge du pilotage et de llaboration de la stratgie du Groupe, du
contrle des filiales, de llaboration et la mise en oeuvre de la politique financire et de la
dfinition de la politique de dveloppement de la ressource humaine.
Filiales mtiers de base : Durant ces dernires annes, les mtiers de base de SONELGAZ
ont t filialiss. Au nombre de huit, ces filiales assurent la production de llectricit ainsi
que le transport et la distribution de llectricit et du gaz.
Filiales travaux : Les entreprises de ralisation institues en entreprises autonomes dans le
cadre de la restructuration de 1983 ont t rintgres au sein du Groupe depuis janvier 2006.
Chapitre II Etude

13

Elles sont spcialises dans la ralisation des infrastructures nergtiques : engineering,
montage industriel et ralisation des rseaux.
Filiales priphriques : SONELGAZ a externalis ses activits priphriques et en a fait
des filiales dont elle dtient entirement le capital. Ces filiales sont au nombre de quatorze et
exercent les prestations de services telles que la maintenance des quipements nergtiques,
lapprovisionnement et la distribution du matriel lectrique et gazier, le transport et la
manutention exceptionnels, ou encore la mise en uvre de systmes dinformation
Socits en participation : SONELGAZ dtient galement des participations dans des
socits dont le mtier est en rapport avec le domaine de llectricit et du gaz tels que la
production de llectricit ou encore la maintenance des turbines gaz.

I.3.1. Organigramme du Groupe
Le Groupe SONELGAZ est linstrument de mise en uvre, par le biais de ses socits filiales,
de la politique nergtique nationale. Lorganigramme suivant donne une vision claire de la
structure et de lorganisation de la socit :





























Chapitre II Etude

14















































Figure 7 : Schma de lOrganisation.




DIRECTION GENERALE

331*
Direction Planification et
Suivi de Projets

15
Secrtariat
(Mutualis)
03
Direction Progiciels de
Gestion Intgre
74*
Secrtaire de
Direction
02
Direction Exploitation SI

48
Direction Rseaux et
Tlcoms

28
Direction Finances /
Comptabilit
13
Direction Ressources
Humaines
12
Direction Commerciale 14
Service
Affaires Gnrales
07
Division Administration
Marchs
08
Assistant SIE
01
Assistant Direction
Gnral
01
Service
Communication
06
Direction Scurit des
Systme dInformation

24
Direction SI des Activits de
Distribution / Gestion de
Rseaux

74*
Chapitre II Etude

15

I.4. Organisation de service commerciale au sein des socits SONELGAZ




Figure 8 : Organisation de service commerciale.


I.5. Prsentation de la structure daccueil : ELIT

ELIT Spa El-Djazar Information Technology , est une filiale dite priphrique dont le
capital est 100% dtenu par SONELGAZ. Elle a t cre en janvier 2009. Les missions qui
lui ont t assignes par la Direction Gnrale du Groupe sont scindes en deux niveaux,
stratgique et oprationnel.
Au niveau stratgique, ELIT contribue la stratgie du Groupe par :
Llaboration de la politique des systmes dinformation et des technologies de
linformation et de la communication du Groupe.
La prise en charge des besoins du Groupe et des filiales en matire
dinformatique et de tlcommunications.
Au niveau oprationnel, ELIT semploie :
Elaborer et mettre en oeuvre les systmes dinformation destins au pilotage et
la gestion des diffrentes activits du Groupe.
Mettre la disposition de lensemble du Groupe les moyens informatiques et
de tlcommunications.
Chapitre II Etude

16

Assurer la maintenance et ladministration des systmes dinformation.
Assurer laccs linformation et aux applications et en garantir la scurit,
lintgrit et la fiabilit.
Mettre la disposition des utilisateurs lexpertise technique indispensable la
satisfaction de leurs besoins.
Proposer, terme, ces mmes services aux clients externes.
Lorganigramme suivant illustre la manire dont est organise la filiale ELIT :




Figure 9 : Organigramme de la filiale ELIT








Chapitre II Etude

17


I.5.1. Direction Etudes et Dveloppement (DED)

Nous effectuons ntre stage au sein de la Direction Etudes et Dveloppement. Cette
direction a pour mission de mener : ltude, la conception, le dveloppement et le dploiement
de solutions nouvelles et la mise en place des systmes dinformation du Groupe. En outre,
elle offre lassistance ncessaire et le suivi des solutions dployes.
Lorganigramme suivant reprend les diffrentes structures de la Direction Etudes et
Dveloppement :



Figure 10 : Organisation de la Direction Etudes et Dveloppement


II. Etude dopportunit

Le Groupe Sonelgaz est compos dun ensemble de socits, issues de la restructuration de
loprateur historique charg, pour le compte de lEtat, de la production du transport et de la
distribution de llectricit ainsi que la distribution publique de gaz, en Algrie.
La restructuration de Sonelgaz, a permis depuis quelques annes la cration dune socit
holding, dnomme Sonelgaz SPA et plusieurs filiales, toutes juridiquement autonomes les
unes des autres. Le Groupe Sonelgaz, ainsi constitu renferme actuellement 36 socits
activant dans divers secteurs, et comptant prs 80 000 salaris de diffrents profils et
catgories.
ELIT tant la filire IT et pour rpondre aux besoins des autres filiales du Groupe Sonelgaz,
sest lance dans plusieurs projets de dveloppement des systmes dinformations. Parmi
Chapitre II Etude

18

dautres le progiciel de gestion Finances et comptabilit baptis HISSAB , le progiciel de
gestion Ressources Humaines baptis NOVA , le systme de gestion des Stocks baptis
ATTAD , le systme de gestion de la trsorerie, le systme de gestion engagements,...etc.
Nanmoins, et pour rpondre davantages aux besoins des filiales du Groupe, dautres projets
de dveloppement sont mener afin de satisfaire les exigences non prise en charges par les
systmes existants.
Pour cela et parmi les besoins les plus pertinents surgit celui dun systme de gestion
commerciale pour le suivi des achats et des ventes des filiales du Groupe. Ce systme va
permettre dinformatiser les procdures de gestion en vigueur, dune part, et de les harmoniser
au niveau du Groupe dautre part. De ce fait les utilisateurs du systme, vont gagner en
productivit et en performance et bnficier de tous les avantages quoffre une application
informatique moderne.
Les risques lis aux mtiers des structures commerciales, son organisation et aux procdures
de gestion et on peut les list dans ce qui suit :
Lorganisation et lorganigramme des structures commerciales sont diffrents dune filiale
une autre selon limportance de lactivit commerciale dans la filiale, elle peut tre une
direction compose de plusieurs dpartements, une division ou bien un simple service. Pour
cela il faut trouver une organisation type implmenter dans le systme.
Les procdures de gestion sont htrognes, elles diffrent dune filiale une autre selon la
nature de ses activits et de son organisation interne. De ce fait il faut essayer dharmoniser la
faon de faire afin davoir un systme qui rpond aux besoins de toutes les filiales.
Les clients autour desquels opre lactivit commerciale sont diffrents dune filiale une
autre, en effet il existe des filiales qui travaillent exclusivement avec les clients du groupe
Sonelgaz, alors que dautres travaillent avec des clients hors-groupe Sonelgaz, voir mme
trangers. Le systme dvelopper doit prendre en considration tous les types de clients
possibles.
Les procdures de gestion sont instables, elles subissent des changements rgulirement et
Pour remdier cela il faut essayer de les prvenir et de ralise un systme paramtrable.
Le systme commercial doit interagir avec les systmes dj en place, pour cela il doit
respecter les conventions techniques dfinies pralablement (Architecture, outils et choix
technologique,) afin de faciliter linteraction avec les autres systmes. Le systme
commercial est au cur du systme dinformation de toute entreprise, il gre une relation
Chapitre II Etude

19

essentielle savoir la relation client/Entreprise, Ne pas avoir un systme informatis qui gre
lactivit commerciale empche lentreprise de bnficier de tous les avantages quoffre les
technologies modernes en matire defficacit et de transparence dans le travail, de
disponibilit dinformations, de la clart des procdures tches quotidienne accomplir.
II.1. les bnfices en attendre
Limplmentation de lapplication de gestion commerciale optimise lorganisation
commerciale de lentreprise et gnre un gain de temps synonyme de rentabilit.
Le retour sur investissement est en effet considrable et conduit lentreprise vers une
dmarche qualit en amliorant les process de travail.
Lapplication de gestion commerciale met laccent sur la qualit de traitement de
linformation.
Les analyses gnres par les informations contenues dans lapplication permettent en
effet de prendre les bonnes dcisions au bon moment.
Il est donc important de construire larchitecture de lapplication de manire
rationnelle et solide.
Lutilisation dun logiciel de gestion commerciale implique avant toute chose, une
gestion extrmement rigoureuse des informations saisies.
III. Etude de la faisabilit

Lentreprise est en relation avec ses clients et fournisseurs : devis, factures, bons de
commande sont autant de documents rptitifs crer.
Linformatique peut, dans ce domaine, simplifier la tche de lutilisateur grce une gamme
de produit spcifique : lapplication de Gestion Commerciale
Lapplication va permettre dorganiser les fichiers ncessaires de lentreprise lors de son
fonctionnement.
Ainsi, lentreprise, elle vende un produit ou un service, doit identifier ses clients et les rper-
torier dans un premier fichier. Lorsque ces prospects demandent une proposition
commerciale, lentreprise doit effectuer un devis pour les articles/prestations concerns.
Apparaissent alors trois nouvelles nomenclatures : les devis, les produits et leurs fournisseurs.
Pour finir, la vente est consigne dans une facture, elle aussi constituant un recueil de
donnes Cette chane commerciale est donc, au minimum, constitue de 5 fichiers diffrents :
produits, clients, fournisseurs, devis, factures/ventes.Lapplication de gestion commerciale va
permettre de grer toutes ces bases de donnes et les liens qui existent entre elles. Il est
Chapitre II Etude

20

intressant de retrouver, pour un client, les devis envoys, les ventes ralises, les fournisseurs
par produits, les rglements en cours, ceux effectus Toutes ces informations seront
facilement collectes dans un systme de gestion informatis

Conclusion
Avec ses dcennies dactivit dans le domaine de lnergie et une rputation qui nest plus
faire, la SONELGAZ est un acteur incontournable de lconomie nationale. Cette brve
prsentation nous a permis den savoir un peu plus sur le Groupe.
Par ailleurs, cette prsentation nous a fait comprendre lenvironnement, la structuration et
lorganisation de la Direction commerciale qui est la fonction cible du prsent projet.
Aussi, elle nous a permis de nous pencher sur linformatique du Groupe dsormais gre, au
niveau national, par la filiale ELIT .
Pour rpondre au dfi des changements induits par la loi 02/01 du 05 Fvrier 2002,
SONELGAZ a entrepris plusieurs initiatives denvergure visant aligner ses processus et
utiliser les technologies de linformation et de la communication pour soutenir sa stratgie. La
mise niveau et la modernisation de l'ensemble des systmes informatiques de gestion
figurent au premier plan des actions inscrites au Plan Stratgique de la SONELGAZ.



Chapitre III Conception
21









Chapitre III :
Conception
















Chapitre III Conception
22

Dans ce chapitre nous allons dcrire la conception de notre solution. Qui est reparties en 3
parties Diagnostique, recherche de solution et formalisation de la solution

I. Le Diagnostique

I.A. Approche par processus (Etude de lexistant)

Ltude de lexistant est une tape indispensable dans tout projet informatique, une bonne
conception doit reposer sur une connaissance du systme actuel.
Notre tude de lexistant portera sur la situation actuelle relative la gestion commerciale au
sien dELIT. Elle met en vidence tous les documents y circulant, les procdures de travail, le
circuit par lesquels circulent les informations ainsi que les ventuels problmes et
insuffisances. Afin de mieux comprendre le systme et son environnement et enfin de
proposer des solutions.

I.A.1. Schma Gnrale de fonctionnement du service commercial

























Chapitre III Conception
23

Client Service commercial Systme adjacents

















































































Ngociation
Facture de retenue
de garantie
OV/Avis de crdit
Rclamation/Erreur
facture
Facture de prestation
Commande
Demande prestation
Informations client
Signature
Devis/Rvision devis
Etablissement de la facture davoir
Enregistrement du rglement
Avec/Sans pointage des factures
concernes (Rapprochement)
Commande de prestation
Attestation de service fait
Facturation du service fait
Avec/Sans remise
Avec/Sans restitution montant davance
Etablissement de la facture de
retenue de garantie
Etablissement de la facture
davance
Tenu du fichier client
Signature des conventions cadre
Signature des contrats de prestation
Enregistrement de la demande du client
HISSAB
Systme de gestion
finance et
comptabilit

GTR
Systme de gestion finance
et comptabilit

Chapitre III Conception
24






























Tableau 1 : Schma Gnrale.





















Chapitre III Conception
25

I.A.3. Les diffrents Processus du Service Commerciale
1. Tenu du fichier client
2. Prparation commerciale
3. Commande client
4. Facturation client
5. Rglement client (Trsorerie)
6. Relance client

I.A.3.1. Tenu du fichier Client
La tenue du fichier client consiste centraliser la totalit des informations concernant chaque
client, afin dassurer un accs rapide et fiable et centraliser aux informations de chaque client.
La tenue du fichier client comporte les donnes suivantes :
Les informations didentification dun client (Code client, nom client, famille
client,.)
Les informations bancaires (banque, compte bancaire,.)
Les modalits des rglements (mode rglement, le dlai de rglement,)
Les renseignements fiscaux (N registre de commerce, N article fiscal,)
Les informations dordre comptable (Compte de crance, Compte davance)
Les informations sur le compte fournisseur, factures rgles et factures non
rgls
Un rcapitulatif des oprations entreprise avec le client (historique des
commandes, des factures, des avoirs, des rglements ainsi que lhistorique des
rceptions)
I.A.3.2. Prparation Commerciale
La prparation commerciale consiste enregistrer les donnes indispensables pour le traitement
commercial savoir les conventions cadres, les contrats et les demandes de prestations, les
devis et ventuellement les rvisions devis afin de traiter les commandes des clients.
La prparation commerciale regroupe les taches suivantes :
Enregistrement des conventions cadre
Enregistrement des contrats de prestations
Enregistrement des demandes de prestations
Enregistrement des devis et rvisions devis

Chapitre III Conception
26

I.A.3.3. Commande Client
Les commandes clients peuvent tre matrialises par :
Les bons de commandes :
Les lettres de commandes :
Les commandes :
Les marchs :
Les informations lmentaires dune commande sont : N commande, date commande, client,
article et/ou prestation,

I.A.3.4. Facturation Client
Une facture atteste de la vente de biens (articles) et/ou de services (prestations). Une facture
peut tre une facture de doit ou une facture davoir . Il peut y avoir plusieurs factures
pour une seule commande (Contrat/March)
Il existe plusieurs types de facturation :
Facture 100% : Le montant de la totalit de la prestation est pay aprs excution.
Facture davance : Facture pour un pourcentage prdfini dans le contrat.
Facture de retenue de garantie : Facture pour un pourcentage prdfini dans le contrat
Facture avec restitution davance : La facture comporte une retenue qui reprsente une
partie ou la totalit de lavance selon les conditions du contrat.
Facture avec retenue de garantie : Un pourcentage du montant est pay aprs excution de la
prestation. Le reste (100 pourcentage pay) reprsente la retenue de garantie qui est dfalque
du montant hors taxe de la facture, cette dernire peut tre rpartie en deux parties :
La premire partie de la retenue est librable aprs la rception provisoire
avec tablissement dune facture.
La deuxime partie de la retenue de garantie est librable aprs la rception
dfinitive (expiration du dlai garantie) avec tablissement dune facture.
Facture avec remise : Le prestataire peut accorder une remise au client, cette
dernire doit apparaitre sur la facture. Les dductions soprent sur le montant
hors taxe.




Chapitre III Conception
27

I.A.3.5. Rglement client (Trsorerie)
La fonctionnalit rglement client est assure au niveau du module Trsorerie. Toute fois une
consultation de la situation de client ainsi que ses rglements doit tre assure au profil du
gestionnaire commercial. Une facture est considre rgle au reu de son ordre de virement
(OV) ou de lavis de crdit.

I.A.3.6. Facturation Client
La relance des clients consiste mettre des lettres de rappel ou dans les cas extrme une lettre
de mise en demeure pour les clients qui ont accuss des retards pour le payement de leurs
factures. La relance ne concerne que les clients ayants des crances exigibles.
La crance est dite exigible si : La date en cous >= Date de remise + Dlai de rglement.
La lettre de relance doit mentionner : la date de son tablissement, le montant payer, le client
concern, lmetteur de la lettre,.
I.A.4. Les diffrentes Fonctionnalits du service commercial
PROCESSUS FONCTIONNALITES ( Par Processus)
Tenu du
fichier client
Gestion des clients : Crer, Modifier, Bloquer, Supprimer
Edition des tats de client : Fiche client, Liste des clients, Relev client
(dtaill et simple), Solde client
Prparation
commerciale
Gestion des conventions cadre
Gestion des contrats de prestations
Gestion des avenants
Editions des tats :
Gestion des articles/prestations
Gestion des modalits de rglement : dlais, mode rglement
Commande
client
Gestion des commandes des clients (Suivi des commandes)
Facturation
Gestion des factures des clients : Crer, diter, Modifier ltat,
Gestion des devis et des rvisions devis
Gestion des tats des factures
Edition des factures : Selon ltat, le fournisseur,..
Gestion des interfaces avec HISSAB
Chapitre III Conception
28

Rglement
client
Gestion des rglements clients
Gestion des modes de rglements
Gestion des interfaces avec GTR (Rapprochement)
Relance client Gestion des relances clients

Tableau 2 : Fonctionnalits de Service Commercial.

I.A.5. Dtails des Fonctionnalits du service commercial
Chaque fonctionnalit se reforme :
fonctionnalit : le nom de la fonctionnalit
processus : le processus qui elle appartient
niveau de traitement : niveau auquel se fait
priorit : priorit de dveloppement

I.A.5.1. Gestion des Clients
Fonctionnalit Gestion des clients
Processus Tenu du fichier client
Niveau de
traitement
Filiale
Priorit 1
Principes et rgles
et de gestion
La gestion des clients consiste en la cration, la modification, la
suppression et le blocage des clients.
Rgles de gestion :
Le client est unique dans lentreprise.
Il existe plusieurs familles de clients.
Les clients Sonelgaz sont traits de la mme manire que les clients
externes.
Le client peut tre bloqu sil est jug mauvais.
NB : Les informations lmentaires du client sont jointes en annexe

Tableau 3 : fonctionnalit Gestion des Clients.



Chapitre III Conception
29

I.A.5.2. Edition des tats Clients
Fonctionnalit Edition des tats de client
Processus Tenu du fichier client
Niveau de
traitement
Filiale Direction rgionale - Unit
Priorit 1
Principes et rgles
et de gestion
Ldition des tats de client consiste imprimer la fiche client et les
diffrents tats relatifs aux clients sous divers format (PDF, Excel,)
Les tats relatifs aux clients sont :
Liste des clients ;
Relev client dtaill ;
Relev client simple ;
Solde client.

Tableau 4 : Edition des tats Clients.

I.A.5.3. Gestion des conventions cadre
Fonctionnalit Gestion des conventions cadre
Processus Prparation commerciale
Niveau de
traitement
Filiale Direction rgionale - Unit
Priorit 1
Principes et rgles
et de gestion
Les conventions cadres sont des accords signs entre le prestataire et le
client. La convention dcrit les natures des prestations et/ou biens fournis
et leurs modalits de mise en uvre en termes de taux et de dure.
Rgles de gestions :
Une convention concerne un et un seul client
Une convention peut avoir un ou plusieurs prestations et/ou articles
NB : Les informations lmentaires dune convention cadre sont jointes
en annexe

Tableau 5 : Gestion des conventions cadre.





Chapitre III Conception
30

I.A.5.4. Gestion des avenants
Fonctionnalit Gestion des avenants
Processus Prparation commerciale
Niveau de
traitement
Filiale Direction rgionale - Unit
Priorit 1
Principes et rgles
et de gestion
Lavenant fait lobjet de clauses additionnelles permettant dapporter des
modifications au contrat/convention pralablement tabli.
Rgles de gestions :
Un avenant fait rfrence un et un seul contrat/convention
Un contrat/convention peut tre tendu par un ou plusieurs avenants
NB : Les informations lmentaires dun avenant sont jointes en annexe
Tableau 6 : Gestion des avenants.



I.A.5.5. Gestion des contrats de prestations
Fonctionnalit Gestion des contrats de prestations
Processus Prparation commerciale
Niveau de
traitement
Filiale Direction rgionale - Unit
Priorit 1
Principes et rgles
et de gestion
Les contrats de prestations sont des accords signs entre le prestataire et
le client. Le contrat dcrit les natures des prestations et/ou articles fournis
et leurs modalits de mise en uvre en termes de taux et de dure.
Rgles de gestions :
Un contrat est associ un et un seul client
Un contrat peut contenir plusieurs prestations et/ou biens
NB : Les informations lmentaires dun contrat de prestation sont jointes
en annexe

Tableau 7 : Gestion des contrats de prestation.






Chapitre III Conception
31

I.A.5.6. Gestion des prestations/articles
Fonctionnalit Gestion des prestations/articles
Processus Prparation commerciale
Niveau de
traitement
Filiale Direction rgionale - Unit
Priorit 1
Principes et rgles
et de gestion
Les prestations commerciales reprsentent lensemble des services offerts
par la socit, tandis que les biens sont les articles vendus par la socit.
Rgles de gestions :
Une prestation/bien doit avoir un et un seul code
Chaque prestation/bien possde un prix unitaire (par dfaut).
NB : Les informations lmentaires dune prestation/bien sont jointes en
annexe

Tableau 8 : Gestion des prestations/articles.

I.A.5.7. Gestion des devis et des rvisions devis

Fonctionnalit Gestion des devis et des rvisions devis
Processus Facturation
Niveau de
traitement
Filiale Direction rgionale - Unit
Priorit 1
Principes et rgles
et de gestion
Un devis (ou facture pro-forma) est un document crit prsent par un
fournisseur proposant de vendre des biens et/ou des services des prix
qu'il s'engage ne pas modifier tant que l'acheteur n'a pas exprim son
intention de renoncer en faire l'acquisition et que la dure de validit
nest pas expire.
Rgles de gestions :
Un devis fait rfrence un et un seul client.
Le devis doit ncessairement contenir la liste des biens et/ou des
prestations fournis.
Le devis doit indiquer le dcompte dtaill, en quantit et en prix, de
chaque bien/prestation.
Le devis doit mentionner la somme payer Hors Taxes (HT) et Toutes
Taxes Comprises (TTC), en prcisant le ou les diffrents taux de TVA
appliqus.
Le devis possde une dure de validit exprime en jours partir de
la date de son tablissement.
NB : Les informations lmentaires dun devis sont jointes en annexe

Tableau 9 : Gestion des devis et des rvisions devis.
Chapitre III Conception
32

I.A.5.8. Gestion des Commandes
Fonctionnalit Gestion des commandes
Processus Prparation commerciale
Niveau de
traitement
Filiale Direction rgionale - Unit
Priorit 1
Principes et rgles
et de gestion
La gestion des commandes de commandes des clients consiste en la
cration, la modification et ldition des commandes.
Les commandes clients peuvent tre matrialises par :
Les bons de commandes : Toute opration dacquisition de biens ou
de services dont le montant est infrieur ou gal cent milles dinars
(100.000 DA), toutes taxe comprise.
Les lettres de commandes : Toute opration dacquisition de biens ou
de services dont le montant est infrieur ou gal cinq cent milles
dinars (500.000 DA), toutes taxe comprise et suprieur cent milles
de dinars (100.000 DA), toutes taxe comprise.
Les commandes : Toute opration dacquisition de biens ou de
services dont le montant est infrieur ou gal huit millions de dinars
(8.000.000 DA), toutes taxe comprise et suprieur cinq cent milles
dinars (500.000 DA), toutes taxe comprise.
Les marchs : Tout contrat dacquisition de biens ou de services dont
le montant est suprieur huit millions de dinars (8.000.000 DA),
toutes taxe comprise.
NB : Les informations lmentaires dune commande sont jointes en
annexe

Tableau 10 : Gestion des commandes.











Chapitre III Conception
33

I.A.5.9. Gestion des Factures Clients
Fonctionnalit Gestion des factures clients
Processus Facturation
Niveau de
traitement
Filiale Direction rgionale - Unit
Priorit 1
Principes et rgles
et de gestion
Une facture est le document qui atteste lopration de vente de biens et/ou
de prestations de service. Cest un lment de preuve dune opration
commerciale, qui renseigne sur les biens vendus et/ou les prestations
rendues au client en termes de quantit et de prix.
Une facture peut tre une facture de doit ou une facture davoir .
Il existe plusieurs types de facturation :
Facture 100% : Le montant de la totalit de la prestation est pay
aprs excution.
Facture davance : Facture pour un pourcentage prdfini dan le
contrat.
Facture de retenue de garantie : Facture pour un pourcentage
prdfini dans le contrat
Facture avec restitution davance : La facture comporte une retenue
qui reprsente une partie ou la totalit de lavance selon les conditions
du contrat.
Facture avec retenue de garantie : Un pourcentage du montant est
pay aprs excution de la prestation. Le reste (100 pourcentage
pay) reprsente la retenue de garantie qui est dfalque du montant
hors taxe de la facture, cette dernire peut tre rpartie en deux
parties.
Facture avec remise : Le prestataire peut accorder une remise au
client, cette dernire doit apparaitre sur la facture. Les dductions
soprent sur le montant hors taxe.
Rgles de gestions :
Une facture fait rfrence un et un seul client.
La facture doit ncessairement contenir la liste des biens et/ou des
prestations fournis.
La facture doit indiquer le dcompte dtaill, en quantit et en prix,
de chaque bien/prestation.
La facture doit mentionner la somme payer Hors Taxes (HT) et
Toutes Taxes Comprises (TTC), en prcisant le ou les diffrents taux
de TVA appliqus.
La facture mis au client doit tre rgle dans un dlai mentionn
dans la facture en jours partir de la date de sa rception par le client.
Une facture est dite exigible si son dlai de rglement par le client
est expir.
Le client peut ventuellement rejeter la facture dans un dlai
dtermin (dans le contrat). Pass ce dlai, les arguments de rejet ne
seront pas recevables et la facture sera considre accepte par le
Client.
Il peut y avoir plusieurs factures pour la mme commande, en dautres
termes une facture peut solder la totalit ou bien une partie du
montant de la commande.
NB : Les informations lmentaires dune facture sont jointes en annexe

Tableau 11 : Gestion des Factures Clients.
Chapitre III Conception
34

I.A.5.10. Gestion des Relances Clients
Fonctionnalit Gestion des relances client
Processus Relance client
Niveau de
traitement
Filiale Direction rgionale - Unit
Priorit 1
Principes et rgles
et de gestion
La relance des clients consiste identifier les clients dont des factures
sont exigibles afin dentreprendre les dmarches ncessaires pour le
payement de leurs factures par lenvoi de lettres de relance ou dans les
cas extrmes des lettres de mises en demeure.
Les lettres de relances sont des lettres de rappel mises pour les clients
qui ont accuss des retards pour le payement de leurs factures.
Rgles de gestions :
Les lettres de relances concernent uniquement les factures dites
exigibles .
La lettre de relance doit mentionner la date de son tablissement et
les factures payer.
On peut mettre plusieurs lettres de relances pour les mmes factures
du mme client.


Tableau 12 : Gestion des relances Clients.

I.B. Listes des diffrents dysfonctionnements

Toutes les procdures de traitement de l'Information sont manuelles et par consquent
coteuses et source de beaucoup d'erreurs ;
Le retard dans la production des rsultats d au fait du traitement manuel ;
Cumul des fonctions d au manque de confiance envers le personnel et une
mauvaise organisation entranant parfois conflits de comptences ;
Gaspillage de la main d'uvre en utilisant plusieurs personnes produire une mme
tche
Baisse de rendement
Certains documents sont trs mal prsents ce qui rend difficile leur exploitation
aise ;
Il manque certains documents qui nous semblent trs important dans la gestion
commerciale tels que le Journal de vente, la solvabilit dun client,
Les documents sont mal codifis



Chapitre III Conception
35

II. Recherche des solutions et Objectifs
Aprs avoir analys le contexte du systme actuel, nous avons suggrs une solution
informatique pouvant remdier aux diffrentes lacunes souleves durant notre stage
La future application devra prendre en charge :
La commande et facturation
Le suivie des clients
LAdministration systme
Lensemble de ces processus devra rpondre aux fonctionnalits suivantes :
Gestion des clients
Gestion des produits
Gestion des socits
Gestion des directions
Gestions des units
Facture
Devis
Commande
Rglement clients.
Suivie client
Gestion des administrateurs
Edition
Le futur systme aura pour objectifs :
Rpondre aux besoins des gestionnaires.
Amliorer la gestion commerciale au niveau technique et fonctionnelle de
lentreprise.
Amliorer la gestion des fournisseurs.
Amliorer la gestion des clients.
Amliorer le suivi des ventes.

III. Description et Formalisation de la solution

III.a. Solution partag sous un rseau (intranet)
Vu que le futur systme concevoir doit tre d'une part, accessible par:
Les diffrents agents de service commercial
Les diffrentes structures de service commercial.
On a opt pour la : Conception et ralisation d'une application trois niveaux (3 tiers)
Chapitre III Conception
36

Lapplication renfermera trois modules applicatifs qui seront hbergs dans le serveur
dapplication
Lorganisation du travail entre les diffrents postes est donne par le schma suivant :
Architecture Client/serveur 3 tiers :


Figure 11 : schma de larchitecture client/serveur 3 tiers.

III.b. Modlisation de la solution
Dans cette partie nous allons formaliser notre solution. Qui est devis en deux parties
Formalisation de laspect dynamique
Formalisation de laspect technique

III.b.1. Formalisation de laspect dynamique
Nous allons, dabord, commencer par introduire lenvironnement de travail :
Langage de modlisation : Unified Modeling Language : UML.
Outil de modlisation : PowerAMC.




Chapitre III Conception
37

III.b.1.1.Prsentation dUML
UML (Unified Modelling Language) est la synthse des diffrentes notations que lon retrouve
dans : Booch de Grady Booch, OMT (Object Modeling Technique) de Jim Raumbaugh et
OOSE (Object-Oriented Software Engineering), de Ivar Jacobson.
UML est en particulier conu pour tre lisible sur des supports courants et
varis,comme le papier, les crans dordinateurs, etc.
UML propose 9 diagrammes de modlisation, rpartis sur trois axes du niveau conceptuel :
Fonctionnel.
Structurel.
Temporel.
III.b.1.2.Prsentation du projet raliser
Cest un logiciel qui doit grer la gestion des commercialisations au niveau de
lentreprise(SONELGAZ).Il doit permettre de suivre les vents des produits aux clients depuis
leur rception lentreprise.

III.b.1.3. Spcification des besoins & cas dutilisation
III.b.1.3.1. Identification des acteurs
Un acteur : Reprsente un rle que peut jouer lutilisateur dans le systme.
Lacteur est associ un cas dutilisation; cest dire quil peut interagir avec lui et participer
son scnario, il est reprsent par un personnage stylis.
Les acteurs de notre systme sont :
Acteur Rle
Client Fait une commande


Utilisateur de systme Gestion des clients
Gestion des commandes
Gestion des produits
Gestion des factures
Gestion des rglements clients
Gestion des relances clients
Gestion des avenants

Chapitre III Conception
38

Administrateur de systme Administrer le systme
Gestion des utilisateurs



Tableau 13: Identification des acteurs.

III.b.1.3.2. Identification des cas dutilisation

Un cas dutilisation reprsente un ensemble de squences dactions ralises par le systme et
produisant un rsultat observable intressant pour un acteur particulier [ROQ, 04].
Nous allons donner dans ce qui suit lidentification des cas dutilisation obtenues aprs
plusieurs itrations. Ensuite, nous allons prsenter les cas dutilisations, les diffrents acteurs
associs et leurs interactions avec le systme.
Liste des cas dutilisation :
Cas utilisation
01
Crer un client
02
MAJ un client
03
Consulter un client
04
Dsactiver un client
05
Ajouter une commande
06
MAJ une commande
07
Consulter une commande
08
Imprimer une commande
09
Crer une facture
10
MAJ une facture
11
Consulter une facture
12
Imprimer une facture
14
Ajouter un produit
15
MAJ un produit
16
Consulter un produit
17
Supprimer un produit
18
Crer un avenant
19
Consulter un avenant
20
Imprimer un avenant
Chapitre III Conception
39


































Tableau14 : Liste des cas utilisations

III.b.1.4. Description des cas d`utilisation
21
Rgularisation des clients
22
Gestion des relances clients
23
Crer une famille
24
MAJ une famille
25
Consulter une famille
26
Crer un utilisateur
27
Consulter un utilisateur
Chapitre III Conception
40

Dans ce qui suit nous proposons le diagramme des cas dutilisation en paquetages avec une
description textuelle, cette dernire elle permet d`avoir une ide sur le fonctionnement de
chaque cas d`utilisation.

III.b.1.4.1. Gestion Des Clients

Figure 12 : Cas dutilisation Gestion des clients
But : Ce cas dutilisation permet lUtilisateur System de gre les clients et fait les
ditions des tats clients.
Acteurs
Utilisateur de systme.
Description
Ds larrive dun client lutilisateur de systme crer une fiche client, Aprs
l'enregistrement de ces informations, l'utilisateur a le droit de mettre jour ou consulter ou
dsactiver, supprimer, dition des tats clients .
Le scnario de gestion des commande permet de
Uti l i sateurSystem
Gre l es cl i ents
Edi ti on des
etats cl i ents
Modi fi er un cl i ent
Crer un cl i ent
Affi cher un cl i ent
Dsacti ver un cl i ent
Rel ev cl i ent
Sol de cl i ent
Li ste cl i ent
Fi che cl i ent
Fi cher cl i ent word
Fi che cl i ent pdf
rel ev detai l l
rel ev si mpl e
Rechercher un cl i ent
Suppri mer un cl i ent
Chapitre III Conception
41

Crer un client
MAJ un client
Consulter un client
Dsactiver un client
Supprimer un client
Edition tats clients

III.b.1.4.2. Gestion Des Commandes clients


Figure 13 : Cas dutilisation Gestion des commandes clients

But : Ce cas dutilisation permet lUtilisateur de systme de cre, de mettre jour et de
consulter diter une Commande.
Acteurs
Utilisateur de systme
Description
A la rception de demande dachat lutilisateur va crer une nouvelle commande, remplit
les informations ncessaires sur la Commande cre. Aprs l'enregistrement l'utilisateur a le
droit de MAJ ou la consultation ou diter de Commande.
Le scnario de gestion des commande permet de :
Crer une Commande
MAJ une Commande
Ger l es commande cl i ent
Edi ti on des commandes
Crer une commande
Modi fi er une
commande
Commande pdf
Commande execl
Uti l i sateurSystem
Bon commande
Lettre de
commande
Contrat Conventi on cadre
Avenant
Chapitre III Conception
42

Consulter une Commande
Editer une commande
III.b.1.4.3. Gestion des factures clients


Figure 14: Cas dutilisation Gestion des factures clients

But : Ce cas dutilisation permet lUtilisateur de systme de cre, de mettre jour, diter et
de consulter ltat facture.
Acteurs :
Utilisateur de systme
Description Pour crer une facture, lutilisateur doit remplir les renseignements ncessaires
sur ce dernier. Aprs lenregistrement, lutilisateur a le droit de mettre jour ou consulter les
factures en cas derreur.
Le scnario de gestion des fournisseurs permet de :
Crer une facture
MAJ une facture
Consulter ltat de la facture
Editer une facture
III.b.1.4.4. Gestion des produits

Ger l es factures cl i ent
Edi ti on des factures
Crer une facture
Modi fi er l 'etat facture
Facture pdf
Facture execl
Uti l i sateurSystem
Ger l es etats des factures
Chapitre III Conception
43



Figure 15 : Cas dutilisation Gestion des produits
But : Ce cas dutilisation permet lutilisateur de systme de cre, modifier, mettre jour et
consulter un Bien.
Acteurs
Lutilisateur de systme
Description
Lutilisateur de systme enregistr des biens(produits) rceptionn. Aprs
l'enregistrement, l'utilisateur a le droit de mettre jour ou consulter ou supprimer.

Le scnario de gestion des Bien permet de
Crer un produit
MAJ un produit
Consulter un produit
Supprimer un produit



III.b.1.4.5. Gestion des relances clients :
Aj outer un produi t
affi cher l i ste produi t
Uti l i sateurSystem
Modi fi er un produi t
Suppri mer un produi t
Chapitre III Conception
44



Figure 16 : Cas dutilisation Gestion des relances clients

But : Ce cas dutilisation permet lutilisateur de systme denvoyer des lettres de relance ou
lettres des mises en demeure au client.
Acteurs :
Lutilisateur de systme

Description :
Lutilisateur de systme tablir des lettres de rappel mises pour les clients qui ont
accuss des retards pour le payement de leurs factures.

Le scnario de gestion des Bien permet de :
Envoi des lettres de relance.
Envoi des lettres de mises en demeure.
III.b.1.5. Les Diagramme de squences
Les diagrammes de squences permettent de dcrire les scenarios de chaque
cas dutilisation en mettant laccent sur la chronologie des oprations en interaction
avec les objets.
Ce type de diagramme insiste sur l'aspect temporel, ils sont formes avec des classes
traduisant la dynamique du systme et qui seront utiliss dans lactivit de conception.




III.b.1.5.1. Diagramme de squence du cas dutilisation crer un client

Uti l i sateurSystem
Ger l es rel ances cl i ents
Envoi des l ettres de rel ance
Envoi des l ettres des mi ses en demeure
Chapitre III Conception
45



Figure 17: Diagramme de squence du cas dutilisation Crer un client .










III.b.1.5.2. Diagramme de squence du cas dutilisation modifier un client

Cl i ent
sauvegarder
val i der
demande de conformati on
cl i ent est crer
(fami l l e,categori e)sel cti onner
sel ect categori e
sel ect fami l l e
aj outer un cl i ent
Uti l i sateur system
Cl i ent Fami l l e Nature
sauvegarder
val i der
demande de conformati on
cl i ent est crer
(fami l l e,categori e)sel cti onner
sel ect categori e
sel ect fami l l e
aj outer un cl i ent
Chapitre III Conception
46



Figure 18 : Diagramme de squence du cas dutilisation Modifier un client.







III.b.1.5.3.Diagramme de squence du cas dutilisation ajouter une
commande
Modfi er cl i ent
val i der
demande de confi rmati on
sauvegarder
modi fi cati on crer
(cl i ent,maj )sel ecti onner
sel ect modi fi er
sel ect cl i ent
modi fi er un cl i ent
Uti l i sateur System
Modi fi cati on Cl i ent MAJ
val i der
demande de confi rmati on
sauvegarder
modi fi cati on crer
(cl i ent,maj )sel ecti onner
sel ect modi fi er
sel ect cl i ent
modi fi er un cl i ent
Chapitre III Conception
47




Figure 19: Diagramme de squence du cas dutilisation ajouter une commande.



III.b.1.5.4. Diagramme de squence du cas dutilisation ajouter un
produit:
Commande
(fami l l e,qte,pri x,tva)sel ecti onner
aj outer qte pri x tva cmd
sauvegarder
val i der
demande de conformati on
commande est crer
sel ect fami l l e
aj outer une commande
Uti l i sateur system
Commande Fami l l e l i gne_cmd
(fami l l e,qte,pri x,tva)sel ecti onner
aj outer qte pri x tva cmd
sauvegarder
val i der
demande de conformati on
commande est crer
sel ect fami l l e
aj outer une commande
Chapitre III Conception
48



Figure 20: Diagramme de squence du cas dutilisation ajouter un produit.






III.b.1.5.5. Diagramme de squence du cas dutilisation modifier un
produit
Produi t
(categori e)sel ecti onner
produi t crer
val i der l a creati on
demande de confi rmati on
sel ect categori e
aj outer un produi t
Uti l i sateur System
Produi t Nature
(categori e)sel ecti onner
produi t crer
val i der l a creati on
demande de confi rmati on
sel ect categori e
aj outer un produi t
Chapitre III Conception
49




Figure 21: Diagramme de squence du cas dutilisation modifier un produit.








III.b.1.5.6 Diagramme de squence du cas dutilisation crer une facture
Modi fi er produi t
mi se a produi t
produi t sel ecti onner
sel ect produi t
modi fi er produi t
val i der
confi rmati on de l a maj
sauvegarder
l e produi t maj
Uti l i sateur System
produi t MAJ
mi se a produi t
produi t sel ecti onner
sel ect produi t
modi fi er produi t
val i der
confi rmati on de l a maj
sauvegarder
l e produi t maj
Chapitre III Conception
50




Figure 22: Diagramme de squence du cas dutilisation crer une facture.






III.b.1.5.7 Diagramme de squence du cas dutilisation ajouter un
utilisateur
Facture
(fami l l e,qte,pri x)sel ecti onner
aj outer qte pri x facture
sauvegarder
val i der
demande de conformati on
facture est crer
sel ect fami l l e
aj outer une facture
Uti l i sateur system
Facture Fami l l e l i gne_facture
(fami l l e,qte,pri x)sel ecti onner
aj outer qte pri x facture
sauvegarder
val i der
demande de conformati on
facture est crer
sel ect fami l l e
aj outer une facture
Chapitre III Conception
51



Figure 23: Diagramme de squence du cas dutilisation crer un utilisateur.






III.b.1.6.Diagrammes dactivit pour quelques cas dutilisation

Uti l i sateur
(profi l )sel ecti onner
uti l i sateur crer
val i der l a creati on
demande de confi rmati on
aj outer profi l
aj outer uti l i sateur
admi ni strateur
uti l i sateur Profi l
(profi l )sel ecti onner
uti l i sateur crer
val i der l a creati on
demande de confi rmati on
aj outer profi l
aj outer uti l i sateur
Chapitre III Conception
52

Le diagramme dactivit fait partie des diagrammes dUML utilise pour la modlisation des
aspects dynamique des systmes.



Figure 24 : Diagramme dactivit pour le cas dutilisation crer un client




Chapitre III Conception
53



Figure25 : Diagramme dactivit pour le cas dutilisation modifier un client




Chapitre III Conception
54



Figure 26 : Diagramme dactivit pour le cas dutilisation crer une commande
Chapitre III Conception
55




Figure 27 : Diagramme dactivit pour le cas dutilisation crer un produit


Figure 28 : Diagramme dactivit pour le cas dutilisation modifier un produit
Chapitre III Conception
56




Figure 29 : Diagramme dactivit pour le cas dutilisation crer une facture


III.b.2. Formalisation de la partie statique

III.b.2.1. Prsentation du dictionnaire des donnes
Dsignation Dsignation Type
Observation
Adresse_c Adresse client AN
100
Adresse_s Adresse socit AN
100
Agence Agence A
20
Article_fiscal Article fiscal A
20
Banque Banque AN
20
Capital_social_s Capital social socit AN
20
client_b Client bloqu A
50
Chapitre III Conception
57

code_c Code client AN
50
code_prest Code prestation/bien AN
50
Compte_bancaire Compte bancaire AN
50
Dara Dara A
20
Date_avenant Date avenant DATE
JJ/MM//AAAA
Date_com Date commande DATE
JJ/MM//AAAA
Date_contrat Date contrat DATE
JJ/MM//AAAA
Date_contrat_prest Date contrat prestation DATE
JJ/MM//AAAA
Date_conv Date convention DATE
JJ/MM//AAAA
Date_conv_cadre Date convention cadre DATE
JJ/MM//AAAA
Date_chance Date dchance DATE
JJ/MM//AAAA
Date_devis Date devis DATE
JJ/MM//AAAA
Date_fact Date facture DATE
JJ/MM//AAAA
Date_remise_fact Date remise facture DATE
JJ/MM//AAAA
Dbut_exct Dbut dexcution DATE
JJ/MM//AAAA
Dlai_prest
Dlai de prestation (en
jours)
N
100
Dlai_rgle Dlai de rglement N
100
Dlai_livrai Dlai livraison N
100
Dnom_abrge_fr_s
Dnomination abrge en
franais socit
A
50
Dnom_fr_s
Dnomination en franais
socit
A
50
Dure contrat Dure contrat( annes) N
50
Dure_conv Dure convention N
100
Dure_garan Dure de garantie( annes) N
2
Email_c Email client AN
20
Email_s Email socit AN
20
Exonr de TVA Exonr de TVA N
10
Famille_c Famille client A
20
Fax_s Fax socit N
15
Forme_jur_c Forme juridique client A
15
Forme_jur_s Forme juridique socit A
15
Id_fiscal Identifiant fiscal AN
50
Id_stat Identifiant statistique AN
50
Chapitre III Conception
58

Lib_prest Libelle prestation/article AN
50
Lib_prest Libelle prestation/bien AN
50
Lieu ralisation Lieu ralisation A
20
Mod_paie Modalits de paiement A
10
Mod_rgle Mode rglement A
10
Mont_contrat Montant contrat N
20
Mont_fact Montant de la facture N
20
Mont_TVA Montant de la TVA N
20
Mont_HT Montant HT N
20
Mont_pna Montant pnalit N
20
Mont_remise Montant remise N
20
MontTTC Montant TTC N
20
N art_fiscal_c N article fiscal client AN
30
N art_fiscal_s N article fiscal socit AN
30
N avenant N avenant N
30
N com N commande N
50
N contrat N contrat N
50
N Contrat_prest N Contrat prestation N
50
N conv N convention N
50
N conv_cadre N convention cadre N
50
N dem_prest N demande prestation N
50
N devis N devis N
20
N facture N facture N
20
N id_fiscal_c
N identifiant fiscal (NIF)
client
N
20
N id_fiscal_s
N identifiant fiscal (NIF)
socit
N
20
N id_stat_c
N identifiant statistique
client
N
20
N re_commerce_c
N registre de commerce
client
N
20
N reg_commerce_s
N registre de commerce
socit
N
20
N_abrg_c Nom abrg client A
20
N_c Nom client A
20
Obs Observation A
20
Chapitre III Conception
59

Priode_validit
Priode de validit (en
jours)
N
20
Prix unit Prix unitaire N
20
Quant Quantit N
10
Rf_demande_c Rfrence demande client AN
20
Registre de commerce Registre de commerce AN
30
Remise Remise % N
3
Sect_act_c Secteur dactivit client A
20
Sect_act_s Secteur dactivit socit A
20
Site_web_s Site web socit AN
15
TVA Taux TVA N
3
Tel_c Tlphone client N
10
Tel_s Tlphone socit N
10
Total_HT Total HT N
10
Type_prest Type prestation A
10
Unit_mesure Unit de mesure A
20
Valeur Valeur AN
100
Valeur_HT Valeur HT aprs remise N
10
Wilaya Wilaya A
15
Wilaya_c Wilaya client A
15

Tableau 15 : dictionnaire de donnes



III.b.2.2.Prsentation des classes association et methode
Attribut Description Type de
donne
Taille
code_ socit Code de socit AN 20
nom_socit Nom de socit A 50
adresse_socit Adresse de socit AN 100
forme_juridique Forme juridique de socit A 20
capitale_social Capital social de socit AN 20
tel_socit Tlphone de socit N 20
fax_socit Fax de socit AN 30
mail_socit Mail de socit AN 20
Siteweb Site web de socit AN 30
Chapitre III Conception
60

code_dr Code de direction AN 20
Nom_dr Nom de direction A 50
adresse_dr Adresse de direction AN 100
tel_dr Tlphone de direction N 20
fax_dr Fax de direction AN 30
mail_dr Mail de direction AN 20
code_unit Code unit AN 20
nom_unit Nom unit A 50
adresse_unit Adresse unit AN 100
tel_unit Tlphone unit N 20
fax_unit Fax unit AN 30
mail_unit Mail unit AN 20
id_client Identifiant client N 1
code_client Code client N 20
nom_client Nom client A 30
adresse_client Adresse client AN 50
tel_client Tlphone client N 20
mail_client Mail client AN 20
raison_sociale Raison sociale client AN 20
article_imposition Article dimposition client AN 20
id_fiscal Identifiant fiscal client AN 30
activite_client Activit client A 15
num_registre_co
m
Numro registre commerce AN 20
code_prod Code produit AN 20
nom_prod Nom produit A 50
famil_prod Famille produit A 50
qte_prod Quantit produit N 10
prix_prod Prix produit N 100
code_fact Code facture AN 15
code_client Code client N 20
Nom_client Nom client A 30
id_fiscal_client Identifiant fiscale client N 15
adresse_client Adresse client AN 100
code_produit Code produit AN 20
famil_prod Famille produit AN 50
qte_prod Quantit produit N 10
mont_tva Montant TVA N 50
Mont_ttc Montant TTC en lettre AN 50
Chapitre III Conception
61

code_client Code client N 20
nom_client Nom client A 30
nom_cmd Nom commande A 20
id_fiscal Identifiant fiscal client AN 30
adresse_client Adresse client AN 50
code_prod Code produit AN 20
famil_prod Famille produit AN 50
qte_prod Quantit produit N 10
prix_prod Prix produit N 100
qte_cmd Quantit commande N 10
prix_cmd Prix commande N 100
tva_cmd Tva commande N 50
qte_fact Quantit facture N 10
prix_fact Prix facture N 100
date_d Date de dbut unit DATE

Tableau 16 : tableau association et methode


III.b.2.3. Diagramme de classe
Le diagramme de classe constitue lun des pivots essentiels de la modlisation avec UML.
En effet, ce diagramme permet de donner la reprsentation statique du systme dvelopper.
Cette reprsentation est centre sur les concepts de classe et dassociation. Chaque classe se
dcrit par les donnes et les traitements dont elle est responsable pour elle-mme et vis--vis
des autres classes. les traitements sont matrialiser par des oprations.
La description du diagramme de classe est fonde sur :
Le concept dobjet,
Le concept de classe comprenant les attributs et les oprations,
Les diffrents types dassociation entre classe





Chapitre III Conception
62




Figure 30 : Diagramme de classe Globale.






1
1..*
1
1..*
1..*
1
1
1..*
1
1..*
1
1..*
1..*
0..*
1..*
1..*
1..*
1..3
1..*
1
1
1..*
1..*
1..*
1..*
1..*
1
0..*
Conventi on-cadre
-
-
pri x_produi t
qte_produi t
: Stri ng
: i nt
Contrat-prestati on
-
-
pri x_produi t
qte_produi t
: Stri ng
: i nt
Lettre-commande
-
-
pri x_produi t
qte_produi t
: Stri ng
: i nt
Bon-commande
-
-
pri x_produi t
qte_produi t
: Stri ng
: i nt
Commande
-
-
-
-
-
code_commande
date_commande
code_cl i ent
nom_cl i ent
type_cmd
: i nt
: Date
: Stri ng
: Stri ng
: Stri ng
Cl i ent
-
-
-
-
-
-
-
-
-
code_cl i ent
nom_cl i ent
adresse_cl i ent
fami l l e_cl i ent
tel
num_regi stre_commerce
scteur_acti vi te
emai l
i d_f
: Stri ng
: Stri ng
: Stri ng
: Stri ng
: i nt
: Stri ng
: Stri ng
: Stri ng
: Stri ng
Soci et
-
-
-
-
-
-
-
-
-
-
code_soci ete
nom_soci ete
adresse
tel ephone
si te_web
i d_f
secteur_acti vi te
capi tal _soci al
fax
num_regi stre_commerce
: Stri ng
: Stri ng
: Stri ng
: i nt
: Stri ng
: Stri ng
: Stri ng
: Stri ng
: Stri ng
: Stri ng
Di recti on-regi onal
-
-
-
-
-
-
-
-
code_dr
nom_dr
adresse
tel
si te_web
secteur_acti vi te
capi tal _soci al
fax
: Stri ng
: Stri ng
: Stri ng
: i nt
: Stri ng
: Stri ng
: Stri ng
: Stri ng
Uni te
-
-
-
-
-
-
-
-
code_uni te
nom_uni te
adresse
tel
si te_web
secteur_acti vi te
capi tal _soci al
fax
: Stri ng
: Stri ng
: Stri ng
: i nt
: Stri ng
: Stri ng
: Stri ng
: Stri ng
Produi t
-
-
-
-
-
-
-
-
code_produi t
nom_produi t
type_produi t
quanti t
pri x_uni tai re
val eur_ht
montant_tva
montant_ttc
: i nt
: i nt
: Stri ng
: i nt
: i nt
: i nt
: i nt
: i nt
Facture
-
-
-
-
-
-
-
-
-
code_facture
date_facture
code_cl i ent
nom_cl i ent
num_cp
date_cp
num_commande
date_commande
code_produi t
: Stri ng
: Date
: Stri ng
: Stri ng
: i nt
: Date
: i nt
: Date
: i nt
Facture-proformat
-
-
pri x_uni tai re
uni te_mesure
: Stri ng
: Stri ng
Facture-cl i ent
-
-
pri x_uni tai re
uni te_mesure
: Stri ng
: Stri ng
Payement
-
-
code_payem
nature_payem
: i nt
: Stri ng
Mode-regl ement
-
-
code_regl ement
dsi gnati on
: Stri ng
: Stri ng
Rel ance-cl i ent
-
-
-
num_facture
date_rel ance
type_rel ance
: i nt
: Date
: Stri ng
Avenant
-
-
-
-
-
num_avenant
date_avenant
obj et_avenant
num_contrat
date_contrat
: Stri ng
: Date
: Stri ng
: i nt
: Date
Li gne-comma
nde
-
-
-
Pri x
Qte
TVA
: i nt
: i nt
: i nt
Li gne-facture
-
-
pri x
Qte
: i nt
: i nt
Fami l l e-cl i ent
-
-
code_fami l l e
dsi gnati on
: Stri ng
: Stri ng
Date
-
-
date_debut
date_fi n
: Date
: Date
Chapitre III Conception
63

Conclusion

Ce chapitre a trait la conception du systme Systme dinformation pour la gestion
commerciale . Conformment la mthode standard de conduite de projet informatique, ce
chapitre a t divis en trois phases principales : Diagnostique, Recherche des solutions et
Formalisation des solutions. Chacun son tour, ces modles ont apport une prcision
supplmentaire en considrant le systme selon diffrentes approches : fonctionnelle, statique
ou encore dynamique, pour aboutir la fin une architecture globale du futur systme.
Cette phase de conception est incontournable pour envisager la ralisation dun systme
informatique. Les diagrammes qui y sont faits permettent daider la rflexion et dinstaurer
la discussion entre les clients et les dveloppeurs.




Chapitre IV Ralisation

63






Chapitre IV :
REALISATION






Chapitre IV Ralisation

64

Aprs avoir prsent dans le chapitre prcdant les diffrentes tapes de la phase conception,
nous allons prsenter dans ce dernier chapitre la phase ralisation qui se devise en deux
tapes :
Prparation
Excution

I. Prparation
Cette tape est une rflexion sur le choix des techniques et outils technologique et logiciels
utiliss pour dvelopper la solution.
Approche Gnie Logiciel
I.A. Mthode de Gestion de Projet SCRUM
I.A.1. Qu'est-ce que Scrum ?
"Scrum est une mthode agileddie la gestion de projets. Son objectif est d'amliorer
la productivit des quipes auparavant ralenties par des mthodologies plus lourdes."
[wikipedia]
Le principe de base de Scrum est de focaliser l'quipe de faon itrative sur un ensemble de
fonctionnalits raliser, dans des itrations de dure fixe de une quatre semaines, appeles
"Sprints". Chaque sprint possde un but atteindre, dfini par le directeur de produit
(appell aussi le product owner), partir duquel sont choisies les fonctionnalits
implmenter dans ce sprint. Un sprint aboutit toujours sur la livraison d'un produit partiel
fonctionnel. Pendant ce temps, le ScrumMaster a la charge de rduire au maximum les
perturbations extrieures et de rsoudre les problmes non techniques de l'quipe.




Chapitre IV Ralisation

65

I.A.2. Scrum, vue d'ensemble

Figure31 : Vue d'ensemble de Scrum

La figure ci-dessus nous donne une vue globale de processus de dveloppement avec la
mthode agile Scrum. Les diffrents points prendre en compte sont:

I.A.3. Les rles dans Scrum
En Scrum, comme reprsenter dans la figure 5.1, on distingue plusieurs rles et pour chacun,
des responsabilits et des tches accomplir:
I.A.3.1.Le Product Owner
Il sagit de la personne reprsentant le client.
Le Product Owner :
Reprsente toutes les personnes qui ont un intrt dans le logiciel qui sera produit.
Finance le projet.
Est responsable de ltablissement des besoins initiaux du projet qui sont lists dans
le backlog produit.
A des objectifs de retour sur investissement.
Dcide des releases, c'est dire des versions qui seront mises disposition des
utilisateurs.
Chapitre IV Ralisation

66

Est responsable de la mise jour du backlog produit. Il doit notamment classer
rgulirement les besoins exprims dans le backlog produit pour s'assurer que les
fonctionnalits qui gnreront le plus de valeur pour le logiciel seront implmentes
en priorit. Il doit galement mettre jour les besoins en fonction des incrments de
logiciel qu'il teste chaque fin de sprint.
I.A.3.2. Le scrummaster:
Ce rle semble simple mais il est en ralit dlicat apprhender car il diffre normment de
la culture projet traditionnelle. Le scrummaster n'est pas un chef de projet. Il n'a aucune
autorit hirarchique sur l'quipe. Il sagit plus dun rle de coach, et de facilitateur. Un
catalyseur de projet en quelque sorte.
Son rle est de :
Isoler l'quipe des perturbations extrieures en cours de sprint.
Apprendre la mthodologie Scrum l'quipe.
S'assurer que l'quipe respecte bien la mthode : que chacun fait bien du Scrum et
ne dvie pas vers d'anciennes mthodes connues et matrises.
Rpondre aux besoins de l'quipe.
Faire cadrer scrum dans la culture d'entreprise.
Travailler avec le product owner pour slectionner avec lui les besoins apportant le
plus de valeur ajoute au logiciel.
Il est responsable de la russite du projet, au mme titre que l'quipe.
I.A.3.3.L'quipe
Les responsabilits et le pouvoir de dcision sont transfrs du chef de projet (dans les
organisations traditionnelles) vers l'quipe. Ainsi l'quipe :
Dveloppe les fonctionnalits : elle transforme les besoins en incrments fonctionnels
de logiciel.
Est autogre et auto organise : c'est elle de dcider comment arriver au mieux
produire le logiciel partir des besoins exprims par le product owner.
Est multidisciplinaire. Si les spcialits persistent, elles sont toutes prsentes au sein
de l'quipe. Les mthodes d'estimation supposent que les personnes ne sont pas
Chapitre IV Ralisation

67

spcialises et que chacun est capable de remplir toutes les tches du backlog de
sprint.
Est responsable collectivement du succs de chaque itration. Toutes les cartes
sont entre ses mains pour russir.
I.A.3. Le Backlog produit
Le backlog produit est un des lments principaux de Scrum. Il s'agit d'un catalogue qui
recense toutes les fonctionnalits souhaites sur le projet. Il est cr par le product owner. Les
entres sont dcrites dans les termes du client, c'est--dire en termes mtier.
Le product owner priorise le backlog en fonction des lments qui reprsentent le plus de
valeur pour lui en assignant un chiffre qui reprsente l'importance de chaque lment. Plus le
chiffre est lev, plus le besoin est important ses yeux et doit tre dvelopp en priorit par
lquipe.
Le Backlog produit n'est pas un document fig, il est toujours vivant. Le product owner a la
possibilit de changer ce backlog a tout moment : ajouter ou enlever des lments, changer les
priorits, modifier les descriptions...

Tableau 17 : Le tableau de Backlog Produit
Chapitre IV Ralisation

68

I.A.4. Le sprint:
Un sprint est un dlai fixe durant lequel le logiciel est dvelopp par l'quipe. Scrum ne
recommande pas de dure de sprint prcise. La dure est de 2 semaines 4 semaines . Cest
lquipe de choisir une dure qui lui convient. Une fois qu'une dure est choisie, il est
ncessaire que cette dure devienne le dlai standard de tous les sprints.
Comme le reprsente la figure 7.1, le sprint comporte plusieurs phases :
La runion de planification du sprint: Se fait au dbut de chaque sprint, pour fixer et
planifier les objectifs de ce sprint.
se poursuit par le sprint en soi: Pendant lequel se fait les dveloppements et les tests
avec une runion quotidienne qui ne dpasse pas les 15 minutes. Pendant ce temps, Le
product owner peut faire voluer son backlog de produit.
En fin de sprint ont lieu la revue de sprint pendant laquelle l'quipe prsente le
logiciel produit et enfin la rtrospective du sprint pour essayer d'amliorer le
processus de dveloppement.
I.B. Choix des outils technologiques
On tait oblig de respecter les choix technologique adopts dj par ELIT. Ainsi les outils et
les mthodes utiliss
I.B.1.Description des serveurs
I.B.1.1 Serveur de base de donnes
Le serveur de la base de donnes utilis dans notre projet est PostgreSQL 9.0. Ce dernier est
un systme de gestion de bases de donnes Objet-Relationnel (SGBDRO). Il est disponible
pour de nombreuses plateformes, dont Linux, FreeBSD, Solaris, Windows et Mac OS X.
Cest un logiciel gratuit et open source. PostgreSQL est considr comme le SGBD non
commercial le plus avanc.
I.B.1.2 Serveur dApplication:
Le serveur dapplication que nous avons utilis est le Glassfish 3.1 qui est le successeur de la
version 3.0.X, offrant un runtime modulaire. Lui aussi, est un outil open source. La figure
suivante illustre la composition dun serveur dapplication.
Chapitre IV Ralisation

69



Figure32 : le serveur java EE GlassFish
I.B.2.JEE6

Il est souvent vrai que lorsque lon crit et que lon compile un programme pour un type de
systme il ne s'excutera pas sur n'importe quel autre systme car la spcification des services
fournis par le systme d'exploitation amne un problme de compatibilit. En effet, la plupart
des programmes ne sont pas portables, et cela provoque des problmes pour les utilisateurs
multiplateformes.
JAVA est un langage de programmation multiplateforme grce la machine virtuelle JAVA
(JVM) qui permet de contourner cette limitation. Ainsi les logiciels crits dans ce langage seront
trs facilement portables sur nimporte quelle machine indpendamment du systme
dexploitation. Cest un langage orient objet avec une riche bibliothque de classes traitant la
gestion des interfaces graphiques, exceptions, etc. En outre, JAVA simplifie laccs aux BDD
implmentes dans diffrents SGBD.
A la fin des annes 1990, est apparu Java Enterprise Edition (JEE, Java EE). Cest un ensemble de
spcifications destines aux applications dentreprise. JEE peut tre vu comme une extension du
langage Java afin de faciliter la cration dapplications rparties, robustes, performantes et haute
disponibilit.
Avec des partenaires industriels comme IBM, Sun Microsystems a conu JEE. Cette technologie
permet de crer des composants modulaires standardiss et facilement rutilisables, mais aussi de
grer de nombreux aspects de la programmation automatiquement. L'avantage tir dune
application conue avec JEE est de pouvoir cacher au client l'implmentation du code ct
serveur. On peut avoir deux types de clients dans ce cas :
Chapitre IV Ralisation

70

Client lger, client Web ou encore thin client : Ce client est entirement gr par un serveur. Il est
accessible en utilisant une interface web o la totalit de la logique mtier est traite du ct
serveur.
Le client lourd ou heavy client : Contrairement au client lger, il ne dpend du serveur que pour
l'change des donnes dont il prend gnralement en charge l'intgralit du traitement.
La technologie JEE occupe une place de plus en plus importante. Sa portabilit, sa scurit et ses
nombreuses API (Application Programming Interface) sont les lments principaux l'origine de
son succs. Les infrastructures web ont d s'adapter cette nouvelle technologie et de nouveaux
serveurs ont d tre mis en place. Limplmentation de cette spcification contient un ensemble
dextensions au Framework Java standard (JSE, Java Standard Edition) [LAFOSSE,
2009].
Notre objectif tant de proposer une application web performante tout en minimisant la
maintenance logicielle et permettre aux utilisateurs de profiter pleinement des avantages de
lapplication accessible depuis un client lger, nous avons choisi dutiliser le JEE.
Nimporte quelle application JEE suit larchitecture prsente dans la figure suivante :


Figure 33: Architecture dune application JEE






Chapitre IV Ralisation

71

I.B.3.NetBeans IDE 7.4

Un langage de programmation ncessite forcment un environnement dans lequel on va
dvelopper lapplication. Un IDE est un environnement de dveloppement intgr.
Il permet aux dveloppeurs de crer rapidement des applications Web, de bureau et des
applications mobiles et cela en utilisant la plateforme Java, ou encore PHP, JavaScript et
Ajax,
Groovy et Grails, et C et C ++.
Pour notre application, nous avons utilis l'IDE NetBeans qui est un environnement prim de
Dveloppement intgr. Il disponible pour diverses plateformes.


Figure34 : netbeans 7.4
I.B.4. Frameworks de dveloppement
Un framework est un ensemble cohrent de classes et dinterfaces collaborant pour fournir des
services la partie centrale dun sous-systme logique. Il contient principalement des classes
abstraites que lutilisateur devra spcialiser pour ses besoins fonctionnels propres, ainsi que des
interfaces auxquelles il lui faudra se conformer.

I.B.4.1.Entreprise Java Bean : EJB 3.1

Enterprise Java Bean (EJB) est la vritable particularit du dveloppement JEE. Il reprsente
larchitecture de composants logiciels ct serveur et une brique matresse de la plateforme de
dveloppement JEE.
Chapitre IV Ralisation

72

La spcification des EJB dtaille ce que le serveur applicatif fournit et propose un cadre pour
crer des composants dploys sur des serveurs distants crit en langage de programmation Java
et hbergs au sein d'un serveur applicatif permettant de reprsenter des donnes (EJB dit entit),
de proposer des services avec ou sans conservation d'tats entre les appels (EJB dit session), ou
encore d'accomplir des tches de manire asynchrone (EJB dit message).
Les EJB permettent aux dveloppeurs dviter de se proccuper de tout ce qui a trait au systme
(transactions, scurit, persistance, etc.). Pour tre dploys, les EJB ont besoin dun conteneur
qui est souvent intgr dans les serveurs dapplications tel quil a t reprsent prcdemment.

I.B.4.2.Java Persistance API : JPA

I.B.4.2.1 Dfinition
Java Persistance API est lAPI standard utilise pour la gestion des donnes persistantes
et le Mapping Objet/Relationnel. Cette API fait partie de la spcification EJB3 qui permet de
faire de la persistance de donnes.
Chaque serveur dapplication compatible avec JEE supporte le JPA. Bien quelle soit
couramment utilise dans le contexte dun serveur dapplication, JPA peut sintgrer a
toutes les applications JAVA. JPA cest un gage de qualit recommand par la communaut
Java EE mais qui nest pas vritablement loutil de persistance en lui-mme.
En effet, JPA repose sur des annotations Java et des techniques mettre en place, mais
laisse au dveloppeur Java le choix de son outil dimplmentation de persistance. Ainsi, les
classes et fichiers de configuration seront crits avec JPA et les persistances seront ralises
par un outil ddi sous forme de paquetages, comme EclipseLink ou Hibernate.

I.B.4.2.2 les principaux services de lAPI JPA se sont
Le mcanisme dORM permettant le mapping des donnes objet vers relationnel et
vice versa
Un gestionnaire appel Entity Manager pour la gestion des oprations comme le
pattern DAO et les oprations CRUD (Create : la cration, Read : la lecture, Update :
la mise jour et Delete : la suppression).
Un langage de manipulation des donnes appel Java Persistence Query Language
(JPQL) permettant de manipuler les donnes avec un langage orient objet.
Chapitre IV Ralisation

73

Un systme de transaction volu permettant des accs concurrentiels par
lintermdiaire de lAPI Java Transaction API (JTA). Les programmes Java SE avec des
ressources locales sont galement supports.
I.B.4.2.3 certaines rgles qui doivent tre respect pour assurer la
transformation des objets en entits et ainsi devenir persistants
Lobjet doit pouvoir tre persistant. Plus clairement, son tat doit pouvoir tre
reprsent par des donnes dans une base de donnes. Par exemple, les donnes de
type image, vido ou flux multimdia sont difficilement reprsentes pour la
persistance.
Les objets Java doivent possder une identit ou cl unique (primaire) permettant de
rfrencer de manire unique chaque instance. Ce concept est nouveau en objet car
lObject Identifier (OID) utilis de faon implicite doit ltre dsormais de manire
explicite en tant dclar dans la classe.
Les objets doivent tre transactionnels, cest dire pouvoir tre crs, modifis et
supprims. Les entits doivent ainsi respecter les contraintes de la JVM pour la
persistance.
Le principe dun Object Relationnal Mapping est de dlguer un outil tiers la tche
de correspondance entre les objets et tables. Le mapping permet alors de dvelopper
des classes sous forme dentits et dutiliser par transparence des bases de donnes
relationnelles. Typiquement, une entit reprsente une table dans une base de donnes
relationnelle et chaque instance dentit correspond une ligne de la table.

I.B.4.3. Java Server Faces : JSF 2
JSF est ax sur la demande web MVC base sur le composant modle, plus prcisment sur la
conception d'interface utilisateur en utilisant des fichiers XML appels modles ou vues
Facelets.
Les demandes sont traites par le Faces Servlet, qui charge le modle de vue appropri,
construit un arbre de composants et rend la rponse (gnralement HTML) au client. Ltat
des composants dinterface utilisateur est enregistr la fin de chaque requte, appel
stateSaving, et est restaur lors de la prochaine cration de cet avis.




Chapitre IV Ralisation

74


I.B.5. Architecture applicative

JEE est une plateforme multi-niveaux. Chaque niveau reprsente un partitionnement logique ou
fonctionnel du systme. Les applications 3tiers sont composes de 3 niveaux : la logique
d'affichage, la logique mtier et la logique de bases de donnes. La figure suivante reprsente
larchitecture 3tiers de notre application :




Figure 35 : Architecture de SI GTR selon le design pattern MVC


La couche Affichage est constitue dun ensemble de composants JSF. Les EJB session
permettent lchange des donnes entre la couche Affichage et la couche Mtier, la validation
des donnes et la gestion des transactions et des sessions des utilisateurs. Les EJB entits
reprsentent le modle des donnes qui seront persists dans la BDD grce lAPI JPA.


II. Excution
Dans la partie, nous allons prsenter :
Lapplication de la mthode SCRUM
Description de larchitecture de lapplication



Chapitre IV Ralisation

75


II.a. Application de la mthode SCRUM
Scnario ou story Priorit et
estimation d la
dure
Niveau utilisateur (cas
dutilisation)
Niveau dtaill
En tant que utilisateur du
systme je veux la gestion
des clients et consulter la
liste des clients
Priorit : A









Dure estim :
2 semaines
Raliser une interface
gestion des clients
-Construire le
formulaire de lajout
dun client
Et indiquer les
champs obligatoires

-Construire et
programm les
boutons consulter
modifier et
supprimer un client
(ce qui nous permet
la gestion des
clients)
Lister les clients dans
un tableau
-construire les
champs de
recherche dun client
selon son code ou
bien son nom

En tant que utilisateur du
systme je veux la gestion
des produits/prestation
et consulter les fiches
produits/prestation
Priorit : A



Dure estim :
2 semaines
Raliser une interface
gestion des
Produits/prestations
Construire le
formulaire de lajout
dun
produit/prestation
Et indiquer les
champs obligatoires

-Construire et
programm les
boutons afficher
informations,
modifier et
supprimer un
Produit/prestation
(ce qui nous permet
la gestion des
Produits/prestations)
Chapitre IV Ralisation

76

Lister les
produits/Prestation
construire les
champs de
recherche dun
produit/Prestation
selon son code, nom
bien sa dsignation

En tant que utilisateur du
systme je veux la gestion
des Socits, Directions,
Units
Priorit : B



Dure estim :
1 semaine
-Raliser une interface
gestion des Socits
(Priorit B1)
-Raliser une interface
gestion des Directions
(Priorit B2)
-Raliser une interface
gestion des Units
(Priorit B3)
Construire le
formulaire de lajout
dune (socit,
direction, Unit)
Et indiquer les
champs obligatoires

-Construire et
programm les
boutons afficher
informations,
modifier et
supprimer une
(socit, direction,
Unit)
ce qui nous permet
la gestion des
(socits, directions,
Units)

En tant que utilisateur du
systme je veux ajouter
une nouvelle commande
et consulter la liste des
commandes mises
Priorit : C



Dure estim :
1 semaine
-Enregistrement dune
nouvelle commande
Construire le
formulaire de lajout
dune nouvelle
commande
Et indiquer les
champs obligatoires

-Edition de la
commande
-imprimer la
commande
-Lister les commandes construire les
champs de
recherche dune
commande selon son
code ou bien la date

En tant que utilisateur du
systme je veux ajouter
une nouvelle commande
consulter et imprimer la
liste des factures


Priorit : c



Dure estim :
1 semaine
-Enregistrement dune
nouvelle Facture





Construire le
formulaire de lajout
dune nouvelle
Facture
Et indiquer les
champs obligatoires

Chapitre IV Ralisation

77












-Edition de la
commande

-imprimer la Facture

-Lister les factures construire les
champs de
recherche dune
Facture selon son
code ou bien la date

En tant
quadministrateur, je dois
pouvoir
Supprimer, ajouter et
modifier un usager du
systme

Priorit : D




Dure estim :
2 jours
Raliser une interface
gestion des
administrateurs
-Construire le
formulaire de lajout
dun Administrateur


-Construire et
programm les
boutons ajouter,
modifier et
supprimer un
administrateur (ce
qui nous permet la
gestion des
administrateurs)
-Lister les
administrateurs
construire les
champs de
recherche dun
administrateur selon
son nom, son code
ou bien sa fonction


Tableau 18: application de la mthode SCRUM.

II.b. Description de larchitecture de lapplication

Dans cette partie nous allons prsenter les fonctionnalits de lapplication travers ses
diffrentes interfaces

II.b.1. les diffrents espaces
a) espace Utilisateur
C'est l'espace ddi aux utilisateurs du systme (les agents commercial)

b) espace Administrateur
Cest lespace rserv ladministrateur du systme qui gre les comptes des utilisateurs

Chapitre IV Ralisation

78

II.b.2 prsentation des fonctionnalits de lapplication

Avant de pouvoir accder lapplication, lutilisateur doit dabord sauthentifier en utilisant les
paramtres de connexion qui lui ont t donns (login, mot de passe).



Figure36 : Interface dauthentification.




Suite lauthentification, lutilisateur est dirig vers la page daccueil qui comprend tous les
diffrentes fonctionnalits auxquels il a le droit daccder.






Figure37 : Interface Ecran daccueil des modules



Chapitre IV Ralisation

79

II.b.2.1. Commande et Facturation




Figure38 : Interface module commande facturation

La fonction Commande et Facturation reforme un ensemble de sous-fonction

II.b.2.2.Enregistrer les donnes de bases
Nous proposons lutilisateur la gestion de plusieurs donnes de base relative la gestion
commercial de SONELGAZ. La figure suivante apparait lorsque lutilisateur slectionne la
fonction Enregistre de donnes de bases



Figure39 : Interface Enregistrement de donnes de bases




Chapitre IV Ralisation

80


a- Interface Gestion clients





Figure40 : Interface Ecran Gestion des clients



b. Interface Ajout dun nouveau client




Figure41 : Interface Ecran ajout dun nouveau client.



Chapitre IV Ralisation

81


c. Afficher dtails client



Figure42 : Afficher dtails client.




d. Modification des informations client




Figure43 : Modification des informations client.

Chapitre IV Ralisation

82



II.b.2.2.commande

le module Commande est compos de la fonction commande client



Figure44 : Interface module commande



II.b.2.3. Facture



Figure45 : Interface module Facture



Chapitre IV Ralisation

83

II.b.2.4. Edition de la facture




Figure46 : Edition de la facture

Conclusion

En dpit de certains problmes rencontrs durant cette phase de ralisation, nous pouvons dire que
nous avons pu raliser la plus grande partie du travail qui nous a t confi.
A travers cette phase de ralisation, nous avons pu nous familiariser avec de nouvelles techniques
de programmation et la plateforme JEE.
Conclusion Gnrale










Conclusion Gnrale








Conclusion Gnrale





Ce projet tait bnfique pour nous dans plusieurs sens. Il nous a permis :
de nous perfectionner en amliorant nos connaissances en programmation et en
conception.
De bien comprendre et mettre en uvre le droulement d'un cycle de vie d'un logiciel.
De dcouvrir le monde de l'entreprise (fonctionnement).
Nous avons essay de raliser ce projet pour le but de faciliter l'entreprise en question,
d'amliorer la gestion et le suivi de ses clients.
On a appliqu au maximum possible les rgles de bases permettant d'avoir une application
performante. Nous avons appliqu UML pour concevoir une grande partie de notre travail.
Nous avons utilis aussi Java et Java/EE pour implmenter notre application.
Grce aux architectures que nous avons utilis (MVC et client/serveur) et du fait que Java/EE
est un langage adaptable dans plusieurs domaines, notre application peut avoir des extensions
ou des modifications dans le futur. Citons quelques-unes :
On peut lier cette application un site web dynamique qui nous permettra le suivi des
clients et des fournisseurs en ligne.
Implmenter la gestion des stocks et des ventes






BIBLIOGRAPHIE















[1] : LAFOSSE, Jrme. Dveloppements n-tiers avec Java EE.Eni dtions,1957,757 pages.

[2] : GABAY,Joseph et David GABAY .UML 2 analyse et conception.Dunod,2008,242 pages

[3] : Hardebolle, Ccile.Dveloppement web avec Java.Suplec,2010,62 pages.

[4] : PUYBARET,Emmanule.les Cahiers du Programmeur Java1.4 et 5.0 3e
dition,Eyrolles,2006,381 pages

[5] : GROUSSARD,Thierry. JAVA 6 Les fondamentaux du langage Java.Eni
ditions,2005,222 pages

[6] : GONCALVES,Antonio.les Cahiers du Programmeur Java EE 5. Eyrolles,2007,349.

[7] : HEFFELFINGER,David.Java EE 6 Development with NetBeans 7.Packt
publishing,2011,392 pages

[8] : GONCALVES,Antonio.Java EE 6 et GlassFish 3.Pearson,2010,572 pages

[9] : BARON,Mickal.Java pour le dveloppement dapplications Web Java EE.Get
powered,2010,175 pages.

[10] :YAMAK,Zaher.JPA Java PersistenceAPI,N.z,2010,50pages

Rfrences Web :

[11] : http : //www.siteduzero. Com.

[12] : http: //www.primefaces.org.

[13] : http: // www.wikipedia.fr.

[14] : http: //www. glassfish.org.

[15] : http: // www.netbeans.org.

[16] : http: // www.postgresql.org.

[17] : http: //www. codes-sources.com.

[18] : http: //www.jquery.com.

[19] : http: //www. bootstrap.org.

[20] : http: // www.scrum.com.



[Y.PRIE, 2005] : Yannick PRIE ; Introduction la conception de systmes d'information,
CoursM1- MIAGE , Universit Claude Bernard Lyon 1 : UFR Informatique, Lyon,
2005/2006.

[P.ROQUES, 2007] : Pascal ROQUES ; Les cahiers du programmeurs UML 2 : Modliser une
application web , Editiond EYROLLES, 2007.
[ROQ, 04] : Pascal ROQUES ; UML 2 en action, de lanalyse des besoins la conception
J2EE , 1re dition,2004.

[J.BARZIC, 2008] : Jacques BARZIC ; Les 13 diagrammes UML 2 , ebook 2008.

[P.ROQUES, 2002] : Pascal ROQUES et CHALMON ; collaboration de Martine, Les cahiers
du programmeur UML : Modliser un site e-commerce , Edition Eyrolles, 2002.




Rsum :

Il est indispensable pour lentreprise, davoir une connaissance parfaite de la situation
commerciale afin dviter toute situation litigieuse avec ses partenaires.
Le Groupe SONELGAZ, premier oprateur nergtique en Algrie, nchappe pas cette
rgle.
Il a dcid de revoir sa politique financire en adaptant ses systmes dinformation,
notamment dans le domaine de la gestion Commerciale par le dveloppement par moyens
propres dun nouveau Systme dInformation SIGC .
De plus, lentreprise a prvu un ensemble de fonctionnalits concernant sa gestion
commerciale qui ne seront pas intgres avec le SIGC, dans un premier temps. Ceci donnera
une visibilit sur les fonds de lentreprise, une meilleure gestion commerciale.
Notre travail consistait en le dveloppement de cette premire version du systme.
Lobjectif premier de notre tude tant de mettre la disposition du Groupe, un systme fiable
qui lui permette davoir une vue sur ses fonds, de grer ses flux de commercialisation et de
pouvoir contrler les oprations vents.
Pour ce faire nous avons dvelopp une application web trois tiers sur la plateforme de
dveloppement JEE6 avec le SGBDRO PostgrSQL.