Memoire Mouamadje Thierry Aing - Maj-Final

Institut Africain d’Informatique (IAI) Société de Services en Ingénierie Informatique(SSII)
Etablissement Inter – Etats d’Enseignement Supérieur Libreville (Gabon) - Tél. (241) 77 05 09 01 / +241 77 43 22 13
BP 2263 Libreville (Gabon) - Tél. (241) 07 70 55 00 / 07 70 56 00 Site web : www.ara-labs.com Email: contacts@ara-labs.com
Site web : www.iaisiege.org Email : contacts@iaisiege.org
CO MEMOIRE DE FIN DE CYCLE

En vue de l’obtention du diplôme d’ingénieur en
informatique
NCEPTI
OR
CONCEPTION ET REALISATION D’UN ERP MULTI

PLATEFORME POUR LES TPE ET PME:Négoce et
Facturation
Réalisé et soutenu par :
MOUAMADJE Thiery
EALISATION D’UN ERP MULTIPLATEFORME:Négoce et Facturation
Superviseur IAI Maître de stage

M. GUIFO KOUAM Donacien M. NODJIAM Théophile
Enseignant permanent à l’IAI DG de ARALAB’S
Année académique 2019-2020

CONCEPTION ET REALISATION D’UN ERP MULTIPLATEFORME POUR LES TPE ET PME:Négoce et Facturation
LISTE DES TABLEAUX .................................................................................................... vi
LISTE DES FIGURES ........................................................................................................ vii
DEDICACES ....................................................................................................................... ix
REMERCIEMENTS ..............................................................................................................x
RESUME ............................................................................................................................. xi
ABSTRACT ........................................................................................................................ xii
ABREVIATIONS .............................................................................................................. xiii
AVANT PROPOS ................................................................................................................xv
INTRODUCTION GENERALE.............................................................................................1
PARTIE I : CONTEXTE GENERAL DE L’ETUDE ..............................................................2
CHAPITRE I : LA STRUCTURE D’ACCUEIL ET LE SUJET .........................................3
I. LA STRUCTURE D’ACCUEIL ..................................................................................3
I.1 Présentation ...........................................................................................................3
I.2 Organisation et fonctionnement .............................................................................3
I.2.1 Direction Générale (DG) .................................................................................3
I.2.2 Direction Administrative et Financière (DAF) .................................................3
I.2.3 Direction Commerciale et Marketing (DCM) ..................................................3
I.2.4 Direction Technique (DT) ...............................................................................4
I.3 Missions ................................................................................................................4
I.4 Localisation ...........................................................................................................5
II. PRESENTATION DU SUJET ...................................................................................6
II.1 Libellé du sujet .....................................................................................................6
II.2 Contexte du sujet ..................................................................................................6
II.3 Intérêt du projet ....................................................................................................6
II.4 Problématique ......................................................................................................7
CHAPITRE II : ETUDE GENERALE DU SUJET .............................................................9
MOUAMADJE Thiery Mémoire de fin de cycle ingénieur (2017-2021) i

II.1 ERP..........................................................................................................................9
II.1.1 Définition ..........................................................................................................9
II.1.2 Présentation de l’ERP ........................................................................................9
II.1.3 Architecture .......................................................................................................9
II.1.3.1 Architecture technique ................................................................................9
II.1.3.2 Architecture modulaire..............................................................................10
II.1.3.3 Le paramétrage ......................................................................................... 11
II.1.3.4 Le workflow ............................................................................................. 11
II.1.4 Avantages et Inconvénients d’un ERP ............................................................. 13
II.2 GESTION COMMERCIALE ................................................................................. 14
II.2.1 Enjeux de la gestion commerciale .................................................................... 14
II.2.2 Gestion d’achat et approvisionnement.............................................................. 15
II.2.2.1 Définition ................................................................................................. 15
II.2.2.2 Processus d’un Achat ................................................................................15
II.2.2.3 L'enregistrement comptable d'une facture d’achat ..................................... 17
II.2.3 Gestion de vente .............................................................................................. 19
II.2.3.1 Définition ................................................................................................. 19
II.2.3.2 Processus de vente .................................................................................... 19
II.2.2.3 L'enregistrement comptable d'une facture de vente .................................... 20
II .2.4 Gestion des stocks .......................................................................................... 22
II.2.4.1 Définition ................................................................................................. 22
II.2.4.2 Processus stock ......................................................................................... 22
CHAPITRE III : ÉTUDE DE L’EXISTANT .................................................................... 24
III.1 QUELQUES SOLUTIONS EXISTANTES........................................................... 24
III.1.1 Les ERP propriétaires ..................................................................................... 24
III.1.1 Les ERP Open source ..................................................................................... 25
III.2 CRITIQUE DE L’EXISTANT ..............................................................................26
MOUAMADJE Thiery Mémoire de fin de cycle ingénieur (2017-2021) ii

III.2.1 Problématique ................................................................................................ 26
III.2.2 Alternative ..................................................................................................... 26
III.2.3 Solution retenue ............................................................................................. 26
III.2.4 Justification .................................................................................................... 26
PARTIE II : ANALYSE ET CONCEPTION ........................................................................ 27
CHAPITRE III : CHOIX DE LA METHODE D’ANALYSE ET DE CONCEPTION ......28
III.1 LANGAGE DE MODELISATION OBJET : UML ...............................................28
III.1.1 Généralités ..................................................................................................... 28
III.1.2 Présentation du langage UML ........................................................................ 28
III.2 LES PROCESSUS DE DEVELOPPEMENT ........................................................ 30
III.2.1 Le processus en cascade ................................................................................. 30
III.2.2 Le processus en V .......................................................................................... 30
III.2.3 Le processus en spirale ................................................................................... 31
III.2.4 Le processus semi-itératif ...............................................................................31
III.2.5 Le processus unifié ......................................................................................... 31
III.3 LES METHODES D’ANALYSE ET DE CONCEPTION ..................................... 32
III.3.1 Méthodes cartésiennes (fonctionnelles)........................................................... 32
III.3.2 Méthodes systémiques .................................................................................... 32
III.3.3 Méthodes orientée-objet ................................................................................. 32
III.3.4 Les méthodes Agiles ...................................................................................... 33
III.3.4.1 XP : eXtreme Programming ..................................................................... 34
III.3.4.2 Scrum ......................................................................................................34
III.3.5 Les méthodes formelles .................................................................................. 35
III.4 CHOIX D’UNE METHODE : UML COUPLE A UN PROCESSUS HYBRIDE .. 36
III.4.1 Le processus utilisé (Un Processus Hybride) .................................................. 37
III.4.2 Description du processus utilisé ......................................................................37
CHAPITRE IV : ANALYSE ET CONCEPTION DU SYSTEME .................................... 39
MOUAMADJE Thiery Mémoire de fin de cycle ingénieur (2017-2021) iii

IV.1 ANALYSE DU BESOIN ...................................................................................... 39
IV.1.1 Les besoins fonctionnels ................................................................................39
IV.1.2 Les besoins techniques ................................................................................... 40
IV.2 CONCEPTION DU SYSTEME ............................................................................ 42
IV.2.1 Spécification fonctionnelle .............................................................................42
IV.2.1.1 Identification des acteurs ......................................................................... 42
IV.2.1.2 Le diagramme de contexte statique .......................................................... 44
IV.2.1.3 Identification des cas d’utilisation............................................................ 44
IV.2.1.4 Organisation des acteurs et des cas d’utilisations en packages .................. 46
IV.2.1.5 Relations entre les cas d’utilisation .......................................................... 48
IV.2.1.6 Classification des UC et planification du projet en itération ..................... 52
IV.2.2 Spécification détaillée .................................................................................... 54
IV.2.2.1 Description textuelle des cas d’utilisation ................................................54
IV.2.2.2 Diagramme de séquence ..........................................................................66
IV.2.3 Réalisation des Diagramme de classe ............................................................. 72
IV.2.3.1 Règle de gestion ...................................................................................... 75
IV.2.3.2 Structuration des classes en package ........................................................ 75
IV.2.4 Diagramme d’activité de navigation ............................................................... 76
IV.2.5 Diagramme de déploiement ............................................................................ 80
PARTIE III : MISE EN ŒUVRE ET CONDUITE DE PROJET ..........................................81
CHAPITRE V : MISE EN ŒUVRE ................................................................................. 82
V.1 ARCHITECTURE DE LA SOLUTION ................................................................. 82
V.1.1 Architecture client/serveur ...............................................................................82
V.1.2 Client lourds VS client légers ..........................................................................83
V.1.2.1 Client lourd (2 tiers).................................................................................. 83
V.1.2.2 Client léger (3 tiers) .................................................................................. 84
V.1.3 Choix de l’architecture .................................................................................... 86
MOUAMADJE Thiery Mémoire de fin de cycle ingénieur (2017-2021) iv

V.1.4 Choix des outils et technologies....................................................................... 86
V.1.4.1 Windev ..................................................................................................... 86
V.1.4.2 PowerDesigner ......................................................................................... 87
V.1.4.3 MySQL .................................................................................................... 88
V.1.5 Déploiement de la solution ..............................................................................89
V.1.5.1 Captures d’écran de l’application .............................................................. 89
CHAPITRES VI : CONDUITE DE PROJET .................................................................... 95
VI.1 GESTION DE PROJET ........................................................................................ 95
VI.1.1 Intervenants au projet ..................................................................................... 95
La Maîtrise d’ouvrage ........................................................................................... 95
La Maîtrise d’œuvre .............................................................................................. 95
VI.1.2 Découpage du projet en phase ........................................................................ 96
VI.1.3 Planification du projet .................................................................................... 96
VI .1.3.1 Diagrammes de GANTT prévisionnel ..................................................... 92
VI .1.3.2 Diagrammes de GANTT réel .................................................................. 93
VI.1.4 Estimation des coûts du projet ........................................................................ 94
VI.2 BILAN ET PERSPECTIVES ................................................................................94
VI.2.1 Etat d’achèvement .......................................................................................... 94
VI.2.2 Apports du stage ............................................................................................ 95
VI.2.3 Difficultés rencontrées ................................................................................... 95
VI.2.4 Perspectives ................................................................................................... 96
CONCLUSION GENERALE ............................................................................................... 97
Références ...........................................................................................................................xiv
MOUAMADJE Thiery Mémoire de fin de cycle ingénieur (2017-2021) v

Tableau 1: Contact Ara lab's ...................................................................................................5

Tableau 2:Compte de charge (Plan comptable général 2020, 2020)....................................... 19
Tableau 3:compte de charge (OHADA PLAN COMPTABLE, 2020) ................................... 19
Tableau 4:Exemple d'écriture comptable d'une facture de vente ............................................ 21
Tableau 5:Compte produit (Plan comptable général 2020, 2020) ..........................................21
Tableau 6:Compte produit (OHADA PLAN COMPTABLE, 2020) ......................................21
Tableau 7: Prix de licence d'ERP SAP (Prix, 2020)............................................................... 24
Tableau 8: Figure 10:Differenst prix de licence sage ............................................................. 25
Tableau 9: Comparaison de différentes méthodes ................................................................. 36
Tableau 10:: Les fonctionnalités du module ..........................................................................40
Tableau 11 :Les différents acteurs ainsi que leur rôle ............................................................ 43
Tableau 12:Organisation de cas d’utilisation en packages ..................................................... 48
Tableau 13:Tableau récapitulatif de la classification et de la planification............................. 53
Tableau 14: Description textuelle du cas d’utilisation s’authentifier ......................................55
Tableau 15: Description textuelle de cas d'utilisation Gérer un rôle....................................... 55
Tableau 16: Description textuelle du cas d’utilisation Ajouter utilisateur .............................. 56
Tableau 17:Description textuelle de cas d'utilisation Sauvegarder les données ...................... 56
Tableau 18: Description textuelle de cas d'utilisation Gérer plan comptable .......................... 57
Tableau 19:Description textuelle de cas d'utilastion Gérer les taux de taxe............................ 58
Tableau 20:Description textuelle de cas d'utilisation Enregistrer un tiers............................... 59
Tableau 21: Description textuelle de cas d'utilisation ............................................................ 60
Tableau 22: Description textuelle de cas d'utilisation Enregistrer un article ........................... 61
Tableau 23: Description textuelle de cas d’utilisation Enregistrer un document de vente ....... 62
Tableau 24: Description textuelle de cas d'utilisation Lister document de vente .................... 63
Tableau 25: Description textuelle de cas d'utilisation Gérer échéancier ................................. 63
Tableau 26:Description textuelle de cas d'utilisation Transformer un document de vente ......64
Tableau 27: Description textuelle de cas d'utilisation Régler facture ..................................... 65
Tableau 28:Découpage du projet........................................................................................... 96
Tableau 29: Diagramme prévisionnel.................................................................................... 92
Tableau 30: Diagramme de GANTT Rée ..............................................................................93
MOUAMADJE Thiery Mémoire de fin de cycle ingénieur (2017-2021) vi

Figure 1:Architecture technique des ERP (Présentation générale des ERP et leur architecture
modulaire, 2020) .................................................................................................................. 10
Figure 2: Architecture modulaire des ERP (Présentation générale des ERP et leur architecture
modulaire, 2020) .................................................................................................................. 11
Figure 3:Le workflow ...........................................................................................................12
Figure 4:Processus de la gestion commerciale (Présentation générale des ERP et leur
architecture modulaire, 2020) ............................................................................................... 14
Figure 5:Processus d'achat et approvisionnement (Home/Achats et Approvisionnements, 2020)
.............................................................................................................................................17
Figure 6: Processus d'achat ................................................................................................... 17
Figure 7: Processus d'achat (Home/Achats et Approvisionnements, 2020) ............................ 17
Figure 8: Processus de vente (Présentation générale des ERP et leur architecture modulaire,
2020) .................................................................................................................................... 20
Figure 9: Processus de stock (Présentation générale des ERP et leur architecture modulaire,
2020) .................................................................................................................................... 22
Figure 10: Le cycle de l'Extreme Programming (Le cycle de l'Extreme Programming., 13
novembre 2013).................................................................................................................... 34
Figure 11: Scrum (SUBRA, septembre 2019) ....................................................................... 34
Figure 12:schémas description du processus utilisé ............................................................... 37
Figure 13: Chaîne complète de la démarche de modélisation du besoin jusqu’au code ..........37
Figure 14: Diagramme de contexte statique ..........................................................................44
Figure 15:Cas d'utilisation gestion d'administration .............................................................. 48
Figure 16:Cas d'utilisation gestion des structures de base ...................................................... 49
Figure 17:Cas d'utilisation gestion de vente ..........................................................................50
Figure 18:Cas d'utilisation gestion d'achat ............................................................................ 51
Figure 19:Cas d'utilisation gestion de stock ..........................................................................52
Figure 20:Diagramme de sequence s'authentifier .................................................................. 66
Figure 21: Diagramme de sequence enregistrer article .......................................................... 67
Figure 22: Diagramme de sequence Enregistrer tiers............................................................. 68
Figure 23:Diagramme de sequence enregistré un document .................................................. 69
Figure 24:Diagramme de sequence enregistré un règlement .................................................. 70
Figure 25:Diagramme de sequence processus de vente ......................................................... 71
Figure 26:Diagramme de classe gestion de vente .................................................................. 73
MOUAMADJE Thiery Mémoire de fin de cycle ingénieur (2017-2021) vii

Figure 27:Diagramme de classe gestion d'achat et stock ....................................................... 74

Figure 28: Diagramme des classes en package ......................................................................75
Figure 29: Diagramme d'activité s'authentifier ......................................................................76
Figure 30: Digramme d'activité enregistrer article ................................................................. 77
Figure 31:Diagramme d’activité processus de vente.............................................................. 78
Figure 32:Diagramme d’activité processus d’achat ............................................................... 79
Figure 33: Diagramme de déploiement ................................................................................. 80
Figure 34:Architecture client/serveur (Architecture client-serveur, 2021) ............................. 83
Figure 35: Architecture client lourd ...................................................................................... 83
Figure 36: Architecture client léger....................................................................................... 85
Figure 37:Windev ................................................................................................................. 87
Figure 38: PowerDesigner .................................................................................................... 87
Figure 39:MySQL ................................................................................................................88
Figure 40: Page de connexion ............................................................................................... 89
Figure 41: Page d'administration ........................................................................................... 89
Figure 42: page d'acceuil ......................................................................................................90
Figure 43: Tableau de bord ................................................................................................... 91
Figure 44: liste des dococuments de vente ............................................................................ 91
Figure 45:Formulaire de saisi d'une facture ...........................................................................92
Figure 46: Formulaire de saisi d'un réglement ....................................................................... 93
Figure 47:Etat d'une facture .................................................................................................. 94
MOUAMADJE Thiery Mémoire de fin de cycle ingénieur (2017-2021) viii

Je dédie ce travail…
À ma chère mère YAYAM Léonie,
À mon cher père NDILNGAR Yota,
Qui n’ont jamais cessé, de formuler des prières à mon égard, de me
soutenir et de m’épauler pour que je puisse atteindre mes objectifs.
À tous mes frères et sœurs particulièrement à mes grands frères
KOMTEBAYE Romain et Merci YOTA Olivier
Pour tous les conseils et divers soutiens. Je vous suis très reconnaissant,
et je ne vous remercierai jamais assez pour votre amabilité, votre
générosité, votre aide précieuse. Je vous souhaite une vie pleine de
bonheur et de succès et que Dieu, le tout puissant, vous protège et vous
garde.
A la mémoire de mon grand frère ALLADOUMADJE Roland,
Aucune dédicace ne saurait exprimer l’amour, l’estime, le dévouement et
le respect que j’ai toujours eu pour toi. Rien au monde ne vaut les efforts
fournis à mon égard.
À toute ma famille et à tous mes amis,

Veuillez trouver dans ce travail l’expression de mon respect le plus
profond et mon affection la plus sincère.
MOUAMADJE Thiery Mémoire de fin de cycle ingénieur (2017-2021) ix

Mes remerciements vont tout d’abord à DIEU le tout puissant qui m’a guidé tout au long du travail et
qui a su me donner la force, le courage et la persévérance malgré d’énormes difficultés rencontrées.
La rédaction de ce mémoire n’aurait pas été possible sans l’intervention consciente des personnes ci-
dessous que je tiens à remercier.
Tout d’abord, je voudrais remercier mes maîtres de stage,
Mr Théophile NODJIAM, Directeur Général de ARALAB’S SARL, et Mr Prince BAYONG,

Directeur général du cabinet 2BN International Qui ont su me faire confiance lors de cette aventure
dans le monde professionnel et ont partagé leurs connaissances de manière très pédagogique. Je les
remercie aussi pour la qualité de leur encadrement en entreprise.
Je souhaite ensuite adresser mes remerciements à M. GUIFO KOUAM Donacien

, mon superviseur, pour le suivi de ce travail et pour sa grande disponibilité ;
Je désire aussi remercier le corps professoral et administratif de l’IAI pour la formation qu’ils nous
ont donnée et l’encadrement dont nous avons bénéficié de leur part ;
Je tiens à remercier la communauté des étudiants tchadienne de l’IAI, mes camarades de classe et les
autres étudiants de l’IAI pour les moments partagés pendant les trois années de formation à l’IAI.
A tous ceux qui ont contribué de près ou de loin à la réalisation de cet ouvrage, soyez-en remerciés.
Sans votre concours, ce travail ne serait arrivé à son terme. Veuillez trouver ici, l’expression de ma
profonde gratitude.
MOUAMADJE Thiery Mémoire de fin de cycle ingénieur (2017-2021) x

Pour améliorer sa performance, l’entreprise d’aujourd’hui vise à automatiser la gestion interne

de ses activités en faisant appel à des technologies informatiques,ce qui amène la pluspart des entreprises
à optimiser la totalité de leur gestion autour d’un système d’information à l’aide des progiciels de gestion
intégrée connus sous l’acronyme de ERP.
En effet, le cabinet 2BN Internationnal est un cabinet d’expertise-comptable qui accompagne
au quotidien les Très Petites Entreprises (TPE) et les Petites et Moyennes Entreprises (PME) dans de
nombreux domaines à savoir : social, fiscal, juridique. Mais aussi dans la recherche de financement,
l’implémentation des systèmes d’information et assurer une bonne tenue de leur comptabilité.Ce
pendant, la plupart des ERP sur le marché sont d’origine occidentale ce qui fait que le cadre fiscale est
moins adapté à la réalité locale ; il y’a plus de fonctionnalités qui rendent leur utilisation complexe mais
aussi le coût d’acquisition est très élevé.C’est ainsi qu’un partenariat est né entre ARA LAB’S et ce
dernier pour la réalisation d’un projet nommer Facteur X. Il s’agit d’un ensemble de système de gestion
(gestion commerciale, comptabilité et finance et gestion de trésorerie) inégré destiné aux TPE, PME.
Compte tenu de sa complexité, il est subdivisé en plusieurs modules dont le module « négoce et
facturation » nous a été confié pour notre stage.Ce module permettra l’automatisation de tous les
processus de gestion d’achat (bon de commande, bon de reception, facture et règlement des factures),
de gestion de vente (devis,bon de commande,bon de livraison,bon de retour, facture, facture d’avoir ),
gestion de stock (bon d’entrée, bon de sortie,transfert et les inventaires). Il permet également de gérer
le paiement des factures enfin de générer les écritures comptables.
Pour méner à bien notre travail nous avons procédé à l’analyse, la conception et la modélisation
du système en utilisant une méthode de conception objet. Cette méthode est l’association d’UML aux
processus unifiés (UP) et aux méthodes agiles telles que XP et Scrum ; Par l’utilisation d’un AGL
WinDev et SGBD MySQL.
Mots clés : ERP, PGI, ACHAT, VENTE, STOCK, SCRUM, XP, Processus UP, UML
MOUAMADJE Thiery Mémoire de fin de cycle ingénieur (2017-2021) xi

To improve its performance, the company of today aims to automate the internal
management of its activities by using computer technologies, which leads most companies to
optimize their entire management around an information system using integrated management
software known by the acronym ERP.
Indeed, the firm 2BN International is an accounting firm that accompanies daily very
small businesses (VSE) and small and medium enterprises in many areas including: social,
tax, legal. But also in the search for financing, the implementation of information systems and
ensure a good accounting.This while, most of the ERP on the market are of Western origin
from where the tax reality does not integrate the local reality; more functionality that makes
their use complex but also their cost of acquisition is very high.Thus a partnership was born
between ARA LAB'S and the latter for the realization of a project named Factor X. This is a
set of management systems (commercial management, accounting, cash management)
designed for small and medium-sized businesses.
This module will allow the automation of all the processes of purchase management
(Order form, Receipt form, Invoice and payment of invoices), sales management (Quotation,
Order form, Delivery form, Return form, Invoice, Credit note and payment of invoices) and
stock management (Entry form, Exit form, Transfer and inventories). It also allows the
generation of accounting entries.
To carry out our work we proceeded to the analysis, the design and the modelling of
the system by using a method of object design. This method is the combination of UML with
unified processes (UP) and agile methods such as XP and Scrum; by using a WinDev AGL
and MySQL DBMS.
Keywords : ERP, ERP, PURCHASE, SALES, STOCK, SCRUM, XP, UP process
MOUAMADJE Thiery Mémoire de fin de cycle ingénieur (2017-2021) xii

2TUP Two Track Unified Process

AGL Atelier de Génie Logiciel
CGV Conditions Générales de Vente
CO Controlling,
CRM Client Relationship Management
DCP Diagrammes des Classes Participantes
DDOS Distributed Denial-Of-Service
DSDM Dynamic Software Development Method
DSS Diagrammes de Séquence Système
ERP Enterprise Resource Planning
FI Financial
IAI Institut Africain d'Informatique
IHM Interface Homme Machine
IM Investments Management
MIT Multi Information Technology
MM Material Management
MVC Modèle-Vue-Controller
PM Plan Maintenance
PGI Progiciel de Gestion Intégré
PME Petites et Moyennes Entreprises
PP Production Planning,
QM Quality Management,
RUP Rational Unified Process
SD Sales and Distribution,
SGBD Système de Gestion de Bases de Données
SGBDOR Système de Gestion de Bases de Données Objet Relationnels
SI Système d’Informaton
SQL Structured Query Language

TIC Technologies de l’Information et de la Communication
TPE Très Petite Entreprise
TR Treasury,
UML Unified Modeling Language
UP Unified Process
MOUAMADJE Thiery Mémoire de fin de cycle ingénieur (2017-2021) xiii

WAMP Windows Appache MySql PHP

XML eXtended Markup Language
XP eXtreme Programming
XUP eXtreme Unified Process
MOUAMADJE Thiery Mémoire de fin de cycle ingénieur (2017-2021) xiv

Dans le but de former des cadres en Informatique, l’Institut Africain d’Informatique a été créé
le 29 Janvier 1971 à Fort-Lamy et compte à ce jour 11 états africains. Il forme des Analystes
programmeurs, des ingénieurs et des Maitres en informatique appliquée à la gestion des entreprises sans
oublier le cycle master et licence professionelle.
Afin de préparer les futurs diplômés à l’insertion professionnelle, l’IAI prévoit que chaque futur diplômé
effectue un stage de fin de formation dans une entreprise ou dans un centre de recherche ou de
développement.
Le présent mémoire rentre dans ce cadre en vue de l’obtention du diplôme de fin d’étude du
cycle ingénieur. Il constitue donc l’aboutissement de trois (3) années de formation à l’Institut Africain
d’Informatique de Libreville, incluant cinq (5) mois de stage pratique effectué à ARA LAB’S SARL. Il
tient lieu de mémoire de fin de formation d’ingénieur en Informatique et s’intitule :
CONCEPTION ET REALISATION D’UN ERP MULTIPLATEFORME POUR LES TPE ET PME :
Négoce et Facturation
MOUAMADJE Thiery Mémoire de fin de cycle ingénieur (2017-2021) xv

Les systèmes d’information (SI) sont devenus des outils prépondérants dans la conduite des
activités par les entreprises et la plupart des organisations.
Ils sont présents dans tous les secteurs de l'économie dont l’informatique de gestion représente le
domaine d'application le plus important. Cette dernière se caractérise par la conception, le
développement et la mise en œuvre d'applications informatiques dédiées au management (gestion
administrative, commerciale etc…) des entreprises, au suivi des clients et aux relations avec les
fournisseurs.
En effet, depuis les années 1990, l’ERP ou Enterprise Resource Planning est devenu un outil
standard pour bon nombre de grandes entreprises ou de PME. Pourtant, dans les années 1970, l’idée
d’un seul outil informatique intégré permettant de gérer l’ensemble des activités de l’entreprise ne
semblait être qu’utopie. Les organisations multipliaient les outils afin d’obtenir un système qui
permettait à chaque fonction de gérer son activité (Markus, 2000). Cependant, cette multitude de
système ainsi que la duplicité des informations qui y est associé fut dans de très nombreux cas, source
d’erreurs plus ou moins graves. C’est ainsi que dans les années 1980-90, des développeurs de systèmes
informatiques eurent l’idée de créer un logiciel unique permettant l’intégration de l’ensemble des
fonctions et apportant une solution aux problèmes rencontrés. Un tel système permet à l’information,
une fois qu’elle est entrée dans l’outil, de circuler à travers l’entreprise et d’être accessible à tout instant,
pour tout service.
C’est ainsi que dans le cadre de la mise en œuvre du partenariat entre ARA LAB’S et le cabinet
2BN International, il nous a été confié la tâche consistante à concevoir et mettre en œuvre le module
« Négoce et Facturation » d’un futur ERP ou progiciel de gestion intégré en français.
Ce module qui est une gestion commerciale dont les principaux objectifs sont de réaliser, la gestion des
ventes, d’achats et de stocks qui sont les fonctions associées aux activités commerciales d’une entreprise.
Il est abordé d'une part dans le cadre des traitements classiques de la chaîne commerciale et d'autre part
dans celui des analyses et prévisions de la politique mercatique tout en intégrant tous les aspects liés au
domaine de la comptabilité.
Ce document est composé de trois (3) grandes parties. D’abord, la première partie traite du sujet
et de ses généralités. Dans cette partie nous présenterons le centre d’accueil, le sujet et ses contours.
Ensuite, la deuxième partie se consacre à l’analyse, la conception et la réalisation du système. Enfin, la
troisième partie porte sur la conduite, la planification et l’estimation globale de notre projet.
MOUAMADJE Thiery Mémoire de fin de cycle ingénieur (2017-2021)

1
Dans cette première partie de notre rapport, nous situons le contexte dans lequel s’inscrit le
sujet soumis à notre étude, la problématique qu’il soulève, son intérêt et les objectifs visés. Tout d’abord,
nous présentons la structure qui nous a accueillis pendant la durée de notre stage, ensuite, nous
poursuivons avec les concepts clés nécessaires à la compréhension du sujet.

2
CHAPITRE I : LA STRUCTURE D’ACCUEIL ET LE SUJET

Dans ce chapitre, nous présenterons dans un premier temps la structure dans laquelle nous
avons effectué le stage. En second lieu nous parlerons du projet qui nous a été confié, de son intérêt, de
ses objectifs et de la problématique
I. LA STRUCTURE D’ACCUEIL
I.1 Présentation
Nous avons éffectué notre stage à ARA LAB’S Sarl, une Société de Services en Ingénierie
Informatique (SSII) que nous allons présenter l’organigramme et la mission de ce dernier.
ARA LAB’S est une Société à Responsabilité Limitée (SARL) créée le 26 Février 2019 par deux
(2) jeunes ingénieurs Africains, sortis de l’Institut Africain d’Informatique (IAI). Ils ont ainsi décidé de
mettre en commun leurs compétences au service des TPE et PME Africaines.
ARA LAB’S dispose des équipes composées d'ingénieurs : de consultants informaticiens aux profils
différents mais complémentaires et de commerciaux indépendants. On y trouve des développeurs, des
consultants fonctionnels (assistance à maîtrise d'ouvrage), des chefs de projets, des ingénieurs de
systèmes et réseaux, des administrateurs de bases de données, etc.
I.2 Organisation et fonctionnement

I.2.1 Direction Générale (DG)
Sous le contrôle du Directeur Général, la Direction Générale coordonne les activités de
l’entreprise et gère l’aspect organisationnel. Elle définit la vision de l’entreprise et s’occupe de veiller à
l’atteinte des objectifs fixés en amont.
I.2.2 Direction Administrative et Financière (DAF)

Elle est chargée de la gestion des aspects administratif, financier et comptable de la société. La DAF
planifie, par élaboration de budget, toutes les entrées et sorties de fonds concernant la société. Elle est
également chargée de réceptionner et gérer tous les encaissements (factures clients, ventes de produits
et services,etc…) ainsi que d’engager tous les décaissements au sein de la société.
I.2.3 Direction Commerciale et Marketing (DCM)
La DCM s’occupe de la prospection, l’acquisition et la gestion des clients de la société. Elle est en
contact permanent avec la clientèle afin de l’éclairer sur l’utilisation des solutions mises en place, mais
aussi pour détecter des nouveaux besoins des clients.
La DCM prépare ainsi les plans marketings (analyse du marché, détermination des cibles, choix des
axes publicitaires), conçoit et met en place des actions promotionnelles destinées à développer les

3
produits existants et à optimiser les ventes. Elle s’occupe également des négociations commerciales de
haut niveau.
I.2.4 Direction Technique (DT)

Elle s’occupe de la gestion des ressources techniques et des projets clients. Ainsi, la DT se charge
de l’exécution des tâches techniques liées aux différents projets des clients de la société. Elle travaille
sans relâche sur les nouveaux projets ainsi que sur la mise à jour des solutions déjà en production - chez
les clients.
DIRECTION GÉNÉRALE
DIRECTION DIRECTION
DIRECTION
ADMINISTRATIVE ET COMMERCIALE
TECHNIQUE
FINANCIÈRE ET MARKETING
SERVICE
INFORMATIQUE
CONSULTANTS
I.3 Missions
ARA LAB’S est une structure dont l’expérience et la qualité des services ainsi que son
dynamisme témoignent son aspiration : « se positionner parmi les meilleurs éditeurs de logiciels
informatiques en Afrique ».
ARA LAB’S offre une palette de services à ses clients.
 Logiciels de gestion
 GP Auto : Gestion de parcs automobiles
 GuestManager : Logiciel de gestion des hôtels et restaurants
 Damla (Gestion de la Caisse)
 ara-immo : Système de gestion des agences immobilières
 Conception et développement
 Interfaçage et intégration à Sage
 Applications sur mesures

4
 Applications Web
 Sites web
 Sécurité systèmes et réseaux
 Conception et déploiement
 Administration et Maintenance
 Windows Server
 Microsoft Office
 Vente de matériels informatiques
 Infogérance
 Diverses formations
 Pack Microsoft Office
C’est nous avons effectué notre stage dans la direction technique principalement dans le service
informatique
I.4 Localisation
ARA LAB’S exercice au sein de l’entreprise partenaire Cabinet 2BN international situé au
quartier Louis au 2e étage appartement B2 de l’immeuble collé au centre de santé de Louis et en face du
petit marché.
Téléphone +241 77 05 09 01
Email nodjiam@ara-labs.com
Site web www.ara-labs.com
Tableau 1: Contact Ara lab's

5
II. PRESENTATION DU SUJET

II.1 Libellé du sujet
CONCEPTION ET REALISATION D’UN ERP MULTIPLATEFORME POUR LES TPE ET PME :
Négoce et Facturation.
II.2 Contexte du sujet

De nos jours, les entreprises souhaitent s’ouvrir aux nouvelles technologies pour une gestion
globale de leur activité, automatiser le traitement des informations et permettre aux dirigeants de prendre
des bonnes décisions et avoir un meilleur rendement.
En effet, le cabinet 2BN Internationnal est un cabinet d’expertise-comptable qui accompagne
au quotidien les TPE et les PME dans de nombreux domaines social, fiscal, juridique. Mais aussi dans
la recherche de financement, l’implémentation des systèmes d’information et assurer la bonne tenue de
leur comptabilité.Ce pendant, la pluspart des ERP sur le marché sont d’origine occidentale ce qui fait
que le cadre fiscale est moins adapté à la réalité locale ;il y a plus de fonctionnalités qui rendent leur
utilisation complexe mais aussi leur coût d’acquisition est très élevé.
C’est dans le soucis d’apporter cette solution aux TPE et PME qu’un partenariat entre ARALAB’S et
Cabinet 2BN International est né pour la mise en œuvre d’un ERP nommé Facteur X.D’ou il nous a été
confié le projet intitulé « Conception et réalisation d’un ERP multi-plateforme pour les TPE et PME:
module négoce et facturation » qui est l’un des modules de ce projet
Ce dit module va permettre d’assurer avec beaucoup de facilité et de souplesse l'exécution des
tâches commerciales classique qui sont la gestion de ventes, achats et stocks grâce à des nombreux
automatismes tout en intégrant les aspects liés à la comptabilité pour pouvoir facilement générer les
écritures comptables, ainsi que le suivi des règlements des factures clients et fournisseurs, avec un
référentiel unique pour tous.
Il offrira aussi aux utilisateurs un accès rapide, un contrôle des erreurs, une réduction des tâches
quotidiennes et de saisie à effectuer, une interface web et un accès mobile, beaucoup plus souple et
ergonomique.
Pour bien y mener et être sûr des besoins des utilisateurs finaux, un cahier de charge est établi
avec la collaboration des differents clients du cabinet 2BN International. Ce dernier contient tous les
besoins fonctionnels du systeme et differentes tâches.
La mise en place et la réalisation de ce dit projet fait l’objet de notre travail.
II.3 Intérêt du projet

Les fonctionnalités que proposent ce module offre une vision globale sur l’ensemble des
processus de gestion commerciale d’une entreprise tout en travaillant sur une base de données unique et

6
homogène afin de gagner en productivité et réduire les travaux redondants. Ainsi, chaque maillon de
l’organisation apportera sa contribution et la mettra à disposition des autres acteurs de la chaine.
Notre projet consiste donc à proposer une solution répondant aux besoins fonctionnels d’entreprise.
Cette solution devra entre autres assurer :
 La gestion des tiers à savoir les prospects, clients et les fournisseurs avec une interface
ergonomique qui facilite la navigation entre les fonctionnalités du système.
 L’optimisation de la gestion des processus métiers : en occurrence, la gestion des ventes, achats
et stock.
 Permettre d’éditer, générer, imprimer ou envoyer par email les documents de vente et d’achats
qui sont : devis, bons de commande, bons de livraison, bons de réception, bons de retour,
facture, avoir.
 Gérer les paiement des factures clients ou fournisseurs et envoyer les lettres de relance.
 Gérer efficacement le stock, avec la possibilité de faire les inventaires physiques et de consulter
l’état des stocks n’importe quand
 Générer des écritures comptables, transferer des données dans la comptabilité et le pilotage, tout
en garantissant un accès mobile aux données.
 Avoir des statistiques de vente
 La possibilité de développer de nouvelles fonctionnalités
 Un client mobile qui permet l’accès aux fonctionnalités système à l’aide des smartphones.
Toutes les informations provenant des transactions - achats-ventes sont présentées sous forme des
rapports, des graphiques, des tableaux de bord et des indicateurs clés, contribuant ainsi à l'optimisation
d'une gestion opérationnelle et à l'amélioration des performances des entreprises
II.4 Problématique
La réussite du projet qui nous a été confié, passe par la compréhension de l’architecture et
fonctionnement du système (ERP) et la gestion commerciale au sein d’une entreprise. Nous devons avoir
les connaissances sur les opérations comptables qui interviennent dans le processus commercial.
La disponibilité du système en web, mobile (systèmes Android et iOS) et desktop est un point important
à ne pas négliger lors de la conception de la solution tout en tenant compte des possibilités d’évolution
de cette dernière. Aussi faudrait-il tenir compte de l’architecture de déploiement du système pour une
parfaite communication entre ces environnements. En résumé nous nous intéresserons principalement :
 Aux choix des outils pour assurer la disponibilité de la solution sur le Web, mobile et desktop ;
 Aux choix d’une architecture de développement adaptée à l’environnement de déploiement du
système ;

7
 Aux choix des mécanismes pour assurer l’interopérabilité, l’évolutivité et la performance du

système.
Par ailleurs,
 Quelle architecture faut-il définir pour le futur système ?
 Quelle méthode utilisée pour pouvoir avoir les informations en temps réelle et en tout lieu ?
 Quelle stratégie faut-il adopter pour assurer la sécurité du système ?
 Quels mécanismes utiliser pour assurer l’interopérabilité, l’évolutivité et la performance du
système ?
Pour répondre à ces interrogations, nous allons explorer tous les contours du domaine d’étude afin de
fixer les bases solides qui nous permettront de mener notre projet à son terme et assurer son évolutivité.
Ce chapitre nous a permis de planter le décor, en présentant la structure au sein de laquelle nous
avons effectué notre stage et le travail qui nous a été confié. Dans le chapitre qui suit, nous présentons
les concepts clés indispensables à la compréhension du sujet.

8
CHAPITRE II : ETUDE GENERALE DU SUJET

Dans ce présent chapitre, nous allons faire une présentation générale des concepts liés à notre
domaine d’étude. Nous allons d’abord présenter ce que s’est un ERP, son architecture et son
fonctionnement, présenter les concepts de la gestion commerciale notamment la gestion des achats,
des ventes et stock puis les concepts de comptabilité liés à la gestion commerciale d’une entreprise
II.1 ERP
II.1.1 Définition
La définition ERP vient de l’anglais « Entreprise Ressource Planning ». ERP a été traduit en français
par l’acronyme PGI (Progiciel de Gestion intégré) et se définit comme un groupe de module relié à une
base de données unique.
II.1.2 Présentation de l’ERP

ERP est un progiciel qui permet de gérer l'ensemble des processus d'une entreprise intégrant
l'ensemble de ses fonctions comme la gestion des ressources humaines, la gestion financière et
comptable, aide à la décision, la vente, la distribution, l'approvisionnement, la production ou encore du
e-commerce.
Le principe fondateur d'un ERP est de construire des applications informatiques correspondant
aux diverses fonctions citées précédemment de manière modulaire sachant que ces modules sont
indépendants entre eux, tout en partageant une base de données unique et commune au sens logique.
L'autre principe qui caractérise un ERP est l'usage de ce qu'on appelle un moteur de workflow
et qui permet, lorsqu'une donnée est enregistrée dans le SI, de la propager dans les modules qui en ont
l'utilité, selon une programmation prédéfinie.
Pour être qualifiée de « progiciel de gestion intégré », une solution logicielle ERP doit couvrir
au moins deux principes fondamentaux qui sont les suivants :
 Construire des applications informatiques sous forme de modules indépendants mais
parfaitement compatibles sur une base de données unique et commune.
 L’usage d’un moteur de workflow permet de définir l’ensemble des tâches d’un processus et de
gérer leur réalisation dans tous les modules du système qui en ont besoin.
II.1.3 Architecture
II.1.3.1 Architecture technique
Tous les utilisateurs utilisent une base de données commune. L'information est au centre, disponible en
temps réel. L'information doit être mise à jour avec justesse et ponctualité.

9
Figure 1:Architecture technique des ERP (Présentation générale des ERP et leur architecture
modulaire, 2020)
II.1.3.2 Architecture modulaire
Les fonctionnalités offertes par un ERP sont présentées sous formes d’activités regroupées par
homogénéité dans des modules. On parle de cartographie d’un ERP. Deux notions sous-jacentes:
✓ La couverture fonctionnelle : fait référence à l’ensemble des fonctions de l’entreprise couverte
par l’ERP. Exemple : fonction achat, fonction projet, etc…
✓ La profondeur fonctionnelle : fait référence au degré de spécialisation par lequel un ERP permet
la réalisation d’une fonction. Exemple : degré de spécialisation offert pour la gestion de projet.

10
Figure 2: Architecture modulaire des ERP (Présentation générale des ERP et leur architecture
modulaire, 2020)
II.1.3.3 Le paramétrage
Le paramétrage d’un ERP consiste à l’activation ou la désactivation de la fonctionnalité standard de
l’ERP pour obtenir le flux désiré. Il y’a plusieurs niveaux de paramétrage :
✓ Paramétrage de base : concernent la configuration aux données de base qu’utilise l’entreprise.
Exemple : les unités par défaut (poids, devise, etc…), format des données, fuseaux horaires,
etc…
✓ Paramétrage fonctionnel : concernent la Configuration aux besoins et aux particularités de
l'entreprise. Exemples : type d’article (sur stock, à la commande, etc…), catégorie tarifaire,
etc…
✓ Paramétrage système : concernent la configuration des droits d’utilisation, des comptes, des
mots de passe,
✓ Certaines contraintes n’existent pas en standard (développement spécifique)
✓ L’exploitation directe de l’ERP n’est pas un paramétrage. Exemple : saisi d’un article, d’un
fournisseur.
II.1.3.4 Le workflow
La notion de workflow est dédiée à la collaboration entre les intervenants des processus métiers en
automatisant les échanges d’informations et en exécutant des tâches, afin d’atteindre un objectif
commun.
Il se caractérise généralement dans un ERP :
 Par la mise à la disposition d’un message dans la file d’attente du poste de travail de l’utilisateur
qui doit réaliser une tâche (de validation).

11
 Le workflow doit être capable d’aiguiller le processus sur la bonne transaction en fonction du
type d’objet de gestion à traiter.
En général, les moteurs de workflow proposent deux choix de distribution du travail dans l’organisation :
 Les intervenants conservent le choix des tâches à exécutées en fonction de leur priorité,
 Les tâches affectées aux intervenants sans laisser le choix.
ERP
Fournit des Fournit des Fournit des

éléments éléments éléments
Assistance comptoir Commerciale Magasinier Comptable

Figure 3:Le workflow

12
II.1.4 Avantages et Inconvénients d’un ERP

Les bénéfices d’un ERP pour l’entreprise sont les suivants
 Eviter la redondance d’informations entre différents SI de l’entreprise ;
 Disposer d’un outil multilingue et multidevises (très adapté aux multinationales) ;
 Eviter des restitutions d’informations divergentes entre différents services et donc apaiser les
conflits qui en résultaient ;
 Une meilleure coordination des services et du coup un meilleur suivi du processus de commande
qui inclut la prise de commande, l’enregistrement d’une sortie de stock, l’expédition de la
commande et l’émission d’une facture ;
 Une meilleure maîtrise des stocks ;
 Une normalisation de la gestion des Ressources Humaines, en particulier pour les entreprises
qui gèrent de nombreuses entités, parfois géographiquement dispersées.
Quant aux inconvénients, même s’ils sont moins nombreux que les avantages, ils sont néanmoins à
prendre en compte.
 L’investissement peut être important en fonction de la taille de l’entreprise et de ses
besoins ;
 La mise en œuvre peut être complexe et longue si le projet n’est pas bien piloté et la conduite
du changement accompagnée ;
 Certains modules de l’ERP peuvent être moins performants qu’un développement
spécifique interne ou un logiciel spécialisé ;

13
II.2 GESTION COMMERCIALE

II.2.1 Enjeux de la gestion commerciale
La gestion commerciale appélé logistique ou encore Negoce, est le module le plus convoité par
les entreprises, car il permet de gérer tout ce qui se rapporte aux ventes/achats, en particulier la gestion
des stocks qui coûtent cher aux entreprises.
Ce module gère les commandes clients et les livraisons. Il assure une liaison directe avec le compte de
résultats et le système de production. Il permet l'optimisation des processus de workflow, la gestion
précise des stocks, des contrôles qualité et factures. Suite au contrôle qualité, il y a coordination et
déclenchement des mesures correctives. Enfin, il est possible de planifier/gérer/suivre la maintenance
du matériel.
Les processus généraux à paramétrer dans le module negoce sont décrits ci-dessous :
Figure 4:Processus de la gestion commerciale (Présentation générale des ERP et leur architecture
modulaire, 2020)
Une commande de vente correspond à une vente, donc il y a décrémentation du stock et
inversement lors d'un retour. Entre le processus de vente et achat, il y a contremarque, c'est-à-dire une
fabrication d'un article après la vente. Enfin, entre le processus vente et comptabilité générale et
analytique, il y a les règlements clients ou encore les avoirs.
Ceci correspond donc aux processus de base à connaître afin de paramétrer un ERP.
Remarque : une entreprise peut avoir des filiales ou encore être multisites.
Les tiers impliqués dans une vente sont: les clients, l'utilisateur (personnel/ représentant), le
transporteur,et le comptable (qui gère le règlement des factures).

14
II.2.2 Gestion d’achat et approvisionnement

II.2.2.1 Définition
L'achat est un acte par lequel une personne physique ou morale obtient un bien ou un service
grâce au paiement d'une contrepartie financière. En d’autres termes l’achat est le fait d’acquérir un bien
ou un service contre paiement.
L'approvisionnement a pour mission de répondre à toutes contraintes environnantes. La règle
première est de livrer de la marchandise, au bon moment, au bon prix, et au meilleur coût selon le choix
du demandeur.
L’approvisionnement se penche sur la logistique matérielle et administrative des achats (combien de
pièces, quand et comment gérer le transport) ainsi que sur la gestion des stocks (où et comment stocker
les achats).
L’approvisionnement a alors en charge :
 Le calcul de la quantité à commander
 La planification des commandes de réapprovisionnement (fréquence et dates
d'approvisionnement) ;
 La passation des commandes en fonction des demandes d’achats ou ordres
d’approvisionnements fermes
 Le suivi de livraison,
 La gestion des stocks.
Le constat que nous pouvons faire est que ces deux fonctions sont solidairement liées, elles ne sont pas
facilement dissociables car elles travaillent conjointement dans l'évaluation des fournisseurs, le
traitement des litiges ainsi que sur la définition des conditions de mises à disposition des produits (taille
de lot, délai de livraison etc...). (Home/Achats et Approvisionnements, 2020)
II.2.2.2 Processus d’un Achat
Du devis au paiement : les 4 étapes du processus d’achat
 La contractualisation à la transaction
Pour réaliser l’achat pour le compte de son entreprise voici le processus d’une manière générale. Que
vous ayez besoin d’acheter un bien ou une prestation de conseil par exemple, trois étapes préalables sont
à respecter :
 L’identification de votre besoin ;
 La recherche de fournisseurs ;
 La négociation.

15
Cette phase préliminaire passée, le vendeur doit préciser toutes les facettes de la prestation de services
ou de la vente : désignation du service ou du produit, quantité, prix unitaire, prix total, modalités de
livraison, pénalités en cas de retard, délais de paiement ou encore droits et devoirs des deux parties.
Cette formalisation de la prestation peut prendre trois formes différentes selon les pratiques des
entreprises :
✓ La signature d’un devis : ce document, fourni par le vendeur, récapitule les termes de l’offre.
Une fois que vous le signez, il a valeur de contrat, engageant juridiquement les deux parties.
✓ L’édition d’un bon de commande : à l’inverse, ce document est émis par l’acheteur. Une fois
signé par le vendeur, il vaut contrat. Il présente généralement les mêmes informations que le
devis, auquel il peut se substituer.
✓ La réalisation d’un contrat : il s’agit d’une convention, qui peut être écrite comme orale, entre
l’acheteur et le vendeur. Le contrat écrit est généralement privilégié par les entreprises pour les
transactions importantes ou périodiques. Il est à l’initiative de l’acheteur et doit, par conséquent,
être signé par le fournisseur.
Le contrat présente l’avantage d’être plus exhaustif que le devis ou le bon de commande. Ainsi,
il peut prévoir des clauses additionnelles (transfert de propriété, limitation de la responsabilité
du vendeur, etc.).
 La réception de la marchandise
Une fois la transaction formalisée et encadrée, une nouvelle phase débute : le suivi de la commande.
L’acheteur doit surveiller l’avancement de la prestation et, éventuellement, réaliser des relances de son
fournisseur, en cas de retard. Lorsque l’objet de la transaction est livré, le fournisseur remet un bon de
livraison. Avant de le signer, vous devez réaliser un contrôle qualitatif et quantitatif et, si nécessaire,
émettre des réserves. Dans le cas de fournitures ou de matière première, la marchandise doit être
enregistrée dans la fiche de stock avant stockage.
 La facturation
À la réalisation de la livraison ou de la prestation de services, le vendeur doit obligatoirement vous

fournir une facture. Si la transaction comprend plusieurs livraisons, le fournisseur a la possibilité de
facturer de manière périodique, au plus tard à la fin du mois suivant la livraison. Ce document, qui doit
être conservé pendant au moins 6 ans, a plusieurs fonctions :
 Elle constitue la preuve juridique de la transaction et constate le droit de créance du vendeur ;
 La facture présente également les conditions de négociation, et tout particulièrement le montant
dont vous êtes redevable ;
 Elle sert aussi de justificatif comptable, indispensable à la réalisation des comptes annuels de
l’entreprise ;
 Elle a enfin un rôle fiscal puisqu’elle sert à la déclaration de la TVA.

16
 Le paiement
En l’absence de mentions contraires notamment dans le devis, le bon de commande ou le contrat le délai
de paiement est, par principe, de 30 jours à compter de l’exécution de la prestation ou de la livraison de
la marchandise. Vous pouvez néanmoins négocier avec votre fournisseur afin d’allonger ce délai de
règlement. Il ne peut cependant pas être supérieur à 60 jours ou à 45 jours fin de mois, dans les deux cas
à date de facturation. Sachez d’ailleurs que des délais spécifiques s’appliquent pour certains secteurs
d’activité, dont l’alimentation et le transport.
Si vous ne réglez pas la facture en temps et en heure, vous vous exposez à plusieurs sanctions :
 Des pénalités de retard : elles sont dues dès le premier jour de retard de paiement. Leur montant
est calculé en fonction d’un taux d’intérêt inscrit sur la facture ;
 Une indemnité forfaitaire : pour tout retard de paiement, vous êtes redevable d’une indemnité pour
frais de recouvrement. C’est également valable en cas de paiement partiel de la facture à échéance ;
 Amende administrative
Figure 6: Processus d'achat
Figure 7: Processus d'achat (Home/Achats et Approvisionnements, 2020)

Figure 5:Processus d'achat et approvisionnement (Home/Achats et Approvisionnements, 2020)
II.2.2.3 L'enregistrement comptable d'une facture d’achat
Il est important de faire la distinction entre :
 L’achat des biens et services nécessaires à l'activité de production,
 L'achat d'immobilisations.

17
L'achat d'un bien/service entrant dans le processus d'exploitation est reporté comme une charge dans le
compte de résultat, car il est destiné à l'activité de production ou à être revendu.
L'achat (ou acquisition) d'immobilisations est en revanche enregistré dans l'actif du bilan.
Lorsque l'on enregistre un achat dans sa comptabilité, il est composé de 3 différents montants :
 Le prix hors taxe (HT),
 La taxe sur la valeur ajoutée (TVA), qui sera déductible s'il s'agit d'un achat professionnel,
 Le prix toutes taxes comprises (TTC), payé au fournisseur, qui reverse la TVA collectée au
Trésor Public.
En conséquence, si une entreprise n'est pas assujettie à la TVA, elle enregistre les prix d'achat TTC
dans les comptes 601 à 607.
A propos des réductions obtenues (Remises, Rabais, Ristournes et escomptes)
Les achats sont comptabilisés déduction faite des rabais et remises déduits du montant des factures.
Autrement dit : les déductions commerciales n'apparaissent pas dans les comptes.
Par contre, les escomptes obtenus (qui sont des réductions financières) doivent être enregistrés
au crédit du compte « 765 - Escomptes obtenus ».
A propos des frais accessoires d'achat (transports, commissions, assurances...)
Les frais accessoires d'achat payés à des tiers sont comptabilisés dans les comptes de charges
correspondant à leur nature ou dans les comptes d’achats concernés (601 à 607) lorsque ces charges
peuvent être affectées de façon certaine à telle ou telle catégorie de marchandises ou
d’approvisionnements.
Ils peuvent aussi être comptabilisés dans une subdivision du compte 608. Par exemple les frais de
transports de marchandises seront enregistrés dans le compte « 608724 - Frais de transport sur achats de
marchandises ».

18
 Les différents comptes d’Achat (Charge)

 Plan comptable général 2021 :
601 Achats stockés - Matières premières (et fournitures)

602 Achats stockés - Autres approvisionnements
6021 Achats stockés - Matières consommables
6022 Achats stockés - Fournitures consommables
6026 Achats stockés - Emballages
604 Achats d'études et prestations de services
605 Achats de matériel, équipements et travaux
606 Achats non stockés de matière et fournitures
6061 Achats non de fournitures non stockables (eau, énergie, …)
6063 Achats de fournitures d'entretien et de petit équipement
6064 Achats de fournitures administratives
6068 Achats d'autres matières et fournitures
607 Achats de marchandises
Tableau 2:Compte de charge (Plan comptable général 2020, 2020)
 Plan comptable Africain (OHADA PLAN COMPTABLE, 2020)
601 Achats de marchandises

602 Achats de matières premières et fournitures liées
603 Variations des stocks de biens achetés
604 Achats stockés de matières et fournitures consommables
605 Autres achats
608 Achats d’emballages
Tableau 3:compte de charge (OHADA PLAN COMPTABLE, 2020)
II.2.3 Gestion de vente
Une vente est l'opération par laquelle un bien ou un droit détenu par un vendeur est cédé à un
acheteur contre une somme d’argent (prix de vente). Lorsque la contrepartie n'est pas de l'argent, alors
il ne s'agit pas de vente mais d'un échange ou d'un troc[wikipedia 2020]
II.2.3.2 Processus de vente

Pour une vente, il faut avoir en données de base : les articles et les clients . Ci-dessous est décrit le
processus de commande de vente à connaître afin d'effectuer, dans l'ordre, une commande de vente.

19
Figure 8: Processus de vente (Présentation générale des ERP et leur architecture modulaire, 2020)
II.2.2.3 L'enregistrement comptable d'une facture de vente
Lorsqu’une société effectue une vente de produits finis, de marchandises ou même de prestations de
service, elle doit enregistrer au crédit un produit en utilisant un compte de la classe 7. Cet enregistrement
se fait à la date d’émission de la facture adressée au client.
✓ Les ventes de marchandises, sont des biens revendus en l’état, et doivent être enregistrées dans
les comptes ou sous-comptes du 707. Ventes de marchandises
✓ Les ventes de produits finis, sont des biens qui ont été transformés ou fabriqués par l’entreprise
elle-même, et doivent être enregistrées en 701. Ventes de produits finis
✓ Les prestations de services sont à enregistrer en 706. Prestations de services
Comment saisir ou enregistrer une facture de vente ?

La société A vend le 01/01/N au client B des marchandises pour 100 000HT ,TVA 20%.
Vente de marchandises le 01/01/N
Compte Intitulé Débit Crédit
411 Client B 120.000
44571 TVA collectée 20.000
707 Ventes de 100.000
marchandises

20
Tableau 4:Exemple d'écriture comptable d'une facture de vente

Le principe d’enregistrement est le même quel que soit la vente :
vous devez débiter le compte client si paiement à crédit sinon un compte de trésorerie
vous devez créditer le compte de TVA ainsi que le compte de produit (compte de la classe 7).
Le compte 411. Clients peut être remplacé par le compte 413. Clients – Effets à recevoir, si une lettre
de change a été établit pour régler cette facture.
L’enregistrement du paiement sera à enregistrer dans le journal de banque ou de caisse :

✓ Le compte de trésorerie (512 ou 530) sera à débiter
✓ Le compte client (411) sera à créditer
Pour rappel, un enregistrement est équilibré lorsque le total des débits est égal au total des crédits.
Les opérations liées aux ventes sont diverses. Cela dépend de la nature de la vente (biens, prestations de
services, immobilisations, emballages…), mais aussi si la vente comporte des rabais, remises ou
ristournes ou escomptes. Nous vous conseillons de vous reporter aux cours relatif à votre recherche.
 Les différents comptes de ventes (Produit)
 Plan comptable Français 2020 :
700 Ventes de produits fabriqués, prestations de services, marchandises

701 Ventes de produits finis
702 Ventes de produits intermédiaires
703 Ventes de produits résiduels
706 Prestations de services
707 Ventes de marchandises
Tableau 5:Compte produit (Plan comptable général 2020, 2020)
 Plan comptable Africain (OHADA) :
701 Ventes de marchandises

702 Ventes de produits finis
703 Ventes de produits intermédiaires
704 Ventes de produits résiduels
705 Travaux factures
706 Services vendus
707 Produits accessoires
Tableau 6:Compte produit (OHADA PLAN COMPTABLE, 2020)

21
II .2.4 Gestion des stocks

Une quantité de biens, accumulés dans l'attente d'une utilisation, en vue d'harmoniser un flux
d'entrée et un flux de sortie dont les rythmes sont différents. Tous les secteurs d'activités font appel à
des réserves plus au moins importants des stocks afin d'assurer la continuité de leur activité.
II.2.4.2 Processus stock

Lors d'une vente, d'un achat ou autre, il y a différents mouvements internes qui ont une influence
sur le stock :
✓ Les entrées diverses ;
✓ Les sorties diverses ;
✓ les changements d'emplacement (d'un article) ;
✓ les inventaires ;
✓ les contrôles qualité ;
✓ les transferts inter sites ;
✓ les changements de numéro de lot ou type de numérotation ;
✓ les déclarations de production.
Voici une description schématique qui modélise le processus stock au sein de l'ERP :
Figure 9: Processus de stock (Présentation générale des ERP et leur architecture modulaire, 2020)
b. Types de stocks
Dans le jargon de la profession, on distingue différents niveaux de stock :

22
 Stock minimum ou d'alerte (ou point de commande ou de couverture) c'est le niveau de stock
servant à déclencher un réapprovisionnement. C’est le niveau de stockage qui permet de
déterminer le point de commande pour les consommations régulières.
 Stock de sécurité ou de protection : le niveau de stock disponible pour répondre à des situations
imprévues telles que retard d'approvisionnement ou commandes exceptionnelles.
 Stock maximum : le niveau de stock qui correspond à la capacité physique maximale de
stockage. Au-dessus de ce seuil, le stockage devient onéreux.
 Stock tampon ou stock délai : permet une consommation normale pendant le délai de
réapprovisionnement.
 Stock mort ou dormant : correspond à des produits stockés sans sortie depuis un certain temps.
S'il s'agit de produits finis, on les appelle particulièrement rossignols, et ils sont soit soldés soit
détruits.
 Stock disponible : niveau de stocks qui correspond au stock existant additionné des entrées
prévisionnelles et diminué des sorties prévisionnelles.

23
CHAPITRE III : ÉTUDE DE L’EXISTANT

Pour la réussite du projet, il s’avère indispensable d’explorer les solutions existante. Ce chapitre
sera consacré à une étude de ces solutions.
III.1 QUELQUES SOLUTIONS EXISTANTES

On distingue deux types d'ERP : les ERP propriétaires, édités par des sociétés, ce qui implique
l'achat d'une licence, et les ERP open source qui sont libre.
III.1.1 Les ERP propriétaires
De nombreux ERP propriétaires existent sur le marché. Nous nous évoquerons ici quelques grands
éditeurs
 SAP
SAP est le leader mondial du monde des ERP. Ce progiciel a remporté rapidement un succès important
auprès des grandes entreprises en proposant un progiciel multilingue et multidevises. SAP s’intéresse
aussi au marché des PME, en pleine croissance en proposant sa suite BusinessOne, pour les entreprises
de 2 à 250 salariés. SAP est une application client-serveur. Ses modules couvrent l'ensemble des
fonctions de gestion de l'entreprise et chaque module couvre des besoins complets de gestion.
Il est doté de plusieurs sortes de modules : des modules orientés logistique (MM, PP, SD, QM, PM),
Finance (FI, CO, TR, IM) et ressources humaines (RH).
Ci-dessous le prix d’acquisition de la solution.
Tableau 7: Prix de licence d'ERP SAP (Prix, 2020)

24
 Sage 100 cloud
Les logiciels de SAGE visent en partculier les entreprises de moins de 500 salariés.
Cependant, en Novembre 2005, Sage rachète l'éditeur Adonix pour s'ouvrir le marché des PME/PMI
de 500 à 2 000 salariés. Les modules de SAGE sont les suivants :
✓ La logistique qui inclut la gestion des nomenclatures, des plans de production, l’analyse des
coûts de fabrication et la gestion des stocks.
✓ La comptabilité qui inclut la comptabilité générale et analytique, la gestion de trésorerie, la
communication bancaire.
✓ Les ressources humaines : gestion de la paie, des carrières, des compétences et de la
formation.
✓ Le marketing/CRM/ventes : campagnes de ventes/marketing, gestion des forces de vente,
module de e-commerce, configurateur de catalogues, gestion des paiements sécurisés
Ci-dessous le prix de la Solutions de gestion commerciale pour les PME - Gamme Sage 100
Tableau 8: Figure 10:Differenst prix de licence sage

III.1.1 Les ERP Open source
 Odoo
Le plus utilisé est l’ERP Odoo, anciennement connu sous le nom d’OpenERP, est un
éditeur de logiciels open source fondé en 2004 qui propose une suite complète de modules de gestion
d’entreprise entièrement intégrés mais la version open source est beaucoups limité.

25
Odoo est le programme de gestion d’entreprise le plus évolutif et le plus installé au monde grâce à ses
applications répondant à tous les besoins d’une entreprise, de la gestion de la relation client à la création
de sites web et d’e-commerce, en passant par la production, la gestion d’inventaire, la comptabilité etc…
 Dolibarr
Dolibarr est un ERP/CRM ou progiciel de gestion intégré et gestion de la relation client.Il fonctionne
avec des utilisateurs multiples, sans licence et gratuitement. Logiciel open-source, il dispose de
fonctionnalités natives que vous pouvez améliorer par l'ajout de modules additionnels ou leur création
si vous en avez les compétences.Dolibarr s'installe sur un serveur internet, chez vous ou hébergé, et son
installation estrelativement simple.Nativement, Dolibarr possède toutes les fonctionnalités nécessaires
à la gestion d'uneentreprise de commerce ou de production de biens et même plus..
III.2 CRITIQUE DE L’EXISTANT

III.2.1 Problématique
La solution deployée par le cabinet 2BN Internationnal pour ses partenaires jusqu’à ce jour est
la solution Sage 100 cloud pour certains mais la plupart utilise aucun ERP.Les données sont traitées
avec le logiciel Excel ce qui cause :
 Problème de fragmentation de l’information
 Problème de synchronisation et double saisie
III.2.2 Alternative
 Utiliser un ERP gratuit comme Odoo ou Dolibarr
 Acheter une licence ERP chez un éditeur
 Developper un ERP adapter aux TPE et PME locale en tenant compte du cadre fiscale
III.2.3 Solution retenue
Developper un ERP synthétisé et bien adapté au contexte africain basé sur d’autres solutions
existantes.
III.2.4 Justification
 Disposer d’une architecture technique flexible, paramétrable et réutilisable
 Pas de dépendance d’un éditeur pour la maintenance de l’outil
 Une solution à un coût réduit
 La politique du cabinet qui est celle de proposer des logiciels developpés en interne

26
Dans cette partie, nous présentons les travaux de conception et de réalisation relatifs à la
solution proposée. Cette partie s’articule autour de trois chapitres : la méthodologie et le choix des
méthodes de développement couplée à une étude préliminaire, la modélisation du problème proprement
dite, et on terminera cette partie par le chapitre sur la mise en œuvre de la solution.

27
CHAPITRE III : CHOIX DE LA METHODE D’ANALYSE ET DE

CONCEPTION
Dans ce chapitre nous allons faire une étude préliminaire au cours de laquelle nous ferons un
tour d’horizons des méthodes d’analyse et de conception les plus connues ; ceci étant nous préciserons
parmi elles la démarche que nous allons adopter. Ensuite nous effectuerons l’analyse statique et
dynamique proprement dite de notre système, que nous compléterons par son architecture.
La plupart des échecs de développement de logiciels sont dus à la recherche précipitée de la solution
et le non adéquation de solution logiciel et des besoins utilisateur. Tout ceci est dû au manque de suivi
d’une méthode d’analyse et de conception. C’est dans cette logique que nous avons trouvé utile de suivre
une méthode de conception afin d’optimiser la réussite de notre projet
III.1 LANGAGE DE MODELISATION OBJET : UML

III.1.1 Généralités
La description de la programmation par objets a fait ressortir l’étendue du travail conceptuel nécessaire
: définition des classes, de leurs relations, des attributs, des méthodes et des interfaces. Pour développer
une application, il ne convient pas de se lancer tête baissée dans l’écriture du code : il faut d’abord
organiser ses idées, les documenter, puis organiser la réalisation en définissant les modules et étapes de
la réalisation. C’est cette démarche antérieure à l’écriture que l’on appelle modélisation ; son produit est
un modèle.
III.1.2 Présentation du langage UML
UML (Unified Modeling Language) est un langage de modélisation graphique et textuelle. Il

est destiné à comprendre, à décrire les besoins, à spécifier, à concevoir des solutions et à communiquer
des points de vue. UML unifie à la fois les notations et les concepts orientés objet. Il ne s’agit pas d’une
simple notation graphique, car les concepts transmis par un diagramme ont une sémantique précise et
sont porteurs de sens au même titre que les mots d’un langage. Par ailleurs, UML modélise le système
suivant deux modes de représentation : l’un concerne la structure du système pris « au repos », l’autre
concerne sa dynamique de fonctionnement. Les deux représentations sont nécessaires et
complémentaires pour schématiser la façon dont est composé le système et comment ses composantes
fonctionnent.
UML depuis la version 2.0 comporte treize types de diagrammes représentant autant de vues distinctes
pour représenter des concepts particuliers du système d’information.
Ils se répartissent en deux grands groupes :

28
 Diagrammes structurels ou diagrammes statiques (UML structure)

 Diagramme de classes : il affiche la structure du système, sous-système ou d'un composant
conçu comme classes et interfaces liées, avec leurs caractéristiques, contraintes et relations
- associations, généralisations, dépendances, etc.
 Diagramme d’objets : il montre les instances des éléments structurels et leurs liens à
l’exécution.
 Diagramme de packages : il montre l’organisation logique du modèle et les relations entre
packages.
 Diagramme de structure composite : il montre l’organisation interne d’un élément
statique complexe.
 Diagramme de composants : il montre des structures complexes, avec leurs interfaces
fournies et requises.
 Diagramme de déploiement : il montre le déploiement physique des « artefacts » sur les
ressources matérielles.
 Diagrammes de profile : il permet de définir les stéréotypes personnalisés, étiquètes
valeurs, et les contraintes en tant que mécanisme d'extension légère à la norme UML
 Diagrammes comportementaux ou diagrammes dynamiques (UML Behavior) :
 Diagramme de cas d’utilisation : il montre les interactions fonctionnelles entre les acteurs
et le système à l’étude.
 Diagramme de vue d’ensemble des interactions : il fusionne les diagrammes d’activité et
de séquence pour combiner des fragments d’interaction avec des décisions et des flots.
 Diagramme de séquence : il montre la séquence verticale des messages passés entre objets
au sein d’une interaction.
 Diagramme de communication : il montre la communication entre objets dans le plan au
sein d’une interaction.
 Diagramme de temps : il fusionne les diagrammes d’états et de séquence pour montrer
l’évolution de l’état d’un objet au cours du temps.
 Diagramme d’activité : il montre l’enchaînement des actions et décisions au sein d’une
activité.
 Diagramme d’états-transition : il montre les différents états et transitions possibles des
objets d’une classe.
Ces diagrammes, d’une utilité variable selon les cas, ne sont pas nécessairement tous produits à
l’occasion d’une modélisation. Les plus utiles pour la maîtrise d’ouvrage sont les diagrammes de cas
d’utilisation, d’activités, de classes, de séquence et d’états transitions. Les diagrammes de composants,
de déploiement et de communication sont surtout pour la maitrise d’œuvre à qui ils permettent de
formaliser les contraintes de la réalisation et la solution technique

29
III.2 LES PROCESSUS DE DEVELOPPEMENT

UML n’étant qu’un langage, afin d’avoir une méthode qui nous permettra de passer des
besoins au code, il nous faut un processus de développement. Un processus de développement
est une séquence d’étapes, partiellement ordonnées, qui concourent à l’obtention d’un système
logiciel ou à l’évolution d’un système existant.
Son objectif est de produire des logiciels de qualité qui répondent aux besoins de leurs
utilisateurs dans des temps et des coûts prévisibles. Plus simplement, un processus doit
permettre de répondre à la question fondamentale « Qui fait quoi et quand ? »
III.2.1 Le processus en cascade
Le modèle en cascade est hérité de l'industrie du BTP. Ce modèle repose sur les hypothèses
suivantes :
 On ne peut pas construire la toiture avant les fondations ;
 Les conséquences d'une modification en amont du cycle ont un impact majeur sur les
coûts en aval.
Les phases traditionnelles de développement sont effectuées simplement les unes après les
autres, avec un retour sur les précédentes, voire au tout début du cycle. Le processus de
développement utilisant un cycle en cascade exécute des phases qui ont pour caractéristiques :
 Produire des livrables définis au préalable ;
 Se terminer à une date précise ;
 Se terminer lorsque les livrables sont jugés satisfaisants lors d'une étape de validation-
vérification
III.2.2 Le processus en V
Le modèle du cycle en V a été imaginé pour pallier le problème de réactivité du modèle en
cascade. Ce modèle est une amélioration du modèle en cascade qui permet en cas d'anomalie,
de limiter un retour aux étapes précédentes. Les phases de la partie montante doivent renvoyer
de l'information sur les phases vis-à-vis lorsque des défauts sont détectés afin d'améliorer le
logiciel.
De plus le cycle en V met en évidence la nécessité d'anticiper et de préparer dans les étapes
descendantes les « attendus » des futures étapes montantes : ainsi les attendus des tests de
validation sont définis lors des spécifications, les attendus des tests unitaires sont définis lors
de la conception, etc.
Le cycle en V est devenu un standard de l'industrie du développement de logiciel et de la gestion
de projet depuis les années 1980.

30
III.2.3 Le processus en spirale

Le développement reprend les différentes étapes du cycle en V. Par l'implémentation de
versions successives, le cycle recommence en proposant un produit de plus en plus complet et
robuste.
Le cycle en spirale met cependant plus l'accent sur la gestion des risques que le cycle en V. En
effet, le début de chaque itération comprend une phase d'analyse des risques. Celle-ci est rendue
nécessaire par le fait que, lors d'un développement cyclique, il y a plus de risques de défaire, au
cours de l'itération, ce qui a été fait au cours de l'itération précédente.
III.2.4 Le processus semi-itératif
Le processus semi-itératif a pour origine les travaux de James Martin publiés à partir de 1989
dans diverses revues nord-américaines. Ce cycle de développement fut totalement formalisé en
1991 dans le livre RAD (Développement rapide d'applications). À partir de 1994, des travaux
complémentaires apportèrent des spécialisations aux techniques basiques initiales. Dans le
cycle semi-itératif, les deux premières phases classiques consistent en l’expression des besoins
et la conception de la solution. C’est lors de la troisième et dernière grande phase, la
construction du produit que la notion d’itérations courtes intervient. C'est vers 2001 avec
l'apparition de plusieurs méthodes dont Crystal, Scrum ou l'eXtreme Programming (XP) que le
cycle semi-itératif fut généralisé.
III.2.5 Le processus unifié
Le Processus Unifié est un patron de processus pouvant être adapté à une large classe de
systèmes logiciels, à différents domaines d'application, à différents types d'entreprises, à
différents niveaux de compétences et à différentes tailles d'entreprise. Les processus unifiés
sont construits sur UML et sont basés sur le principe d’un cycle de développement itératif et
incrémental, centré sur l’architecture, conduit par les cas d’utilisation et piloté par les risques.
 Itératif et incrémental : le projet est découpé en itérations de courte durée (environ 1
mois) qui aident à mieux suivre l’avancement global. À la fin de chaque itération, une
partie exécutable du système final est produite, de façon incrémentale.
 Centré sur l’architecture : tout système complexe doit être décomposé en parties
modulaires afin de garantir une maintenance et une évolution facilitées. Cette
architecture (fonctionnelle, logique, matérielle, etc.) doit être modélisée en UML et pas
seulement documentée en texte.

31
 Conduit par les cas d’utilisation : le projet est mené en tenant compte des besoins et des
exigences des utilisateurs. Les cas d’utilisation du futur système sont identifiés, décrits
avec précision et priorisés
 Piloté par les risques : les risques majeurs du projet doivent être non seulement identifiés
au plus tôt, mais surtout levés le plus rapidement possible. Les mesures à prendre dans
ce cadre déterminent l’ordre desitérations.
Il existe plusieurs processus unifiés à savoir : 2TUP, RUP, XUP, etc.
III.3 LES METHODES D’ANALYSE ET DE CONCEPTION

Une méthode d'informatisation est composée :
 De modèles : ce sont des spécimens de résultats intermédiaires pouvant être produit par une
étape du processus ;
 De langages : pour élaborer les spécifications, et faciliter leur communication ;
 D’une démarche : processus pour effectuer les travaux préconisés, étape par étape.
III.3.1 Méthodes cartésiennes (fonctionnelles)

Avec les méthodes cartésiennes, le système étudié est vu comme un ensemble de fonctions. Le
processus de conception est vu comme un développement linéaire. Il y a décomposition systématique
des fonctions principales en sous fonctions, elles-mêmes décomposées en sous fonctions jusqu'à un
niveau considéré comme élémentaire. En insistant exclusivement sur les fonctions ces méthodes
finissent par occulter la prise en compte des données dans le système. SADT (Structured-Analysis-
Design-Technique) est un exemple des méthodes cartésiennes.
III.3.2 Méthodes systémiques

L’un des objectifs des méthodes systémiques est de corriger les failles des méthodes
cartésiennes en incorporant les données. Elles définissent différents niveaux de préoccupation ou
d'abstraction et proposent de nombreux modèles complémentaires. Les méthodes systémiques sont
souvent spécialisées pour la conception d'un certain type de systèmes tels que les systèmes de conception
de bases de données relationnelles (MERISE, AXIAL...). Toutefois, ces méthodes juxtaposent les
données et les traitements sans véritablement les intégrer.
III.3.3 Méthodes orientée-objet

Les méthodes objets viennent intégrer véritablement les données aux fonctions dans le concept
objet. Pour un objet donné, les données et les fonctions sont traitées ensemble. Les méthodes objets
consistent à créer une représentation informatique des éléments du monde réel auxquels on s'intéresse,
sans se préoccuper de l'implémentation, ce qui signifie indépendamment d'un langage de

32
programmation. Il s'agit donc de déterminer les objets présents et d'isoler leurs données et les fonctions
qui les utilisent. Pour cela des méthodes ont été mises au point. Entre 1970 et 1990, de nombreux
analystes ont mis au point des approches orientées objets, si bien qu'en 1994 il existait plus de 50
méthodes objets. Toutefois seules trois (3) méthodes ont véritablement émergé :
 La méthode OMT de Rumbaugh ;
 La méthode BOOCH'93 de Booch ;
 La méthode OOSE de Jacobson.
Les promoteurs de ces trois (3) méthodes se sont fixées pour objectif de créer une méthode qui fasse la
synthèse des éléments indispensables pour faire du développement objet. Sur le plan du langage, ils ont
créé le langage UML pour la modélisation orientée objet. Pour les processus, le consensus se fait sur les
processus unifiés qui sont des méta-processus à partir desquels le
chef du projet doit décrire son véritable processus, en prenant en compte les spécificités du
problème posé, les outils et les personnes impliquées. Ce processus réel construit sur le modèle
qu’est le processus unifié, s’exprime en termes d’itérations.
III.3.4 Les méthodes Agiles

Les méthodes de développement dites « méthodes agiles » (en anglais Agile Modeling) visent à
réduire le cycle de vie du logiciel (donc accélérer son développement) en développant une version
minimale, puis en intégrant les fonctionnalités par un processus itératif basé sur une écoute cliente et
des tests tout au long du cycle de développement. L'origine des méthodes agiles est liée à l'instabilité de
l'environnement technologique et au fait que le client est souvent dans l'incapacité de définir ses besoins
de manière exhaustive dès le début du projet. Le terme « agile » fait ainsi référence à la capacité
d'adaptation aux changements de contexte et aux modifications de spécifications intervenant pendant le
processus de développement. En 2001, 17 personnes mirent ainsi au point le manifeste agile dont la
traduction est la suivante : Individus et interactions plutôt que processus et outils ;
 Développement logiciel plutôt que documentation exhaustive ;
 Collaboration avec le client plutôt que négociation contractuelle ;
 Ouverture au changement plutôt que suivi d'un plan rigide.
Grâce aux méthodes agiles, le client est un pilote à part entière de son projet et obtient très vite une
première mise en production de son logiciel. Ainsi, il est possible d'associer les utilisateurs dès le début
du projet.
Plusieurs méthodes agiles sont aujourd’hui recensées : Crystal Clear, Scrum, Extreme Programming
(XP), Dynamic Software Development Method (DSDM).

33
III.3.4.1 XP : eXtreme Programming

modèle XP date de 1996 et s’adapte aux petites équipes travaillant dans un contexte changeant.
Le but principal est de réduire les coûts liés aux changements. eXtreme Programming fait en sorte que
le projet soit plus flexible et ouvert au changement.
Figure 10: Le cycle de l'Extreme Programming (Le cycle de l'Extreme Programming., 13 novembre
2013)
III.3.4.2 Scrum
Scrum est conçue pour améliorer de manière significative la productivité des équipes de développement.
C’est une méthode qui s’adapte à tout type de contexte et de projet dès lors qu’un groupe de personnes
cherche à atteindre un but commun.
Figure 11: Scrum (SUBRA, septembre 2019)

34
III.3.5 Les méthodes formelles

Par « formel », il faut comprendre l'établissement de règles strictes afin de structurer la
«forme » , le tout au sens mathématique. En effet, la rigueur de cette discipline correspond bien à cette
idée de règles. Une utilisation de ces concepts est permise grâce à un langage formel, offrant une syntaxe
ou des notations (ensemblistes, logiques, etc.…) à un énoncé. Le langage d'une méthode formelle forme
sa sémantique. Chaque énoncé et/ou expression possède ainsi une signification mathématique précise,
qui n'a d'autre sens que celui décrit par la syntaxe du texte.
En l'occurrence, le but d'une méthode formelle est de proposer un processus de production, ainsi que
des outils permettant d'offrir une certaine « abstraction » (fournie par la rigueur mathématique
intrinsèque à chaque méthodologie) au logiciel à développer.

35
III.4 CHOIX D’UNE METHODE : UML COUPLE A UN PROCESSUS

HYBRIDE
Le choix de notre démarche se fera en prenant en compte des spécifications essentielles de la solution à
concevoir et des caractéristiques des principales méthodes de conception. Nous synthétisons dans ce
tableau les critères retenus pour évaluer ces méthodes :
Critère/Méthode Méthode Méthode Méthode Méthode Méthode

Cartésienne systémique Objet Agile (XP) formelle
Itératif NON NON OUI OUI NON
Prise en charge de NON NON OUI NON NON
projets d’envergure
Incrémental NON NON OUI OUI NON
Axé sur la NON NON OUI NON NON
documentation
Gestion des risques NON NON OUI OUI
Simplicité de mise en NON NON NON OUI NON
œuvre
Langage de NON OUI OUI NON OUI
modélisation
Dialogue entre NON NON NON OUI NON
intervenants
Piloté par les cas NON NON OUI OUI NON
d’utilisation
Axé sur le NON NON NON OUI NON
développement
Tableau 9: Comparaison de différentes méthodes
Pour des raisons d'efficacité, de rapidité et d'analyse complète, et compte tenu des critères retenus,
nous opterons pour un processus situé à mi-chemin entre UP (Unified Process) et XP (eXtreme
Programming), une approche minimaliste centrée sur le code. Le Processus Unifié s’est imposé comme
processus de développement itératif pour la construction des systèmes orientés objet. Ce processus est
très souple et très ouvert, il incite à inclure des pratiques judicieuses issues d’autres méthodes itératives,
telles qu’eXtreme Programming. Le développement itératif et incrémental offre les avantages suivants:
 Diminution des échecs, amélioration de la productivité et de la qualité.
 Gestion précoce des risques élevés (risques techniques) grâce aux cas d’utilisation.
 Feed-back, implication des utilisateurs et adaptation précoces. Ces points permettent d’obtenir
un système élaboré qui répond plus étroitement aux besoins réels des parties prenantes.

36
 Complexité gérée. L’équipe n’est plus épuisée par l’analyse ou la complexité des tâches.
 Possibilité d’exploiter méthodiquement les leçons tirées d’une itération. Cela permet
d’améliorer le processus de développement lui-même, une itération après l’autre.
III.4.1 Le processus utilisé (Un Processus Hybride)

Dans le but de disposer d’un processus que nous couplerons avec UML pour avoir une méthode, nous
nous sommes posé la question suivante : « comment passer des besoins exprimés au code de
l’application ? » Autrement dit : « nous avons une bonne idée de ce que notre système doit faire, des
fonctionnalités attendues par les futurs utilisateurs. Comment obtenir le plus efficacement possible un
code informatique opérationnel, complet, et qui réponde parfaitement au besoin exprimés ? ».
La réponse à la problématique précédente a donné naissance à un processus « hybride ».
III.4.2 Description du processus utilisé
Besoins Code
utilisateurs
Figure 12:schémas description du processus utilisé

A la question de savoir « comment passer des besoins utilisateurs au code source ?», nous allons suivre
la démarche comme la montre la figure ci-dessous.
Figure 13: Chaîne complète de la démarche de modélisation du besoin jusqu’au code

37
Dans un premier temps, les besoins vont être modélisés au moyen des cas d’utilisation UML.
Ils seront représentés de façon plus concrète par une maquette d’IHM (Interface Homme Machine)
destinée à faire réagir les futurs utilisateurs. Dans cette première phase, nous allons affecter un degré
d’importance et un coefficient de risque à chacun des cas d’utilisation afin de définir l’ordre des
incréments à réaliser. De ce fait, seront développées et livrées en premier lieu, les fonctionnalités des
cas d’utilisation les plus centraux.
Dans un second temps, nous expliciterons, sous forme textuelle puis sous forme graphique au moyen
des diagrammes de séquence système, les interactions entre les acteurs et le système. L’objectif visé
dans cette étape est d’aider les utilisateurs à formuler et formaliser leurs besoins.
Parallèlement, nous réaliserons les diagrammes de classes participantes qui décriront, cas d’utilisation
par cas d’utilisation, les 3 principales classes d’analyse et leurs relations. Les diagrammes de classes
participantes sont particulièrement importants car ils feront la jonction entre les cas d’utilisation, la
maquette et les diagrammes de conception logicielle (diagrammes d’interaction).
Puis il faut détailler l’exploitation de la maquette. Elle va nous permettre de réaliser des diagrammes
dynamiques représentant de manière formelle l’ensemble des chemins possibles entre les principaux
écrans proposés à l’utilisateur. Ces diagrammes, qui mettent en jeu les classes participantes de type «
dialogues » et « contrôles », s’appellent des diagrammes de navigation. Dans notre projet, nous
utiliserons des diagrammes d’activité.
Troisièmement, à partir des diagrammes de séquence système et des diagrammes de classes
participantes, chaque diagramme d’interaction (séquence ou communication) va représenter un
ensemble d’objets de classes différentes collaborant dans le cadre d’un scénario d’exécution du système.
Finalement, viendra l’étape de production du diagramme de classes de conception. Les diagrammes de
classes de conception représentent bien la structure statique du code, par le biais des attributs et des
relations entre classes. Ils contiennent également les opérations (aussi appelées méthodes) qui décrivent
les responsabilités dynamiques des classes logicielles. Nous devons ainsi répartir tout le comportement
du système entre les classes de conception, et décrire les interactions induites.
À l’issue de ce chapitre nous en ressortons plus outiller à pouvoir débuter notre conception car nous
savons dès à présent le processus à suivre pour pouvoir développer notre solution. Le chapitre suivant
sera donc le lieu pour nous de nous appesantir sur l’analyse et la conception de notre système.

38
CHAPITRE IV : ANALYSE ET CONCEPTION DU SYSTEME

Dans ce chapitre nous allons présenter les phases d’analyse et de conception de la solution
informatique à mettre en place. Premièrement, nous allons commencer par présenter
l’analyse du besoin puis par la suite la conception du système à mettre en place. Il s’agira ici, à la
rescousse de la méthode que nous venons de présenter dans le chapitre précédent,
d’analyser le problème posé afin de concevoir une solution informatique répondant aux besoins
exprimés
IV.1 ANALYSE DU BESOIN

Le succès de tout type de projet informatique repose sur une bonne compréhension des besoins
exprimés par les différents acteurs et futurs utilisateurs de la solution à mettre en place. Aussi
conviendrait-il de mener une réflexion futuriste afin d’anticiper les éventuels besoins qui pourrait
apparaître avec le temps.
En effet, grâce aux différentes interventions chez les clients ainsi que nos multiples entretiens au près
des techniciens et experts comptables du cabinet ont permis d’appréhender clairement les besoins réels
des entreprises vis-à-vis des différents ERP que ces derniers utilisent. Cette collaboration quotidienne
avec les clients, les techniciens et experts du cabinet nous ont permis de mieux cerner les besoins de
chaque utilisateur et de savoir exactement ceux à quoi ces derniers s’attendent.
Dans ce paragraphe, nous présenterons les besoins fonctionnels et techniques ainsi que les acteurs du
système à concevoir
IV.1.1 Les besoins fonctionnels
Le projet consiste à développer le module Négoce et Facturation d’un ERP dénommé FacteurX.
Les fonctionnalités que propose ce module s’étendent du devis à la facturation en passant par
l’approvisionnement, les stocks, la génération des écritures comptables et le pilotage, tout en
garantissant un accès mobile aux données
Objectif Fonctionnalité
Gestion des structures de base ✓ Gerer les tiers(client, fournisseurs)
✓ Gérer les familles d’articles
✓ Gérer les articles
✓ Gérer le plan comptable
✓ Gérer les taxes
✓ Gérer les journaux
✓ Gérer les Entrepôts
✓ Gérer les contacts
✓ Gérer les unités

39
Gestion des ventes ✓ Gérer les documents de vente

✓ Gérer les échéanciers de paiement
✓ Gérer les règlement de factures
Gestion des Achats et stocks ✓ Gérer les documents d’achat
✓ Gérer les règlement de factures fournisseurs
✓ Consulter le stock
✓ Gérer les bons d’entrée
✓ Gérer les bons de sortie
✓ Gérer les transfert
✓ Gérer les inventaires
Les rapports ✓ Imprimer les rapports (devis, bon de commande,
bon de livraison, facture, bon de retour, facture
d’avoir)
✓ Imprimer listes des Articles
Statistiques et tableau de bord ✓ Consulter les produits du stock
✓ Chiffre d’affaire mensuel
✓ Chiffre d’affaire annuel
✓ Lister les ventes par client
✓ Lister les ventes par article
✓ Chiffre d’affaire réalisé par client, par article sur
une période donnée
✓ Visualiser les états prévisionnels / réalisés sur les
ventes
✓ Visualiser les performances des collaborateurs
Inventaire physique des produits
Les services de messageries ✓ Envoi des documents de vente et achat par email
Administration ✓ Gérer les utilisateurs
✓ Gérer les groupes
✓ Sauvegarder la base de données
Tableau 10:: Les fonctionnalités du module
IV.1.2 Les besoins techniques
La capture des besoins techniques couvre, par complémentarité avec celle des besoins
fonctionnels, toutes les contraintes qui ne traitent ni de la description du métier des utilisateurs, ni de la
description applicative.

40
En tenant compte des besoins et fonctionnalités précités, la finalité est de concevoir et de mettre en
œuvre un système de gestion commerciale au sein d’une entreprise. Pour cela, l’application doit
répondre aux besoins techniques suivants :
 L’application doit être performante, et simple d’utilisation ;
 La solution doit inclure une plateforme accessible à travers des smartphones (Application
mobile) ;
 Le système doit avoir un temps de réponse relativement court ;
 Le respect des principes de la norme Interface Homme Machine (IHM), tels que l’ergonomie,
la convivialité, la performance et la fiabilité doit être prise en compte ;
 L’application doit assurer l’intégrité des informations enregistrées ;
 Les mots de passe des utilisateurs doivent être cryptés ;
 Les langages de programmations sont WinDev (pour la plateforme desktop) et WebDev (pour
le web) et WinDev Mobile (pour le mobile) ;
 Le SGBD à utiliser pour le stockage des données est MySQL et Hyper file ;
 La solution doit être évolutive et paramétrable.

41
IV.2 CONCEPTION DU SYSTEME

En Génie Logiciel, la conception constitue une phase fondamentale dans le cycle de vie d'un
logiciel. La réussite de ce dernier dépend beaucoup de cette étape. Dans le cadre de notre projet, nous
nous sommes basés sur deux conceptions : la conception détaillée et la conception architecturale. Dans
cette partie, nous présenterons la conception dans sa spécification fonctionnelle, puis détaillé
l’architecture technique globale et la spécification fonctionnelle du futur système. Ensuite viendra la
réalisation des cas d’utilisations et enfin la conception architecturale du futur système.
IV.2.1 Spécification fonctionnelle

Acteurs et cas d’utilisation sont les concepts UML fondamentaux pour la spécification des
exigences. À partir de l’expression initiale des besoins, nous avons identifié les acteurs et les cas
d’utilisation du système à mettre en place. Nous avons structuré, relié et classé ces cas d’utilisation ainsi
que les représentations graphiques UML associées.
IV.2.1.1 Identification des acteurs
Il s’agit dans cette partie de bien reconnaître les acteurs (Homme, Machine, Système) qui vont
interagir avec notre système. Ces acteurs ne font pas partie de la solution à mettre en place, mais participe
au fonctionnement général de la solution par une interaction. Le tableau ci-dessous illustre les différents
acteurs ainsi que le rôle de chacun.
Acteurs Description
Le commercial Peut créer un client comme il peut le mettre à
jour, il a le droit de visualiser l’ensemble des
clients de la société.et leur situation. D’autre part,
le commercial peut créer un devis, effectué les
commandes pour réaliser une opération de vente,
il peut également vérifier la disponibilité de
l’article en stock
Le responsable de ventes Peut effectuer les mêmes tâches que le
commercial et assure le suivi des ventes
Le responsable commercial Assure le suivi des achats et ventes faites par les
commerciaux. Il peut aussi effectuer les mêmes
opérations que le commercial. De plus, il valide
l’ensemble des bons de commandes et il gère
l’ensemble des articles.

42
Directeur Supervise l’ensemble des activités et il possède

les mêmes droits d’utilisation comme tous les
acteurs du système.
Le magasinier Peut créer les articles comme il peut le mettre à
jour. Valide les bons de livraison, et les bons de
réception
Le responsable des achats Peut créer un fournisseur comme il peut le mettre
à jour, il a le droit de visualiser l’ensemble des
fournisseurs de la société.et leur situation.
D’autre part, il peut créer un devis, effectué les
commandes pour réaliser une opération d’achat
de marchandise, il peut également vérifier la
disponibilité de l’article en stock
Administrateur Il administre et maintient le système. Il a tous les
droits pour gérer les données du système.
Comptable Il peut enregistrer les règlement de facture client
et des factures d’achat, envoie les lettres de
relance
Tableau 11 :Les différents acteurs ainsi que leur rôle

43
IV.2.1.2 Le diagramme de contexte statique

FacteurX est un système fondamentalement multi-utilisateur : à tout instant, il peut avoir
plusieurs acteurs connectés au système, ce qui explique les multiplicités des acteurs dans le diagramme
de contexte statique ci-après :
Magazinier
0,n
0,n
0,n
Administrateur
Commercial
0,n
0,n
FacteurX
Responsable
Comptable
commercial
0,n 0,n
0,n
Responsable de vente
Directeur
Responsable Achat
Figure 14: Diagramme de contexte statique

IV.2.1.3 Identification des cas d’utilisation
cas d’utilisation (use case) représente un ensemble de séquences d’actions qui sont réalisées par
le système et qui produisent un résultat observable, intéressant pour un acteur particulier. Il exprime les
interactions acteurs/système et apporte une valeur ajoutée considérable à l’acteur concerné.
Le fait d'avoir identifié tous les acteurs (ainsi que leur fonctions) qui vont interagir avec le système
simplifie grandement l’identification des cas d’utilisation ; car, il nous suffit alors d'analyser pour chaque
acteur les fonctionnalités qui lui seront utiles au regard de l’utilisation du système, et de s’assurer que
chacun dispose desdites fonctionnalités. Ci-dessous les différents cas d’utilisation du système à mettre
en place :
✓ Enregistrer un tiers (client, fournisseur)
✓ Gérer une unité
✓ Gérer le Plan comptable
✓ Gérer un taux de taxe

44
✓ Gérer les journaux

✓ Gérer un entrepôt
✓ Gérer une famille
✓ Gérer un article
✓ Enregistrer un document de vente(devis, bon de commande, bon de livraison, facture, bon de
retour, acture de retour)
✓ Enregistrer un document d’achat (devis, bon de commande, bon de reception, facture, bon de
retour, fsacture d’avoir)
✓ Envoyer un document
✓ Modifier un document
✓ Supprimer un document
✓ Lister les documentss
✓ Changer statut d’un document
✓ Rechercher un document
✓ Transformer un document
✓ Filtrer un document
✓ Enregistrer document de stock(bon d’entrée, bon de sortie)
✓ Enregistrer un inventaire
✓ Gérer un règlement de facture(Client, fournisseur)
✓ Gérer un échéancier
✓ Gérer un utilisateur
✓ Gérer un groupe
✓ S’authentifier
✓ Sauvegarder les données

45
IV.2.1.4 Organisation des acteurs et des cas d’utilisations en packages

Pour améliorer notre modélisation, nous allons regrouper nos cas d’utilisation en ensembles
fonctionnels cohérents. Pour ce faire, nous utilisons le concept général d’UML : le package. C’est un
mécanisme général de regroupement d’éléments en UML, qui peut être utilisé par exemple pour
regrouper des éléments tels que les cas d’utilisations, les classes, acteurs …
Le tableau ci-dessous présente l’organisation de nos cas d’utilisation en packages.
Cas d’utilisation Acteurs Package

Enregistrer un tiers ( client, fournisseur)
Gérer une unité
Gérer le Plan comptable
Gérer un taux de taxe

Commercial,
Gérer les journaux
Responsable de vente, Gestion de
Gérer un entrepôt Responsable structures de
Gérer une famille (Enregistrer, Modifier, commercial, Directeur, base
Supprimer, imprimer) Administrateur
Gérer un article (Enregistrer, Modifier,Supprimer,

Imprimer)
Enregistrer un document de vente (devis, bon de

commande, bon de livraison, facture, bon de retour,
facture de retour)
Envoyer un document
Modifier un document
Supprimer un document
Lister les document

Commercial,
Changer statut d’un document Responsable de vente, Gestion de vente
Rechercher un document Responsable

46
Transformer un document commercial, Directeur,

Administrateur
Filtrer un document
Gérer un échéancier
Gérer un règlement de facture
envoyer une lettre de relance
Enregistrer un document d’achat (demande de prix,

bon de commande, bon de reception, facture, bon
de retour, facture de retour)
Modifier un document d’achat
Supprimer un document d’achat
Lister les document d’achat
Changer statut d’un document d’achat

Responsable d’achat, Gestion d’achat
Rechercher un document d’achat Responsable
Transformer un document d’achat commercial, Directeur,

Administrateur
Filtrer un document d’achat
Gérer un règlement de facture fournisseur
envoyer une lettre de relance
Enregistrer document de stock(bon d’entrée, bon

de sortie)
Lister les documents de stock Responsable d’achat,

Responsable Gestion de Stock
Modifier un document de stock
commercial, Directeur,
Rechercher un document de stock Administrateur
Enregistrer un inventaire
Gérer un utilisateur
Gérer un groupe

47
S’authentifier Administrateur, Administration

Directeur
Sauvegarder les données
Tableau 12:Organisation de cas d’utilisation en packages

IV.2.1.5 Relations entre les cas d’utilisation
Pour affiner le diagramme de cas d’utilisation, UML définit trois types de relations standardisées
entre cas d’utilisation :
 La relation d’inclusion, formalisée par le mot-clé « include » : le cas d’utilisation de base en
incorpore explicitement un autre, de façon obligatoire ;
 La relation d’extension, formalisée par le mot-clé « extend » : le cas d’utilisation de base en
incorpore implicitement un autre, de façon optionnelle ;
 La relation de généralisation : les cas d’utilisation descendants héritent de la description de leur
parent commun ; chacun d’entre eux peut néanmoins comprendre des interactions spécifiques
supplémentaires.
Nous avons utilisé ces trois types de relations dans la représentation schématique de nos cas d’utilisation.
Ci-dessous le diagramme de cas d’utilisation système :
 Gestion d’administration
Gestion d'administration
Sauvegarder les <<include>>

données
Ajouter un utilisateur
Gérer un utilisateur
Administrateur
Modifier un utilisateur
<<include>>
S'authentifier
Gérer un groupe <<include>>
Supprimer un
utilisateur
Ajouter un groupe Supprimer un groupe

Modifier un groupe
Directeur
Figure 15:Cas d'utilisation gestion d'administration

48
 Gestion des structures de base
Structure de base
Enregistré un
prospect
Enregistrer un tiers
Enregistré
un client
Enregistré
fournisseur <<include>>
Modifier
Commercial
Consulter tiers <<extend>> Supprimer <<include>>
<<extend>>
Gérer le plan <<extend>>

Enregistré un
Gerer le code comptable contact
journaux Gérer le taux
<<include>>
de taxe
Gerer une unité
<<include>> <<include>>
<<include>>
Responsable commercial <<include>> <<include>>
<<include>>
Enregistrer une
Enregistrer Modifier une
famille
un article famille
Consulter une <<extend>>

famille
<<extend>> Supprimer
Enregistrer un une famille
entrepôt
Administrateur Consulter un
article
<<extend>>
Consulter un <<extend>>
entrepôt Modifier un
article
<<extend>>
<<extend>> Supprimer
Supprimer un un article
<<include>>
entrepôt <<include>>
S'authentifier
Modifier un <<include>>
<<include>>
Directeur entrepôt
Figure 16:Cas d'utilisation gestion des structures de base

49
 Gestion de vente
Gestion de vente
Ajouter un client
Enregistrer un
devis
<<extend>>
Enregistrer un
Enregistrer un bon de
Commercial document de vente commande
<<include>>
Enregistrer bon de
retour client
Enregistrer une
facture
livraison
Responsable vente <<extend>>

Enregistrer une factures
d’Avoir
S'authentifier
Responsable
commercial <<include>>
Lister document vente <<extend>> Envoyer
Consulter les statistiques

des ventes <<extend>> <<extend>> <<include>>
Comptable <<extend>>
Rechercher
Changer <<extend>>
statut <<extend>> Archiver
Transformer
Gérer un règlement
<<include>>
Modifier
Filtrer
Administrateur
Directeur
Figure 17:Cas d'utilisation gestion de vente

50
 Gestion de document d’achat
Gestion d'achats
Ajouter un
fournisseur
Enregistrer une
demande de prix
<<extend>>
Enregistrer un bon
Responsable d'achat Enregistrer un
de commande
document d'achat
<<include>>
retour fournisseur
réception
Enregistrer une
facture d'achat
Enregistré une factures

<<extend>>
Responsable d’Avoir
commercial
S'authentifier
<<include>>
Lister les documents d' <<include>>
Comptable achat <<extend>>
Envoyer
Consulter les statistiques d'
achat <<include>>
<<extend>> <<extend>>
<<extend>>
Rechercher
Changer
<<extend>>
statut <<extend>> Archiver
Transformer
Administrateur Effectuer un paiement
<<include>>
Modifier
Filtrer
Directeur
Figure 18:Cas d'utilisation gestion d'achat

51
 Gestion de stock
Gestion de stock
Enregistrer un bon d'

entrée
<<extend>>
Enregistrer un documents de Enregistrer un articles
stock
Responsable Achat Enregistrer un bon de
sortie
Transferer un stock
<<include>>
Magasinier <<include>>
Enregistrer un inventaire
<<include>>
S'authentifier
Lister les document stock <<include>>
Modifier
<<extend>>
<<extend>>
Administrateur <<extend>>
<<extend>>
Supprimer <<extend>> Valider
Imprimer Rechercher
Directeur
Figure 19:Cas d'utilisation gestion de stock

IV.2.1.6 Classification des UC et planification du projet en itération
La classification ci-dessous a été faite en tenant en compte deux aspects primordiaux : la priorité
 fonctionnelle déterminée par les utilisateurs;
 le risque technique déterminé par notre implémentation.
Pour mieux identifier et lever les risques majeurs au plus tôt, nous avons donc combiné l’estimation du
risque et la priorité fonctionnelle en prenant en compte les éventuelles relations entre les cas
d’utilisation. Ainsi, si le risque est haut ainsi que la priorité, il nous faut planifier le cas d’utilisation
dans une des toutes premières itérations. Si la priorité est basse ainsi que le risque, nous pouvons reporter
ce cas d’utilisation à une des toutes dernières itérations.
Ci- dessous le tableau récapitulatif de la classification et de la planification

52
Cas d’utilisation priorité Risque N°

Itération
Gérer le Plan comptable Haute Haut 1
Gérer un taux de taxe Haute Haut 1
Gérer un journal Haute Haut 1
Gérer une unité Haute Haut 1

Gérer les entrepôt Haute Haut 1
Enregistrer une famille Haute Haut 2
Enregistrer un article Haute Haut 2
Gérer les tiers (fournisseurs,clients) Moyenne moyen 2
Enregistrer un document d’achat Haute Haut 3
Lister les documents d’achats bas Moyen 3
Gérer les documents de stock Moyenne Haut 3

Enregistrer un document de vente bas Moyen 3
Lister les documents de vente bas Moyen 3
Gérer un écheancier bas Moyen 4
Effectuer un paiement de facture bas Haut 4
Imprimer documents bas moyen 4
Gérer un groupe bas Haut 5
Gérer un utilisateur bas Haut 5
Tableau 13:Tableau récapitulatif de la classification et de la planification

Les cas d’utilisation Gérer le Plan comptable, Gérer un taux de taxe, Gérer un journal, Gérer une unité,
Gérer les entrepôt,Enregistrer une famille et Enregistrer un article sont les cas d’utilisation de base. Ainsi
aucun autre cas ne peut être réalisé sans que ces derniers ne soient préalablement réalisés. Ce qui nous
oblige à leur donner une priorité haute. En effet une mauvaise réalisation de ces derniers affectera tout
le système.
« Enregistrer documents de vente », « Enregistrer documents d’achat », « Enregistrer document de
stock » puis « Gérer paiement de factures » sont des cas d’utilisation majeurs de notre système,
la réussite de notre projet dépend à 80% de la réussite de ces cas d’utilisation

53
IV.2.2 Spécification détaillée

L’expression des besoins a donné lieu à une modélisation par les cas d’utilisation. Après cette
étape, nous passons à la conception de notre système où nous décrivons les cas d’utilisation de façon
détaillée afin d’obtenir une expression précise des besoins et produire les diagrammes de séquence
système illustrant la description, avant de procéder à la conception objet.
Dans cette partie, sans être exhaustif, nous présentons la description textuelle de quelques cas
d’utilisation ; les cas d’utilisation sont ensuite illustrés par des diagrammes de séquence système et des
diagrammes d’activité.
IV.2.2.1 Description textuelle des cas d’utilisation
Notons que, bien que non normalisée par UML, le tableau de description textuelle d’un cas d’utilisation
que nous proposons ici, a été adapté à notre problème. Pour les principaux cas d’utilisation, nous ferons
un bref résumé, ensuite nous précisérons l’acteur principal, les éventuels acteurs secondaires, puis
l’invariant du cas d’utilisation avant une description proprement dite du cas d’utilisation. Les
alternatives et les exceptions probables des cas d’utilisation sont ensuite décrites respectivement dans
les deux derniers volets du tableau.
 Cas d’utilisation s’authentifier
Cas d’utilisation : s’authentifier
Résumé : Ce cas permet à tous les utilisateurs du système de s’identifier afin d’avoir accés au
système
Acteurs : Tous les acteurs
Date Création : 30/01/2021
Mise à jour :
Responsable : MOUAMADJE Thiery
Pré conditions Le système est fonctionnel
Description des scénarios

1. Le système demande à l’utilisateur de s’identifier
2. L’utilisateur saisit le nom d’utilisateur, le mot de passe et valide (A1)
3. Le système affiche les fonctionnalités accessibles à l’utilisateur
Scénarios alternatifs
A1. Le système signale les informations obligatoire.
L’enchaînement A1 démarre au point 2 du scénario nominal.
4. Le système signal à l’utilisateur les informations obligatoires
Le scénario nominal reprend au point 1

54
Tableau 14: Description textuelle du cas d’utilisation s’authentifier

 Cas d’utilisation Gérer un groupe
Cas d’utilisation : Gérer un groupe
Résumé : Ce cas permet à l’administrateur du système de créer ,modifier ou supprimer un

groupe
Acteurs : L’administrateur
Mise à jour :
Acteur authentifier
1. Le système affiche la liste des utilisateurs et les groupes existants au sein du système
2. L’administrateur sélectionne le(s) groupe(s) à attribuer ainsi que le(s) utilisateur(s)
bénéficiaire(s)
3. Le système enregistre les informations fournies
Tableau 15: Description textuelle de cas d'utilisation Gérer un rôle
 Cas d’utilisation Ajouter un utilisateur
Cas d’utilisation : Ajouter un utilisateur
Résumé : Ce cas permet à l’administrateur du système de créer un nouveau utilisateur
Mise à jour :
Acteur authentifier

55
1. Le système demande à L’administrateur de saisir les informations relatives au compte

utilisateur
2. L’administrateur saisit le nom d’utilisateur, le mot de passe et valide (A2) (A2)
3. Le système contrôle les informations saisies
4. Le système enregistre les informations fournies puis ouvre la liste des utilisateurs
A1. Le système signale les informations obligatoire.
5. Le système signale à l’utilisateur les informations obligatoires
Scénarios d’exceptions
A2. L’utilisateur est déjà enregistré
6. Le système signale que l’utilisateur est déjà enregistré
Tableau 16: Description textuelle du cas d’utilisation Ajouter utilisateur

 Cas d’utilisation sauvegarder les données
Cas d’utilisation : sauvegarder les données
Résumé : Ce cas permet à l’administrateur du système de sauvegarder la base de donnée
Mise à jour :
Acteur authentifier
1. l’administrateur accède à son espace et clique sur l’item
« sauvegarder la base de données »
2. Le système réalise la sauvegarde complète de la base de
données, qui sera transféré sur son poste de travail.
Tableau 17:Description textuelle de cas d'utilisation Sauvegarder les données

56
 Gestion de structure de base

 Cas d’utilisation Gérer le plan comptable
 Cas d’utilisation : Gérer le plan comptable
Résumé : Ce cas d’utilisation permet de gérer les différents comptes du plan comptable
Acteurs : Commercial, responsable commercial,responsable de vente

Mise à jour :
L’acteur s’est authentifié
1. L’utilisateur clique sur le bouton plan comptable
2. Le système lui affiche la liste des comptes ainsi que les bouton pour ajouter un nouveau
compte, modifier,importer, imprimer et supprimer
3. L’utilisateur choisit l’opération a effectuer (Cas nouveau)
4. L’acteur saisie les informations obligatoires (type du compte, code ,libellé) puis valide
5. Le système à son tour vérifie les informations (A1)(A2).
6. Le système enregistre les informations du compte,ferme le formulaire puis ouvre la liste
des tous les comptes le nouvel enregistrement
A1. Le système signale les informations obligatoires.
7. Le système signal à l’utilisateur les informations obligatoires à saisir
A2. Le compte est déjà enregistré
8. Le système ferme le formulaire et affiche la liste des comptes
Tableau 18: Description textuelle de cas d'utilisation Gérer plan comptable

 Cas d’utilisation Gérer taux de taxe
 Cas d’utilisation : Gérer taux de taxe

57
Résumé : Ce cas d’utilisation permet de gérer les différents taux de taxe

Mise à jour :
9. L’utilisateur clique sur le bouton taux de taxe
10. Le système lui affiche la liste des taux de taxe ainsi que les bouton pour ajouter un
nouveau taux, modifier , imprimer et supprimer
11. L’utilisateur choisit l’opération a effectuer (Cas nouveau)
12. L’acteur saisie les informations obligatoires (référence, compte de taxe,type, le sens
,libellé, le taux, ..) puis valide
14. Le système enregistre les informations du,ferme le formulaire puis ouvre la liste des
tous les taux de taxe et le nouvel enregistrement
A2. Le Taxe est déjà enregistré
16. Le système ferme le formulaire et affiche la liste des taxes
Tableau 19:Description textuelle de cas d'utilastion Gérer les taux de taxe

 Cas d’utilisation enregistrer un tiers
Cas d’utilisation : Enregister un tiers
Résumé : Ce cas d’utilisation permet à l’acteur de créer un tiers

58

Mise à jour :
17. L’utilisateur clique sur le bouton Ajouter
18. Le système lui affiche le formulaire d’enregistrement d’un tiers.
19. L’acteur saisie les informations obligatoires en precisant le type tiers à créer puis valide
21. Le système enregistre les informations du tiers puis ouvre la liste des clients si le tiers
est un client et fournisseur si le tiers est un fournisseur avec le nouvel enregistrement
A2. Le client est déjà enregistré
23. Le système ferme le formulaire et affiche la liste des clients
Tableau 20:Description textuelle de cas d'utilisation Enregistrer un tiers

 Cas d’utilisation gérer une famille
Cas d’utilisation : gérer une famille
Résumé : Ce cas d’utilisation permet à l’acteur de gérer une famille
Acteurs : Responsable d’achat , responsable commercial

Création : 30/01/2021
Date Mise à jour :
Le système est fonctionnel
Pré conditions L’acteur s’est authentifié

59
1. L’acteur clique sur le bouton.de nouveau (cas d’ajout)

2. Le système lui affiche le formulaire d’ajout d’une famille.
3. L’acteur saisie les informations obligatoires puis valide
5. Le système enregistre les informations puis ouvre la liste des familles
A2. La famille est déjà enregistré
7. Le système notifie à l’utilisateur que la famille est déjà enregistré.
8. Le système ferme le formulaire et affiche la liste des familles
Tableau 21: Description textuelle de cas d'utilisation

 Cas d’utilisation gérer un article
Cas d’utilisation : gérer un article
Résumé : Ce cas d’utilisation permet à l’acteur de gérer un article
Acteurs : Commercial
Création : 30/01/2021
Date Mise à jour :
Pré conditions L’acteur s’est authentifié en tant que commercial
1. Le système affiche la liste des articles déjà enregistrée ainsi les familles
2. L’acteur selection la famille à la quelle le nouveau article devra appartenir
et clique sur le bouton nouveau (cas d’un ajout)
3. Le système lui affiche le formulaire d’ajout d’un article
4. L’acteur saisie les informations obligatoires puis valide

60
6. Le système enregistre les informations puis ouvre la liste des artcles avec le nouveau
article
A2. L’article est déjà enregistré
10. Le système notifie à l’utilisateur que l’article est déjà enregistré.
11. Le système ferme le formulaire et affiche la liste des articles
Tableau 22: Description textuelle de cas d'utilisation Enregistrer un article

 Cas d’utilisation Enregistrer un document de vente
Cas d’utilisation : Enregistrer un document de vente
Résumé : Ce cas d’utilisation permet à l’acteur d’ajouter au système l’un des documents : devis,
bon de commande, bon de livraison, bon de retour, facture, facture d’avoir
Acteurs : Commercial
Création : 30/01/2021
Date Mise à jour :
Pré conditions L’acteur s’est authentifié en tant que commercial
1. Le cas est initié par un lancement utilisateur
2. Le système lui affiche le formulaire de création
3. L’acteur saisie les informations obligatoires de l’entête du document
4. Le système à son tour vérifie les informations (A1).(A2)
5. Le système enregistre les informations de l’entête du document
6. L’ utilisateur choisi un par un l’article à ajouter dans la liste avec la modibilité de
modifier le prix unitaire, la quantité, … puis valide(A3)(A4)
7. L’acteur clique pour tout enregistrer et quitter

61
A1. Le système signale les informations qui sont obligatoire
8. Le système signal à l’utilisateur les champ obligatoire
A3. Le système signale la rupture de stock pour l’article choisit
L’enchaînement A3 démarre au point 6 du scénario nominal
9. Le système demande si l’utilisateur veut choisir un article en rupture
A4 le système signale que l’article a déjà été ajouté
L’enchaînement A4 démarre au point 6 du scénario nominal
10. Le systeme signale a l’utilisateur que l’article existe déjà dans la liste donc peut modifier
sa quanté s’il veut ajouter
A2. Le document est déjà enregistré
11. Le système notifie à l’utilisateur que le document est déjà enregistré.
Le cas d’utilisation se termine par un échec.
Tableau 23: Description textuelle de cas d’utilisation Enregistrer un document de vente

 Cas d’utilisation Lister document de vente
Cas d’utilisation : Lister document de vente
Résumé : Ce cas permet à l’utilisateur du système de consulter les différents documents (les
devis, les bons de commande, les bons de livraison, les factures, les bon de retours, les facture
d’avoir)
Création : 30/01/2021
Date Mise à jour :
L’utilisateur authentifier
1. L’utilisateur demande la liste des éléments à lister puis
2. Le système affiche la liste,
3. L’utilisateur peut ensuite choisir le mode de filtrage

62
4. Le système rafraîchit la liste.
5. On peut consulter chaque élément et éventuellement effectuer des modifications,
archiver ou imprimer
Tableau 24: Description textuelle de cas d'utilisation Lister document de vente

 Cas d’utilisation Gérer Echéancier
Cas d’utilisation : Gérer échéancier
Résumé : Ce cas permet à l’utilisateur du système de créer un nouveau échéancier, modifier et

supprimer
Acteurs :commercial
Création : 30/01/2021
Date Mise à jour :
L’utilisateur authentifier
1. L’acteur edit la facure non régler clique sur le bouton nouveau pour la creation
2. Le système affiche le formulaire d’échéancier avec le montant de la facture
3. L’acteur choisit le nombre d’échéance pour la facture
4. Le système lui génère le(s) date(s) et montant de chaque échéance(A1)
5. L’utilisateur valide la création de(s) échéance(s )
6. Le système ferme le formulaire puis affiche la liste des échéances de la facture
selectionnée
7. L’acteur peut saisir manuellement la date et montant d’échéance
Tableau 25: Description textuelle de cas d'utilisation Gérer échéancier

 Cas d’utilisation transformer document

63
Cas d’utilisation : Transformer un document
Résumé : Ce cas permet à l’utilisateur du système de transformer un document d’un type en un

document d’un autre type (par exemple :devis en bon de commande , bon de commande en bon
de livraison )
Création : 30/01/2021
Date Mise à jour :
Acteur authentifier
1. Le système affiche la liste des documents
2. L’utilisateur selectionne le document à transformer
3. Le système affiche le option de transformation possible
4. Le système affiche le formulaire avec les informations preremplies à savoir reference
client et la liste des article selectionnés puis valide(A1)
5. Le système ferme le formulaire de création de document et le redirige vers la liste de
document
A1. Modifier le document pendant la transformation
6. L’utilisateur peut modifier le document en ajoutant d’autres articles si le document n’est
pas encore valider
Tableau 26:Description textuelle de cas d'utilisation Transformer un document de vente

 Cas d’utilisation gérer règlement
Cas d’utilisation : Gérer un règlement
Résumé : Ce cas permet à l’utilisateur du système d’enregistrer le règlement d’une

facture,modifier et supprimer
Acteurs : comptable
Création : 30/01/2021
Date Mise à jour :

64

Acteur authentifier
1. Le système affiche la liste des factures non réglées ainsi les bouton régler, modifier,
supprimer, imprimer et une zone de recherche.
2. L’acteur clique sur l’une des items et exécute l’opération
Souhaité
 Cas d’utilisation régler facture

.
Cas d’utilisation : Régler facture
Résumé : Ce cas permet à l’utilisateur sur système Enregistrer le règlement d’une facture
Acteurs : comptable
Création : 30/01/2021
Date Mise à jour :
Acteur authentifier
1. Le système affiche la liste des factures client non réglées
2. L’utilisateur sélectionne la facture
3. L’utilisateur sélectionne le mode de payement,l’échéance à régler (pour le cas d’un règlement
specifique)
4. L’utilisateur saisit le montant du règlement et valide (A1)
5. Le système enregistre le règlement , informe l’utilisateur de la situation financière du client
et ferme le formulaire
A1.Montant de versement > montant à payer
1. Le système informe l’utilisateur de la situation
2. Retour au point 4 du scénario nominal
Tableau 27: Description textuelle de cas d'utilisation Régler facture

65
IV.2.2.2 Diagramme de séquence

Pour mieux illustrer les actions entre les acteurs et les objets du système, nous allons traduire
graphiquement Quelques principaux cas d’utilisation parmi ceux décrit précedement. L’élaboration de
ce diagramme nécessite parfois la mise à jour du diagramme des cas d’utilisation.
Voici ci-après quelques diagrammes de séquence de notre système
 Diagramme de séquence s’authenfier
Diagramme de sequence authentification
systeme
Tous
demande d'authentification
Afficher formulaire d'authentification
Entrée login et mot de passe
alt informations incorrectes

Envoi message d'erreur
informations correctes
Autorisation d'accès
Figure 20:Diagramme de sequence s'authentifier

66
 Diagramme de séquence enregistrer article

Diagramme de sequence enregistrer article
Systeme2
Responsable commercial
demande d'enregistrer d'un article
formulaire enregistrer d'un article
envoie de saisie d'informations
Enregistrement d'information
message de succès
alt article existe Echec article existe
champs manquant
echec champs obligatoires
Figure 21: Diagramme de sequence enregistrer article

67
 Diagramme de sequence Enregistrer tiers

Diagramme sequence enregistrer tiers
Systeme
Commercial
Demande d'ajouter un tiers
formulaire de saisie tiers
envoie d'information tiers
alt information correcte Enregistrement d'information

message de succès
Tiers existe
Echec d'ajout
Figure 22: Diagramme de sequence Enregistrer tiers

68
 Diagramme de sequence enregistré un document

DS Enregistrer un document
Systeme
Commercial
Demande de saisie d'un document
formulaire de choix de document à saisir
envoie du choix de document à saisir
Formulaire de type de document
Saisie d'informations + saisie de ligne

document
Enregistrement des informations
opt [Si ligne document de trop]

Supprimer une ligne document
Recalculer les montants
Mise à jour du document
Figure 23:Diagramme de sequence enregistré un document

69
 Diagramme de sequence enregistré un règlement

DS Enregistrer règlement
System
Comptable
Demande de règlement
Formulaire de règlement
Envoie des informations saisies
Enregistrer le règlement
Réçu de règlement
Figure 24:Diagramme de sequence enregistré un règlement

70
 Diagramme de sequence processus de vente

DiagrammeSequence vente
Systeme
Client Commercial,comptable
Besoin d'article (s)
Demande d'information
Informations fournies
Créer devis
contrôle de stock
Article disponible
Enregistrer devis
Envoi de devis par email
Commande
Transformer devis en BC
enregistrer BC
Tranformer BC en BL
enregitrer BL
Envoi de BL
Transformer BL en facture
enregistrer facture
Envoi de facture
Paiement Enregistrer le règlement

enregistrer règlement
Envoi reçu de paiement
Figure 25:Diagramme de sequence processus de vente

71
 Diagramme de séquence processus d’achat

DiagrammeSequence processus achat
Systeme
Fournisseur Commercial,comptable
Enregistrer demande de prix

Enregistrer demande de prix
Envoi de demande de prixpar email
Transformer demande prix en BC ou créer

enregistrer BC
Envoi de BC
Reception de commande Tranformer BC en BR

enregitrer BR
Réception de la facture Transformer BR en facture ou créer

enregistrer facture
Paiement de la facture Enregistrer le règlement

enregistrer règlement
IV.2.3 Réalisation des Diagramme de classe

Après la réalisation des spécifications détaillées, nous devons procéder par la conception des objets. La
conception de ces objets nécessite principalement une description structurelle,statique du système à
réaliser sous forme d’un ensemble de classes logicielles regroupées en packages.
Pour parvenir à établir le modèle nous avons procéder à :
 Identification des entités ou concepts du domaine d’étude,
 Identification et ajout des associations et des attributs,
 Organisation et simplification du modèle en éliminant les classes redondantes.
Ci-dessous nos diagramme de classes de conception obtenu par module

72
 Gestion de vente
Type_Compte
- idTypeCompte : int Famille Article
- libelle : int - idFamilleArticle : int Unité_achat
+ ajouter () : void - reference : String 0..*
- idUnite : int
+ modifier () : void - libelle : String 1..1
- reference : String
+ supprimer () : void - photo : String - libelle : String
... 1..1
- qteMax : int - description : String
1..* - qteMin : int - estActif) : boolean
- estSuiviEn Stock : boolean
+ ajouter () : void
Compte_Comptable 0..1 - modeGestionStock : String
+ modifier () : void
- idTypeCompte : int - flagActif : boolean
+ supprimer () : void
- reference : int - saisiPar : String ...
- libelle : int 0..*
- saisiLe : String 0..*
1..*
- modifieLe : String
+ ajouter () : void - modifiePar : String Type_Taxe
+ supprimer () : void + ajout () : void - idTypeTaxe : int
1..1
+ imprimer () : void 1..1 + modifier () : void - libelle : int
1..1 + supprimer () : void
+ importer () : void + ajouter ()
... ... + modifier ()
+ supprimer ()
0..*
...
0..1
1..1
Ligne_Document_Vente
Taxe
- idLigneDocument : int
- quantite : int - idTaxe : int
Entrepôt - remise : long - reference : String
- tauxRemise : int 0..* - libelle : int
- idEntrepôt : String - idTypeTaxe : int
- reference : String - montantTaxe3 : double
0..*
- libelle : String - totalMontantTaxes : double Article + Ajouter () : void
- montantBrutHT : double + Modifier () : void
+ ajouter () : void - idArticle : int 0..1
- montantNetTTC : double + Supprimer () : void
+ modifier () : void 1..1 - reference : String ...
+ supprimer () : void + ajouter () : void - libelle : String
0..*
... + modifier () : void - Description : String
+ supprimer () : void - prixU : double
... - photo : String
- codeBarre : String
0..*
- refInterne : String
0..* - qteMax : int
Mode_Reglement 0..*
- qteMin : int Article_Unité
- iddModeReglement : String 1..1 Document_Vente - estSuiviStock : boolean - idArticleUnite : int
- reference : String - idDocument : int - saisiPar : String 0..* - prixAchat : double
- libelle : String - reference : String - saisiLe : String - prixVente : double
+ ajouter () : void 0..* - dateEnr : Date - modifiePar : String + ajouter () : void
+ modifier () : void - Observation : String - modifieLe : String + modifier () : void
+ supprimer () : void - refModeReglement : String + Ajout () : void + supprimer () : void
... - remise : double + Modifier () : void 1..1 ...
- tauxRemise : int + Supprimer () : void
- montantBrutHT : double Mode_Gestion_Stock
- montantNetHT : double
- montantTTC : double 0..* - idModeGestionSt : String
Mode_Livraison - estArchiver : boolean - reference : String
- estValider : boolean - libelle : String
- idModeLivraison : String 1..1
- statut : String + ajouter () : void
- reference : String
- refDemandePrix : String Echéance + modifier () : void
- libelle : String 1..*
- refBC : String - idEcheance : int + supprimer () : void
+ ajouter () : void - refBR : String ...
- dateEcheance : Date
+ modiifier () : void - refFacture : String
0..*
- montantNetTTCDocument : double
... + ajouter () : void 1..1
- montantEcheance : Date
+ modifier () : void - observations : String
+ supprimer () : void - estActif : boolean
+ annuler () : void - saisiPar : String
+ transformer () : void - saisiLe : Date
0..* 1..1 - modifieLe : Date
1..1
- modifiePar : String
0..*
Tiers 1..*
+ ajouter () : void
- IdTiers : int
- codeTiers : String
...
- Civilite : String 1..1
0..1
- Nom : String
- Prenom : String Type_document_Vente 0..* 0..* 0..*
- Adresse : String
- idTypeDocument : int Article_Categorie
- Ville : String
- Pays : String
- libelle : String Règlement - idArticleCate : int
- Telephone : String + ajouter () : void - idReglement : int - prixVente : double
- Email : String + modifier () : void - dateEnreg : Date + ajouter () : void
- DateNaissance : Date + supprimer () : void - montantNetTTCDocument_ : double + modifier () : void
+ ajout () : void - montantReglement : double + supprimer () : void
+ modifier () : void - resteAPayer : double
0..*
+ supprimer () : void + ajouter () : void
... + modifier () : void
1..1 0..* + supprimer () : void 0..*
0..* ... Categorie
0..1
- idCategorie : int
contact - libelle : int
- idContact : int 1..1
Ville + ajouter () : int
1..1 Type_Tiers Pays
- civilite : String - IdVille : int 1..*
+ modifier () : int
- nom : String - idTypeTiers : int - code : String - idPays : int + supprimer () : int
1..1
- prenom : String - libelle : int - nom : String - code : String ...
0..*
- nomComplet : String + ajouter () : int + ajouter () : void - nom : String
- fonction : String + modifier () : int + modifier () : void - indicatif : String
- bp : String + supprimer () : int + supprimer () : void + ajouter () : void
- telephones : String ... ... + modifier () : void
- email : String + supprimer () : void
- pays : String
- ville : String
- adresse : String
+ ajouter () : void
...
Figure 26:Diagramme de classe gestion de vente

73
 Gestion d’achat et stock

Type_Compte
- idTypeCompte : int Famille_Article
- libelle : int - idFamilleArticle : int Unité_achat
0..*
+ ajouter () : void - reference : String - idUnite : int
+ modifier () : void - libelle : String 1..1 - reference : String
+ supprimer () : void - photo : String - libelle : String
... - qteMax : int - description : String
1..* 1..1 - qteMin : int - estActif) : boolean
- estSuiviEn Stock : boolean
+ ajouter () : void
Compte_Comptable 0..1 - modeGestionStock : String
- idTypeCompte : int - flagActif : boolean
- reference : int - saisiPar : String ...
- libelle : int 0..*
- saisiLe : String 0..* 1..*
- modifieLe : String
+ ajouter () : void - modifiePar : String Type_Taxe
0..1 + ajouter () : void
1..1 + supprimer () : void - idTypeTaxe : int
+ imprimer () : void 1..1 + modifier () : void - libelle : int
1..1 + supprimer () : void
+ importer () : void + ajouter ()
... ... + modifier ()
+ supprimer ()
Ligne_Document_achat ...
0..1 0..*
- idLigneDocument : int 1..1
- quantite : int
- remise : long Taxe
- tauxRemise : int - idTaxe : int
- montantTaxe3 : double - reference : String
Entrepôt - totalMontantTaxes : double 0..* 0..* - libelle : int
- idEntrepôt : String - montantBrutHT : double - idTypeTaxe : int
- reference : String - montantNetTTC : double 0..*
+ ajouter () : void
Article
- libelle : String + ajouter () : void + modifier () : void
+ modifier () : void - idArticle : int 0..1
+ ajouter () : void + supprimer () : void
+ supprimer () : void - reference : String ...
+ modiifier () : void 0..1
... - libelle : String
+ supprimer () : void 0..*
- Description : String
...
- prixU : double
- photo : String
- codeBarre : String
- refInterne : String
0..* 0..* - qteMax : int
Mode_Reglement - qteMin : int Article_Unité
1..1
- iddModeReglement : String Document_achat 0..* - estSuiviStock : boolean - idArticleUnite : int
- reference : String - idDocument : int - saisiPar : String - prixAchat : double
- libelle : String - reference : String - saisiLe : String - prixVente : double
0..*
+ ajouter () : void - dateEnr : Date - modifiePar : String + ajouter () : void
+ modifier () : void - Observation : String - modifieLe : String 0..* + modifier () : void
+ supprimer () : void - remise : double + Ajout () : void + supprimer () : void
... - tauxRemise : int + Modifier () : void ...
- montantBrutHT : double + Supprimer () : void 1..1
- montantNetHT : double
- montantTTC : double 0..* Mode_Gestion_Stock
- estArchiver : boolean
Mode_Livraison - estValider : boolean - idModeGestionSt : String
1..1
- idModeLivraison : String - statut : String - reference : String
- reference : String - refDemandePrix : String - libelle : String
- libelle : String - refBC : String Echéance + ajouter () : void
1..* 0..*
+ ajouter () : void - refBR : String - idEcheance : int + modiifier () : void
+ modiifier () : void - refFacture : String - dateEcheance : Date + supprimer () : void
+ supprimer () : void + ajouter () : void - montantNetTTCDocument : double ...
... + modifier () : void - montantEcheance : Date
1..1
+ supprimer () : void - observations : String
+ annuler () : void - estActif : boolean
+ transformer () : void - saisiPar : String
- saisiLe : Date Ligne_Mouvement
0..* 1..1 - modifieLe : Date - idLigneMouvement : int
0..* - modifiePar : String - quantite : int
Tiers + ajouter () : void - valeurReelleAchat : double
1..* 1..1 - valleurReelleVente : double
- IdTiers : int + modifier () : void
- codeTiers : String + supprimer () : void + ajouter () : void
- Civilite : String 1..1 ... + modifier () : void
- Nom : String 0..* 0..* 0..* 0..1 + supprimer () : void
- Prenom : String ...
Type_document_achat
- Adresse : String
- idTypeDocument : int Règlement_achat 0..*
- Ville : String
- libelle : String - idReglement : int
- Pays : String
+ ajouter () : void - dateEnreg : Date Mouvement_Stock
- Telephone : String
+ modifier () : void - montantNetTTCDocument_ : double
- Email : String - idMouvement : int
+ supprimer () : void - montantReglement : double
- DateNaissance : Date - reference : String
- resteAPayer : double
+ ajout () : void - dateEnr : Date
0..* + ajouter () : void
+ modifier () : void - Observation : String
+ modifier () : void - refModeReglement : String
... + supprimer () : void - valeurReelleAchat : double
... - valeurReelleVente : double
1..1
0..* 1..1 - statut : String
+ ajouter () : void
Contact Type_Tiers + modifier () : void
- idTypeTiers : int Ville Pays + supprimer () : void
- idContact : int 0..* + annuler () : void
- civilite : String - libelle : int 1..1 - IdVille : int - idPays : int
1..* 1..1 + transformer () : void
- nom : String + ajouter () : int - code : String - code : String
- prenom : String + modifier () : int - nom : String - nom : String 1..1
- nomComplet : String + supprimer () : int - indicatif : String 0..*
+ ajouter () : void
- fonction : String ... + modifier () : void + ajouter () : void
- bp : String
Type_Mouvement
+ supprimer () : void + modifier () : void
- telephones : String + supprimer () : void - idTypeMouvement : int
...
- email : String - libelle : String
- pays : String + ajouter () : void
- ville : String + modifier () : void
- adresse : String + supprimer () : void
+ ajouter () : void
...
Figure 27:Diagramme de classe gestion d'achat et stock

74
IV.2.3.1 Règle de gestion

1. Un tiers peut avoir un ou plusieurs Documents;
2. Un document est accordé à un seul tiers ;
3. Un document contient un ou plusieurs articles
4. Un article appartient à une famille
5. Un article existe dans un ou plusieurs documents
6. Un document peut être transformer en un autre type de document
7. Un document avec le statut valider ne peut être modifier
8. Seul un document de type facture peut faire l’objet d’un règlement
9. Un document peut être régler un ou plusieurs fois
10. Un document(facture) peut avoir 0 ou plusieurs échéances
IV.2.3.2 Structuration des classes en package
Les paquetages servent à organiser les éléments de modélisation en groupe avec pour objectif
de rendre les diagrammes plus simples et faciles à comprendre.
Ci-dessous le diagramme des classes en package de notre système
Famille Article Compte_Comptable Taux de taxe
Structure de base
Tiers Entrepôt Journaux Unité
Document_Vente Echéance
Document_Achat Echéance_Achat
Vente
Achat et Stock
Penalité Règlement_Achat Document de stock

Règlement
Figure 28: Diagramme des classes en package

75
IV.2.4 Diagramme d’activité de navigation

Les IHM facilitent la communication entre l’application et l’utilisateur en offrant des moyens
d’action et de visualisation comme des menus déroulants ou contextuels, des palettes d’outils, des boîtes
de dialogues, des fenêtres de visualisation, etc. UML nous permet de représenter graphiquement cette
activité de navigation par des diagrammes appelés diagrammes d’activité de navigation.
Ci-dessous quelques diagrammes d’activité de navigation du projet.
 Diagramme d’activité s’authentifier
Utilisateur Systeme
Démarrer d'application Ouvrir l'application
Remplissage et soumission des Afficher le formulaire d'

informations authentification
Vérification et contrôle du mot de passe
Affichage du message d' Decision

erreur
Affichage de la page d'

acceuil
Figure 29: Diagramme d'activité s'authentifier

76
 Diagramme d’activité enregistrer article
Utilisateur Systeme
selectionner une famille puis cliquer

sur le bouton nouveau Ouvrir le formulaire d'enregistrement
Remplissage et soumission des

informations Affichage du formulaire
Contrôle d'informations
M essage d'erreur Decision
Affichage de liste des articles
Figure 30: Digramme d'activité enregistrer article

77
 Diagramme d’activité processus de vente
Devis
Decision 1 Accepter Bon de commande Bon de livraison
Decision 2 Non conforme Bon de retour

Refuser
Conforme
Facture
Valider
Decision 3 Erreur Facture d'avoir
Non erreur
Règlement
Figure 31:Diagramme d’activité processus de vente

78
 Diagramme d’activité processus d’achat
Demande de prix
Decision 1 Accepter Bon de commande Bon de reception
Decision 2 Non conforme Bon de retour

Refuser
Conforme
Facture
Valider
Decision 3 Erreur Facture d'avoir
Non erreur
Règlement
Figure 32:Diagramme d’activité processus d’achat

79
IV.2.5 Diagramme de déploiement

Le deploiement dependra des besoins techniques des clients de 2BN Internationnal, celle-ci
sera déployée dans une architecture 2 tiers sur un poste client ou au sein d’un réseau entièrement
sécurisé. Le diagramme ci-dessous comprend des nœuds correspondant aux supports physiques
(Serveur de donnée , PC) et la répartition des composants logiciels sur ces nœuds.
Réseau local d'entreprise
Poste client
Serveur de base de données
Executable
MySQL
Requête exe
Figure 33: Diagramme de déploiement

80
Dans cette partie, nous allons présenter la réalisation de notre projet et la conduite de
projet. Nous y présenterons les outils de modélisation et les outils de développement choisis.
Nous y présenterons également l’architecture de notre système, les langages de programmation
et enfin la conduite de projet.

81
CHAPITRE V : MISE EN ŒUVRE

Dans ce chapitre, nous présenterons les outils, techniques et langages que nous avons utilisés
pour la conception et l’implémentation de notre système. Nous nous attarderons sur quelques aspects
que nous jugeons très importants dans la réalisation de ce projet et quelques copies écrans du système
que nous avons mise en place
La conception du système étant achevée, nous allons nous pencher sur l’étape de réalisation de
notre projet. Nous nous proposons donc dans ce chapitre de justifier nos choix techniques et aussi
présenter les différents outils, techniques et le langage que nous avons utilisé pour l’implémentation de
la solution. Nous expliquerons les aspects importants de la réalisation, présenterons les captures d’écran
de notre application avant de terminer par la présentation de l’architecture réseau de notre solution
V.1 ARCHITECTURE DE LA SOLUTION

V.1.1 Architecture client/serveur
L’architecture client/serveur désigne un mode de communication entre plusieurs ordinateurs d’un
réseau qui distingue un ou plusieurs postes clients du serveur : chaque logiciel client peut envoyer des
requêtes à un serveur d’application, de fichiers, de terminaux ou encore de messagerie électronique.
Caractéristiques d’un serveur :
 Il est passif (ou maitre)
 Il est à l’écoute, prêt à répondre aux requêtes envoyées par le client
 Dès qu’une requête lui parvient, il la traite et renvoie une réponse
Caractéristiques d’un client :

 Il est actif (ou esclave)
 Il envoie des requêtes au serveur
 Il attend et reçoit les réponses du serveurs

82
Figure 34:Architecture client/serveur (Architecture client-

serveur, 2021)
V.1.2 Client lourds VS client légers

V.1.2.1 Client lourd (2 tiers)
Le terme « client lourd » désigne une application cliente graphique exécutée sur le système
d'exploitation de l'utilisateur. Un client lourd possède généralement des capacités de traitement évoluées
et peut posséder une interface graphique sophistiquée. Néanmoins, son architecture demande un effort
de développement et tend à mêler la logique de présentation (l'interface graphique) avec la logique
applicative (les traitements).
Figure 35: Architecture client lourd
Les principaux avantages du client lourd sont entre autres :

 L’ergonomie : étant exécutée sur le poste client le développeur a accès à l’ensemble des
fonctionnalités de l’OS ainsi que toutes les ressources et évènements matériels.

83
 La répartition : en mode client-serveur, le code d’affichage côté IHM et de gestion de

l’interaction utilisateur est exécuté au niveau du poste client ce qui offre l’avantage de solliciter
les ressources serveurs uniquement pour la restitution des données et/ou traitements centralisés.
 L’inter-connectivité : ayant accès aux ressources matérielles les solutions de type client lourd
permettent le pilotage et/ou la réception d’informations de périphériques matériels connectés au
poste client.
Malgré ces nombreux avantages les solutions client lourd ont perdu progressivement de leur intérêt
aux yeux des décideurs informatiques dès le début des années 2000 en raison de quelques inconvénients
complexifiant la phase de maintenance. Les principaux inconvénients des solutions client lourd sont :
 Le déploiement et la montée de version : étant installée sur chacun des postes clients, le
déploiement d’une solution de type client lourd devient un autre projet. Un tel projet devient
très complexe lorsque le parc informatique est vaste et hétérogène. Par la suite, à chaque montée
de version il est nécessaire de redéployer la nouvelle version sur chacun des postes.
La compatibilité : étant compilé pour une architecture processeur et faisant appel à des
fonctionnalités au niveau OS, une solution de type client lourd offre une compatibilité restreinte à une
configuration matérielle et un système d’exploitation donné. Cette problématique a été résolu
notamment avec Java et C# par la mise en place de la notion de machine virtuelle. Cependant ce nouveau
mode de fonctionnement limite les performances des applications compilées en byte code à cause de la
mise en place d’une couche intermédiaire. De plus il devient très difficile de dialoguer avec des
périphériques extérieurs car la machine virtuelle Java n’a qu’un nombre très limité d’interactions
possible avec l’OS et ses périphériques.
V.1.2.2 Client léger (3 tiers)
Pour faciliter alors le déploiement et la maintenance des applications de gestion, la majorité des
entreprises se sont tournées vers les architectures client léger. Un client léger est une application dont
les écrans sont calculés côté serveur puis transmis au poste client à travers un navigateur. Ce mode de
fonctionnement permet de résoudre les inconvénients vus précédemment sur les clients lourds. En effet,
le passage par un navigateur Web évite la phase de déploiement de l’application sur l’ensemble des
postes clients. Ainsi lors des montées de version seul l’applicatif côté serveur a besoin d’être mise à
jour. Quant à la compatibilité, une application en client léger est compatible avec tous les OS et
processeurs permettant l’exécution d’un navigateur Web supportant l’application.

84
Figure 36: Architecture client léger

Les solutions client léger sont couramment utilisées à cause de leurs gros avantages suivants :
 Coût : si l'on dispose d'un parc informatique vieillissant, il est possible de lui donner une
nouvelle jeunesse en achetant seulement une machine récente (le serveur).
 Maintenance système : toute application installée sur le serveur est instantanément disponible
pour tous les clients et les réglages du système ou les mises à jour ne sont faites qu'une fois pour
tout l'ensemble serveur-clients légers.
 Robustesse : une station spécialisée est bien moins sensible aux pannes qu'un ordinateur muni
d'un système et d'un disque dur ; une machine ancienne est facilement remplaçable en cas de
panne.
 Sécurité matérielle : le serveur peut être placé dans un lieu non accessible aux utilisateurs de
base, évitant ainsi les risques de vol ou de dégradation.
 Sécurité logicielle : tous les réglages de sécurité (coupe-feu, filtrage internet) sont centralisés.
Un utilisateur de base ne peut accéder aux documents des autres ni au système.
 Environnement : en choisissant comme clients légers des stations spécialisées sans disque dur,
on peut réduire de manière importante la consommation électrique et le niveau sonore d'une
salle informatique.
 Indépendance machine-environnement de travail : en cas de panne de matériel, d’un
changement de bureau ou lorsqu’un un utilisateur se trouve à une station autre que la maison
mère, il peut se connecter sur n'importe quel client et retrouver son environnement de travail et
ses documents. C’est l’avantage de la centralisation
L’inconvénient majeur d’une telle architecture est la forte dépendance au serveur : en cas de
défaillance du serveur, tous les clients sont hors service. Le serveur peut aussi atteindre ses limites si de
nombreux utilisateurs lancent des applications gourmandes en ressources (montage vidéo, modélisation

85
3D, feuilles de calculs lourdes). Mais pour remédier à celui-ci il est possible de faire tourner les
applications en local sur le serveur.
V.1.3 Choix de l’architecture
Nous venons de voir que le client léger à certains avantages qui poussent aujourd’hui les développeurs
de solutions informatique à tendre vers celui-ci. Mais le client ne peut pas être supplanter dans des cas
bien précis. Pour le développement de notre solution nous allons utiliseé l’architecture client lourd pour
les Desktop afin de donner la possibilité à l’utilisateur de travailler hors connexion avec une base de
données intégrée au système. L’utilisateur pourra ensuite synchroniser les données de cette base à la
base de donnée centrale en utilisant le réseau.
Enfin pour les solutions web et mobile nous allons opter pour l’architecture client leger
V.1.4 Choix des outils et technologies
V.1.4.1 Windev
WinDev est un atelier de génie logiciel (AGL) édité par la société française PC SOFT et conçu pour
développer des applications, principalement orientées données pour Windows et également pour Linux,
.NET et Java. Il propose son propre langage : le WLangage. La première version de l'AGL est sortie en
1993.Aujourd’hui nous sommes à la version 26.
WinDev inclut en standard un ensemble d'éditeurs qui composent l'Atelier de Génie Logiciel : éditeur
d'analyse (description des données), éditeur de fenêtres, éditeur de requêtes SQL, éditeur d'états, éditeur
de tests automatisés, éditeur d'aide, éditeur d'images, éditeur UML, éditeur de code, éditeur de
télémétrie, robot de surveillance, audit d'application, éditeur de dossier RGPD…
Sous WinDev, les fenêtres et états sont typiquement créés à l'aide d'un éditeur visuel. Les différents
champs sont créés sous l'éditeur, et leurs paramètres sont définis à l'aide d'assistants de paramétrage
visuels nommés « 7 onglets ». Chaque champ dispose en moyenne d'une centaine de paramètres. Cet
éditeur ne génère pas de code mais crée un objet WinDev (fenêtre ou état).
L'éditeur d'interface graphique permet de créer des IHM par glisser-déplacer. Il permet également de
choisir un modèle de charte graphique parmi un ensemble proposé et d'en créer de nouveaux.
WebDev et WinDev Mobile permettent d'utiliser le même langage de programmation (WLangage), et
les mêmes concepts (analyse, fenêtre, états, composants, classes…), pour la génération de sites Web et
d'applications mobiles.
La programmation s'effectue typiquement dans les composants graphiques, en saisissant directement le
code dans les événements proposés.
Pour notre projet nous utilis la version 24

86
Figure 37:Windev
V.1.4.2 PowerDesigner
PowerDesigner (anciennement PowerAMC) est un logiciel de conception créé par la société SAP, qui
permet de modéliser les traitements informatiques et leurs bases de données associées.
Il a été créé par SDP sous le nom AMC*Designor, racheté par Powersoft qui lui-même a été racheté par
Sybase en 1995. Depuis 2010 Sybase appartient à l'éditeur allemand SAP.
Avant mars 2016, la version française était commercialisée par SAP sous la marque PowerAMC, jusqu'à
la fusion avec la version internationale sous le nom PowerDesigner depuis la version 16.6.
PowerDesigner est disponible sous forme d'application native Microsoft Windows ou comme plugin
eclipse. Par défaut, PowerDesigner stocke ses modèles sous forme de fichiers, dont l’extension dépend
du type de modèle: bpm (pour business process model), cdm (pour conceptual data model)... La structure
interne du fichier peut être du XML ou du binaire compressé. PowerDesigner peut aussi stocker ses
modèles dans un Référentiel.
Figure 38: PowerDesigner

87
V.1.4.3 MySQL
MySQL est un système de gestion de bases de données relationnelles (SGBDR). Il est distribué sous
une double licence GPL et propriétaire. Il fait partie des logiciels de gestion de base de données les plus
utilisés au monde, autant par le grand public (applications web principalement) que par des
professionnels, en concurrence avec Oracle, PostgreSQL et Microsoft SQL Server.
Son nom vient du prénom de la fille du cocréateur Michael Widenius, My (sv) (prononcer [my]). SQL
fait référence au Structured Query Language, le langage de requête utilisé.
MySQL AB a été acheté le 16 janvier 2008 par Sun Microsystems pour un milliard de dollars américains.
En 2009, Sun Microsystems a été acquis par Oracle Corporation, mettant entre les mains d'une même
société les deux produits concurrents que sont Oracle Database et MySQL. Ce rachat a été autorisé par
la Commission européenne le 21 janvier 2010.
Depuis mai 2009, son créateur Michael Widenius a créé MariaDB (Maria est le prénom de sa deuxième
fille) pour continuer son développement en tant que projet Open Source.
Figure 39:MySQL

88
V.1.5 Déploiement de la solution

V.1.5.1 Captures d’écran de l’application
 Page login
Figure 40: Page de connexion

 Page d’administration
Figure 41: Page d'administration

89
 Page d’acceuil
Figure 42: page d'acceuil

90
 Page tableau de bord
Figure 43: Tableau de bord
 Liste des documents de vente
Figure 44: liste des dococuments de vente

91
 Formulaire de saisi d’une facture de vente
Figure 45:Formulaire de saisi d'une facture

92
 Formulaire règlement d’une facture
Figure 46: Formulaire de saisi d'un réglement

93
 Etat d’une facture de vente
Figure 47:Etat d'une facture

94
CHAPITRES VI : CONDUITE DE PROJET

La réussite d’un projet n’est pas uniquement dépendante du choix de la méthode et des outils à utiliser.
Une méthode est bien entendu nécessaire, mais elle est loin d’être suffisante. Conduire un projet, c'est
prendre toutes les mesures nécessaires pour faire en sorte que le projet atteigne ses objectifs, notamment
sur quatre principaux axes :
 Le respect des objectifs de qualité des livrables,
 Le respect des délais,
 Le respect des coûts,
 La satisfaction du client.
Ce chapitre est composé de deux grandes parties : la gestion de projet où nous présenterons les moyens
mis en œuvre pour la réalisation des objectifs du projet ; et le bilan du projet qui sera consacré à une
évaluation globale du travail effectué.
VI.1 GESTION DE PROJET

Seront présentés dans cette section, les intervenants du projet, le découpage, la planification de celui-ci
dans le temps et une estimation des coûts y afférents
VI.1.1 Intervenants au projet
Avant d'être une aventure technologique, un projet informatique est avant tout une aventure humaine
dans laquelle s'embarquent en même temps de nombreux intervenants. Il rassemble des acteurs qui
doivent travailler ensemble pour définir le besoin, la solution, la mise en œuvre et le déploiement de la
solution. La réussite d’un projet passe donc par une organisation rigoureuse et efficace de l'équipe projet
La Maîtrise d’ouvrage
La maîtrise d’ouvrage (MOA), est l’entité porteuse du besoin, définissant l’objectif du projet, son
calendrier et le budget consacré à ce projet. La MOA doit décrire le besoin dans un document, souvent
nommé Cahier Des Charges Fonctionnel (CDCF) ou spécifications fonctionnelles. Elle est aussi chargée
de préparer des cas de tests fonctionnels pour vérifier que les développements et/ou paramétrages
effectués par la MOE fonctionnent. Dans notre cas, ce rôle a été joué par une équipe de la Direction du
cabinet 2BN Internationnal
La Maîtrise d’œuvre
La maîtrise d'œuvre (MOE) est garante de la réalisation technique de la solution à mettre en place. Elle
peut réaliser elle-même cette solution, ou missionner un ou plusieurs fournisseurs pour cette réalisation
: la sous-traiter. Pour ce faire, elle rédige un dossier de réponse au besoin, nommé Cahier Des Charges
Technique (CDCT) ou dossier de paramétrage ou dossier de conception général ou encore étude
technique. La MOE se charge aussi de faire les développements et/ou paramétrages nécessaires.

95
Dans le cadre du projet Facteur X, le département de service informatiques dans laquelle nous étions
intégrés a été le principal acteur de la MOE. Notre devoir principal a été entre autres de
✓ Comprendre le besoin exprimé afin de rédiger un CDCT ;
✓ Concevoir une solution répondant au besoin exprimé ;
✓ Choisir les outils et technologies pour la mise en place de la solution conçue;
✓ Mettre en place la solution.
VI.1.2 Découpage du projet en phase
Dans cette partie nous présenterons comment notre projet a été organisé, notamment son découpage en
sous-projets et en tâches. En effet nous avons effectué un découpage à deux niveaux : l’ensemble du
projet a été découpé en phase et chaque phase est ensuite découpée en tâches.
Le tableau ci-dessous résume le découpage que nous avons effectué.
Phases Tâches
Etude préliminaire Prise de contact et exploration
Etude des concepts liés au sujet
Recueil des besoins
Rédaction du cahier de charge
Validation du cahier de charge
Étude de l’existant
Analyse et conception Choix d’une méthode
Choix des outils de modélisation
Mise en œuvre de la méthode choisie
Réalisation Représentation de l’architecture du système
Choix des outils de développement
Codage et tests
Implémentation
Validation
Documentation Rédaction du mémoire
Rédaction du guide utilisateur
Rédaction de la procédure de dépannage
Tableau 28:Découpage du projet
VI.1.3 Planification du projet
Le diagramme de GANTT est un outil utilisé en ordonnancement et en gestion de projet. Il permet de
visualiser les diverses tâches composant le projet, et les dates de réalisation de ces dernières. Il est mis
en œuvre dans l’optique d’assurer un meilleur déroulement des activités du projet. Il est principalement

96
question, dans cette section, de présenter les prévisions initiales et de faire une comparaison avec le
déroulement effectif du projet.

97
VI .1.3.1 Diagrammes de GANTT prévisionnel
Tableau 29: Diagramme prévisionnel

92
VI .1.3.2 Diagrammes de GANTT réel
Tableau 30: Diagramme de GANTT Rée

93
VI.1.4 Estimation des coûts du projet

L’estimation des charges prend en compte le coût des ressources matérielles, logicielles et humaines
nécessaires à la réalisation du projet.
Le tableau ci-dessous fait état des coûts et charges liés à notre projet.
Coût
Ressource Type Quantité Total
unitaire
Indemnité de stage Humain 5 50 000/mois 250 000
Ordinateur portable
LONOVO core i7 10e Matériel 1 750 000 750 000
Génération 8Go RAM
Clé USB Matériel 1 5 000 5 000
Licence windev Logiciel 1 - -
Licence wamp server Logiciel 1 - -
TOTAL 1 005 000 FCFA
VI.2 BILAN ET PERSPECTIVES

Au terme des cinq (5) mois qu’a duré notre stage, il est impératif de dresser le bilan de nos travaux et
d’envisager un avenir pour le projet qui nous a été confié. En dépit de quelques difficultés rencontrées
au quotidien, ce stage a été pour nous le moment d’effectuer un travail à la hauteur du titre d’ingénieur
auquel nous prétendons.
VI.2.1 Etat d’achèvement

Au cours de ce travail, il fallait mettre en place le module négoce et facturation d’un ERP
Facteur X qui permettra de gérer toutes les opérations commerciales (gestion des achats, de
ventes et de stock) d’une entréprise qui sont entre autres :
✓ La gestion des tiers (clients fournisseur )
✓ La gestion des Articles et familles d’article
✓ La gestion de Plan comptable et taux de taxe
✓ La gestion des document de ventes, des achats et stocks
✓ La gestion des échéanciers
✓ La gestion des règlement de factures

94
✓ La gestion des inventaires

✓ Imprimer les rapports (devis, bon de commande, bon de livraison, facture, bon de retour,
facture d’avoir)
✓ Consulter les articles du stock
✓ Chiffre d’affaire mensuel
✓ Chiffre d’affaire annuel
✓ Chiffre d’affaire réalisé par client, par article sur une période donnée
Durant ce stage, notre objectif principal à atteindre est de produire une première
version desktop avec les fonctionnalités de ces grands points précédemment cités.
A la fin de notre stage, nous pouvons dire que ces objectifs ont été globalement atteints.
Les différentes fonctionnalités étant testées et validées. Concernant la plateforme web et
mobile elles sont encours de developpement.
VI.2.2 Apports du stage
Ce stage a été d’un apport indéniablement significatif dans l’accomplissement de notre
formation. Comme point positif, nous pouvons souligner, entre autre, nos échanges avec une
équipe pluridisciplinaire de collaborateurs au sein de ARALAB’S et 2BN International. Notre
quotidien était enrichi de nouvelles expériences et de pratiques permettant de mieux
appréhender non seulement le métier d’ingénieur informaticien, mais aussi le rôle d’un
ingénieur dans une entreprise. Ce stage nous a aussi permis de suivre une méthodologie de
travail bien étudiée, d’approfondir nos connaissances dans le monde du développement
d’applications et de bien nous exercer à l’utilisation d’un AGL en occurrence WinDev.
Ces cinq mois de stage ont aussi été pour nous l’occasion d’épanouir nos capacités de
communication dans un environnement professionnel. Ce stage de fin de cycle, de façon plus
personnelle, a constitué une mine de connaissances qui a complété et enrichi celles acquises
durant nos trois années de formation.
VI.2.3 Difficultés rencontrées

Comme dans presque toute œuvre humaine, des obstacles nous sont apparus au cours de notre
stage. Loin de nous décourager, certaines de ces difficultés ont été pour nous une motivation
supplémentaire. Parmi ces difficultés rencontrées, nous pouvons citer :
✓ Le fossé entre les concepts théoriques appris et leur mise en pratique ;
✓ La familiarisation avec les concepts du domaine qui nous ont pris un peu de temps car
le domaine commercial et la comptabilité était pour nous un domaine totalement
étranger;

95
✓ L’environnement WinDev et WLangage étaient nouveaux pour nous et il fallait

répondre à tous objets fixés.
✓ Nous avons également rencontré des grandes difficultés pour la détermination de la
durée de certaines tâches
VI.2.4 Perspectives
Notre travail a permis de réaliser une première version fonctionnelle du module négoce et
facturation pour les clients lourd.
Cette version répond parfaitement aux exigences du cahier des charges. Nous envisageons de
perfectionner au fur et à mesure en intégrant de nouveau module telles que module Paie et RH
et module Production.

96
Notre travail a consisté à automatiser le processus de la gestion commerciale d’une

entreprise au travers d’un ERP. Après analyse des avantages et inconvénients des différentes
alternative, sans oublier les contraintes fixées, notre choix c’est porté sur le développement d’un
ERP sur mesure adapter au contexte local. Ce module a permis de gérer les achats, les ventes
et le stock des articles d’une entreprise; gérer le paiement des factures; éditer les devis, bons de
commandes ; enregistrer les bons de livraisons. gérer les clients, les fournisseurs enfin généré
les écritures comptables et avoir les statistiques des ventes. Le module permettra ainsi
d’augmenter la productivité de l’entreprise et éviter le problème de fragmentation de
l’information.
Nous avons abordé l'étude par une définition des contours du sujet et des concepts qui lui sont
liés. Nous avons ensuite dressé l'analyse et la conception du système, puis la mise en œuvre
pratique de la solution.
Ce travail nous a permis de mettre en application les connaissances théoriques, mais aussi
pratiques acquises au cours de nos années de formation ; d’approfondir nos connaissances sur
les méthodes agiles en générale le processus UP et XP en particulier; d’avoir une expérience en
matière de gestion des projets informatiques ; de renforcer notre capacité à travailler en équipe.
Toutefois, nous avons rencontré quelques difficultés durant ce stage. Il s’agit notamment du
fonctionnement modulaire de notre solution ; de l’utilisation du processus UP couplet a XP.
Au stade actuel, le résultat obtenu est satisfaisant. Néanmoins, il nous reste à développer la
version web et mobile de la solution ainsi que quelques modules supplementaires notament la
gestion des ressources humaines,Paie,production etc…
Par ailleurs le progiciel que nous avons développé sera proposé aux clients de 2BN
Internationnal pour gérer leurs activités

97
Architecture client-serveur. (2021). Récupéré sur Genov: https://www.geonov.fr/architecture-

client-serveur/
Du devis au paiement : les 4 étapes du processus d’achat. (2020). Récupéré sur Sage:
https://www.sage.com/fr-fr/blog/devis-paiement-processus-achat/
Home/Achats et Approvisionnements. (2020, Janvier). Récupéré sur Serge Bil Logistics:
https://sergebillogistics.blogspot.com/2017/06/quelle-difference-fondamentale-ya-t-
il.html
Le cycle de l'Extreme Programming. (13 novembre 2013). Récupéré sur Wikipedia:
https://fr.wikipedia.org/wiki/Extreme_programming#/media/Fichier:Extreme_program
ming.svg
Markus, T. e. (2000). ERP.
OHADA PLAN COMPTABLE. (2020). Récupéré sur www.droit-afrique.com:
http://www.droit-afrique.com/upload/doc/ohada/Ohada-Acte-Uniforme-2000-plan-
des-comptes.pdf
Plan comptable général 2020. (2020). Récupéré sur Comptabilité claire et intelligible:
https://www.comptabilisation.fr/pcg-plan-comptable-general.php
Présentation générale des ERP et leur architecture modulaire. (2020, Decembre). Récupéré
sur Developpez.com: https://fablain.developpez.com/tutoriel/presenterp/
Prix. (2020). Récupéré sur Le bon logiciel: https://lebonlogiciel.com/organisation-facturation-
et-planification-gestion-commerciale-erp-gpao/sap-erp/prix/27
Processus unifié : enchainements d'activités au cours du cycle de vie. (2020). Récupéré sur
Wikipedia:
https://fr.wikipedia.org/wiki/Processus_unifi%C3%A9#/media/Fichier:Processus_unif
i%C3%A9_-_enchainements_d'activit%C3%A9s_au_cours_du_cycle_de_vie.png
SUBRA, J.-P. (septembre 2019). SCRUM,Une méthode Agile pour vos projet (3e édition). Eni.
Récupéré sur Eni: https://www.editions-
eni.fr/open/mediabook.aspx?idR=b48d25ea277899fa9b04164796f9b7fc

xiv
Ouvrage
Cours sur ERP de Dr LILIA S Faxi et Dr Amine DRIRA INSAT :Date 15/02/2021
Fréderic Charles – « Cours ERP/PGI » : http://fr.slideshare.net/fcharles/cours-erp-introduction-aux-
erp-v10
P. ROQUES et F. VALLEE, UML2 en action – De l’analyse des besoins à la conception
P. ANDRE, E. DESMONTILS et A. VAILLY, Méthodes systémiques d’analyse et de
conception (A354), décembre 2014, 31 pages.
Valtech, Transition vers l’agilité à l’échelle d’une organisation, 2e éd., 2012, 111 pages.
P. ROQUES, UML 2 -Modéliser une application web, 4e éd., Paris: Eyrolles, Coll. Les
cahiers du programmeur, 246 pages.
P. ROQUES, UML 2 par la pratique, 5e éd., Paris: Eyrolles, Coll. Les cahiers du
programmeur, 364 pages.
S. KOUSSOUBE, Méthodes et processus de développement objet, dans le cadre du
cours d’UML en 2AING à l’IAI, 2019, 133 diapositives.
Mémoires
ALI TASSIOU Abass, Mémoire d'ingénieur IAI 2014-2015

xv

Memoire Mouamadje Thierry Aing - Maj-Final

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Memoire Mouamadje Thierry Aing - Maj-Final

Transféré par

Droits d'auteur :

Formats disponibles

Institut Africain d’Informatique (IAI) Société de Services en Ingénierie Informatique(SSII)

CO MEMOIRE DE FIN DE CYCLE

CONCEPTION ET REALISATION D’UN ERP MULTI

Réalisé et soutenu par :

Superviseur IAI Maître de stage

Année académique 2019-2020

LISTE DES TABLEAUX .................................................................................................... vi

LISTE DES FIGURES ........................................................................................................ vii

ABSTRACT ........................................................................................................................ xii

ABREVIATIONS .............................................................................................................. xiii

AVANT PROPOS ................................................................................................................xv

PARTIE I : CONTEXTE GENERAL DE L’ETUDE ..............................................................2

CHAPITRE I : LA STRUCTURE D’ACCUEIL ET LE SUJET .........................................3

I. LA STRUCTURE D’ACCUEIL ..................................................................................3

I.1 Présentation ...........................................................................................................3

I.2 Organisation et fonctionnement .............................................................................3

I.2.1 Direction Générale (DG) .................................................................................3

I.2.2 Direction Administrative et Financière (DAF) .................................................3

I.2.3 Direction Commerciale et Marketing (DCM) ..................................................3

I.2.4 Direction Technique (DT) ...............................................................................4

I.3 Missions ................................................................................................................4

I.4 Localisation ...........................................................................................................5

II. PRESENTATION DU SUJET ...................................................................................6

II.1 Libellé du sujet .....................................................................................................6

II.2 Contexte du sujet ..................................................................................................6

II.3 Intérêt du projet ....................................................................................................6

II.4 Problématique ......................................................................................................7

CHAPITRE II : ETUDE GENERALE DU SUJET .............................................................9

MOUAMADJE Thiery Mémoire de fin de cycle ingénieur (2017-2021) i

II.1.1 Définition ..........................................................................................................9

II.1.2 Présentation de l’ERP ........................................................................................9

II.1.3 Architecture .......................................................................................................9

II.1.3.1 Architecture technique ................................................................................9

II.1.3.2 Architecture modulaire..............................................................................10

II.1.3.3 Le paramétrage ......................................................................................... 11

II.1.3.4 Le workflow ............................................................................................. 11

II.1.4 Avantages et Inconvénients d’un ERP ............................................................. 13

II.2 GESTION COMMERCIALE ................................................................................. 14

II.2.1 Enjeux de la gestion commerciale .................................................................... 14

II.2.2 Gestion d’achat et approvisionnement.............................................................. 15

II.2.2.1 Définition ................................................................................................. 15

II.2.2.2 Processus d’un Achat ................................................................................15

II.2.2.3 L'enregistrement comptable d'une facture d’achat ..................................... 17

II.2.3 Gestion de vente .............................................................................................. 19

II.2.3.1 Définition ................................................................................................. 19

II.2.3.2 Processus de vente .................................................................................... 19

II.2.2.3 L'enregistrement comptable d'une facture de vente .................................... 20

II .2.4 Gestion des stocks .......................................................................................... 22

II.2.4.1 Définition ................................................................................................. 22

II.2.4.2 Processus stock ......................................................................................... 22

CHAPITRE III : ÉTUDE DE L’EXISTANT .................................................................... 24

III.1 QUELQUES SOLUTIONS EXISTANTES........................................................... 24

III.1.1 Les ERP propriétaires ..................................................................................... 24

III.1.1 Les ERP Open source ..................................................................................... 25

III.2 CRITIQUE DE L’EXISTANT ..............................................................................26

MOUAMADJE Thiery Mémoire de fin de cycle ingénieur (2017-2021) ii

III.2.1 Problématique ................................................................................................ 26

III.2.2 Alternative ..................................................................................................... 26

III.2.3 Solution retenue ............................................................................................. 26

III.2.4 Justification .................................................................................................... 26

PARTIE II : ANALYSE ET CONCEPTION ........................................................................ 27

CHAPITRE III : CHOIX DE LA METHODE D’ANALYSE ET DE CONCEPTION ......28

III.1 LANGAGE DE MODELISATION OBJET : UML ...............................................28