Vous êtes sur la page 1sur 101

DEDICACES

Je ddie ce travail mon pre Raphal S. KOUTOU pour toute laffection dont jai
bnfici de sa part depuis ma tendre enfance.

A ma mre Madeleine KOUTOU/PAGABABELEM qui a toujours cru en moi et pour tous les
sacrifices qu'elle a consentis mon gard.

J'espre qu'ils trouveront dans ce travail toute ma reconnaissance.

A tous mes frres, oncles, tantes, amis et tous ceux qui ont contribu dune manire ou
dune autre la ralisation de ce document.

THEME : Gestion des marchs publics la SONAPOST

Page I

REMERCIEMENTS
Nos remerciements pour leurs soutiens et encouragements :
A ladministration de lISIG/Ouagadougou ;
Au corps enseignant de lISIG/Ouagadougou ;
Au Directeur Gnral de la SONAPOST ;
Au Directeur des Systmes dInformation de la SONAPOST, M. SOU Aristide ;
Au Directeur des Systmes dInformation du Conseil Burkinab des Chargeurs, M.
OUEDRAOGO Boukary ;
A mon matre de stage, M. BANHORO Siaka ;
A tout le personnel de la Direction du Patrimoine et de la Logistique de la
SONAPOST;
A tout le personnel de la Direction des Systmes dInformation de la SONAPOST.

THEME : Gestion des marchs publics la SONAPOST

Page II

RESUME
Ce document est le rapport dune tude sur la gestion des marchs publics la
SONAPOST. Il dcrit tout dabord le processus dlaboration et de passation des marchs
publics.
Ensuite, cette tude propose des solutions informatiques pour lautomatisation des
diffrentes tches de gestion des marchs publics. La mise en place dun tel systme procurera
de la valeur la SONAPOST. Cet apport peut se matrialiser par lamlioration des processus
de gestion des marchs publics, par lamlioration des prises de dcision, un suivi-valuation
en temps rel de lexcution des marchs.

ABSTRACT
This document is the report of a study on the management of public works contracts at
SONAPOST. Firstly, it describes the award procedures of public works.
Secondly, this work proposes solutions to computerize the different tasks of the
management of public works. The implementation of such a system will be valuable for
SONAPOST. These added values will be materialized by the improvement of the processes of
public works management, by the improvement of decision-making and to follow the
execution of public works in real time.

THEME : Gestion des marchs publics la SONAPOST

Page III

TABLE DES ABREVIATIONS


Tableau I.1 : Rcapitulatif des sigles et abrviations
SIGLE OU ABREVIATION

SIGNIFICATION

2TUP

Two Track Unified Process

ARMP

Autorit de Rgulation des Marchs Publics

AUP

Agile Unified Process

CAM

Commission d'Attribution des Marchs

CAMES

Conseil Africain et Malgache pour l'Enseignement


Suprieur

CBC

Conseil Burkinab des Chargeurs

COCOMO

COnstructive COst MOdel

CR

Comit de Rception

CRD

Comit de Rglement des Diffrends

DAO

Dossier d'Appel d'Offre

DFC

Direction Financire et Comptable

DGCMEF

Direction Gnrale du Contrle des Marchs et des


Engagements Financiers

DP

Division du Patrimoine

DPL

Direction du Patrimoine et de la Logistique

DSI

Direction des Systmes d'Information

HM

Homme/Mois

HTML

Hypertext Markup Language

IHM

Interface Homme/Machine

ISIG

Institut Suprieur d'Informatique et de Gestion

KLSL

Kilo Ligne Source du Logiciel

OMT

Object Modeling Technique

OOD

Object Oriented Design

THEME : Gestion des marchs publics la SONAPOST

Page IV

OOSE

Object Oriented Software Engineering

PHP

Hypertext Preprocessor

PPM

Plan annuel de Passation des Marchs

PRM

Personne Responsable des Marchs

PU

Processus Unifi

PV

Procs Verbal

RAD

Rapid Application Development

RAID

Redundant Array of Independent Disks

RIB

Relev d'Identit Bancaire

RTC

Rseau Tlphone Commut

RUP

Rational Unified Process

SADT

Structured Analysis and Design Technique

SCT

Sous Comission Technique

SGBD

Systme de Gestion des Bases de Donnes

SI

Systme d'Information

SONAPOST

Socit Nationale des Postes

SQL

Structured Query Language

TDEV

Temps de Dveloppement

TDR

Termes De Rfrence

UEMOA

Union Economique et Montaire Ouest Africaine

UML

Unified Modeling Language

UP

Unified Process

WAN

Wide Area Network

WYSIWYG

What You See Is What You Get

XML

eXtensible Markup Language

THEME : Gestion des marchs publics la SONAPOST

Page V

AVANT-PROPOS
LISIG est une grande cole prive denseignement suprieur cre en Octobre 1992.
La cration de lISIG a t motive par le dsir de dvelopper lenseignement suprieur, la
recherche scientifique, les prestations de conseil envers le monde des affaires pour un
dveloppement durable du Burkina Faso et des pays de lUEMOA.
Depuis sa cration, linstitut na cess de multiplier ses domaines de comptences par
louverture de nouvelles filires pour rpondre la demande du march de lemploi.
LISIG propose alors de nombreuses filires de formation parmi lesquelles nous avons :

Linformatique de gestion ;
La maintenance lectronique ;
Le secrtariat de direction ;
La finance comptabilit ;
La gestion commerciale ;
La banque ;
Lassurance ;
La communication dentreprise.

En 2004, linstitut entre dans une nouvelle re en devenant membre titulaire du


CAMES. LISIG compte actuellement 19 diplmes homologus par le CAMES et
entretient une collaboration avec de nombreux partenaires africains et occidentaux dont on
peut citer :

LAgence Universitaire de la Francophonie (AUF) ;


LUniversit de la Mditerrane (Aix-Marseille II) ;
LEcole Suprieure des Ingnieurs de Luminy (lESIL, Universit de Marseille) ;
LEcole dIngnieurs de Limoges (3il) ;
LUniversit de Lagon et Cape Coast au Ghana ;
La Confrence des Recteurs des Universits Francophones de lAfrique et de lOcan
Indien (CRUFAOCI) ;
LUniversit de Ouagadougou (UO);
LUniversit Polytechnique de Bobo-Dioulasso (UPB);
LOrdre National des Experts Comptables et Comptables Agrs du Burkina Faso
(ONECCA).
etc.

LISIG forme aussi bien en cours du jour quen cours du soir. Depuis lanne
acadmique 2006-2007, lISIG a adopt le systme LMD (Licence - Master - Doctorat)
pour ses diffrentes filires de formation.
En outre, depuis fvrier 2012 lISIG a t rig en Universit dont le nom est
lUniversit Aube Nouvelle en abrg U. AUBEN .

THEME : Gestion des marchs publics la SONAPOST

Page 1

SOMMAIRE
DEDICACES ......................................................................................................................... I
REMERCIEMENTS ............................................................................................................. II
RESUME ............................................................................................................................. III
ABSTRACT ......................................................................................................................... III
TABLE DES ABREVIATIONS .......................................................................................... IV
AVANT-PROPOS ................................................................................................................. 1
INTRODUCTION GENERALE ............................................................................................ 3
CHAPITRE I : NOTE DE LANCEMENT ..............................................................................4
INTRODUCTION ............................................................................................................4
I.

Prsentation de lentreprise ....................................................................................... 4

II. Ressources matrielles et logicielles ..........................................................................6


III. Prsentation de la problmatique..............................................................................8
IV. Planning prvisionnel .............................................................................................. 10
CONCLUSION ............................................................................................................... 10
CHAPITRE II : ETUDE DE LEXISTANT ......................................................................... 11
INTRODUCTION .......................................................................................................... 11
I.

Expression des besoins travers les interviews ...................................................... 11

II. Analyse des besoins .................................................................................................. 17


III. Forces et faiblesses du systme existant .................................................................. 42
CONCLUSION ............................................................................................................... 43
CHAPITRE III : ETUDE CONCEPTUELLE DETAILLEE DU FUTUR SYSTEME .......... 44
INTRODUCTION .......................................................................................................... 44
I.

Etude prliminaire ................................................................................................... 44

II. Capture des besoins fonctionnels ............................................................................ 47


III. Capture des besoins techniques (Etude des scnarii) ............................................. 58
IV. Analyse ..................................................................................................................... 72
V. Conception darchitecture ....................................................................................... 88
VI. REALISATION ....................................................................................................... 89
CONCLUSION ............................................................................................................... 94
CONCLUSION GENERALE ............................................................................................... 95
ANNEXE ............................................................................................................................... I
I. Bibliographie et webographie ....................................................................................... I

THEME : Gestion des marchs publics la SONAPOST

Page 2

INTRODUCTION GENERALE
De nos jours, la comptitivit dune entreprise rside dans la matrise de toutes les
facettes de linformation. En effet, avoir le contrle sur linformation confre lentreprise
une meilleure connaissance de son secteur dactivits et est de ce fait un excellent outil daide
la prise de dcision. Cette matrise de linformation passe ncessairement par la mise en
place dun bon SI mais aussi et surtout par lautomatisation des diffrentes tches de
lentreprise. Cest dans ce contexte que la SONAPOST, dans un souci dtre toujours
comptitif, a dcid de la mise en place dun systme informatique pour assurer la gestion de
ses diffrents services et, notamment de celui charg de la gestion des marchs publics.
Cest dans ce cadre que nous avons t reus la Direction des Systmes dInformation
(DSI) de la SONAPOST pour un stage dune dure de deux (02) mois. Lobjectif de ce stage
est de mener une tude sur le systme actuel de gestion des marchs publics afin den dceler
les forces et les faiblesses. Ltude permettra terme de mettre en place une solution
informatique qui permettra dassurer une meilleure gestion des marchs publics la
SONAPOST.
Pour mener bien notre tude, nous allons adopter le plan suivant : dabord, nous ferons
une note de lancement pour dcrire la structure daccueil ainsi que les diffrentes mthodes
danalyse et de conception qui soffrent nous avant de faire notre choix sur la mthodologie
qui sera utilise ; ensuite nous ferons une tude du systme existant ; nous terminerons par
une tude conceptuelle dtaille du systme futur.

THEME : Gestion des marchs publics la SONAPOST

Page 3

CHAPITRE I : NOTE DE LANCEMENT


INTRODUCTION
Dans ce premier chapitre, notre attention portera sur la structure daccueil. Pour cela,
nous traiterons de lorganisation et du fonctionnement de celle-ci. En outre, cette phase nous
permettra galement de mieux cerner le thme du projet, de dterminer la mthode danalyse
que nous adopterons et didentifier tous les acteurs du systme tout en tablissant un planning
afin de mener bien le projet.

Prsentation de lentreprise

I.

La SONAPOST est une Socit dEtat cre par le dcret n94-414/PRES/MCC du 21


Novembre 1994 et son modificatif n7-209/PRES/PM/MCC/MEF/MCIA du 28 Avril 1997.
Elle dispose dun capital de deux milliards cinq cent quatre-vingt dix millions de FCFA
(2 590 000 000) entirement dtenu par lEtat et compte environ mille (1000) employs. Son
sige social est situ Ouagadougou 566 avenue de la nation 01 BP 6000 Ouagadougou 01.

I.1.

Missions

La SONAPOST dispose de quatre vingt douze (92) bureaux de poste rpartis sur le
territoire national et est investie des missions essentielles suivantes :

Le dsenclavement du pays par lquipement du territoire en infrastructures postales ;


La collecte, lacheminement et la distribution des objets de correspondances ;
La mobilisation et la promotion de lpargne nationale ;
Le dveloppement de toute activit compatible avec la gestion des services postaux et
financiers.

I.2.

Domaines dactivits

La SONAPOST base ses activits essentiellement sur le courrier (courrier officiel, bote
postale, colis postal, ), les finances (chques postaux, caisse dpargne, transfert
dargent,) et sur les technologies de linformation et de la tlcommunication (Cyber
postes).

I.3.

Organigramme gnral de la SONAPOST

THEME : Gestion des marchs publics la SONAPOST

Page 4

Figure I.1: Organigramme gnral de la SONAPOST


DG

SP/DG

IGS

DCGAI

CT

DWU

DJ
DAI

DSC
SG

DC

DR
C

DSF

DFC

DRH

DRO

DG

Direction Gnrale

SP/DG

Secrtariat Particulier/Direction Gnrale

IGS

Inspection Gnrale des Services

DC
M

DRN

DPL

DSI

DRE

DCGAI Dpartement du Contrle de Gestion et de lAudit Interne


CT

Conseil Technique

DWU

Dpartement Western Union

DJ

Dpartement Juridique

THEME : Gestion des marchs publics la SONAPOST

Page 5

DAI

Dpartement des Affaires Internationales

DSC

Dpartement Secrtariat Central

SG

Secrtariat Gnral

DC

Direction du Courier

DSF

Direction des Services Financiers

DFC

Direction Financire et Comptable

DRH

Direction des Ressources Humaines

DCM

Direction de la Communication et du Marketing

DPL

Direction du Patrimoine et de la logistique

DSI

Direction des Systmes dInformation

DRC

Direction Rgionale du Centre

DRO

Direction Rgionale de lOuest

DRN

Direction Rgionale du Nord

DRE

Direction Rgionale de lEst

I.4.

Prsentation du service concern par ltude

La SONAPOST est une Socit dEtat administre par un Conseil dAdministration (CA).
Elle dispose dune administration centrale compose de la direction gnrale et de ses services
dappui, des directions techniques, des directions rgionales, des centres spcialiss et des
bureaux postaux.
La Direction du Patrimoine et de la Logistique (DPL) est un service de ladministration
centrale charge de veiller sur tout le patrimoine ainsi que les besoins logistiques. Elle dispose
en son sein dun service qui soccupe de la passation des marchs publics. En effet, la PRM
(Personne Responsable des Marchs) est le service responsable de la passation ainsi que le
suivi des marchs publics jusqu la rception des biens.

II.

Ressources matrielles et logicielles


II.1.

Ressources matrielles

Les ressources matrielles informatiques utilises par la SONAPOST sont indiques dans
le tableau suivant :

THEME : Gestion des marchs publics la SONAPOST

Page 6

Tableau I.2 : Rcapitulatif des ressources matrielles utilises la SONAPOST


DESIGNATION

QUANTITE

Ordinateurs

640 dont 585 de bureau et 55 portables

Imprimantes

120

Serveurs

12

Onduleurs centraux

10

Switchs (Commutateurs)

60

Routeurs

50

II.2.

Solutions informatiques existantes

Les applications utilises au sein de la SONAPOST sont regroupes dans le tableau ci-aprs :
Tableau I.3 : Rcapitulatif des ressources logicielles utilises la SONAPOST
NOM

DESCRIPTION

CNE

Application de gestion des caisses nationales


dpargne

CCP

Application de gestion des chques postaux

CCM

Application de gestion de contrle des


mandats

CCB

Application de contrle de la comptabilit


des bureaux

Teliman

Application de gestion des transferts dargent


locaux

MEI

Application de gestion des mandats express


internationaux

Orion

Application bancaire
applications CCP-CNE

Sage ligne 1000

Application de gestion comptable

Application boite postale IPS

Application de suivi et localisation du


courrier

THEME : Gestion des marchs publics la SONAPOST

de

reprise

des

Page 7

II.3.

Le rseau informatique

Dans le souci de raccorder toutes ses agences, la SONAPOST a entrepris un vaste projet
dinterconnexion de tous ses bureaux. Nous sommes ce jour quarante huit (48) bureaux
interconnects au sige et 20 autres utilisant une liaison RTC. Ce rseau est de type
toile . La DPL dispose cependant dun rseau local avec une connexion ADSL et nest
pas relie au WAN.
Figure I.2 : Schma du rseau de la SONAPOST

III.

Prsentation de la problmatique
III.1.

Prsentation du problme

La gestion actuelle des marchs publics assure par la PRM se fait de faon manuelle. De
ce fait cette gestion savre difficile compte tenu de la diversit des tches accomplir et du
nombre important de marchs passer chaque anne. Parmi les difficults rencontres on note
principalement :
Une lenteur dans lexcution des tches ;
Une non matrise des priodes de passation des marchs ;
Une mauvaise conservation de linformation qui nest soumise aucune contrainte de
scurit ;
Une difficult de suivi-valuation de lexcution des marchs.
Notre tude sur le thme Gestion des marchs publics la SONAPOST consistera
apporter une solution informatique aux difficults rencontres, en vue damliorer la gestion
des marchs publics la SONAPOST. Pour cela nous adopterons la mthode 2TUP pour
conduire le projet terme.

THEME : Gestion des marchs publics la SONAPOST

Page 8

NB. : La mthode 2TUP nous impose lutilisation du langage de modlisation UML pour
la reprsentation des diffrents diagrammes. En outre, notre choix sest port sur la mthode
2TUP du fait de son approche nouvelle, originale.

III.2.

Objectifs

Lautomatisation de la gestion des marchs publics devrait :

III.3.

Permettre la matrise des priodes de lancement des marchs ;


Faciliter le suivi-valuation de lexcution des marchs ;
Faciliter un accs rapide aux informations ;
Amliorer la scurit et la confidentialit des donnes ;
Rendre les informations disponibles en temps rel.

Les acteurs du projet

III.3.1. Le groupe de pilotage


Le groupe de pilotage est mis en place afin darbitrer et de contrler les dcisions
prendre. Il valide les grands choix techniques et fonctionnels, fixe les orientations gnrales et
les dlais respecter. Il dfinit galement les moyens mettre en place pour la ralisation du
projet et approuve le plan daction tabli par le groupe de projet. Il est constitu du Comit
de Direction .
III.3.2. Le groupe de projet
Le groupe de projet est charg de lexcution du projet c'est--dire ltude de la
conception et ventuellement la ralisation et le dploiement de lapplication. Il tablit
galement des rapports sur lactivit et lavancement du projet auprs du groupe de pilotage.
Le groupe de projet est constitu de :
M. OUEDRAOGO Boukary, Directeur des Systmes dInformation au CBC ;
M. KOUTOU Wend-Nougui Odilon, Etudiant en troisime (3me) anne de Licence
dInformatique option Gnie Logiciel lISIG Ouagadougou.
III.3.3. Le groupe des utilisateurs
Le groupe des utilisateurs assure les rles suivants :
Etre consult directement sous forme dinterviews ;
Valider les procdures et les lments de ltude relevant de son domaine de
comptence ;
Raliser des tests et valider les maquettes ;
Etre une ressource pour le projet.
Le groupe des utilisateurs est compos principalement de:
M. NIKIEMA Casimir, Directeur du Patrimoine et de la Logistique ;
M. SANOUIDI Inoussa, chef du service PRM ;
THEME : Gestion des marchs publics la SONAPOST

Page 9

M. ILBOUDO Christophe, agent de la PRM ;


M. OUATTARA Jol, agent de la PRM ;
M. SAWADOGO Serge, chef de la codification.

IV.

Planning prvisionnel

Tableau I.4 : Planning prvisionnel


ETAPE

DOCUMENT A
PRODUIRE

PERIODE

Gnralits

Note de lancement

Du 04 Septembre au 18 15 jours
Septembre

Etude de lexistant

Du 19 Septembre au 06 18 jours
Octobre

Etude du
existant

systme

Conception dtaille

Conception dtaille
systme futur

Programmation
mise en uvre

Dossier de programmation,
guide de lutilisateur, guide Du 01 Novembre au 31 Mars
dexploitation

et

du

Du 21 Octobre au 31 Octobre

DUREE

15 jours

5 mois

CONCLUSION
Cette partie nous a permis de prsenter lorganisation gnrale de la structure daccueil
et de prendre connaissance de notre thme dtude. Aussi, elle nous a permis de dterminer la
mthode danalyse et de conception pour la conduite de notre projet. Ainsi, nous avons opt
pour la mthode 2TUP. En outre ce chapitre nous a permis de dterminer les acteurs
intervenants dans le projet et dtablir un planning prvisionnel pour lexcution des
diffrentes tches du projet.
Nous entamerons dans la partie suivante ltude de lexistant dont le but majeur est de
prendre connaissance en dtail du domaine concern par notre prsent thme dtude.

THEME : Gestion des marchs publics la SONAPOST

Page 10

CHAPITRE II : ETUDE DE LEXISTANT


INTRODUCTION
La note de lancement nous a permis non seulement de prendre connaissance de notre
structure daccueil savoir la SONAPOST, mais aussi de dgager la problmatique qui
dcoule de ltude de notre thme. Elle nous a galement permis de dterminer la mthode
danalyse et de conception ainsi que le langage de modlisation que nous utiliserons tout au
long de notre tude.
Dans le prsent chapitre, nous ferons une tude de la gestion actuelle des marchs
publics. Cette phase a pour objectif premier de faire un tat de lexistant. Cela nous permettra
par la suite de faire des propositions de solutions pertinentes pour assurer une meilleure
gestion des marchs publics.
I.

Expression des besoins travers les interviews

Lexpression des besoins constitue une tape primordiale dans le processus de mise en
place de tout systme informatique. Elle reprsente une plate-forme de collaboration entre
informaticiens et utilisateurs du futur systme. La capture des besoins consiste dans un
premier temps, rpertorier lensemble des besoins des diffrents acteurs du systme travers
des entretiens ainsi que les documents de travail ; puis dans un second temps, distinguer les
besoins fonctionnels de ceux non fonctionnels.
Dans le souci de mieux apprhender les besoins des utilisateurs, il nous t accord des
entretiens avec les diffrents acteurs intervenant dans le processus de passation des marchs
publics. Cest ainsi que nous nous sommes entretenus avec :
M. NIKIEMA Casimir : Directeur du Patrimoine et de la Logistique ;
M. SANOUIDI Inoussa : Chef du service PRM ;
M. ILBOUDO Christophe et M. OUATTARA Jol : tous deux (02) agents du service
PRM ;
M. SAWADOGO Serge : Chef de la section codification.
Les informations recueillies au cours de nos entretiens nous ont permis de mieux
comprendre la procdure de passation des marchs publics, mais aussi et surtout de mieux
apprhender les objectifs du projet. Les comptes rendus des interviews peuvent tre rsums
dans les tableaux ci-aprs :
Tableau II.1 : Interview ralis avec M. SANOUIDI Inoussa, M. ILBOUDO Christophe et
M. OUATTARA Jol
Organisme : SONAPOST

Domaine : Gestion des marchs publics la SONAPOST


Poste : PRM
Personnes interviewes :

THEME : Gestion des marchs publics la SONAPOST

Page 11

Compte rendu de linterview

M. SANOUIDI Inoussa
M. ILBOUDO Christophe
M. OUATTARA Jol
Date : 05/09/2012

Descriptif du poste
La PRM est un service de la DPL la SONAPOST.
Ce service est responsable de la passation des marchs publics ainsi que leur suivi jusqu la
rception des biens.
Procdure de passation des marchs publics
A lissue de linterview avec les agents de la PRM, il est ressorti que la passation des marchs publics
se fait suivant un PPM. Ce PPM est tabli ladoption du budget de lanne en cours et contient :

La liste des marchs ;


Les montants prvisionnels des dits marchs ;
Les priodes de lancement des marchs ;
Les modes de passation des marchs ;
Le service responsable de la rdaction des TDR ;
Les priodes probables de livraison des biens.

Une fois que la priode de lancement dun march est arrive, la PRM prend les dispositions
ncessaires pour finaliser le DAO sur la base des TDR reus des directions techniques souvent avec
lappui de consultants extrieurs.
Remarque : Lorsquil sagit dun march concernant le domaine informatique, cest la DSI qui
dfinit les TDR.
Ce DAO est tabli et transmis la DGCMEF pour avis et publication. Une fois la publication faite,
les soumissionnaires achtent le DAO afin de prparer leurs offres. Ces offres sont dposes sous pli
ferm la DPL dans le dlai fix par le DAO.
Le dpouillement des dossiers se fait par la CAM en prsence des soumissionnaires. Cette opration
consiste :

Vrifier les pices exiges dans le dossier ;


Lire haute voix les montants des soumissionnaires.
A lissue du travail de la CAM, une SCT est constitue pour analyser en dtail les offres prsentes
par les diffrents soumissionnaires afin de choisir le ou les attributaires provisoires. Aprs quoi, la
SCT transmet son rapport la CAM qui analyse les motifs de rejet ou dacceptation des offres.
Lorsque la CAM valide le travail de la SCT, un document de synthse est labor. Ce document
contient :

Le PV douverture de plis ;
Le rapport de la SCT ;

THEME : Gestion des marchs publics la SONAPOST

Page 12

Le PV de dlibration de la CAM.
Ce document est ensuite adress la DGMEF pour avis et publication des rsultats provisoires. Ces
rsultats peuvent faire lobjet dune contestation auprs de lARMP dans un dlai de cinq (5) jours
ouvrables compter de la publication des rsultats.
Remarque : Lorsquil sagit dune demande de prix pour les besoins urgents, la CAM soccupe ellemme de lanalyse du march sans lappui dune SCT.
En cas de plainte formule par un soumissionnaire, lARMP suspend la procdure puis analyse le
processus dattribution du march dans son ensemble afin de sassurer si la plainte est fonde ou pas.
Un CRD est alors runi pour une confrontation entre : le plaignant, la SONAPOST et lattributaire
provisoire.
Aprs chaque confrontation, lARMP prend une dcision qui mentionne les motifs de la plainte et le
caractre fond ou non de celle-ci.
Lorsquaucune plainte nest enregistre dans le dlai de cinq (5) jours ouvrables, une notification
provisoire est adresse lattributaire pour lui signifier quil a t retenu pour lexcution du march.
Lattributaire met ensuite la disposition de la SONAPOST une facture pro forma ainsi que son RIB
pour la mise au point du contrat.
Lattributaire rcupre ensuite le contrat pour signature puis le ramne la SONAPOST pour tre
sign par les diffrents directeurs concerns. Par la suite, le contrat doit tre enregistr aux impts par
lattributaire.
A la rception du contrat avec le visa des impts, un ordre de service qui mentionne la dure
dexcution du march ainsi quune notification sont remis lattributaire. Le travail de lattributaire
peut donc dbuter.
Le suivi de ltat dexcution des marchs de travaux incombe un bureau dtude (le bureau dtude
qui a dfinit les besoins plus haut) qui doit parfois faire des relances lentrepreneur en cas de
manquement aux clauses du contrat.
Remarque : La SONAPOST par le biais de la DP fait parfois des contrles sur les chantiers pour voir
ltat dexcution du march.
A la fin de lexcution du march, lentrepreneur adresse une correspondance la SONAPOST pour
la rception des biens. Cette rception se fait en prsence des membres de la commission de
rception, lentreprise et le bureau charg du suivi-contrle des travaux.
Remarques :

Lorsquil sagit dune construction, la rception se fait en deux temps (provisoire et


dfinitive) ;
Dans le cas dun retard de livraison, une premire lettre de mise en demeure est adresse
lentrepreneur pour lui intimant achever les travaux dans un certain dlai. Pass ce dlai,
une ultime lettre de mise en demeure lui est adresse puis la SONAPOST saisit lARMP pour
entamer la procdure de rsiliation du contrat.

THEME : Gestion des marchs publics la SONAPOST

Page 13

Tableau II.2 : Interview ralis avec M. NIKIEMA Casimir


Organisme : SONAPOST

Domaine : Gestion des marchs publics la SONAPOST

Compte rendu de linterview

Poste : Direction du Patrimoine et de la Logistique (DPL)


Personne interviewe :
M. NIKIEMA Casimir
Date : 05/09/2012

Processus dattribution des marchs


La CAM a pour missions :

Louverture des plis


Il sagit notamment douvrir les plis contenant les diffrentes soumissions en vue de publier les noms
des soumissionnaires et les montants des soumissions. Une vrification des pices administratives est
faite cette tape. Ensuite la CAM transmet les dossiers la SCT qui va effectuer lanalyse
minutieuse des offres.

Dlibration
Sur la base du rapport de la SCT qui propose un attributaire provisoire, la CAM doit statuer pour
retenir ou pas lattributaire propos. Lorsque la CAM valide le travail de la SCT, un document de
synthse est labor.
Remarque : Lorsquil sagit dune demande de prix pour les besoins de moins de vingt millions
(20 000 000) de F CFA, la CAM soccupe elle-mme de lattribution du march sans lappui dune
SCT.

Tableau II.3 : Interview ralis avec M. SAWADOGO Serge


Organisme : SONAPOST

Domaine : Gestion des marchs publics la SONAPOST

Compte rendu de linterview

Poste : Comptable
Personne interviewe :
M. SAWADOGO Serge (Membre de la SCT)
Date : 17/09/2012

Descriptif du poste
Tout dabord, aucune SCT nest dfinie par avance. Elle se constitue en fonction du besoin et des
marchs. La SCT a pour rle danalyser en dtail les offres prsentes par les diffrents
soumissionnaires afin de choisir le ou les attributaires provisoires.

THEME : Gestion des marchs publics la SONAPOST

Page 14

Processus danalyse des offres


Le travail de la SCT se droule en trois (03) tapes et se base sur le DAO :

Etape 1 : vrification des pices administratives


Dans cette tape, la SCT revrifie les pices administratives contenues dans les diffrentes offres en
se basant sur le procs verbal de la CAM. Il faut noter ce niveau quaucun dossier nest rejet
lorsquune pice est manquante. Il est simplement demand lintress de complter son dossier.

Etape 2 : analyse des offres techniques


Cette analyse consiste dterminer si les offres proposes par les soumissionnaires sont en
conformit avec les caractristiques techniques dcrites dans le DAO. A lissue de cette tape, les
soumissions rpondant aux caractristiques demandes sont retenues pour poursuivre lanalyse. Les
autres tant simplement rejetes.

Etape 3 : analyse des offres financires et proposition dattribution


Cette tape concerne uniquement les soumissions qui ont t retenues lors de lanalyse technique.
Elle consiste notamment vrifier les montants des soumissions afin de corriger les ventuelles
erreurs de calcul. Ensuite, les soumissions sont classes par rapport aux montants puis, on retient
loffre value la plus conomiquement avantageuse.

Tableau II.4 : Interview ralis avec M. SAWADOGO Serge


Organisme : SONAPOST

Domaine : Gestion des marchs publics la SONAPOST

Compte rendu de linterview

Poste : Comptable
Personne interviewe :
M. SAWADOGO Serge (Membre du CR)
Date : 17/09/2012

Descriptif du poste
Le CR se charge notamment de la rception des biens la fin de lexcution du march. Ce comit est
compos de :

Un reprsentant de la DFC ;
Un reprsentant de la PRM ;
Un reprsentant de la DPL ;
Un reprsentant du service technique (sil y a lieu).

Processus de rception des biens


Le travail du CR dbute lorsque le fournisseur manifeste le besoin de livrer les biens demands.
Le comit est runi sur convocation du prsident (reprsentant DFC) et ses tches consistent :

THEME : Gestion des marchs publics la SONAPOST

Page 15

Contrler si les biens sont conformes aux caractristiques techniques demandes ;


Vrifier les quantits ;
A lissue de ce travail, un PV de rception sign par tous les membres du comit est dress.

Au cours de ces interviews nous avons pu rpertorier les difficults et les souhaits
suivants :
Difficults :
Difficile de suivre ltat davancement des travaux ;

Difficile de contrler la qualit du travail ;


Surprise concernant les priodes de lancement des marchs ;
Absence doutil de surveillance des dates de livraison des biens ;
Difficults pour archiver les dossiers.

Souhaits :
Mise en place dun outil qui permette de connaitre lavance les priodes de passation des
marchs ;

Mise en place dun outil qui permette de surveiller les dates de livraison des biens ;
Mise en place dun outil permettant de faire larchivage ;
Mettre en place un systme o il est difficile de pouvoir enfreindre la rglementation en
matire de marchs publics.

Remarque : Au cours de nos entretiens nous avons recens un certain nombre de


documents qui interviennent dans le processus de passation des marchs publics. Vous
pourrez retrouver tous ces documents en annexe. Le tableau ci-aprs donne une brve
description de ces documents de travail :
Tableau II.5 : Tableau rcapitulatif des documents manipuls
DOCUMENT

DESCRIPTION

Avis dappel doffre

Document se rfrant un march et publi par la


DGCMEF

Ordre de service

Document autorisant
lexcution du march

Notification

Document informant le soumissionnaire quil est


attributaire dun march

Contrat

Matrialise le contrat pass entre la SONAPOST et


lattributaire

Plan de Passation des Marchs (PPM)

Document rpertoriant les marchs passer

THEME : Gestion des marchs publics la SONAPOST

lattributaire

entamer

Page 16

Dossier dappel doffre (DAO)

Document contenant les informations sur le march


labor

Procs Verbal douverture de pli

Document labor par les membres de la CAM


lissue de louverture des plis

Procs Verbal de dlibration

Document ratifi par les membres de la CAM lissue


de la dlibration des travaux de la SCT

Offre technique

Document contenant les caractristiques techniques


dune soumission

Offre financire

Document contenant les propositions financires dune


soumission

Procs Verbal de rception

Document labor par les membres du CR la


rception des biens

II.

Analyse des besoins

Lanalyse a pour objectif principal la mise en vidence des besoins fonctionnels du


systme actuel. Elle permet donc de rpondre la question Que fait le systme actuel ? .
De ce fait, elle apporte une description du processus actuel de gestion des marchs publics.
Les spcifications du systme qui dcoulent de cette description nous permettront de proposer
des solutions en vue damliorer la gestion des marchs publics.

II.1.

Dlimitation du domaine dtude (Diagramme de contexte statique)

La dlimitation du domaine dtude permet de dterminer lensemble des composantes de


la SONAPOST participant au processus de gestion des marchs publics. Elle nous permettra
de fixer les limites de notre tude en identifiant tous les acteurs intervenant dans la chane de
gestion des marchs publics. Ainsi donc, il nous sera difficile de nous loigner du cadre de
ltude. Suite lanalyse du systme travers les diffrents entretiens, nous aboutissons au
diagramme de contexte statique qui est reprsent de la manire suivante :

THEME : Gestion des marchs publics la SONAPOST

Page 17

Figure II.1 : Diagramme de contexte statique


DGCMEF

ARMP

CA

Soumissionnaire

Gestion des marchs


publics la
SONAPOST

PRM

CAM

SCT

CR

DIRECTION DU PATRIMOINE ET DE LA LOGISTIQUE

II.2.

DIRECTION
DESdutilisation
TRANSPORTS ET DE LA LOGISTIQUE
Diagramme
des cas

Il sagit de reprsenter un point de vue fonctionnel de larchitecture systme. Par le


biais des cas dutilisation, nous serons en contact permanent avec les acteurs du systme en
vue de dfinir les limites de celui-ci, et ainsi viter de trop sloigner des besoins rels de
lutilisateur final.
Concepts utiliss
a) Notion dacteur
Un acteur dfinit un ensemble cohrent de rles quun utilisateur ou une entit externe
peut jouer en interagissant avec le systme .Un acteur peut consulter et modifier directement
ltat du systme en mettant et/ou en recevant des messages susceptibles dtre porteurs de
donnes.

THEME : Gestion des marchs publics la SONAPOST

Page 18

Figure II.2 : Formalisme dun acteur dans le diagramme de cas dutilisation

Acteur humain

b) Cas dutilisation
Un cas dutilisation est une description du systme tudi en privilgiant le point de
vue de lutilisateur. Il permet une meilleure structuration des besoins des utilisateurs qui
dfinissent clairement la manire dont ils interagissent avec le systme. Les cas dutilisation
sont relis par des relations de plusieurs types.
Include : Une relation dinclusion dun cas dutilisation B vers un cas
dutilisation A indique quune instance du cas dutilisation B contient galement
le comportement spcifi du cas dutilisation A . Ce comportement est insr un
endroit dfini par le cas dutilisation B .
Figure II.3 : Formalisme dune relation dinclusion des cas dutilisations

"include"
Cas d'utilisation B

Cas d'utilisation A

Par exemple dans le systme de gestion dun guichet automatique un client devra
dabord sauthentifier avant de retirer de largent. Donc toute opration inclut une
authentification.
Figure II.4 : Exemple pour le formalisme dune relation dinclusion des cas dutilisations

Retirer de l'argent

"include"
S'authentifier

Extend : La relation dextension dun cas dutilisation B vers un cas dutilisation


C indique quune instance du cas dutilisation C peut tre augmente par le
comportement du cas dutilisation B . Le cas dutilisation B est insr lendroit
dfini par le point dextension du cas dutilisation C .

THEME : Gestion des marchs publics la SONAPOST

Page 19

Figure II.5 : Formalisme dune relation dextension des cas dutilisations

Cas d'utilisation C

"Extend"

Cas d'utilisation B

Par exemple dans la gestion de la bibliothque dune association, une personne


voulant emprunter un livre devra dabord se faire enregistrer sil ntait pas membre de
lassociation. Lemprunt du livre devra passer dabord par linscription de la personne
intresse si cette dernire ntait pas membre.
Figure II.6 : Exemple pour le formalisme dune relation dextension des cas dutilisations

Emprunter livre

"extend"

Enregistrer personne

Relation de gnralisation : Elle existe lorsquun cas dutilisation hrite de la


fonctionnalit dun autre cas dutilisation ; on peut dans ce cas augmenter dans le cas
dutilisation enfant des interactions supplmentaires ou modifier des interactions hrites.
Une relation de gnralisation dun cas dutilisation A par un cas dutilisation B signifie
que B hrite des fonctionnalits du cas dutilisation A.
Figure II.7 : Formalisme dune relation de gnralisation des cas dutilisation

Cas d'utilisation B

Cas d'utilisation A

Par exemple dans le cas de la gestion dun guichet automatique de banque, le retrait
dargent pourra se faire en dollars. Donc le cas dutilisation Retirer dollars peut se
gnraliser au cas dutilisation Retirer argent .
Figure II.8 : Exemple pour le formalisme dune relation de gnralisation des cas
dutilisations

Retirer dollars

II.2.1.

Retirer argent

Identification des acteurs

Les acteurs du systme identifis dans un premier temps sont :

THEME : Gestion des marchs publics la SONAPOST

Page 20

Tableau II.6 : Tableau rcapitulatif des acteurs du systme


ABREVIATION
DU ROLE

DESIGNATION DU ROLE

DESCRIPTION

EB

Elaborateur de Budget

Cest lacteur charg dlaborer le


budget de lanne en affectant les
montants aux lignes budgtaires.

RDTR

Responsable des Termes De Cest lacteur charg de la rdaction


des termes de rfrence.
Rfrence

VB

Validateur de Budget

CPPM

Conseiller de Plan
Passation des Marchs

de Cest lacteur charg dassister


llaborateur de plan de passation des
marchs dans llaboration du plan de
passation des marchs.

EPPM

Elaborateur de Plan
Passation des Marchs

de Cest lacteur charg de la gestion du


plan de passation des marchs publics
depuis son laboration jusqu sa
validation.

VPPM

Validateur de Plan
Passation des Marchs

de Cest lacteur charg de valider le


plan de passation des marchs.

RM

Responsable des Marchs

RAM

Responsable
des Marchs

AD

Archiviste de Document

Cest lacteur charg de valider le


budget de lanne.

Le responsable des marchs soccupe


de la gestion des dossiers dappel
doffre, des soumissions ainsi que de
lexcution des marchs.

dAttribution Cest lacteur charg de lattribution


dun march un soumissionnaire.
Larchiviste procde larchivage
des diffrentes pices des marchs.

THEME : Gestion des marchs publics la SONAPOST

Page 21

AO

Analyseur dOffres

Cest lacteur charg deffectuer


lanalyse technique et financire des
offres puis de proposer un
attributaire.

RB

Responsable des Biens

Cest lacteur charg de recevoir les


biens la fin de lexcution du
march.

SM

Soumissionnaire de March

Personne physique ou morale qui


soumissionne un march.

GC

Gestionnaire de Contentieux Cest lacteur qui gre les contentieux


qui peuvent natre suite lattribution
dun march ou lexcution de
celui-ci.

PM

Publicateur de March

II.2.2.

Cest lacteur qui est charg de


valider le DAO, publier le DAO ainsi
que les rsultats dattribution du
march.

Identification des cas dutilisation en fonction des acteurs

Les cas dutilisation identifis dans un premier temps sont rpertoris dans le tableau ciaprs :
Tableau II.7 : Tableau rcapitulatif des cas dutilisation du systme
ACTEURS

CAS DUTILISATION

EB

Elaborer budget

VB

Valider budget

CPPM

Elaborer PPM

EPPM

Elaborer PPM

VPPM

Valider PPM

RTDR

Rdiger TDR

RM

Elaborer DAO

THEME : Gestion des marchs publics la SONAPOST

Page 22

Vendre DAO
Suivre et valuer march
Approuver facture
Grer contrat :
Etablir ordre de service
Etablir notification
Etablir contrat

AD

Archiver document

RAM

Valider proposition attributaire


Dpouiller offres
Rdiger PV de dpouillement

AO

Analyser offres
Analyser offre financire
Analyser offre technique
Proposer attributaire

RB

Rceptionner biens
Rdiger PV de rception

SM

Soumissionner march
Acheter DAO
Consulter DAO

GC

Grer les contentieux

PM

Publier DAO
Valider DAO
Publier proposition attributaire

Nous disposons de vingt sept (27) cas dutilisation que nous pouvons regrouper en
sept (07) cas dutilisation principaux.
Tableau II.8 : Tableau rcapitulatif des cas dutilisation principaux

EB, VB
EPPM, VPPM, CPPM
RM, SM, PM

CAS
DUTILISATION
PRINCIPAUX
Grer budget
Grer PPM
Grer DAO

RM, RAM, SM, AO

Grer soumission

RM, RB, SM

Grer march

GC

Grer contentieux

AD

Grer archive

ACTEURS

CAS DUTILISATION
Elaborer budget, valider budget
Elaborer PPM, valider PPM
Rdiger TDR, Elaborer DAO, vendre
DAO, valider DAO, publier DAO, acheter
DAO, consulter DAO, publier proposition
attributaire
Soumissionner march, analyser offres,
dpouiller offres, valider proposition
attributaire
Etablir
ordre de service,
tablir
notification, tablir contrat, suivre et
valuer march, rceptionner les biens,
rdiger PV de rception, approuver facture.
Suspendre march, reprendre march,
poursuivre march
Archiver soumission, archiver document

THEME : Gestion des marchs publics la SONAPOST

Page 23

march

II.2.3.

Diagramme de cas dutilisation

Figure II.9 : Diagramme de cas dutilisation

THEME : Gestion des marchs publics la SONAPOST

Page 24

System

<<extend>>
EB

Elaborer budget

Valider budget

Elaborer PPM

<<include>>

EPPM

<<extend>>
Rdiger TDR

Valider PPM

Valider DAO

VB

Archiver document

<<extend>>

<<include>>

<<include>>

CPPM

Elaborer DAO
RTDR

Publier DAO
<<extend>>

Vendre DAO

<<extend>>

Publier proposition
attributaire

AD

Soumissionner
march
<<include>>

<<extend>>

SM

Proposer
attributaire
Rdiger PV de
rception

<<include>>

<<extend>>

Valider
proposition
attributaire

PM

<<include>>

<<include>>
Rceptionner
les biens

<<include>>
Approuver facture

<<extend>>
RB

Consulter DAO

Grer
contentieux
<<extend>>

GC

VPPM

<<include>>

Acheter DAO

Analyser offres

Dpouiller offres
<<include>>
RAM

Suivre et
valuer
march

Rdiger PV de
dpouillement

Etablir ordre
de service
<<include>>

Grer contrat

RM

Analyse technique
<<include>>

Etablir notification

<<include>>

Analyse financire

AO
Etablir contrat

THEME : Gestion des marchs publics la SONAPOST

Page 25

Description des relations entre cas dutilisation

II.2.3.1.

Tableau II.9 : Tableau rcapitulatif des relations entre les diffrents cas dutilisation
CAS DUTILISATION A

RELATION

CAS DUTILISATION B

DESCRIPTION

Valider budget

tend

Elaborer budget

Un budget labor peut


tre valid ou pas.

Elaborer PPM

inclut

Valider budget

Pour laborer le PPM il


faut que le budget ait
t valid.

Valider PPM

tend

Elaborer PPM

Un PPM labor peut


tre valid ou pas.

Elaborer DAO

inclut

Rdiger TDR

Pour laborer le DAO il


faut que les TDR aient
t rdigs.

Valider DAO

tend

Elaborer DAO

Un DAO labor peut


tre valid ou pas.

Publier DAO

inclut

Valider DAO

Pour publier le DAO il


faut quil soit valid.

Publier DAO

tend

Vendre DAO

Un DAO publi peut


tre mis en vente.

Acheter DAO

tend

Vendre DAO

Un DAO mis en vente


peut
faire
lobjet
dachat.

Acheter DAO

inclut

Consulter DAO

Pour acheter un DAO il


faut lavoir consult.

Soumissionner March

inclut

Consulter DAO

Pour soumissionner
un march il faut avoir
consult le DAO.
La publication de la
proposition
dattributaire
peut
donner lieu un
contentieux.

Publier
attributaire

proposition tend

Grer contentieux

Publier
attributaire

proposition inclut

Valider
attributaire

Grer contentieux

tend

proposition Pour
publier
la
proposition
dattributaire il faut
quelle soit valide.

Rceptionner les biens

THEME : Gestion des marchs publics la SONAPOST

La rception des biens


peut donner lieu un
contentieux.

Page 26

et

valuer

Le suivi et lvaluation
du march peut aboutir
la rception des biens.

Rceptionner les biens

tend

Suivre
march

Rceptionner les biens

inclut

Rdiger
rception

Analyser offres

inclut

Proposer attributaire

Proposer attributaire

tend

Valider
attributaire

Approuver facture

inclut

Rdiger PV de rception Pour


approuver
la

facture, il faut que le


PV de rception ait t
rdig.

Dpouiller offres

inclut

Rdiger
PV
dpouillement

Grer contrat

inclut

Etablir ordre de service

La gestion du contrat
implique la rdaction
dun ordre de service.

Grer contrat

inclut

Etablir notification

La gestion du contrat
implique
ltablissement
dune
notification.

Grer contrat

inclut

Etablir contrat

La gestion du contrat
implique
ltablissement
du
contrat.

Analyse financire

hrite

Analyse des offres

Lanalyse financire est


une partie de lanalyse
des offres qui concerne
loffre financire de la
soumission.

Analyse technique

hrite

Analyse des offres

Lanalyse technique est


une partie de lanalyse
des offres qui concerne
loffre technique de la
soumission.

PV

de Pour rceptionner les


biens il faut rdiger un
PV de rception.
Lanalyse des offres
aboutit la proposition
dun attributaire.

proposition La
proposition
dattributaire provisoire
peut tre valide ou pas.

THEME : Gestion des marchs publics la SONAPOST

de Le dpouillement des
offres
implique
la
rdaction dun PV de
dpouillement.

Page 27

II.2.3.2.

Description dtaille des cas dutilisation

Nous allons maintenant dtailler chaque cas dutilisation qui doit faire lobjet dune
dfinition priori qui dcrit lintention de lacteur lorsquil utilise le systme et les squences
dactions principales quil est susceptible deffectuer. Ces dfinitions servent fixer les ides
et nont pas pour but de spcifier un fonctionnement complet et irrversible.
Tableau II.10 : Description textuelle du cas dutilisation Grer budget
Description du cas Grer Budget
Identification
Nom du cas : Grer Budget .
But : dtaille les tapes permettant de grer le budget de lanne.
Acteur principal : EB
Acteur secondaire : VB
Date de cration : le 19/09/2012
Date de mise jour : le 26/02/2013
Responsable : KOUTOU Wend-Nougui Odilon
Version : 1.0.
Squencement
Le cas dutilisation commence lorsque lEB demande laborer le budget de lanne.
Pr-conditions
Il ya un budget global.
Scnario nominal
1. LEB indique lanne du budget
2. LEB cre les lignes budgtaires
3. LEB transmet le budget au VB
4. Le VB vrifie les lignes budgtaires
5. Le VB valide les lignes budgtaires
Enchanements alternatifs ou derreur
Enchanements alternatifs
A1 : les lignes budgtaires comportent des erreurs
Lenchanement A1 dmarre aprs le point 4 du scnario nominal
5. Le VB indique les erreurs sur les lignes budgtaires
6. Le VB demande lEB de corriger les erreurs
7. LEB corrige les erreurs
8. LEB transmet le budget corrig au VB
Lenchanement reprend au point 5 du scnario nominal.
Post-conditions
Le budget de lanne est labor et valid.

Tableau II.11 : Description textuelle du cas dutilisation Grer PPM


Description du cas Grer PPM
Identification
Nom du cas : Grer PPM .
But : dtaille les tapes permettant de grer le plan annuel de passation des marchs.
Acteur principal : EPPM
Acteur secondaire : CPPM, VPPM

THEME : Gestion des marchs publics la SONAPOST

Page 28

Date de cration : le 19/09/2012


Date de mise jour : le 16/02/2013
Responsable : KOUTOU Wend-Nougui Odilon
Version : 1.0.
Squencement
Le cas dutilisation commence lorsque lEPPM demande laborer le plan annuel de passation des
marchs.
Pr-conditions
Le budget de lanne a t valid
Scnario nominal
1. LEPPM consulte le budget valid
2. LEPPM cre les marchs pour toutes les lignes budgtaires
3. Le CPPM donne son avis sur le PPM
4. LEPPM intgre les observations du CPPM
5. LEPPM transmet le PPM au VPPM
6. Le VPPM vrifie les marchs sur le PPM
7. Le VPPM valide le PPM de lanne
Enchanements alternatifs ou derreur
Enchanements alternatifs
A1 : le PPM comporte des erreurs
Lenchanement A1 dmarre aprs le point 6 du scnario nominal
7. Le VPPM indique les erreurs sur les marchs figurant sur le PPM
8. Le VPPM demande lEPPM de corriger les erreurs
9. LEPPM corrige les erreurs sur le PPM
10. LEPPM transmet le PPM corrig au VPPM
Lenchanement reprend au point 7 du scnario nominal.
Post-conditions
Le plan annuel de passation des marchs est labor et valid.

Tableau II.12 : Description textuelle du cas dutilisation Grer DAO


Description du cas Grer DAO
Identification
Nom du cas : Grer DAO .
But : dtaille les tapes permettant de grer le DAO.
Acteur principal : RM
Acteur secondaire : RTDR, PM, SM
Date de cration : le 19/09/2012
Date de mise jour : le 16/02/2013
Responsable : KOUTOU Wend-Nougui Odilon
Version : 1.0.
Squencement
Le cas dutilisation commence lorsque le RM demande laborer un dossier dappel doffres.
Pr-conditions
Le PPM a t valid.
La priode de lancement du march est arrive
Scnario nominal
1. Le RTDR rdige les TDR
2. Le RTDR transmet les TDR au RM
3. Le RM consulte les TDR
4. Le RM cre le DAO du march
5. Le RM transmet le DAO au PM

THEME : Gestion des marchs publics la SONAPOST

Page 29

6. Le PM vrifie le DAO
7. Le PM valide le DAO
8. Le PM publie le DAO
9. Le RM met en vente le DAO
10. Le SM consulte le DAO
11. Le SM achte le DAO
Enchanements alternatifs ou derreur
Enchanements alternatifs
A1 : le DAO comporte des erreurs
Lenchanement A1 dmarre aprs le point 6 du scnario nominal
9. Le PM indique les erreurs sur DAO
10. Le PM demande au RM de corriger le DAO
11. Le RM corrige les erreurs sur le DAO
12. Le RM transmet le DAO au PM
Lenchanement reprend au point 7 du scnario nominal.
Post-conditions
Le DAO a t publi.

Tableau II.13 : Description textuelle du cas dutilisation Grer soumission


Description du cas Grer soumission
Identification
Nom du cas : Grer soumission .
But : dtaille les tapes permettant de grer les soumissions
Acteur principal : RAM
Acteur secondaire : RM, AO, SM
Date de cration : le 19/09/2012
Date de mise jour : le 16/02/2013
Responsable : KOUTOU Wend-Nougui Odilon
Version : 1.0.
Squencement
Le cas dutilisation commence lorsque le RM demande laborer un dossier dappel doffres.
Pr-conditions
Le dlai de dpt des soumissions nest pas arriv terme
Scnario nominal
1. Le SM dpose sa soumission
2. Le RAM effectue le dpouillement des offres
3. Le RAM vrifie les pices administratives de chaque soumission
4. Le RAM rdige un procs verbal de dpouillement
5. Le RAM remet lAO le procs verbal ainsi que les diffrentes soumissions
6. LAO vrifie encore les pices administratives de chaque soumission
7. LAO procde lanalyse technique des offres
8. LAO retient un certain nombre de soumissionnaires pour la suite de lanalyse
9. LAO procde lanalyse financire des offres
10. LAO tablit un rapport qui propose un attributaire provisoire
11. Le RAM vrifie les motifs de rejet ou dacceptation des offres
12. Le RAM valide la proposition de lAO
13. Le RAM tablit un PV de dlibration
14. Le RAM transmet le PV douverture de plis, le PV de dlibration ainsi que le rapport de
lAO au PM
15. Le PM publie la proposition dattributaire
Enchanements alternatifs ou derreur

THEME : Gestion des marchs publics la SONAPOST

Page 30

Enchanements alternatifs
A1 : il sagit dun appel doffre restreint ou dun march de gr gr
Lenchanement A1 dmarre aprs le point 4 du scnario nominal
5. Le RAM demande au SM de complter les soumissions
6. La RAM analyse les offres
Lenchanement reprend au point 13 du scnario nominal
A2 : il ya des soumissions incompltes
Lenchanement A2 dmarre aprs le point 3 du scnario nominal
4. Le RAM demande au SM de complter les soumissions
Lenchanement reprend au point 4 du scnario nominal
A3 : les motifs dacception ou de rejet des soumissions ne sont pas justifis
Lenchanement A3 dmarre aprs le point 11 du scnario nominal
12. Le RAM indique les corrections apporter au rapport de lAO
13. LAO intgre les corrections au rapport
14. LAO transmet le rapport corrig au RAM
Lenchanement reprend au point 12 du scnario nominal
Enchanements derreur
E1 : loffre technique nest pas conforme
Lenchanement E1 dmarre aprs le point 7 du scnario nominal
8. LAO ne retient pas la soumission pour la suite de lanalyse
Post-conditions
La proposition dattributaire a t publie.

Tableau II.14 : Description textuelle du cas dutilisation Grer contentieux


Description du cas Grer contentieux
Identification
Nom du cas : Grer contentieux .
But : dtaille les tapes permettant au GC de grer un contentieux
Acteur principal : GC
Acteur secondaire : RM, SM
Date de cration : le 25/09/2012
Date de mise jour : le 16/02/2013
Responsable : KOUTOU Wend-Nougui Odilon
Version : 1.0.
Squencement
Le cas dutilisation commence lorsque le GC doit grer un contentieux
Pr-conditions
La proposition dattributaire a t publie
Scnario nominal
1. Le SM adresse une plainte au GC
2. Le GC suspend le march concern par la plainte
3. Le GC reoit la dcision concernant la plainte
4. Le GC consulte la dcision
5. Le RM poursuit le march
Enchainements alternatifs ou derreur
Enchanements derreur
E1 : la dcision est de reprendre le march
Lenchanement E1 dmarre aprs le point 4 du scnario nominal
1. Le RM reprend toute la procdure de passation du march
Post-conditions
Le contentieux a t gr.

THEME : Gestion des marchs publics la SONAPOST

Page 31

Tableau II.15 : Description textuelle du cas dutilisation Grer march


Description du cas Grer march
Identification
Nom du cas : Grer march .
But : dtaille les tapes permettant au RM de grer un march
Acteur principal : RM
Acteur secondaire : Attributaire, RB
Date de cration : le 25/09/2012
Date de mise jour : le 16/02/2013
Responsable : KOUTOU Wend-Nougui Odilon
Version : 1.0.
Squencement
Le cas dutilisation commence lorsque le RM doit grer un march.
Pr-conditions
La proposition dattributaire a t publie.
Scnario nominal
1. Le RM adresse une notification provisoire lattributaire
2. Lattributaire apporte son RIB et une facture pro forma
3. Le RM tablit le contrat
4. Lattributaire signe le contrat
5. Lattributaire enregistre le contrat aux impts
6. Le RM adresse une notification et un ordre de service lattributaire
7. Lattributaire fait un tat davancement priodique au RM
8. Le RM tient un journal de bord pour suivre lexcution des marchs
9. Le RM relance lattributaire lapproche du dlai
10. Lattributaire adresse une correspondance au RM
11. Le RM demande au RB de rceptionner les biens
12. Lattributaire amne le ou les biens
13. Le RB vrifie la conformit des biens
14. Le RB dresse un PV de rception des biens
15. Lattributaire dpose sa facture
16. Le RM vrifie la facture de lattributaire
17. Le RM approuve la facture
Enchanements alternatifs ou derreur
Enchanements alternatifs
A1 : les biens ne sont pas conformes
Lenchanement A1 dmarre aprs le 13 du scnario nominal
1. Le RB met des rserves
2. Lattributaire prend en compte les rserves
Lenchanement reprend au point 14 du scnario nominal
A2 : la facture nest pas conforme la facture pro forma
Lenchanement A2 dmarre aprs le 16 du scnario nominal
1. Le RM indique les erreurs sur la facture
2. Le RM demande lattributaire de corriger les erreurs sur la facture
3. Lattributaire corrige les erreurs
4. Lattributaire transmet la facture corrige au RM
Lenchanement reprend au point 17 du scnario nominal
Post-conditions
Le march a t gr

THEME : Gestion des marchs publics la SONAPOST

Page 32

Tableau II.16 : Description textuelle du cas dutilisation Grer archive


Description du cas Grer archive
Identification
Nom du cas : Grer archive .
But : dtaille les tapes permettant lAD darchiver un document du march
Acteur principal : AD
Acteur secondaire : SM
Date de cration : le 19/09/2012
Date de mise jour : le 16/02/2013
Responsable : KOUTOU Wend-Nougui Odilon
Version : 1.0.
Squencement
Le cas dutilisation commence lorsque lAD demande archiver un document du march
Pr-conditions
Le march a t publi
Enchanement nominal
1. Le SM a apport un document archiver
2. LAD vrifie si larchive nest pas complte
3. LAD ajoute le document larchive
4. LAD met jour sa fiche darchivage
Enchanements alternatifs ou derreur
Enchanements alternatifs
A1 : larchive est complte
Lenchanement A1 dmarre aprs le 2 du scnario nominal
1. LAD cre une nouvelle archive
Lenchanement reprend au point 4 du scnario nominal
Post-conditions
Un document a t archiv
Une fiche darchivage a t cre

NB : Larchive dsigne ici un carton o sont rangs les documents se rapportant un


march.
II.3.

Diagramme de classes

Cette phase va prparer la modlisation oriente objet en aidant trouver les classes
principales du futur modle statique danalyse.
La technique utilise pour identifier les classes candidates est la suivante :
Chercher les noms communs importants dans les descriptions textuelles des cas
dutilisation ;
Vrifier les proprits objet de chaque concept (identit, proprits,
comportement).

THEME : Gestion des marchs publics la SONAPOST

Page 33

Concepts utiliss
a) Notion de classe
Une classe est la description dune famille dobjets ayant la mme structure et le
mme comportement. Elle comporte une partie statique (attributs) et une partie dynamique
(mthodes ou oprations).
La notation dune classe est un rectangle qui comporte trois (03) compartiments.
1er compartiment : nom de la classe ;
2me compartiment : les attributs ;
3me compartiment : les mthodes.
Figure II.10 : Reprsentation dune classe
Nom de classe
-

Attribut_1
Attribut_2
.
Attribut_i

+
+
+
+

Methode 1 ()
Methode 2 ()
. ()
Methode k ()

: type
: type
:
: type

NB : Les deux(02) derniers compartiments peuvent tre omis selon le niveau dabstraction
choisi.
La syntaxe complte des attributs est :

visibilit nom [multiplicit] type = Valeur_initiale {proprits}


La visibilit est reprsente par les signes + (public), - (private) et # (protected).
La multiplicit est le nombre doccurrences possibles de lattribut.
La syntaxe dune mthode est la suivante :

visibilit Nom (liste paramtre) type {proprits}


Liste paramtre est reprsente par Nature Nom : type=Valeur par dfaut.
La nature est soit, IN, soit OUT ou encore IN OUT.

Notion dattribut
Un attribut est une information lmentaire composant une classe. Un attribut peut
permettre didentifier la classe. Il est typ (Integer, Real, String, ).
THEME : Gestion des marchs publics la SONAPOST

Page 34

Notion de mthode ou opration


Une mthode ou opration est une fonctionnalit assure par la classe.

b) Notion de multiplicit
La multiplicit est le nombre dinstances dune classe implique dans une association.
Elle est la traduction dune rgle de gestion. En gnral on fait apparaitre deux (02)
nombres (entiers) reprsentant le minimum (min) obligatoire et le maximum autoris (max).
Parfois ces deux(02) cardinalits sont gales. De faon pratique on utilise des valeurs :

0 uniquement pour un minimum ;


1 pour un minimum et/ou un maximum ;
* pour 0 ou plusieurs.

Pour les associations binaires, la multiplicit sexprime comme suit :


Figure II.11 : Reprsentation de la notion de multiplicit
Classe A

q1...q2

p1...p2

Classe B

Pour une instance de la classe A, il ya au minimum q1 instance(s) de la classe B et au


maximum q2. De la mme faon, pour une instance de classe B, il ya au minimum p1
instance(s) de classe A et au maximum p2.
Parfois on nutilise quun seul nombre, le second tant implicite :
1 pour 1..1 ;
* pour 0..* ;
Q1 pour q1..q1.
Exemple : Dans le cas de la gestion dune universit, nous pouvons avoir une classe
Etudiant et une classe facult et il existe un lien Sinscrire entre ces deux classes.
Un tudiant pourra sinscrire dans une ou plusieurs facults et une facult peut recevoir
plusieurs tudiants.
Figure II.12 : Exemple pour la notion de multiplicit
Etudiant
-

Numero
Nom
Prenoms
Age
Filire

:
:
:
:
:

int
string
string
int
string

Facult
0..*

S'inscrire

1..*

- Numero : int
- Nom
: int
+ Crer ()

+ Caler nbre d'tudiants ()

c) Notion dassociation
THEME : Gestion des marchs publics la SONAPOST

Page 35

Une association est un lien smantique entre deux(02) classes.


Figure II.13 : Formalisme de la notion dassociation
Nom de
l'association
min..max

min..max

Une classe association est porteuse dattributs.


Figure II.14 : Formalisme de la notion de classe association
Nom de
l'association
min..max

min..max

Classe Asociation
- Attribut_1 : int

Figure II.15 : Exemple pour la notion de classe association


Etudiant
-

Numero
Nom
Prenoms
Age
Filire

:
:
:
:
:

int
string
string
int
string

Facult
0..*

S'inscrire

1..*

- Numero : int
- Nom
: int
+ Crer ()

+ Calculer nbre d'tudiants ()

Date inscription
- anne : string
- jour
: string

d) Gnralisation/Spcialisation
La gnralisation est une relation entre un lment gnral (superclasse ou classe
mre) et un lment driv de celui-ci mais plus spcifique dsign par le terme sous-classe
ou une classe fille. La gnralisation est qualifie de relation est une sorte de .
La spcialisation dune classe permet de mettre en facteur commun certaines
descriptions, soit prciser de nouvelles contraintes sur le modle de classes. La
gnralisation/spcialisation est reprsente par :

THEME : Gestion des marchs publics la SONAPOST

Page 36

Figure II.16 : Formalisme de la notion de Gnralisation/Spcialisation

Classe Generique
- Attribut communs :
+ Methodes communes ()

Specialisation
Gneralisation

Classe specialise
- Attributs Specifiques :
+ Methodes Specifiques ()

Exemple : Dans le cas de la gestion de luniversit il peut exister une classe


Enseignant qui, en plus de la Etudiant peuvent se gnraliser en une seule classe
Personne
Figure II.17 : Exemple pour la notion de Gnralisation/Spcialisation
Personne
-

Numero
Nom
Prenoms
Date naissance
Adresse

:
:
:
:
:

int
string
string
string
string

Etudiant

Enseignant
-

Numero
Nom
Prenoms
Grade
Age

:
:
:
:
:

int
string
string
string
int

Numero
Nom
Prenoms
Age
Filire

:
:
:
:
:

int
string
string
int
string

+ Calculer nbre d'tudiants ()

e) Agrgation

THEME : Gestion des marchs publics la SONAPOST

Page 37

Cest un type particulier dassociation. Elle met en vidence une classe agrgat et une
Classe agrge. Lagrgation dfinit une relation tout ou partie entre lagrgat (le tout) et
lagrge (la partie).
Lagrgation est reprsente par un losange clair associ lagrgat.
Figure II.18 : Formalisme gnrale de lagrgation
Classe agrege

Classe agregat
1..1

1..*

Exemple : Dans le cas de la gestion dun parking, on a une classe Parking et une
classe Place . Un parking contient une ou plusieurs places et une place nest affecte qu
un et un seul parking.
Figure II.19 : Exemple pour la notion dagrgation
Parking
- Numero
: int
- Nom
: string
- Nbre de places : int

Place
1..1

1..*

- Numero : int

f) Composition
Cest une forme dagrgation qui vhicule des notions de fortes proprits et de vie
concidente des parties par rapport au tout.
Dans une composition, le tout est responsable de la mise disposition de ses parties. La
suppression dun objet agrgat entraine la suppression des objets agrgs. Ma valeur
maximale de la multiplicit dun du conteneur ne doit pas excder 1 puisque les objets,
instances de la classe des composants, doivent tous appartenir au mme objet conteneur. La
suppression dune classe agrgat entraine la suppression des objets agrgs.
La composition est reprsente par un objet noir.
Figure II.20 : Formalisme gnrale de la composition
Classe agrege

Classe agregat
1..1

1..*

Exemple : Dans le cas de la gestion dune municipalit, il ya une relation de


composition entre la classe Commune et la classe Mairie . A une commune on peut
associer une ou plusieurs mairies et une mairie appartient une et une seule commune. La
suppression dune commune entraine la suppression de ses mairies.

THEME : Gestion des marchs publics la SONAPOST

Page 38

Figure II.21 : Exemple pour la notion de composition


Mairie

Commune
- Numero
: int
- Nom
: string
- Nom province : string

II.3.1.

1..*
1..1

- Code
: int
- Nom
: string
- Adresse : string

Rgles de gestion

Les rgles de gestion (RG) retenues sont :


RG1:
RG2:
RG3:
RG4:
RG5:
RG6:
RG7:
RG8:
RG9:
RG10:
RG11:
RG12:
RG13:
RG14:
RG15:
RG16:
RG17:
RG18:
RG19:
RG20:
RG21:
RG22:
RG23:
RG24:
RG25:
RG26:
RG27:
RG28:
RG29:
RG30:

Un exercice budgtaire contient plusieurs comptes budgtaires


Un compte budgtaire peut figurer dans plusieurs exercices budgtaires
Un PPM contient plusieurs lignes budgtaires
Une ligne budgtaire concerne un seul PPM
Une ligne budgtaire se compose dun ou de plusieurs marchs
Un march est rattach une seule ligne budgtaire
Un march contient un ou plusieurs lots
Un lot concerne un seul march
Un march fait lobjet dun seul mode de passation
Un mode de passation concerne un ou plusieurs marchs
Un march appartient un et un seul type de march
Un type de march concerne un ou plusieurs marchs
Un march est possde un et un seul DAO
Un DAO concerne un et un seul march
Un soumissionnaire achte un ou plusieurs DAO
Un dossier est achet par un ou plusieurs soumissionnaires
Un soumissionnaire soumissionne un ou plusieurs lots
Un lot fait lobjet dune ou plusieurs soumissions
Une soumission fait lobjet dun dpouillement
Un dpouillement concerne une ou plusieurs soumissions
Une dlibration concerne une et une seule analyse
Une analyse concerne une ou plusieurs soumissions
Une soumission fait lobjet dune ou plusieurs analyses
Une soumission contient une plusieurs pices administratives
Un march possde une ou plusieurs archives
Une archive concerne un et un seul march
Une archive contient un ou plusieurs documents
Une rception concerne un et un seul lot
Un lot fait lobjet dune ou plusieurs rceptions
Un ordre de service concerne un et un seul lot

THEME : Gestion des marchs publics la SONAPOST

Page 39

RG31:
RG32:
RG33:
RG34:
RG35:
RG36:
RG37:
RG38:
RG39:
RG40:
RG41:
RG42:
RG43:
II.3.2.

Un lot possde un et un seul ordre de service


Une notification concerne un et un seul lot
Un lot possde une et une seule notification
Un contrat concerne un et un seul lot
Un lot possde un et un seul contrat
Un lot fait lobjet dun ou plusieurs suivis
Un suivi concerne un et un seul lot
Un RIB concerne un et un seul lot
Une pro forma concerne un et un seul lot
Une plainte concerne une dlibration
Une dlibration fait lobjet dune ou plusieurs plaintes
Une plainte fait lobjet dune dcision
Une dcision concerne une et une seule plainte
Diagramme de classes

THEME : Gestion des marchs publics la SONAPOST

Page 40

Figure II.22 : Diagramme de classes

THEME : Gestion des marchs publics la SONAPOST

Page 41

Document

Exercice budgtaire

+
+
+
+
+
+

PPM

creer ()
modifier ()
supprimer ()
rechercher ()
valider ()
lister ()
...

- annee
: int
- etat
: boolean
- observation : String
+
+
+
+
+
+

creer ()
modifier ()
supprimer ()
rechercher ()
valider ()
lister ()
...

- libelle
: String
- dateajout : Date

Compte budgtaire

- annee
: int
- etat
: String
- observation : String
1..*

: void
: void
: void
: void
: void
: void

- numero : int
- libelle : String

contient

+
+
+
+

1..*

creer ()
modifier ()
supprimer ()
rechercher ()
...

: void
: void
: void
: void

1..1 contient

+
+
+
+
+

1..*

Type
- code : int
- libelle : String
+
+
+
+

creer ()
modifier ()
supprimer ()
lister ()
...

creer ()
modifier ()
supprimer ()
rechercher ()
lister ()
...

: void
: void
: void
: void
: void

+ creer ()
possde+ modifier ()
1..1
+ supprimer ()
est compose
+ lister ()
1..*
1..*
...

1..1

1..1
: void
: void
: void
: void

appartient
1..*

1..*

se compose

1..1

Rception

numero
nature
responsableTDR
dateLancement
dateDemarrage
dateReception
financement

+
+
+
+
+
+

creer ()
modifier ()
supprimer ()
rechercher ()
initier ()
lister ()
...

: String
: String
: String
: Date
: Date
: Date
: String

: void
: void
: void
: void
: void
: void

1..1
1..1
1..1
Ordre de service

1..1

- numero : String
- date
: Date

concerne

Deliberation

creer ()
modifier ()
supprimer ()
rechercher ()
lister ()
...

: String
: String
: double
: double
: int
: int
: boolean

- chargeNotification : String
- date
: Date

1..*soumissionne
1..*

1..*

1..1
Plainte

concerne

1..*

- dateDebut : Date
- dateFin
: Date
- rapport
: String

enregistrer ()
modifier ()
supprimer ()
suspendreMarche ()
...

numero
dateCreation
nbExemplaires
chemin
etat

+ creer ()
+ valider ()
Rcpiss + joindre ()
+ publier ()
numeroMandat : String
...
typeMandat
: String
montantMandat : double
bureauPoste
: String
dateEmission : Date

RIB

- adresseTitulaire : String
- numeroCompte : String

Soumission
-

numeroOrdre
dateArrivee
nomDepositaire
montant
offreFinanciere
offreTechnique

: int
: Date
: String
: double
: String
: String

requiert
1..1
1..1
contient
1..1

Pieces Administratives

1..*
1..*est faite

1..*

- intitule : String

Decision

- numero
: String
- date
: Date
- observation : String
+
+
+
+

1..1

0..1
1..1
fait l'objet

Analyse
concerne

concerne

concerne

1..1

1..1

1..1

Soumissionnaire

: void
: void
: void
: void
: void

- date : Date
- lieu : String

1..*

- nom
: String
- adresse : String
- telephone : String

Depouillement
Notification

dispose de

1..*

1..1

- date
: Date
- procesVerbal : String

1..1

+
+
+
+
+

Suivi

DAO

Lot

concerne

1..*

1..1

achte

1..1
numero
description
montant
garantie
delaiEngagement
delaiExecution
etat

+ creer ()
: void
+ ajouterdocument () : void
...

1..1

1..*

+ creer ()
: void
+ supprimer () : void
...
1..*

: void
: void
: void
: void

- date
: Date
- information : String

- type
: String
- date
: Date
- observation : String

fait rfrence

Archive
- numero : int

March

fait l'objet

Contrat

1..1

- code : int
- libelle : String

1..1

- numero : String
- date
: Date

est constitue
Mode Passation

Ligne budgtaire
- montant : int

: void
: void
: void
: void
: void
: void

1..*

1..1
: void
: void
: void
: void

1..1

1..*

fait rfrence

- numero
: String
- date
: Date
- observation : String
+ reprendreMarche () : void
+ poursuivreMarche () : void
...

requiert

adresse
0..1
Proforma
- numero : String
- date
: Date
- chemin : String

III.

Forces et faiblesses du systme existant

THEME : Gestion des marchs publics la SONAPOST

Page 42

: void
: void
: void
: void

: String
: Date
: int
: String
: String

La gestion actuelle des marchs publics comporte un certain nombre de points positifs
parmi lesquels nous pouvons citer :
Existence dun rfrentiel de dlais pour le traitement des dossiers ;
Mise en place dun plan de passation des marchs ;
La volont et la disponibilit du personnel.
De nombreuses difficults ont t galement constates dans le processus de gestion des
marchs publics. Il sagit notamment de :

Le travail se fait de faon manuelle ;


Les tches des diffrents acteurs ne sont pas clairement dfinies ;
Laccs aux diffrents dossiers nest soumis aucune contrainte de scurit ;
Absence dun systme de suivi de lexcution du plan de passation des marchs ;
Absence dun systme darchivage des diffrents documents.

CONCLUSION
A lissue de ce chapitre, nous sommes parvenus dcrire le fonctionnement du
systme actuel de gestion des marchs publics. En effet, il nous a permis de dgager les forces
ainsi que les faiblesses du systme actuel. Cela nous permettra par la suite de proposer des
solutions en vue de pallier aux insuffisances actuelles.

THEME : Gestion des marchs publics la SONAPOST

Page 43

CHAPITRE III : ETUDE CONCEPTUELLE


DETAILLEE DU FUTUR SYSTEME
INTRODUCTION
Le prcdent chapitre nous a permis de rvler les forces et les faiblesses du systme
actuel de gestion des marchs publics la SONAPOST. Dans le prsent chapitre nous ferons
une tude dtaille du futur systme.
Pour mener bien cette tude dtaille, nous numrerons les cas dutilisation qui vont
exister ainsi que lenchanement des messages changs entre les diffrents acteurs de notre
systme. Puis nous laborerons le diagramme de classes pour avoir une vue de lagencement
des donnes dans la base de donnes.
Enfin, il sera question de la politique de gouvernance et de scurit du futur systme.

I.

Etude prliminaire

Ltude prliminaire (ou pr tude) est la toute premire tape du processus 2TUP. Elle
consiste effectuer un premier reprage des besoins fonctionnels et oprationnels, en utilisant
principalement des diagrammes trs simples. Elle prpare les activits plus formelles de
capture des besoins fonctionnels et techniques.

I.1.

Identification des acteurs

Les acteurs identifis du futur systme sont :


Tableau III.1 : Tableau rcapitulatif des acteurs du futur systme
ABREVIATION
DU ROLE

DESIGNATION DU ROLE

DESCRIPTION

EB

Elaborateur de Budget

Cest lacteur charg dlaborer le


budget de lanne en affectant les
montants aux lignes budgtaires.

RDTR

Responsable des Termes De Cest lacteur charg de la rdaction


des termes de rfrence.
Rfrence

VB

Validateur de Budget

Cest lacteur charg de valider le


budget de lanne.

THEME : Gestion des marchs publics la SONAPOST

Page 44

EPPM

Elaborateur de Plan
Passation des Marchs

de Cest lacteur charg de la gestion du


plan de passation des marchs publics
depuis son laboration jusqu sa
validation.

VPPM

Validateur de Plan
Passation des Marchs

de Cest lacteur charg de valider le


plan de passation des marchs.

RM

Responsable des Marchs

RAM

Responsable
des Marchs

AD

Archiviste de Document

Larchiviste procde larchivage


des diffrentes pices des marchs.

AO

Analyseur dOffres

Cest lacteur charg deffectuer


lanalyse technique et financire des
offres puis de proposer un
attributaire.

RB

Responsable des Biens

Cest lacteur charg de recevoir les


biens la fin de lexcution du
march.

SM

Soumissionnaire de March

Personne physique ou morale qui


soumissionne un march.

GC

Gestionnaire de Contentieux Cest lacteur qui gre les contentieux


qui peuvent natre suite lattribution
dun march ou lexcution de
celui-ci.

PM

Publicateur de March

Le responsable des marchs soccupe


de la gestion des dossiers dappel
doffre, des soumissions ainsi que de
lexcution des marchs.

dAttribution Cest lacteur charg de lattribution


dun march un soumissionnaire.

Cest lacteur qui est charg de


valider le DAO, publier le DAO ainsi
que les rsultats dattribution du

THEME : Gestion des marchs publics la SONAPOST

Page 45

march.
AS

Cest lacteur qui sera charg de la


cration des profils utilisateurs et de
lattribution des droits daccs.

Administrateur du Systme

I.2.

Modlisation du contexte

A partir des informations obtenues ltape prcdente, nous allons modliser le contexte
de notre application. Ceci va nous permettre dans un premier temps, de dfinir le rle de
chaque acteur dans le systme :
Tableau III.2 : Tableau rcapitulatif des cas dutilisation du futur systme
UTILISATEURS FINAUX

DESCRIPTION
FONCTIONNELS

EB

Elaborer budget

VB

Valider budget

EPPM

Elaborer PPM

VPPM

Valider PPM

RTDR

Rdiger TDR

RM

DES

BESOINS

Elaborer DAO
Vendre DAO
Suivre et valuer march
Approuver facture
Grer contrat :
Etablir ordre de service
Etablir notification
Etablir contrat

AD

Archiver document

RAM

Valider proposition attributaire


Dpouiller offres
Rdiger PV de dpouillement

AO

Analyser offres
Analyser offre financire
Analyser offre technique
Proposer attributaire

RB

Rceptionner biens
Rdiger PV de rception

THEME : Gestion des marchs publics la SONAPOST

Page 46

SM

Soumissionner march
Acheter DAO
Consulter DAO

GC

Grer les contentieux

PM

Publier DAO
Valider DAO
Publier proposition attributaire

AS

Grer les profils dutilisateurs

Remarque : Le cas dutilisation sauthentifier est inclu dans tous les autres cas
dutilisation.

II.

Capture des besoins fonctionnels

Cette phase reprsente un point de vue fonctionnel de larchitecture systme. Par le


biais des cas dutilisation, nous serons en contact permanent avec les acteurs du systme en
vue de dfinir les limites de celui-ci, et ainsi viter de trop sloigner des besoins rels de
lutilisateur final.

II.1.

Dterminer les cas dutilisation

Utilisation doutils de gnration de diagrammes UML :


Tout au long du projet, nous sommes passs par plusieurs outils qui gnrent les
diagrammes UML. Nous allons faire une prsentation rapide de ceux l.
ArgoUML: cest un outil gratuit crit avec Java, nous lavons utilis au dbut puis nous
lavons dlaiss pour sa lourdeur et son interface peu intuitive.
PowerAMC: cest un environnement graphique de modlisation d'entreprise trs simple
d'emploi.
Identification des cas dutilisation :
Lidentification des cas dutilisation une premire fois nous donne un aperu des
fonctionnalits futures que doit implmenter le systme.
Cependant, il nous faut plusieurs itrations pour ainsi arriver constituer des cas
dutilisation complets. Dautres cas dutilisation vont apparatre au fur et mesure de la
description de ceux l, et lavancement dans le recueil des besoins fonctionnels . Pour
constituer les cas dutilisation, il faut considrer l'intention fonctionnelle de l'acteur par
rapport au systme dans le cadre de l'mission ou de la rception de chaque message. En
regroupant les intentions fonctionnelles en units cohrentes, on obtient les cas d'utilisation
suivants :

THEME : Gestion des marchs publics la SONAPOST

Page 47

Tableau III.3 : Tableau rcapitulatif des cas dutilisation du systme avec les diffrents
scnarios
ACTEURS

CAS
DUTILISATION CAS DUTILISATION
PRINCIPAUX

EB, VB

Grer budget

Elaborer budget, valider budget

EPPM, VPPM

Grer PPM

Elaborer PPM, valider PPM

RM, SM, PM

Grer DAO

Rdiger TDR, Elaborer DAO, vendre


DAO, valider DAO, publier DAO, acheter
DAO, consulter DAO

RM, RAM, SM, AO

Grer soumission

Soumissionner march, analyser offres,


dpouiller offres, publier proposition
attributaire, valider proposition attributaire

RM, RB, SM

Grer march

Etablir
ordre de service,
tablir
notification, tablir contrat, suivre et
valuer march, rceptionner les biens,
rdiger PV de rception, approuver facture.

GC

Grer contentieux

Suspendre march,
poursuivre march

AD

Grer archive

Archiver soumission, archiver document


march

AS

Grer profils

Gestion des profils

reprendre

march,

Remarque : Ce premier tableau n'est pas dfinitif, un processus de dveloppement avec UML
est itratif, il se peut qu'il change au fur et mesure de l'avancement du projet.

II.2.

Description dtaille des cas dutilisation

Tableau III.4 : Description textuelle du cas dutilisation Grer budget


Description du cas Grer Budget
Identification
Nom du cas : Grer Budget .
But : dtaille les tapes permettant de grer le budget de lanne.
Acteur principal : EB
Acteur secondaire : VB
Date de cration : le 19/09/2012
Date de mise jour : le 16/02/2013
Responsable : KOUTOU Wend-Nougui Odilon
Version : 1.0.
Squencement

THEME : Gestion des marchs publics la SONAPOST

Page 48

Le cas dutilisation commence lorsque lEB demande laborer le budget de lanne.


Pr-conditions
LEB est authentifi
Scnario nominal
Enchainement (a) : Crer un compte budgtaire
1. LEB saisit le numro du compte budgtaire
2. LEB donne un nom au compte budgtaire
3. LEB cre le compte budgtaire, si le numro du compte existe dj dclencher : [Exception
1 : CompteExistant]
Enchainement (b) : Crer un budget
1. LEB saisit lanne du budget
2. LEB valide lanne, si le budget existe dj dclencher : [Exception 2 : BudgetExistant]
3. LEB choisit un compte budgtaire
4. LEB affecte un montant au compte budgtaire
5. LEB cre le budget
Enchainement (c) : Valider un budget
1. Le VB choisit le budget
2. Le VB valide le budget
Enchanements alternatifs
Enchainement (d) : Modifier un compte budgtaire
1. LEB affiche la liste des comptes budgtaires
2. LEB choisit le compte budgtaire modifier
3. LEB modifie le compte budgtaire
Enchainement (e) : Supprimer un compte budgtaire
4. LEB affiche la liste des comptes budgtaires
5. LEB choisit le compte budgtaire supprimer
6. LEB supprime le compte budgtaire, si le compte appartient un budget dclencher :
[Exception 4 : CompteUtilise]
Enchainement (f) : Modifier un budget en cours dlaboration
1. LEB affiche la liste des budgets en cours dlaboration
2. LEB choisit le budget modifier
3. LEB modifie le budget
Enchainement (g) : Supprimer un budget en cours dlaboration
1. LEB affiche la liste des budgets en cours dlaboration
2. LEB choisit le budget supprimer
3. LEB supprime le budget
Enchainement (h) : Editer un budget valid
1. LEB affiche la liste des budgets valids
2. LEB choisit le budget diter
3. LEB gnre le budget choisi au format PDF

Exceptions
[Exception 1 : CompteExistant] : le systme affiche un message derreur tant que le numro du
compte na pas t chang.
[Exception 2 : BudgetExistant] : le systme affiche un message derreur tant que lanne du budget
na pas t chang.
[Exception 3 : CompteUtilise] : le systme affiche un message derreur tant que le compte
appartient un budget.

THEME : Gestion des marchs publics la SONAPOST

Page 49

Post-conditions
Le budget de lanne est labor et valid.

Tableau III.5 : Description textuelle du cas dutilisation Grer PPM


Description du cas Grer PPM
Identification
Nom du cas : Grer PPM .
But : dtaille les tapes permettant de grer le plan annuel de passation des marchs.
Acteur principal : EPPM
Acteur secondaire : VPPM
Date de cration : le 19/09/2012
Date de mise jour : le 16/02/2013
Responsable : KOUTOU Wend-Nougui Odilon
Version : 1.0.
Squencement
Le cas dutilisation commence lorsque lEPPM demande laborer le PPM.
Pr-conditions
LEPPM est authentifi.
Scnario nominal
Enchainement (a) : Crer un PPM
1. LEPPM consulte la liste des budgets valids
2. LEPPM choisit un budget
3. Le systme affiche les lignes budgtaires du budget choisi
4. LEPPM choisit une ligne budgtaire
5. LEPPM cre les marchs pour la ligne budgtaire choisie
6. LEPPM valide
Enchainement (b) : Valider un PPM
1. Le VPPM choisit le PPM valider
2. Le VPPM valide le PPM
Enchanements alternatifs
Enchainement (c) : Modifier un PPM en cours dlaboration
1. LEB affiche la liste des PPM en cours dlaboration
2. LEB choisit le PPM modifier
3. LEB modifie le PPM
Enchainement (d) : Supprimer un PPM en cours dlaboration
1. LEB affiche la liste des PPM en cours dlaboration
2. LEB choisit le PPM supprimer
3. LEB supprime le PPM
Enchainement (e) : Editer un PPM valid
1. LEB affiche la liste des PPM valids
2. LEB choisit le PPM diter
3. LEB gnre le PPM choisi au format PDF
Post-conditions
Le PPM de lanne est labor et valid.

THEME : Gestion des marchs publics la SONAPOST

Page 50

Figure III.1 : Diagramme dactivits du cas dutilisation Grer PPM

Tableau III.6 : Description textuelle du cas dutilisation Grer DAO


Description du cas Grer DAO
Identification
Nom du cas : Grer DAO .
But : dtaille les tapes permettant de grer le dossier dappel doffre pour un march donn.
Acteur principal : RM
Acteur secondaire : PM, SM
Date de cration : le 19/09/2012
Date de mise jour : le 16/02/2013
Responsable : KOUTOU Wend-Nougui Odilon
Version : 1.0.
Squencement
Le cas dutilisation commence lorsque le Responsable des Marchs (RM) demande initier un
march.
Pr-conditions
Le RM est authentifi.
Scnario nominal
Enchainement (a) : Crer un DAO
1. Le RM consulte la liste des PPM valids

THEME : Gestion des marchs publics la SONAPOST

Page 51

2.
3.
4.
5.
6.
7.

Le RM choisit un PPM
Le systme affiche la liste des marchs initier
Le RM choisit un march
Le RM cre les lots du march
Le RM joint le DAO au format PDF
Le RM valide

Enchainement (b) : Valider un DAO


1. Le PM affiche la liste des DAO valider
2. Le PM choisit le DAO valider
3. Le systme affiche le DAO
4. Le PM valide le DAO
5. Le PM publie le DAO
6. Le RM met en vente le DAO
Enchainement (c) : Acheter un DAO
1. Le RM affiche la liste des DAO en vente
2. Le RM choisit le DAO acheter
3. Le systme affiche le DAO
4. Le RM saisit les informations du rcpiss
5. Le RM valide
6. Le systme autorise le RM remettre le DAO au SM
Enchanements alternatifs
Enchainement (d) : Modifier un DAO en cours dlaboration
1. Le RM affiche la liste des marchs ayant un DAO en cours dlaboration
2. Le RM choisit le march dont on doit modifier le DAO
3. Le RM modifie les lots du march
4. Le RM joint un nouveau DAO
Enchainement (e) : Supprimer un DAO en cours dlaboration
1. Le RM affiche la liste des marchs ayant un DAO en cours dlaboration
2. Le RM choisit le march dont on doit supprimer le DAO
3. Le RM supprime le DAO
Post-conditions
Un dossier dappel doffre a t labor.

THEME : Gestion des marchs publics la SONAPOST

Page 52

Figure III.2 : Diagramme dactivits du cas dutilisation Grer DAO

Tableau III.7 : Description textuelle du cas dutilisation Grer soumission


Description du cas Grer Soumission
Identification
Nom du cas : Grer Soumission .
But : dtaille les tapes permettant de grer les soumissions pour un march donn.
Acteur principal : RM
Acteur secondaire : RAM, SM, AO.
Date de cration : le 19/09/2012
Date de mise jour : le 16/02/2013
Responsable : KOUTOU Wend-Nougui Odilon
Version : 1.0.
Squencement
Le cas dutilisation commence lorsque le Responsable des Marchs (RM) demande grer les
soumissions dun march.
Pr-conditions
Le RM est authentifi.
Scnario nominal
Enchainement (a) : Recevoir soumission

THEME : Gestion des marchs publics la SONAPOST

Page 53

1. Le RM consulte la liste des marchs en cours


2. Le RM choisit un march
3. Le RM saisit les informations de la soumission (date et heure de rception du dossier, numro
darrive, nom de la socit qui soumissionne)
4. Le RM valide
5. Le systme enregistre les informations
Enchainement (b) : Dpouiller soumission
1. Le RAM affiche la liste des marchs en cours
2. Le RAM choisit un march
3. Le systme affiche la liste des soumissions
4. Le RAM saisit pour chaque soumission les pices manquantes
5. Le RAM joint loffre financire et technique pour chaque soumission
6. Le systme enregistre les informations
Enchainement (c) : Analyser soumission (offre)
1. LAO affiche la liste des soumissions analyser
2. LAO choisit une soumission
3. Le systme affiche loffre technique et financire de la soumission
4. LAO saisit la proposition dattributaire
5. LAO joint son rapport danalyse
Enchainement (d) : Valider proposition attributaire
1. Le RAM affiche la liste des propositions dattributaire
2. Le RAM choisit un attributaire
3. Le RAM fait des observations
4. Le RAM valide la proposition dattributaire
Enchanements alternatifs
Enchainement (e) : Modifier une proposition dattributaire non valide
1. LAO affiche la liste des propositions dattributaire
2. LAO choisit la proposition modifier
3. LAO modifie la proposition dattributaire
Post-conditions
Les soumissions ont t gres.

Tableau III.8 : Description textuelle du cas dutilisation Grer contentieux


Description du cas Grer Contentieux
Identification
Nom du cas : Grer Contentieux .
But : dtaille les tapes permettant de grer les contentieux pour un march donn.
Acteur principal : GC
Acteur secondaire : SM
Date de cration : le 19/09/2012
Date de mise jour : le 16/02/2013
Responsable : KOUTOU Wend-Nougui Odilon
Version : 1.0.
Squencement
Le cas dutilisation commence lorsque le Gestionnaire des Contentieux (GC) demande grer les
contentieux dun march.
Pr-conditions

THEME : Gestion des marchs publics la SONAPOST

Page 54

Le GC est authentifi.
Scnario nominal
Enchainement (a) : Enregistrer une plainte
1. Le GC consulte la liste des marchs en cours
2. Le GC choisit un march
3. Le GC joint la plainte
4. Le GC suspend le march
5. Le systme enregistre les informations
Enchainement (b) : Enregistrer une dcision
1. Le GC consulte la liste des marchs suspendus
2. Le GC choisit un march
3. Le GC joint la dcision
4. Le systme enregistre les informations
Post-conditions
Les soumissions ont t gres.

Tableau III.9 : Description textuelle du cas dutilisation Grer march


Description du cas Grer march
Identification
Nom du cas : Grer march .
But : dtaille les tapes permettant de grer un march donn.
Acteur principal : RM
Acteur secondaire : Nant
Date de cration : le 19/09/2012
Date de mise jour : le 16/02/2013
Responsable : KOUTOU Wend-Nougui Odilon
Version : 1.0.
Squencement
Le cas dutilisation commence lorsque le RM demande grer un march.
Pr-conditions
Le RM est authentifi.
Scnario nominal
Enchainement (a) : grer contrat
1. Le RM consulte la liste des marchs en cours
2. Le RM choisit un march
3. Le RM tablit lordre de service, la notification et le contrat
4. Le systme enregistre les informations
Enchainement (b) : Suivre et valuer march
1. Le RM consulte la liste des marchs en cours
2. Le RM choisit un march
3. Le RM met jour le tableau de bord
4. Le systme enregistre les informations
Post-conditions
Lordre de service, la notification et le contrat ont t tablies.

THEME : Gestion des marchs publics la SONAPOST

Page 55

Tableau III.10 : Description textuelle du cas dutilisation Grer contentieux


Description du cas Grer archive
Identification
Nom du cas : Grer archive .
But : dtaille les tapes permettant de grer les archives dun march donn.
Acteur principal : AD
Acteur secondaire : Nant
Date de cration : le 19/09/2012
Date de mise jour : le 16/02/2013
Responsable : KOUTOU Wend-Nougui Odilon
Version : 1.0.
Squencement
Le cas dutilisation commence lorsque lArchiviste Document (AD) demande grer les archives
pour un march donn.
Pr-conditions
Le RM est authentifi.
Scnario nominal
Enchainement (a) : ajouter une archive
1. LAD consulte la liste des marchs en cours
2. LAD choisit un march
3. LAD remplit la fiche darchivage
4. LAD valide
5. Le systme enregistre les informations
Enchanements alternatifs
Enchainement (b) : Consulter fiche darchivage
1. LAD affiche la liste des archives
2. LAD choisit une archive
3. Le systme affiche lemplacement de larchive
Post-conditions
La fiche darchivage a t mise jour.

Tableau III.11 : Description textuelle du cas dutilisation Grer profils


Description du cas Grer profils
Identification
Nom du cas : Grer profils .
But : dtaille les tapes permettant de grer les profils dutilisateurs.
Acteur principal : AS
Acteur secondaire : Nant
Date de cration : le 19/09/2012
Date de mise jour : le 16/02/2013
Responsable : KOUTOU Wend-Nougui Odilon
Version : 1.0.
Squencement
Le cas dutilisation commence lorsque lAS demande grer les profils dutilisateurs.
Pr-conditions
Ladministrateur sest authentifi
Scnario nominal
Enchainement (a) : Crer un utilisateur

THEME : Gestion des marchs publics la SONAPOST

Page 56

1.
2.
3.
4.

Ladministrateur saisit le nom et le prnom de lutilisateur


Ladministrateur saisit le login de lutilisateur
Ladministrateur saisit deux (02) fois le mot de passe de lutilisateur
Ladministrateur valide, si le login existe dj dclencher : [Exception 1 : LoginUtilise]

Enchanements alternatifs
Enchainement (b) : Modifier un utilisateur
1. Ladministrateur affiche la liste des utilisateurs
2. Ladministrateur choisit un utilisateur
3. Ladministrateur modifie les informations
4. Ladministrateur valide, si les informations sont incorrectes dclencher : [Exception 2 :
InformationsIncorrectes]
Enchainement (c) : Supprimer un utilisateur
1. Ladministrateur affiche la liste des utilisateurs
2. Ladministrateur choisit un utilisateur
3. Ladministrateur supprime lutilisateur

Exceptions
[Exception 1 : LoginUtilise] : le systme affiche un message derreur tant que le login na pas t
chang.
[Exception 2 : InformationsIncorrectes] : le systme affiche un message derreur tant que les
informations nont pas t changes.
Post-conditions
Un utilisateur a t mis jour.

Tableau III.12 : Description textuelle du cas dutilisation sauthentifier


Description du cas Sauthentifier
Identification
Nom du cas : Sauthentifier .
But : Permettre laccs un compte.
Rsum : Pour quun utilisateur se connecte son compte, il doit sauthentifier par un nom
dutilisateur et un mot de passe
Acteur: Tout acteur du systme
Date de cration : le 19/09/2012
Date de mise jour : le 16/02/2013
Responsable : KOUTOU Wend-Nougui Odilon
Version : 1.0.
Squencement
Le cas dutilisation commence lorsquun acteur demande accder au systme.
Pr-conditions
Lancer lapplication
Scnario nominal
1. Saisir le nom dutilisateur ou le login
2. Saisir le mot de passe
3. Valider, si le login ou le nom dutilisateur nexiste pas dj dclencher : [Exception 1 :
UtilisateurInexistant]
Enchanements alternatifs ou derreur
Enchainement (d) : Modifier son mot de passe
1. Lutilisateur saisit son ancien mot de passe

THEME : Gestion des marchs publics la SONAPOST

Page 57

2. Lutilisateur saisit son nouveau mot de passe deux (02) fois


3. Lutilisateur valide, si lancien mot de passe est incorrect dclencher : [Exception 2 :
MotPasseIncorrect]

Exceptions
[Exception 1 : UtilisateurInexistant] : le systme affiche un message derreur tant que le login ou le
mot de passe na pas t chang.
[Exception 2 : MotPasseIncorrect] : le systme affiche un message derreur tant que le mot de passe
na pas t chang.
Post-conditions
Lutilisateur sest authentifi.

III.

Capture des besoins techniques (Etude des scnarii)


III.1.

Etude des scnarii

III.1.1. Dfinition
Un scenario est une solution parmi plusieurs autres pour atteindre un mme objectif
spcifique qui est ici, dautomatiser la gestion des marchs publics. Un scnario comprend
une solution technique, une estimation en besoin financier, matriel et humain et une
valuation des gains et des risques sur lorganisation.
III.1.3. Proposition doutils de ralisation
Il sagit dvoquer quelques outils de ralisation qui existent, faire une comparaison entre
eux, mentionner leurs cots, leurs atouts et leurs limites ; tout ceci en tenant compte des missions,
de lvolution technique du domaine informatique et des contraintes conomiques du domaine.
Cette tude nous clairera sur le choix des outils pour la ralisation de notre systme futur.

III.1.3.1.

Les SGBD

Tableau III.13 : Rcapitulatif des SGBD

THEME : Gestion des marchs publics la SONAPOST

Page 58

Dsignation Forces
Faiblesses
Licence
Administration aise ;
Distributions fortement lies au systme
Fonction daudit volu ;
dexploitation ;
Indpendance entre les diverses bases,
Mono-plateforme (MS Windows) ;
facilitant
lintgration
de
plusieurs
Pas certifi SQLJ, pas dintgration Java,
SQL Server
applicatifs dans une mme instance ;
orientation C#.
2008 (dj
Commerciale
Services Web ;
utilis)
Support XML ;
Ordonnanceur intgr ;
Compression des
donnes
et
des
sauvegardes.

MySQL

Grande flexibilit dans l'optimisation de


la base ;

Incertitude sur sa prennit suite


lachat de Sun par Oracle ;

Fonctionne sur de nombreux systmes


d'exploitation diffrents ;

Support incomplet des triggers et


procdures stockes ;

Fait partie des SGBD les plus utiliss au


monde.

Moins de richesse fonctionnelle ;

THEME : Gestion des marchs publics la SONAPOST

Gratuit

Manque de robustesse avec de fortes


volumtries.

Page 59

III.1.3.2.

Les langages de programmation

Tableau III.14 : Rcapitulatif des langages de programmation


Dsignation Forces
Faiblesses
Licence
Popularit, simplicit, souplesse ;
Langage trop permissif : trs peu dinterdictions
Interoprabilit :
capacit

rendre
Les applications sont assez lourdes
compatibles deux systmes quelconques
Portabilit
(sadapte

toutes
les
plateformes)
Prennit (assure une grande continuit)
Support Objet complet
GRATUIT
JAVA
Gestion des exceptions : capacit de grer
les diffrentes erreurs qui peuvent survenir
Simplification de lutilisation dXML
Intgration dune base de donnes
embarque SQLite
Permet de dvelopper tout type dapplication
Amlioration de la gestion des flux
Permet un interfaage simple avec les
PHP5 ne contient pas de container pouvant
nombreux SGBD
contenir certains composants, tel quEJB de la
Une grande communaut de dveloppeurs
plateforme J2EE ou les entreprises services (ex :
La simplicit dcriture des scripts
COM+ de .NET)
PHP5
Simplification de lutilisation dXML,
GRATUIT
intgration dune base de donnes
embarqu : SQLite
Amlioration de la gestion des flux
Programmation Oriente Objet.

THEME : Gestion des marchs publics la SONAPOST

Page 60

III.1.3.3.

Les environnements de dveloppement

Tableau III.15 : Rcapitulatif des environnements de dveloppement


Dsignation
NetBeans
IDE

Zend Studio

Forces
Faiblesses
Facilit de prise en main pour les dbutants
Trs exigeant en taille mmoire
Facilit de raliser des interfaces graphiques avec
Matisse, un diteur WYSIWYG ;
Possibilit de dveloppement de modules pour le
logiciel ;
Ajout de support de multiples langages (C, C++,
UML, PHP, XML, JavaScript) depuis linterface
du programme
Systme de plug-ins performant
Outils visuels de dveloppement dapplications
Zend Studio propose des ressources dites
web et de sites web dynamiques.
de bas niveau. En dautres termes, le
des composants souples, de plus en plus nombreux
framework ne se considre pas comme un
et complets, avec peu dinterdpendance. Ces
L4G qui permettrait de construire une
ressources couvrent tous les dveloppements
application presque sans code, ce qui
redondants et communs aux projets web, qui, grce
limiterait les possibilits dinnovation et
au framework, ne sont plus redvelopper ;
de personnalisation ;
Large utilisation par la communaut des
Ce framework demande un minimum de
dveloppeurs.
connaissances en programmation oriente
objet (POO) et ne fonctionne pas avec
PHP 4. Il est important en particulier de
comprendre les aspects thoriques de
certains composants, ce qui est en partie le
but de cet ouvrage.

THEME : Gestion des marchs publics la SONAPOST

Licence

GRATUIT

COMMERCIALE (74 500)

Page 61

III.2.

Mthode de calcul des cots

On distingue plusieurs mthodes permettant destimer le cot de dveloppement dun


logiciel parmi lesquelles nous avons le modle COCOMO. Cette mthode existe en trois
versions : simple, intermdiaire et dtaille.
Nous utiliserons le modle COCOMO simple qui est le mieux document, il donne des
estimations des cots en s'appuyant sur la taille (estime) du logiciel et sur le type de logiciel
ou projet raliser. Il existe trois (03) types de projets qui sont :
les projets de mode organique : ces projets sont raliss par une quipe de taille
relativement petite travaillant dans un environnement familier et dans un domaine
d'application connu de l'quipe.
les projets de mode semi-dtach : ce sont des types de projets qui ne sont pas trop
complexes. Lquipe de dveloppement se connat un peu et les technologies peuvent
tre mal connues, mais pas dune grande difficult dapprhension.
les projets de mode embarqu : le systme dvelopper est une partie d'un systme
complexe et les modifications de spcifications destines contourner des problmes
logiciels sont en gnral impossibles.
Les formules permettant de calculer le cot ou plus exactement l'effort requis pour le
dveloppement du logiciel en fonction du type de projet sont les suivantes :
mode organique :
HM = 2,4 (KLSL) 1,05
mode semi-dtach : HM = 3 (KLSL) 1,12
mode embarqu :
HM = 3,6 (KLSL) 1,20
HM (signifie Homme-Mois) : reprsente leffort requis pour le dveloppement de
lapplication.
KLSL (Kilo-Lignes-Sources du logiciel) : correspond 1/1000 du nombre de lignes de code
du logiciel.
Le modle COCOMO simple permet galement d'estimer le temps ncessaire au
dveloppement dun projet (TDEV). Les quations pour les diffrents types de projets sont les
suivantes :
Mode organique : TDEV = 2,5 (HM) 0,38
Mode semi-dtach : TDEV = 2,5 (HM) 0,35
Mode embarqu : TDEV = 2,5 (HM) 0,32
HM qui est le nombre d'homme/mois ncessaire la ralisation du projet HM reprsente aussi
leffort requis pour le dveloppement de lapplication.
KLSL reprsente le nombre de Kilo-Lignes-Sources du logiciel.
Le nombre de personnes requis pour raliser le projet dans cet intervalle de temps est donc:
N = HM/TDEV.

THEME : Gestion des marchs publics la SONAPOST

Page 62

Le cot total de ralisation est donn par :


Cot = HM*ValeurHM
O ValeurHM reprsente le salaire moyen dun informaticien au Burkina Faso qui est de
200.000 FCFA.
La mise en place dun systme informatique pour La gestion des marchs publics
est un projet de type semi-dtach car les critres de ce type de projet sont les mieux adapts
notre contexte dtude.

III.3.

Description des scnarii

III.3.1. Symboles utiliss


Figure III.3 : Description des symboles utiliss
Symboles utiliss

Ordinateur de bureau

Modem

Commutateur
Internet

Liaison spcialise
Routeur

Serveur de base de donnes


Pare-feu
Titre

Liaison filaire
Imprimante
Serveur dapplications
Btiment

III.3.2. Premier scnario


Le premier scnario que nous proposons est assez simple dans son architecture rseau et
dans sa mise en uvre. Ce scnario consistera mettre en place une application fonctionnant
selon une architecture 2-tiers encore appele architecture client lourd. Ce style
d'architecture met en uvre deux niveaux environnementaux et organisationnels. En effet, on
distingue d'une part le client lourd demandeur de service et d'autre part le serveur de
donnes qui fournit le service. Aussi, les couches prsentation et mtier seront dveloppes
du ct client et la couche accs aux donnes du ct serveur . Nous aurons donc la
base de donnes qui sera dlocalise sur un serveur ddi, le serveur de donnes qui fournira

THEME : Gestion des marchs publics la SONAPOST

Page 63

les donnes exploiter. Les utilisateurs pourront avoir accs ces donnes travers le code
applicatif qui sera install sur leurs postes de travail respectifs et ce, via le rseau.
Pour ce faire, nous proposons MySQL comme systme de gestion de bases de donnes,
NetBeans IDE comme environnement de dveloppement et JAVA comme langage de
programmation.
III.3.2.1.

Architecture rseau

Figure III.4 : Architecture rseau du scnario 1


DPL
PRM

Sige SONAPOST

Salle Serveurs

Chef codification

Chef DPL

III.3.2.2.

Besoins logiciels

Tableau III.16 : Rcapitulatif des besoins logiciels du scnario 1


Dsignation

Caractristiques

Systme
dexploitation
(ordinateur de
bureau)
Systme
dexploitation
(serveur)
SGBD
Antivirus
Environnement
de
dveloppement

Microsoft Windows
Professionnelle

Quantit
XP

Edition 05

Prix unitaire Montant


(F CFA)
CFA)
Existant
Existant

Microsoft Windows Server 2008

01

Existant

Existant

MySQL
Norton Antivirus 2013
NetBeans IDE 7.0

01
05
01

Gratuit
Existant
Gratuit

Existant
Existant
Existant

THEME : Gestion des marchs publics la SONAPOST

(F

Page 64

TOTAL

0 F CFA

III.3.2.3.

Besoins matriels

Tableau III.17 : Rcapitulatif des besoins matriels du scnario 1


Dsignation
Ordinateurs
bureau

Caractristiques

Quantit

Prix unitaire (F CFA)

de Pentium 4 Dual-

05
(03 350 000
ordinateurs
Core
HP,
Disque Dur 150 existent
Go, 2 Go RAM, dj)

Lecteur/graveur
DVD.
Serveur de base HP
1 800 000
Proliant 01
de donnes
DL180 G6 xeon
quad-core
E5620 2.4GHZ
1P 8GB base
rackmount
serveur 2U
Imprimante
(01 195 000
HP
LaserJet 03
imprimante
P2035m
Onduleur

Mercury
ellite800

TOTAL

III.3.2.4.

existe dj)
05

Existant

Montant
CFA)
700 000

(F

1 800 000

390 000

Existant

2 890 000 F CFA

Evaluation du cot de dveloppement de lapplication

Comme nous lavons dit plus haut, le mode de projet dcrit dans le modle COCOMO
qui sied le mieux notre projet est le mode semi-dtach. Ce choix sexplique notamment par
le fait que la technologie qui sera utilise nest pas totalement maitrise.
La difficult de la mthode COCOMO rside dans lestimation du nombre de lignes de
code. Pour ce faire, nous estimons trois milles (3000) lignes la taille du code source pour ce
scnario
Par ailleurs, le salaire moyen dun informaticien au Burkina Faso est estim 200 000
FCFA.
Par application des formules de calcul du modle COCOMO pour un projet semidtach, nous avons :
Intitul
Effort de dveloppement (HM)
Temps de dveloppement (TDEV)
Valeur de lhomme/mois (ValeurHM)
Nombre de dveloppeurs
Cot de ralisation

Valeur
10,27
5 mois et 18 jours
200000
2
2 240 000

THEME : Gestion des marchs publics la SONAPOST

Page 65

Cot de formation des utilisateurs


La formation des utilisateurs est une condition pralable une prise en main efficace de
lapplication qui sera mise en place.
Prix de lhoraire (F CFA)
3000

Nombre dheures
utilisateur
08

par

Nombre dutilisateurs

Montant (F CFA)

1 20 000

Cot total de ralisation


Dsignation
Cot du matriel et des logiciels acqurir
Cot de dveloppement
Cot de la formation des utilisateurs
Cot total

Prix (F CFA)
2 890 000
2 240 000
120 000
5 250 000

Critiques du scnario
AVANTAGES
Facilit de mise en uvre ;
Cot acceptable pour la mise en uvre ;
Centralisation des donnes au niveau du
serveur avec possibilit de sauvegardes
rgulires ;
Facilit de traitement des donnes;
Disponibilit permanente de la base de
donnes ;
Systme dinformation facile scuriser
cause de la rduction des points
d'entre.

INCONVENIENTS
Maintenance difficile ;
Ncessite
une
installation
et
configuration du client sur chaque poste
client ;
Lourdeur du poste de travail de
lutilisateur.

III.3.3. Deuxime scnario


Le deuxime scnario consiste en la mise en place dune application web avec une
architecture logicielle 3-tiers o lon sparera les couches prsentation, mtier et accs aux
donnes. Les donnes seront accessibles par les diffrents utilisateurs depuis un navigateur
web. Ces types dapplications ont lavantage de dcharger les postes clients des traitements en
leur permettant partir du navigateur web daccder aux fonctionnalits de lapplication
stocke sur le serveur dapplication, do leur nom de client lger. Il faut aussi souligner que
les applications web sont dune mise niveau aise grce la centralisation du code de
lapplication. Les traitements et la gestion des accs aux donnes seront effectus du ct des
serveurs.
Pour la mise en place de ce scnario, nous envisageons dutiliser le SGBD MySQL
ainsi que le langage web PHP 5 dans lenvironnement de dveloppement Zend Studio
9.0.3 .

THEME : Gestion des marchs publics la SONAPOST

Page 66

III.3.3.1.

Architecture rseau

Figure III.5 : Architecture rseau du scnario 2


DPL
PRM

Sige SONAPOST

Salle Serveurs

Chef codification

III.3.3.2.

Chef DPL

Besoins logiciels

Tableau III.18 : Rcapitulatif des besoins logiciels du scnario 2


Dsignation

Caractristiques

Quantit

Systme
dexploitation
(ordinateur de
bureau)
Systme
dexploitation
(serveur)
SGBD
Antivirus

Microsoft
Windows XP
Edition
Professionnelle
Microsoft
Windows Server
2008
MySQL
Norton Antivirus
2013
Zend Studio
9.0.3

Environnement
de
dveloppement
Total

Montant (F CFA)

05

Prix unitaire (F
CFA)
Existant

02

Existant

Existant

01
05

Gratuit
Existant

Gratuit
Existant

01

74 500

74 500

Existant

74 500

THEME : Gestion des marchs publics la SONAPOST

Page 67

III.3.3.3.

Besoins matriels

Tableau III.19 : Rcapitulatif des besoins matriels du scnario 2


Dsignation

Caractristiques

Ordinateurs de
bureau

Pentium 4 DualCore HP,


Disque Dur 150
Go, 2 Go RAM,
Lecteur/graveur
DVD.
Serveur de base
HP Proliant
de donnes
DL180 G6 xeon
quad-core
E5620 2.4GHZ
1P 8GB base
rackmount
serveur 2U
Imprimante
HP LaserJet
P2035m
Onduleur

Mercury
ellite800

Quantit

Prix unitaire (F CFA)

05 (03
ordinateurs
existent
dj)

350 000

Montant (F
CFA)
700 000

01

1 800 000

1 800 000

03 (01
imprimante
existe dj)
05

195 000

390 000

Existant

Existant

TOTAL

III.3.3.4.

890 000 F CFA

Evaluation du cot de dveloppement de lapplication

A linstar du premier scnario, nous avons un projet en semi-dtach. Nous estimons


quatre milles (4000) lignes la taille du code source pour ce scnario.
Intitul
Effort de dveloppement (HM)
Temps de dveloppement (TDEV)
Valeur de lhomme/mois (ValeurHM)
Nombre de dveloppeurs
Cot de ralisation

Valeur
14,17
6 mois et 10 jours
200 000
3
3792000

Cot de formation des utilisateurs


Prix de
CFA)
4000

lhoraire (F

Nombre
utilisateur
08

dheures

par

Nombre dutilisateurs

Montant (FCFA)

160 000

Cot total de ralisation


Dsignation
Cot du matriel et des logiciels acqurir
Cot de dveloppement

Prix (F CFA)
74 500
3 792 000

THEME : Gestion des marchs publics la SONAPOST

Page 68

Cot de la formation des utilisateurs


Cot total

160 000
4 026 500

Critiques du scnario
AVANTAGES
Ce scnario en plus des avantages de la
premire solution prsente galement
dautres avantages :
Mise niveau aise grce la
centralisation du code de lapplication ;
Dchargement
du
poste
client
(lapplication ny sera pas installe) ;
Application qui pourra tre accessible
aussi bien lintrieur qu lextrieur de
la structure bnficiaire;
Facilit de maintenance et damlioration
de lapplication grce la sparation des
couches.

III.4.

INCONVENIENTS
Cot de mise en uvre lev,
Temps dexcution long.

Scnario retenu

La solution retenir devra rpondre aux attentes suivantes :

Mise en place dun logiciel multi plateforme ;


Utilisation facile et aise par les utilisateurs ;
Lapplication devra tre accessible depuis les postes de travail se trouvant dans les
diffrents niveaux ;
Evolutivit et maintenance facile ;
Trs bonne scurit des donnes surtout numriques ;
Cot assez rduit.

Au vu de ces diffrents points dont devrait rpondre la nouvelle solution et en accord avec
le groupe de pilotage, nous avons choisi le Scnario 2.

III.5.

Politique de gouvernance et de scurit

La Scurit des Systmes d'Information est lensemble des moyens techniques,


organisationnels, juridiques et humains ncessaires et mis en place pour conserver, rtablir, et
garantir la scurit de l'information et du systme d'information. Scuriser un systme
d'information revient essayer de se protger contre les risques lis l'informatique pouvant
avoir un impact sur la scurit de celui-ci, ou des informations qu'il traite. (Tir de
http://www.pactepme.org/place-de-marche/thematique/92/securite-des-systemes-dinformation-ssi).
III.5.1. Evaluation des risques

THEME : Gestion des marchs publics la SONAPOST

Page 69

Toute solution informatique bien que performante est soumise certaines contraintes qui
peuvent empcher son bon fonctionnement. Nous pouvons identifier quelques lments qui
peuvent tre :

La panne dun micro-ordinateur ;


La panne dun serveur ;
Une panne lectrique ;
Une intrusion ;
Une attaque de virus.
III.5.2. Procdures de secours

Ce sont des procdures appliquer en cas de dfaillance du systme. Quelques cas de


figure peuvent se prsenter notamment :
Panne dun micro-ordinateur
En cas de panne dun micro-ordinateur, lutilisateur pourra utiliser toute autre machine
connecte au rseau et signaler le problme au service maintenance.
Panne dun serveur
La technologie RAID de niveau 1 (les donnes sont dupliques intgralement sur un
second disque ou sur un second groupe de disques durs) sera applique sur les serveurs. Ainsi,
lorsquun disque est en panne, on pourra utiliser les donnes du second disque.
Panne dlectricit
Lorsquil y a une panne dlectricit, les onduleurs prendront la relve en attendant que
le groupe lectrogne ne dmarre.
III.5.3. Procdures de scurit
III.5.3.1.

Protection contre les catastrophes

Il nest pas exclu que les salles contenant les diffrents serveurs soient soumis des
catastrophes naturelles telles que la foudre, les incendies, les inondations. Il serait donc trs
important dinstaller des extincteurs, des paratonnerres dans ces salles pour viter une quasitotale perte du matriel, du logiciel et des donnes enregistres.
III.5.3.2.

Politique de gestion contre les attaques

a) Protection contre les virus informatiques


Les virus informatiques sont des programmes informatiques capables de provoquer la
destruction des donnes et/ou du matriel et porter atteinte la fiabilit des rsultats produits
par le systme. Ces virus peuvent provenir des CD-ROM, des disquettes contamines, ou tout
autre support (disque dur) ou rseau (local, internet).
Pour viter toute propagation de virus, un antivirus sera install sur tous les postes de travail
et seront rgulirement mis jour pour une meilleure efficacit.
b) Les accs non autoriss
THEME : Gestion des marchs publics la SONAPOST

Page 70

Pour une meilleure scurit du systme dinformation, il faudrait un contrle trs rigoureux de
lidentit de toute personne voulant avoir accs au systme pour effectuer des tches
principales. Lapplication mettre en uvre tant une application web, nous proposons des
contrles daccs tous les niveaux :
Une protection au niveau du serveur : le paramtrage du systme
dexploitation du serveur est trs important. Pour cela il faut des mesures de
scurit spcifiques, concernant la gestion des utilisateurs, des processus, des
systmes de fichiers, etc.
Une protection au niveau du rseau : par la mise en place dun dispositif de
FIREWALL pour limiter les flux rseaux ouverts depuis lextrieur (Un
FIREWALL est un dispositif permettant dassurer le filtrage par services des
accs entrants et limite ainsi les risques auxquels est soumis le serveur web).
Une protection au niveau de lapplication : par lauthentification des
utilisateurs. Chaque utilisateur naccdera quaux donnes dont il a droit et
neffectuera que les traitements qui lui sont autoriss.
c) La sauvegarde des donnes du systme
Une politique de sauvegarde des donnes doit tre mise en place pour viter les pertes de
donnes. Elle permet de restituer les donnes aprs une attaque lintgrit du systme, ou un
accident tel que les incendies, les inondations. Les sauvegardes se feront quotidiennement et
hebdomadairement et seront places dans des coffres forts ignifuges.
III.5.4. Procdures de mise en uvre
Cest lensemble des mesures qui accompagnent le dploiement des systmes
nouvellement conus. En effet, la conception dun logiciel est beaucoup plus thorique face
sa mise en uvre.
III.5.4.1.

Procdures de vrification de lapplication

Le passage au futur systme se fera de faon progressive. Les utilisateurs utiliseront


conjointement le nouveau et lancien systme pendant une priode de deux mois. Le systme
futur devra tre soumis une srie de tests afin de vrifier son bon fonctionnement et son
adquation avec les besoins et exigences exprims par les utilisateurs. Les erreurs ou les
dfaillances qui seront dcels lors de ces tests permettront damliorer progressivement
lapplication et de mieux ladapter aux besoins des utilisateurs. Deux (02) types de tests
seront faits avant la mise en exploitation de lapplication. Ce sont :
Un test fonctionnel : pour vrifier que les rsultats produits par le systme
sont ceux attendus ;
Un test structurel : pour contrler le mode et les normes mtiers de ralisation
des diffrentes fonctionnalits.
III.5.4.2.

Formation des utilisateurs

Un systme informatique nest efficace que lorsque les diffrents utilisateurs prennent
conscience de certains aspects scuritaires et normes dutilisation. Cette prise de conscience
passe ncessairement par leur formation et leur sensibilisation. En effet, les utilisateurs
THEME : Gestion des marchs publics la SONAPOST

Page 71

doivent tre forms bien utiliser les services du systme en vitant les oprations qui
pourraient le dstabiliser ou prsenter des failles de scurit et en privilgiant les oprations
qui participent le mieux son maintien et sa scurit.
III.5.4.3.

Charte dutilisation des dispositifs informatiques

La charte dutilisation des dispositifs informatiques consistera en la mise en place dune


rglementation qui dfinira clairement les normes dutilisation, les responsabilits et les
sanctions de toute utilisation du matriel informatique qui viendrait causer des
dsagrments. Cette charte sera mise en place avec lensemble des dcideurs et acteurs
concerns et sera remise chaque utilisateur qui en prendra connaissance avant toute prise de
fonction ou utilisation du systme.

IV.

Analyse
IV.1.

Dveloppement du modle statique (Diagramme de classes)

Le dveloppement du modle statique constitue la deuxime tape danalyse. Le


diagramme de classes tabli lors de ltude de lexistant va tre complt et optimis.
Il sagit dune activit itrative, fortement couple avec la modlisation dynamique.
IV.1.1. Diagramme de classe du cas dutilisation Grer Budget
Figure III.6 : Diagramme de classes du cas dutilisation Grer budget

Compte budgtaire

Exercice budgtaire

-numero: int
-libelle: String

-annee: int
-etat: String
-observation: String

+creer()
+modifier()
+supprimer()
+rechercher()
+lister()

contient

1..*

1..*

+creer()
+modifier()
+supprimer()
+rechercher()
+valider()
+lister()

Ligne budgtaire
-montant: Double
+creer()
+modifier()
+supprimer()
+rechercher()
+lister()

THEME : Gestion des marchs publics la SONAPOST

Page 72

IV.1.2. Diagramme de classe du cas dutilisation Grer PPM


Figure III.7 : Diagramme de classes du cas dutilisation Grer PPM

PPM
Ligne budgtaire

-annee: int
-etat: String
-observation: String

1..*

-montant: Double
+creer()
+modifier()
+supprimer()
+rechercher()
+lister()

+creer()
+modifier()
+supprimer()
+rechercher()
+lister()
+valider()

1
1..*
March
Type
-code: int
-libelle: String
+creer()
+modifier()
+supprimer()
+lister()
+rechercher()

appartient
1

-numero: String
-nature: String
-responsableTDR: String
1..*
-dateLancement: Date
-dateDemarrage: Date
concerne
1..* -dateReception: Date
-financement: String
+creer()
+modifier()
+supprimer()
+rechercher()
+initier()
+lister()

Mode Passation
-code: int
-libelle: String
1

+creer()
+modifier()
+supprimer()
+rechercher()
+lister()

1..*
Lot
-numero: int
-description: String
-montant: Double
-garantie: Double
-delaiEngagement: int
-delaiExecution: int
-etat: boolean
+creer()
+modifier()
+supprimer()
+rechercher()
+lister()

THEME : Gestion des marchs publics la SONAPOST

Page 73

IV.1.3. Diagramme de classe du cas dutilisation Grer DAO


Figure III.8 : Diagramme de classes du cas dutilisation Grer DAO
March
-numero: String
-nature: String
-responsableTDR: String
-dateLancement: Date
-dateDemarrage: Date
-dateReception: Date
-financement: String
+creer()
+modifier()
+supprimer()
+rechercher()
+initier()
+lister()

DAO

possde

-numero: int
-datecreation: Date
-nbExemplaires: int
-chemin: String
-etat: String
+creer()
+joindre()
+valider()
+publier()
1..*
achte
1..*

Rcpiss
-numeroMandat: String
-typeMandat: String
-montantMandat: Double
-bureauPoste: String
-dateEmission: Date

Soumissionnaire
-nom: String
-adresse: String
-telephone: String
+creer()
+soumissionner()

IV.1.4. Diagramme de classe du cas dutilisation Grer Soumission


Figure III.9 : Diagramme de classes du cas dutilisation Grer soumission

THEME : Gestion des marchs publics la SONAPOST

Page 74

Lot
Soumissionnaire
-nom: String
-adresse: String
-telephone: String

soumissionne

1..*

+creer()
+soumissionner()

-numero: int
-description: String
-montant: Double
1..* -garantie: Double
-delaiEngagement: int
-delaiExecution: int
-etat: boolean
+creer()
+modifier()
+supprimer()
+rechercher()
+lister()

Soumission
Depouillement
-date: Date
-lieu: String

fait l'objet

-numeroOrdre: int
-dateArrivee: Date
1..* -nomDepositaire: String
-montant: Double
-offreFinanciere: String
-offreTechnique: String

1..*
concerne

1..*
Pieces Administratives

1..*

Deliberation
-date: Date
-procesVerbal: String

Analyse

concerne
1

-intitule: String

-dateDebut: Date
-dateFin: Date
-rapport: String

IV.1.5. Diagramme de classe du cas dutilisation Grer Archive


Figure III.10 : Diagramme de classes du cas dutilisation Grer archive

THEME : Gestion des marchs publics la SONAPOST

Page 75

Archive
-numero: int

+creer()
+ajouterdocument()

1..*

Document
-libelle: String
-dateajout: Date

1..*
concerne
1
March
-numero: String
-nature: String
-responsableT DR: String
-dateLancement: Date
-dateDemarrage: Date
-dateReception: Date
-financement: String
+creer()
+modifier()
+supprimer()
+rechercher()
+initier()
+lister()

IV.1.6. Diagramme de classe du cas dutilisation Grer March


Figure III.11 : Diagramme de classes du cas dutilisation Grer march

THEME : Gestion des marchs publics la SONAPOST

Page 76

Suivi

1..*

Lot

Reception
-type: String
-date: Date
-observation: String

1..2

1
fait l'objet

+creer()
+supprimer()

-numero: int
-description: String
-montant: Double
-garantie: Double
-delaiEngagement: int
-delaiExecution: int
-etat: boolean

1
concerne

soumissionne

-numero: String
+date: Date

-numero: String
-date: Date

1..*

+creer()
+soumissionner()

Soumission

-numeroOrdre: int
-dateArrivee: Date
1
-nomDepositaire: String
-montant: Double
-offreFinanciere: String
-offreTechnique: String

requiert0..1

RIB
-adresseTitulaire: String
-numCompte: String

1
1

Ordre de service

Contrat

-nom: String
-adresse: String
-telephone: String

1..*

concerne

Soumissionnaire

fait l'objet

+creer()
+modifier()
+supprimer()
+rechercher()
1
+lister()
concerne

-date
-information

requiert
Notification

0..1
Proforma

-chargeNotification: String
-date: Date

-numero: String
-date: Date
-chemin: String

IV.1.7. Diagramme de classe du cas dutilisation Grer Contentieux


Figure III.12 : Diagramme de classes du cas dutilisation Grer contentieux

Analyse
Soumissionnaire

-dateDebut: Date
-dateFin: Date
-rapport: String

-nom: String
-adresse: String
-telephone: String
+creer()
+soumissionner()

concerne 1
1

Deliberation
-date: Date
-procesVerbal: String

adresse
1

1..*

fait l'objet
1..*
Decision
-numero:String
-date: Date
-observations: String
+reprendreMarche()
+poursuivreMarche()

concerne
1

Plainte
-numero: String
-date: Date
-observations: String
+enregistrer()
+modifier()
+supprimer()
+suspendreMarche()

THEME : Gestion des marchs publics la SONAPOST

Page 77

IV.1.8. Diagramme
Sauthentifier

de

classe

du

cas

dutilisation

Grer profils

et

Figure III.13 : Diagramme de classes du cas dutilisation Grer profils et


sauthentifier

Utilisateur
-login: String
-motdepasse: String
-profil: String
-nom: String
-prenom: String
+creer()
+modifier()
+supprimer()
+authentifier()

IV.1.9. Documentation des diagrammes de classes


Rgles de gestion
Les rgles de gestion retenues dans cette partie sont les mmes que celles retenues lors de
ltude du systme existant.
Description des attributs et des mthodes
Classe Exercice budgtaire : Regroupe tous les budgets.
Nom
Description
anne
Anne du budget
Attributs
tat
Indique si le budget a t valid ou pas
observation
Contient les observations en cas de rejet du budget
Nom
Description
crer()
Permet de crer un nouveau budget
valider()
Permet de valider un budget
Mthodes
afficher()
Permet dafficher un budget
supprimer()
Permet de supprimer un budget
modifier()
Permet de modifier un budget

Classe Compte Budgtaire : Regroupe tous les comptes budgtaires.


Nom
Description
Attributs
numro
Numro du compte budgtaire
libell
Intitul du compte budgtaire
Nom
Description
crer()
Permet de crer un nouveau compte budgtaire
Mthodes
supprimer()
Permet de supprimer un compte budgtaire

THEME : Gestion des marchs publics la SONAPOST

Type
Numrique
Boolen
Texte

Type
Numrique
Texte

Page 78

modifier()
lister()

Permet de modifier un compte budgtaire


Permet de lister les comptes budgtaires

Classe Ligne Budgtaire : Regroupe toutes les lignes budgtaires.


Nom
Description
Attributs
montant
Montant allou au compte budgtaire pour lanne
Nom
Description
crer()
Permet de crer une nouvelle ligne budgtaire
Mthodes
supprimer()
Permet de supprimer une ligne budgtaire
modifier()
Permet de modifier une ligne budgtaire

Classe PPM : Regroupe tous les plans de passation des marchs.


Nom
Description
Attributs
anne
Anne du PPM
tat
Indique si le PPM a t valid ou pas
Nom
Description
crer()
Permet de crer un PPM
afficher()
Permet dafficher un PPM
Mthodes
valider()
Permet de valider un PPM
supprimer()
Permet de supprimer un PPM
modifier()
Permet de modifier un PPM

Classe March : Regroupe tous les marchs.


Nom
Description
numro
Numro du march
nature
Indique si le PPM a t valid ou pas
responsableTDR
Service responsable des TDR
Attributs
dateLancement
Date de lancement concurrence du march
dateDemarrage
Date de dmarrage du march
dateReception
Date probable de rception
financement
Indique la source de financement
Nom
Description
crer()
Permet de crer un nouveau march
afficher()
Permet dafficher un march
Mthodes
initier()
Permet dinitier un march
supprimer()
Permet de supprimer un march
modifier()
Permet de modifier un march

Type
Numrique

Type
Numrique
Boolen

Type
Numrique
Texte
Texte
Date
Date
Date
Texte

Classe Type : Regroupe tous les types de marchs


Nom
Description
Type
Attributs
libell
Libell du type de march
Texte
Nom
Description
Crer
Permet denregistrer un type de march
Mthodes
Modifier
Permet de modifier un type de march
Supprimer
Permet de supprimer un type de march

THEME : Gestion des marchs publics la SONAPOST

Page 79

Classe Mode Passation : Regroupe tous les modes de passation des marchs
Attributs
Nom
Description
Type
libell
Libell du mode de passation
Texte
Mthodes
Nom
Description
crer()
Permet denregistrer un mode de passation
modifier()
Permet de modifier un mode de passation
supprimer()
Permet de supprimer un mode de passation

Classe Lot : Regroupe tous les lots des marchs


Nom
Description
numro
Numro du lot
description
Description du lot
montant
Montant du dossier dappel doffre
Attributs
garantie
Montant de la garantie de soumission
delaiEngagement Dlai dengagement des offres des soumissionnaires
delaiExecution
Dlai dexcution du lot
etat
Situation actuelle du lot
Nom
Description
crer()
Permet denregistrer un nouveau lot
Mthodes
modifier()
Permet de modifier un lot
supprimer()
Permet de supprimer un lot
lister()
Permet de lister les lots

Type
Numrique
Texte
Numrique
Numrique
Numrique
Numrique
Texte

Classe Suivi : Regroupe tous les comptes rendus de suivi dun lot
Attributs
Nom
Description
Type
date
Date du compte rendu
situation
Situation du march
Texte
Mthodes
Nom
Description
crer()
Permet denregistrer un mode de passation

Classe DAO : Regroupe tous les dossiers dappel doffres des marchs
Nom
Description
numro
Numro du DAO
datePublication Date de publication du DAO
Attributs
dateLimite
Date et heure limite de dpt des soumissions
lieuDepot
Lieu de dpt des soumissions
dossier
Chemin vers le DAO joint au format PDF
Nom
Description
valider()
Permet denregistrer un DAO
Mthodes
publier()
Permet de modifier un DAO
vendre()
Permet de supprimer un DAO

THEME : Gestion des marchs publics la SONAPOST

Type
Texte
Date
Date
Texte
Texte

Page 80

Classe Archive : Regroupe toutes les archives


Nom
Description
Attributs
numro
Numro du carton darchivage
emplacement
Emplacement du carton darchivage
Nom
Description
crer()
Permet denregistrer une nouvelle archive
Mthodes
ajouterDocument()
Permet dajouter un document larchive
supprimerDocument Permet de retirer un document dune archive

Classe Document : Regroupe tous les documents archivs


Nom
Description
Attributs
nom
Nom du document
date
Date darchivage
Nom
Description
crer()
Permet de crer un nouveau document
Mthodes
modifier()
Permet de modifier un document
supprimer()
Permet de retirer un document

Classe Rcpiss : Regroupe tous les rcpisss de mandat


Nom
Description
numro
Numro du mandat
type
Type de mandat
Attributs
montant
Montant du mandat
bureauPoste
Bureau de poste o le mandat a t mis
dateEmission
Date dmission du mandat
Nom
Description
crer()
Permet denregistrer un rcpiss
Mthodes
modifier()
Permet de modifier un rcpiss
supprimer()
Permet de supprimer un rcpiss

Classe Soumissionnaire : Regroupe tous les soumissionnaires


Nom
Description
nom
Nom de lentreprise soumissionnaire
Attributs
telephone
Tlphone de lentreprise soumissionnaire
adresse
adresse de lentreprise soumissionnaire
Nom
Description
crer
Permet denregistrer un soumissionnaire
Mthodes
modifier
Permet de modifier un soumissionnaire
supprimer
Permet de supprimer un soumissionnaire
soumissionner
Permet de soumissionner un march

Type
Numrique

Type
Numrique
Date

Type
Numrique
Texte
Texte
Texte
Date

Type
Texte
Texte
Texte

Classe Pieces Administratives : Regroupe toutes les pices administratives dune soumission
Attributs
Nom
Description
Type

THEME : Gestion des marchs publics la SONAPOST

Page 81

Mthodes

libelle
piece
Nom
crer()
modifier()
supprimer()

Intitul de la pice administrative


Chemin vers la pice jointe au format PDF
Description
Permet denregistrer une pice administrative
Permet de modifier une pice administrative
Permet de supprimer une pice administrative

Classe RIB : Regroupe tous les relevs didentit bancaire


Attributs
Nom
Description
numro
Numro du compte
titulaire
Adresse complte du titulaire du compte
Mthodes
Nom
Description
crer()
Permet denregistrer un RIB
modifier()
Permet de modifier un RIB
supprimer()
Permet de supprimer un RIB

Classe Ordre de Service : Regroupe toutes les ordres de service


Nom
Description
numro
Numro de lordre de service
Attributs
date
Date dtablissement de lordre de service
ordre
Chemin vers lordre de service joint au format PDF
Nom
Description
crer()
Permet denregistrer un ordre de service
Mthodes
modifier()
Permet de modifier un ordre de service
supprimer()
Permet de supprimer un ordre de service

Classe Notification : Regroupe toutes les notifications


Nom
Description
date
Date de notification
Attributs
type
Notification provisoire ou dfinitive
notification
Chemin vers la notification joint au format PDF
Nom
Description
crer()
Permet denregistrer une notification
Mthodes
modifier()
Permet de modifier une notification
supprimer()
Permet de supprimer une notification

Classe Reception : Regroupe toutes les rceptions de biens


Nom
Description
date
Date de la rception des biens
Attributs
type
Type de rception des biens
observation
Observation concernant la rception
procesVerbal
Chemin vers le procs verbal joint au format PDF
Nom
Description
Mthodes
Crer
Permet denregistrer une rception

THEME : Gestion des marchs publics la SONAPOST

Texte
Texte

Type
Numrique
Texte

Type
Numrique
Date

Type
Date
Texte
Texte

Type
Date
Texte
Texte
Texte

Page 82

Modifier
Supprimer

Permet de modifier une rception


Permet de supprimer une rception

Classe Contrat : Regroupe toutes les contrats


Nom
Description
date
Date de signature du contrat
Attributs
contrat
Chemin vers le contrat au format PDF
Nom
Description
crer()
Permet denregistrer un contrat
Mthodes
modifier()
Permet de modifier un contrat
supprimer()
Permet de supprimer un contrat

Classe Pro forma : Regroupe toutes les factures pro forma


Nom
Description
numro
Numro de la facture
Attributs
date
Date dtablissement de la facture
montant
Montant de la facture
Nom
Description
crer()
Permet denregistrer une facture pro forma
Mthodes
modifier()
Permet de modifier une facture pro forma
supprimer()
Permet de supprimer une facture pro forma

Classe Soumission : Regroupe toutes les soumissions


Nom
Description
numro
Numro dordre darrive de la soumission
dateArrivee
Date et heure darrive de la soumission
nomDepositaire
Nom du dpositaire de la soumission
montant
Montant de la soumission
Attributs
offreFinanciere
Chemin vers loffre financire joint au format
PDF
offreTechnique
Chemin vers loffre technique joint au format PDF
observation
Observation sur la soumission
classement
Classement de la soumission aprs lanalyse
etat
Indique si la soumission a t retenue ou pas
Mthodes
Nom
Description
crer()
Permet denregistrer une soumission
modifier()
Permet de modifier une soumission
supprimer()
Permet de supprimer une soumission
dpouiller()
Permet de faire le dpouillement dune soumission
Classe Dpouillement : Regroupe tous les PV douverture
Attributs
Nom
Description
date
Date douverture des plis
procesVerbal
Chemin vers le procs verbal joint au format PDF

THEME : Gestion des marchs publics la SONAPOST

Type
Date
Texte

Type
Texte
Date
Numrique

Type
Numrique
Date
Texte
numrique
Texte
Texte
Texte
Texte
Boolen

Type
Date
Texte

Page 83

Mthodes

Nom
Crer
Modifier
Supprimer

Description
Permet denregistrer un PV douverture de plis
Permet de modifier un PV douverture de plis
Permet de supprimer un PV douverture de plis

Classe Analyse : Regroupe toutes les analyses


Nom
Description
Type
date
Date de lanalyse
Date
Attributs
rapport
Chemin vers le rapport danalyse joint au
Texte
format PDF
etat
Indique si le rapport a t valid ou pas
Boolen
Nom
Description
analyserFinancierement() Permet deffectuer lanalyse financire des offres
Mthodes
analyserTechniquement() Permet de procder lanalyse technique des offres
valider()
Valider le rapport danalyse
publier()
Permet de publier le rapport danalyse
Classe Deliberation : Regroupe tous les PV douverture
Attributs
Nom
Description
date
Date de la dlibration
procesVerbal
Chemin vers le procs verbal joint au format PDF
Mthodes
Nom
Description
crer()
Permet denregistrer un PV de dlibration
modifier()
Permet de modifier un PV de dlibration
supprimer()
Permet de supprimer un PV de dlibration

Classe Plainte : Regroupe toutes les plaintes


Nom
Description
date
Date de la plainte
Attributs
dateConfrontation Date de la confrontation
motif
Motif de la plainte
Nom
Description
crer()
Permet denregistrer une nouvelle plainte
Mthodes
modifier()
Permet de modifier une plainte
supprimer()
Permet de supprimer une plainte
suspendre()
Permet de suspendre un march.

Classe Decision : Regroupe toutes les dcisions


Nom
Description
date
Date de la dcision
Attributs
decision
Chemin vers la dcision jointe au format PDF
Nom
Description
crer()
Permet denregistrer une dcision
Mthodes
poursuivre()
Permet de poursuivre le march

THEME : Gestion des marchs publics la SONAPOST

Type
Date
Texte

Type
Date
Date
Texte

Type
Date
Texte

Page 84

reprendre()

Permet de reprendre toute la procdure dattribution du march

Classe Utilisateur : Regroupe tous les utilisateurs


Nom
Description
login
Login de lutilisateur
motdepasse
Mot de passe de lutilisateur
Attributs
profil
Profil de lutilisateur
nom
Nom de lutilisateur
prenom
Prnom de lutilisateur
Nom
Description
crer()
Permet denregistrer un nouvel utilisateur
Mthodes
modifier()
Permet de modifier les informations dun utilisateur
supprimer()
Permet de supprimer un utilisateur
authentifier()
Permet dauthentifier un utilisateur

IV.2.

Type
Texte
Texte
Texte
Texte
Texte

Dveloppement du modle dynamique

Le dveloppement du modle dynamique constitue la troisime activit de ltape


danalyse. Il sagit dune activit itrative, fortement couple avec la modlisation statique.
Remarque : Etant donn le nombre important de scnarios dans chaque cas
dutilisation, nous ferons un diagramme de squence pour certains scnarios uniquement.
IV.2.1. Diagramme de squence du cas dutilisation Sauthentifier
Figure III.14 : Diagramme de squence du cas dutilisation sauthentifier

IV.2.2. Diagramme de squence du cas dutilisation Grer budget

THEME : Gestion des marchs publics la SONAPOST

Page 85

Figure III.15 : Diagramme de squence du scnario Elaborer budget

Figure III.16 : Diagramme de squence du scnario Valider budget

THEME : Gestion des marchs publics la SONAPOST

Page 86

IV.3.

Construction des diagrammes dtats

On recourt au concept de machine tats finis, qui consiste sintresser au cycle de


vie dun objet gnrique dune classe particulire au fil de ses interactions avec les autres
classes, dans tous les cas possibles. Cette vue locale dun objet, dcrivant comment il ragit
des vnements en fonction de son tat courant et passe dans un nouvel tat, est reprsente
graphiquement sous forme dun diagramme dtats.
Dfinition : un tat reprsente une situation durant la vie dun objet pendant laquelle :
Il satisfait une certaine condition ;
Il excute une certaine activit ;
Ou bien il attend un certain vnement.
Un objet passe par une succession dtats durant son existence. Un tat a une dure finie,
variable selon la vie de lobjet, en particulier en fonction des vnements qui lui arrivent.

THEME : Gestion des marchs publics la SONAPOST

Page 87

Diagramme dtats de la classe Soumissionnaire :


Figure III.17 : Diagramme dtats-transitions de la classe Soumissionnaire
create

Fin de contrat

Acheter( DAO )

En attente de
soumission

Offre non satisfaisante

Soumissionner( March )

Soumissionnaire

Attributaire
dfinitif

Aucune plainte

Soumissionnaire
potentiel

Plainte enregistre

Offre satisfaisante
Dlibration non OK

Attributaire
valid

V.

Dlibration OK( Rapport d'analyse )

Attributaire
provisoire

Conception darchitecture

La conception prliminaire est ltape o seffectue la fusion des tudes fonctionnelles et


techniques.
La conception dtaille qui vient juste aprs est une activit qui sinscrit dans
lorganisation dfinie par la conception prliminaire. Le modle logique y est particulirement
important dans la mesure o cest dans cette tape quon gnre le plus grand nombre
dinformations. Il est ainsi possible de confier les catgories des personnes diffrentes, qui
pourront travailler indpendamment les unes des autres. Les concepteurs dans cette phase
construisent les classes, les vues dIHM, les interfaces, les tables et les mthodes qui vont
donner une image prte coder de la solution.

V.2.

Les Designs Patterns

De nombreuses mthodes existent pour simplifier la phase de conception des logiciels.


Parmi les plus connues, considrons Merise et UML.
Mais une autre mthode existe, plus proche de l'implmentation. Lors de la conception
d'une application de nombreux problmes peuvent survenir. Le systme des Design Patterns,
ou motifs de conception, reprsente un systme objet destin la rsolution de problmes
techniques. (Eric Freeman, 2005)
Un Design Pattern constitue un petit ensemble de classes apte offrir la solution la
plus efficace un problme. La dfinition d'un motif de conception repose donc sur trois
critres. Premirement, le problme rsoudre est classique et bien connu.
Ensuite, l'ensemble des classes employes porte un nom unique (on parle par exemple du
motif "Decorator"). Enfin, la solution que propose ce motif correspond la rsolution la plus
optimale du problme.
Il existe plusieurs Designs Patterns mais pour notre part nous allons nous intresser au
Design Pattern MVC qui est intgr lEDI Zend Studio 9.0.3.
Prsentation du Design Pattern MVC
Le Modle Vue Contrleur (MVC), est un patron darchitecture et une mthode de
conception qui consiste organiser linterface homme-machine (IHM) dune application. Ce
modle a t cre par Trygve Reenskaug vers la fin des annes 1970. Sa dmarche a pour

THEME : Gestion des marchs publics la SONAPOST

Page 88

objectif dorganiser une application interactive en sparant : les donnes (Modle), la


reprsentation des donnes (Vue) et le comportement de lapplication (Contrleur).
Un avantage apport par ce modle est la clart de larchitecture quil impose. Cela simplifie
la tche du dveloppeur quant la future maintenance de lapplication. En effet, la
modification des traitements ne change en rien la vue. Par exemple on peut passer dune base
de donnes de type SQL XML en changeant simplement les traitements dinteraction avec
la base, et les vues ne sen trouvent pas affectes.

VI.

REALISATION

Lapplication est structure selon le Design Pattern MVC : le modle, la vue et le


contrleur. Nous allons prsenter ici quelques maquettes de lapplication.
Figure III.18 : Interface de connexion de lapplication

THEME : Gestion des marchs publics la SONAPOST

Page 89

Figure III.19 : Interface de cration des budgets (Etape 1)

THEME : Gestion des marchs publics la SONAPOST

Page 90

Figure III.20 : Interface de cration des budgets (Etape 2)

THEME : Gestion des marchs publics la SONAPOST

Page 91

Figure III.21 : Interface de cration des budgets (Etape 3)

THEME : Gestion des marchs publics la SONAPOST

Page 92

Figure III.22 : Interface ddition du budget (Etape 1)

THEME : Gestion des marchs publics la SONAPOST

Page 93

Figure III.23 : Interface ddition du budget (Etape 2)

CONCLUSION
Ce chapitre nous a permis de faire une bauche de ce que sera le futur systme de
gestion des marchs publics la SONAPOST. Il propose des diagrammes dcrivant le
fonctionnement du dit systme en mettant en vidence les interactions avec les diffrents
acteurs.

THEME : Gestion des marchs publics la SONAPOST

Page 94

CONCLUSION GENERALE
Durant notre stage la SONAPOST, il nous a t confi ltude du thme : Gestion
des marchs publics la SONAPOST . Cette tude avait pour finalit la mise en place dun
systme informatique qui permettrait dautomatiser la gestion des marchs publics.
Pour mener bien cette tude, nous avons choisi la mthode danalyse et de
conception 2TUP ainsi que le langage de modlisation UML. Notre travail sest donc articul
autour du plan suivant : dans un premier temps, nous avons fait une note de lancement ; dans
un second temps, il sagissait de faire une tude du systme existant et enfin nous avons
termin par une tude conceptuelle dtaille du futur systme.
Au titre des acquis mettre lactif de ce stage, nous avons appris mieux organiser
et grer notre temps. Par ailleurs, il nous a t donn de mieux apprhender les dfis du
monde professionnel. Le climat qui rgne en entreprise est diffrent en tout point de celui qui
prvaut dans le milieu acadmique.
Enfin, la mise en place de ce systme informatique sera pour nous une grande
satisfaction et dmontrera la pertinence de notre tude.

THEME : Gestion des marchs publics la SONAPOST

Page 95

ANNEXE
I. Bibliographie et webographie
I.1.
Bibliographie

I.2.

Chromatic. (2005). Extreme programming. O'Reilly ;


Revue des marchs publics, Edition spciale N3, Octobre 2011 ;
Eric Freeman, E. F.-C. (2005). Design Patterns Tte la premire. O'Reilly ;
Meyer, B. (2000). Conception et Programmation orientes objet. Eyrolles ;
Pitman, N. (2006). UML 2 en concentr. O'Reilly ;
Rocques, P., & Valle, F. (2004). UML 2 En Action (De l'analyse des besoins
la conception J2EE). Eyrolles ;
Roques, P. (2006). UML 2 en pratique. Eyrolles ;
Julien Pauli & Guillaume Ponon. Zend Framework Bien dvelopper en PHP ;

Webographie

http://framework.zend.com/ visit en Octobre 2012.


http://fr.wikipedia.org/ visit de Septembre 2012 Mars 2013.
www.developpez.com visit de Septembre 2012 Mars 2013.
www.siteduzero.com visit de Septembre 2012 Mars 2013.
http://uml.free.fr/ visit en Novembre 2012.

THEME : Gestion des marchs publics la SONAPOST

Page I