Mise en place d'un système de Gestion des marchés publics à la SONAPOST

THEME : Gestion des marchs publics la SONAPOST Page I

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 II

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 III

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 IV

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 V

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 1

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 .


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


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.


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.

I. Prsentation de lentreprise

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


Figure I.1: Organigramme gnral de la SONAPOST

DG Direction Gnrale

SP/DG Secrtariat Particulier/Direction Gnrale

IGS Inspection Gnrale des Services

DCGAI Dpartement du Contrle de Gestion et de lAudit Interne

CT Conseil Technique

DWU Dpartement Western Union

DJ Dpartement Juridique

DG

SP/DG

DCGAI

DWU

IGS

CT

DJ

DAI

DSC

SG

DC DSF DFC DRH DC

M

DPL DSI

DR

C

DRO DRN DRE


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 :


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 de reprise des

applications CCP-CNE

Sage ligne 1000 Application de gestion comptable

Application boite postale IPS Application de suivi et localisation du

courrier


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.


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 :

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.

III.3. 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 ;


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 DUREE

Gnralits Note de lancement Du 04 Septembre au 18

Septembre

15 jours

Etude du systme

existant Etude de lexistant

Du 19 Septembre au 06

Octobre

18 jours

Conception dtaille Conception dtaille du

systme futur Du 21 Octobre au 31 Octobre

15 jours

Programmation et

mise en uvre

Dossier de programmation,

guide de lutilisateur, guide

dexploitation

Du 01 Novembre au 31 Mars

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.


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 :


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 ;


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 elle-

mme 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.


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


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


Compte rendu de linterview Poste : Comptable


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.


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


Compte rendu de linterview Poste : Comptable


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 :


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 lattributaire entamer

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


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 :


Figure II.1 : Diagramme de contexte statique

II.2. Diagramme des cas dutilisation

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.

CA

Gestion des marchs

publics la

SONAPOST

DGCMEF ARMP

DIRECTION DU PATRIMOINE ET DE LA LOGISTIQUE

DIRECTION DES TRANSPORTS ET DE LA LOGISTIQUE

PRM CAM SCT CR

Soumissionnaire


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

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

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

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 .

Acteur humain

"include"

Cas d'util isation B Cas d'util isation A

"include"Retirer de l 'argent S'authentifier


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

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

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

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

II.2.1. Identification des acteurs

Les acteurs du systme identifis dans un premier temps sont :

"Extend"Cas d'util isation C Cas d'util isation B

"extend"Emprunter livre Enregistrer personne

Cas d'util isation B Cas d'util isation A

Retirer dollars Retirer argent


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

Rfrence

Cest lacteur charg de la rdaction

des termes de rfrence.

VB Validateur de Budget Cest lacteur charg de valider le

budget de lanne.

CPPM Conseiller de Plan de

Passation des Marchs

Cest lacteur charg dassister

llaborateur de plan de passation des

marchs dans llaboration du plan de

passation des marchs.

EPPM Elaborateur de Plan de


Cest lacteur charg de la gestion du

plan de passation des marchs publics

depuis son laboration jusqu sa

validation.

VPPM Validateur de Plan de


Cest lacteur charg de valider le

plan de passation des marchs.

RM Responsable des Marchs Le responsable des marchs soccupe

de la gestion des dossiers dappel

doffre, des soumissions ainsi que de

lexcution des marchs.

RAM Responsable dAttribution

des Marchs

Cest lacteur charg de lattribution

dun march un soumissionnaire.

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 Cest lacteur qui est charg de

valider le DAO, publier le DAO ainsi

que les rsultats dattribution du

march.

II.2.2. Identification des cas dutilisation en fonction des acteurs

Les cas dutilisation identifis dans un premier temps sont rpertoris dans le tableau ci-

aprs :

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


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

ACTEURS CAS DUTILISATION PRINCIPAUX

CAS DUTILISATION

EB, VB Grer budget Elaborer budget, valider budget

EPPM, VPPM, CPPM 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, publier proposition

attributaire

RM, RAM, SM, AO Grer soumission Soumissionner march, analyser offres,

dpouiller offres, 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, reprendre march,

poursuivre march

AD Grer archive Archiver soumission, archiver document


march

II.2.3. Diagramme de cas dutilisation

Figure II.9 : Diagramme de cas dutilisation


System

Elaborer budget Valider budget

Elaborer PPM

Rdiger TDR Valider DAO

Archiver document

Valider PPM

Elaborer DAO

Publier DAO

Publier propositionattributaire

Soumissionnermarch

Vendre DAO

Consulter DAOAcheter DAO

Grercontentieux

Rceptionnerles biens

Suivre etvaluermarch

Rdiger PV derception

Proposerattributaire

Analyser offres

Validerpropositionattributaire

Analyse financire

Analyse technique

Approuver facture

Grer contrat

Etablir contrat

Etablir ordrede service

Etablir notification

Dpouiller offres

Rdiger PV dedpouillement

EB

VB

RTDR

RM

GC

RB

EPPM

CPPM

AD

VPPM

PM

SM

RAM

AO


II.2.3.1. Description des relations entre cas dutilisation

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.

Publier proposition attributaire

tend Grer contentieux La publication de la proposition

dattributaire peut donner lieu un contentieux.

Publier proposition

attributaire inclut Valider proposition

attributaire

Pour publier la

proposition

dattributaire il faut quelle soit valide.

Grer contentieux tend Rceptionner les biens La rception des biens

peut donner lieu un contentieux.


Rceptionner les biens tend Suivre et valuer

march

Le suivi et lvaluation du march peut aboutir

la rception des biens.

Rceptionner les biens inclut Rdiger PV de rception

Pour rceptionner les biens il faut rdiger un

PV de rception.

Analyser offres inclut Proposer attributaire Lanalyse des offres aboutit la proposition dun attributaire.

Proposer attributaire tend Valider proposition

attributaire

La proposition

dattributaire provisoire peut tre valide ou pas.

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 de

dpouillement

Le dpouillement des

offres implique la

rdaction dun PV de 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.


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


Date de cration : le 19/09/2012

Date de mise jour : le 16/02/2013


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


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


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



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


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


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


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



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


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.


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



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


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


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



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


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).


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

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, ).

Nom de classe

-

-

-

-

Attribut_1

Attribut_2

.

Attribut_i

: type

: type

:

: type

+

+

+

+

Methode 1 ()

Methode 2 ()

. ()

Methode k ()


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

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

c) Notion dassociation

q1...q2p1...p2Classe A Classe B

S'inscrire0..* 1..*

Etudiant

-

-

-

-

-

Numero

Nom

Prenoms

Age

Filire

: int

: string

: string

: int

: string

+ Caler nbre d'tudiants ()

Facult

-

-

Numero

Nom

: int

: int

+ Crer ()


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

Figure II.13 : Formalisme de la notion dassociation

Une classe association est porteuse dattributs.

Figure II.14 : Formalisme de la notion de classe association

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

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 :

min..maxmin..max

Nom de

l'association

min..maxmin..max

Nom de

l'association

Classe Asociation

- Attribut_1 : int

S'inscrire0..* 1..*

Etudiant

-

-

-

-

-

Numero

Nom

Prenoms

Age

Filire

: int

: string

: string

: int

: string

+ Calculer nbre d'tudiants ()

Facult

-

-

Numero

Nom

: int

: int

+ Crer ()

Date inscription

-

-

anne

jour

: string

: string


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

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

e) Agrgation

SpecialisationGneralisation

Classe Generique

- Attribut communs :

+ Methodes communes ()

Classe specialise

- Attributs Specifiques :

+ Methodes Specifiques ()

Etudiant

-

-

-

-

-

Numero

Nom

Prenoms

Age

Filire

: int

: string

: string

: int

: string

+ Calculer nbre d'tudiants ()

Enseignant

-

-

-

-

-

Numero

Nom

Prenoms

Grade

Age

: int

: string

: string

: string

: int

Personne

-

-

-

-

-

Numero

Nom

Prenoms

Date naissance

Adresse

: int

: string

: string

: string

: string


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

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

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

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.

1..1 1..*Classe agrege Classe agregat

1..1 1..*

Parking

-

-

-

Numero

Nom

Nbre de places

: int

: string

: int

Place

- Numero : int

1..1 1..*Classe agrege Classe agregat


Figure II.21 : Exemple pour la notion de composition

II.3.1. Rgles de gestion

Les rgles de gestion (RG) retenues sont :

RG1: Un exercice budgtaire contient plusieurs comptes budgtaires

RG2: Un compte budgtaire peut figurer dans plusieurs exercices budgtaires

RG3: Un PPM contient plusieurs lignes budgtaires

RG4: Une ligne budgtaire concerne un seul PPM

RG5: Une ligne budgtaire se compose dun ou de plusieurs marchs

RG6: Un march est rattach une seule ligne budgtaire

RG7: Un march contient un ou plusieurs lots

RG8: Un lot concerne un seul march

RG9: Un march fait lobjet dun seul mode de passation

RG10: Un mode de passation concerne un ou plusieurs marchs

RG11: Un march appartient un et un seul type de march

RG12: Un type de march concerne un ou plusieurs marchs

RG13: Un march est possde un et un seul DAO

RG14: Un DAO concerne un et un seul march

RG15: Un soumissionnaire achte un ou plusieurs DAO

RG16: Un dossier est achet par un ou plusieurs soumissionnaires

RG17: Un soumissionnaire soumissionne un ou plusieurs lots

RG18: Un lot fait lobjet dune ou plusieurs soumissions

RG19: Une soumission fait lobjet dun dpouillement

RG20: Un dpouillement concerne une ou plusieurs soumissions

RG21: Une dlibration concerne une et une seule analyse

RG22: Une analyse concerne une ou plusieurs soumissions

RG23: Une soumission fait lobjet dune ou plusieurs analyses

RG24: Une soumission contient une plusieurs pices administratives

RG25: Un march possde une ou plusieurs archives

RG26: Une archive concerne un et un seul march

RG27: Une archive contient un ou plusieurs documents

RG28: Une rception concerne un et un seul lot

RG29: Un lot fait lobjet dune ou plusieurs rceptions

RG30: Un ordre de service concerne un et un seul lot

1..1

1..*

Commune

-

-

-

Numero

Nom

Nom province

: int

: string

: string

Mairie

-

-

-

Code

Nom

Adresse

: int

: string

: string


RG31: Un lot possde un et un seul ordre de service

RG32: Une notification concerne un et un seul lot

RG33: Un lot possde une et une seule notification

RG34: Un contrat concerne un et un seul lot

RG35: Un lot possde un et un seul contrat

RG36: Un lot fait lobjet dun ou plusieurs suivis

RG37: Un suivi concerne un et un seul lot

RG38: Un RIB concerne un et un seul lot

RG39: Une pro forma concerne un et un seul lot

RG40: Une plainte concerne une dlibration

RG41: Une dlibration fait lobjet dune ou plusieurs plaintes

RG42: Une plainte fait lobjet dune dcision

RG43: Une dcision concerne une et une seule plainte

II.3.2. Diagramme de classes


Figure II.22 : Diagramme de classes


III. Forces et faiblesses du systme existant

contient1..*

1..*

est constitue

1..1

1..*

possde

1..1

1..*

dispose de

1..1

1..*

concerne

1..*

1..1

concerne

1..1

1..1

achte

1..*

1..*

contient1..1

1..*

est compose1..1

1..*

appartient1..1

1..*

fait l'objet

1..1

1..*se compose

1..1

1..*

fait rfrence

1..1

1..1

concerne

1..1

1..1

concerne

1..1

1..1

soumissionne1..*

1..*

fait l'objet1..1

1..*

est faite1..*

1..*concerne

1..1

1..1

concerne

1..1

1..*

fait rfrence1..11..1

adresse

1..1

1..*

requiert

1..1

0..1

contient

1..1

1..*

requiert

1..1

0..1

Exercice budgtaire

-

-

-

annee

etat

observation

: int

: String

: String

+

+

+

+

+

+

creer ()

modifier ()

supprimer ()

rechercher ()

valider ()

lister ()...

: void

: void

: void

: void

: void

: void

Ligne budgtaire

- montant : int

+

+

+

+

+

creer ()

modifier ()

supprimer ()

rechercher ()

lister ()...

: void

: void

: void

: void

: void

Compte budgtaire

-

-

numero

libelle

: int

: String

+

+

+

+

creer ()

modifier ()

supprimer ()

rechercher ()...

: void

: void

: void

: void

Document

-

-

libelle

dateajout

: String

: Date

Archive

- numero : int

+

+

creer ()

ajouterdocument ()...

: void

: void

PPM

-

-

-

annee

etat

observation

: int

: boolean

: String

+

+

+

+

+

+

creer ()

modifier ()

supprimer ()

rechercher ()

valider ()

lister ()...

: void

: void

: void

: void

: void

: void March

-

-

-

-

-

-

-

numero

nature

responsableTDR

dateLancement

dateDemarrage

dateReception

financement

: String

: String

: String

: Date

: Date

: Date

: String

+

+

+

+

+

+

creer ()

modifier ()

supprimer ()

rechercher ()

initier ()

lister ()...

: void

: void

: void

: void

: void

: void

Mode Passation

-

-

code

libelle

: int

: String

+

+

+

+

creer ()

modifier ()

supprimer ()

lister ()...

: void

: void

: void

: voidSuivi

-

-

date

information

: Date

: String

DAO

-

-

-

-

-

numero

dateCreation

nbExemplaires

chemin

etat

: String

: Date

: int

: String

: String

+

+

+

+

creer ()

valider ()

joindre ()

publier ()...

: void

: void

: void

: voidRcpiss

-

-

-

-

-

numeroMandat

typeMandat

montantMandat

bureauPoste

dateEmission

: String

: String

: double

: String

: Date

Soumissionnaire

-

-

-

nom

adresse

telephone

: String

: String

: String

Type

-

-

code

libelle

: int

: String

+

+

+

+

creer ()

modifier ()

supprimer ()

lister ()...

: void

: void

: void

: void

Rception

-

-

-

type

date

observation

: String

: Date

: String

+

+

creer ()

supprimer ()...

: void

: void

Contrat

-

-

numero

date

: String

: Date

Ordre de service

-

-

numero

date

: String

: Date

Notification

-

-

chargeNotification

date

: String

: Date

Lot

-

-

-

-

-

-

-

numero

description

montant

garantie

delaiEngagement

delaiExecution

etat

: String

: String

: double

: double

: int

: int

: boolean

+

+

+

+

+

creer ()

modifier ()

supprimer ()

rechercher ()

lister ()...

: void

: void

: void

: void

: void

Soumission

-

-

-

-

-

-

numeroOrdre

dateArrivee

nomDepositaire

montant

offreFinanciere

offreTechnique

: int

: Date

: String

: double

: String

: String

Depouillement

-

-

date

lieu

: Date

: String

Analyse

-

-

-

dateDebut

dateFin

rapport

: Date

: Date

: String

Deliberation

-

-

date

procesVerbal

: Date

: String

Plainte

-

-

-

numero

date

observation

: String

: Date

: String

+

+

+

+

enregistrer ()

modifier ()

supprimer ()

suspendreMarche ()...

: void

: void

: void

: void

Decision

-

-

-

numero

date

observation

: String

: Date

: String

+

+

reprendreMarche ()

poursuivreMarche ()...

: void

: void

RIB

-

-

adresseTitulaire

numeroCompte

: String

: String

Pieces Administratives

- intitule : String

Proforma

-

-

-

numero

date

chemin

: String

: Date

: 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.


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

Rfrence

Cest lacteur charg de la rdaction

des termes de rfrence.

VB Validateur de Budget Cest lacteur charg de valider le

budget de lanne.


EPPM Elaborateur de Plan de


Cest lacteur charg de la gestion du

plan de passation des marchs publics

depuis son laboration jusqu sa

validation.

VPPM Validateur de Plan de


Cest lacteur charg de valider le

plan de passation des marchs.

RM Responsable des Marchs Le responsable des marchs soccupe

de la gestion des dossiers dappel

doffre, des soumissions ainsi que de

lexcution des marchs.

RAM Responsable dAttribution

des Marchs

Cest lacteur charg de lattribution

dun march un soumissionnaire.

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 Cest lacteur qui est charg de

valider le DAO, publier le DAO ainsi

que les rsultats dattribution du


march.

AS Administrateur du Systme Cest lacteur qui sera charg de la

cration des profils utilisateurs et de

lattribution des droits daccs.

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 DES BESOINS

FONCTIONNELS

EB Elaborer budget

VB Valider budget

EPPM Elaborer PPM

VPPM Valider PPM

RTDR Rdiger TDR

RM

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


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

Documents

Mise en place d'un système de Gestion des marchés publics à la SONAPOST