Conception Et Mise en Place D Un Outil D

MINISTERE DE L’ENSEIGNEMENT SUPERIEUR MINISTERE DE L’ENSEIGNEMENT SUPERIEUR,
ET DE LA RECHERCHE DE LA RECHERCHE ET DE L’INNOVATION

(TOGO) (FRANCE)
01 BP 1515 Lomé 01 – TOGO UTBM – 90010 BELFORT CEDEX

Tel : (0028) 22 25 33 29 Fax : (0028) 22 21 85 95 Tel : +33 (0) 3 84 58 30 00 Fax : +33 (0) 3 84 58 30 30
Site web : www.univ-lome.tg Site web : www.utbm.fr
N° d’ordre : 0016GL
MEMOIRE DE FIN DE FORMATION

pour l’obtention du diplôme de
MASTER INFORMATIQUE
Spécialité : Génie Logiciel
Thème :
CONCEPTION ET MISE EN PLACE

D’UN OUTIL D’ANALYSE FINANCIERE PREVISIONNELLE
DES ENTREPRISES DEMANDEUSES DE CREDITS
Soutenu le 19/09/2018 par :
TSOGBETSE Israël Kodjo
Devant le Jury composé de
Président : M. PINDRA Nadjime, Maître de Conférences
Examinateur : M. HOETOWOU Yaovi, Ingénieur de Conception en Informatique
Directeur de mémoire : M. ATCHONOUGLO Kossi, Maître de Conférences
Maitre de stage : M. KPEGLO Boris, Ingénieur Informaticien

Conception et mise en place d’un outil d’analyse financière prévisionnelle des entreprises demandeuses de crédits
DEDICACE
Je dédie ce mémoire à mes Parents
Mémoire de Master – TSOGBETSE I. K. i CIC - UTBM

REMERCIEMENTS
Nous exprimons nos reconnaissances
 à Monsieur ATCHONOUGLO Kossi, Directeur du CIC et Directeur de ce mémoire

pour sa foi en la formation et aussi pour avoir bien voulu diriger la rédaction de ce
mémoire ;
 à Monsieur LAMROUS Sid, co-responsable de la formation master à UTBM, pour sa

contribution à l’instauration de cette formation ;
 à Monsieur BOROZE Tchamye Tcha-Esso, Directeur Adjoint du CIC et à Monsieur

AGBETI Kodjo, Représentant Résidant de l’IAI-TOGO, pour leur dévouement
exprimé dans la réussite de la formation ;
 à Monsieur DOGBO Yao Dodzi, PDG de CERGI SA, de nous avoir permis d’effectuer
ce stage au sein du service informatique de sa société ;
 à Monsieur KPEGLO Boris, Ingénieur Informaticien, Directeur Technique Adjoint à

CERGI SA et Maître de stage de ce projet pour sa disponibilité et son encadrement ;
 aux membres du jury qui ont accepté ce travail ;
 au corps professoral de CIC-UTBM pour la qualité de la formation ;
 à Monsieur DOLEAGBENOU Rodrigue, Chef Projet à CERGI SA, qui nous a fait
profiter de ses connaissances et de sa grande expérience ;
 aux membres de la Team Scoring, nommément Monsieur KASSA Stéphane,

Monsieur KOLEVI Kokou et Monsieur MUGIRANEZA Oscar pour leur assistance et
leur soutien dans la réalisation de ce projet ;
 à Monsieur NONDOH-ADABI Noël du service informatique interne de CERGI SA

pour son appui technique ;
 à Monsieur ALLAGBE Etse Essi, Chef Projet Sénior à CERGI SA, pour ses instructions
ainsi qu’à l’ensemble du personnel de CERGI SA, témoignant de la bonne ambiance
dans laquelle nous avons évolué durant cette période de stage ;
 à nos camarades de la promotion 2016-2018 pour l’esprit de partage et d’entraide ;
 à nos parents, proches et amis pour la confiance que vous portez en nous ;
 à toutes les personnes qui ont aidé d’une manière ou d’une autre à la réalisation de
ce mémoire.
Mémoire de Master – TSOGBETSE I. K. ii CIC - UTBM

RESUME
Le risque de crédit, selon De Servigny A. et Zeleko I. (2010), est le premier risque qu’une
banque est appelée à supporter. Il désigne le risque de défaillance d’une contrepartie
(client) sur laquelle est détenue une créance ou un engagement. Ce mémoire de fin de
formation s’intéresse à l’appréciation de ce risque. Afin de mesurer la solvabilité présente
et future d’une contrepartie, les banques utilisent comme méthode principale d’évaluation,
l’analyse financière. Notre travail ambitionne de mettre à la disposition des établissements
de crédits une solution informatique permettant d’effectuer l’étude des dossiers de
demande de prêts. Et plus particulièrement les projets de création ou d’extension
d’entreprise. D’où le thème : « Conception et mise en place d’un outil d’analyse financière
prévisionnelle des entreprises demandeuses de crédits ». Cet outil permettra aux analystes
financiers de produire des états financiers objectifs tout en s’assurant de la disponibilité,
de la cohérence et de la pérennité des données manipulées. Pour établir une bonne base
au travail, une étude du cahier des charges a été faite. Cette étude préalable a permis de
centrer la problématique, de définir l’intérêt du sujet et de ressortir une critique
constructive de l’existant. La solution retenue après la critique est le développement d’une
application. Elle définit la ligne directrice qui nous a mené à la phase d’analyse et
conception. Dans ce chapitre, le système à mettre en place a été modélisé à travers
plusieurs diagrammes qui s’inscrivent dans une approche objet jugée convenable pour ce
projet. Cette approche justifie l’utilisation du langage de modélisation UML (Unified
Modeling Language) couplé avec le processus 2TUP (Two Track Unified Process). Le 2TUP
a permis de décomposer le système sur ses axes fonctionnel et technique. Ces deux (2)
axes produiront respectivement une analyse fonctionnelle (statique et dynamique) et une
conception générique. De leur fusion naîtra la conception détaillée du système. Après la
modélisation, la réalisation a été effective grâce au Système de Gestion de Base de Données
(SGBD) SQL Server et à la technologie ASP .NET MVC avec leurs corollaires.
Mémoire de Master – TSOGBETSE I. K. iii CIC - UTBM

ABSTRACT
Credit risk, according to De Servigny A. and Zeleko I. (2010), is the first risk that a bank is
called upon to bear. It refers to the risk of default by a counterparty (client) on which a loan
or commitment is held. This end-of-training thesis focuses on the valuation of this risk. In
order to measure the present and future creditworthiness of a counterparty, banks use
financial analysis as their main valuation method. Our work aims to provide credit
institutions with an IT solution for studying loan applications. And more particularly
projects for the creation or extension of a company. Hence the theme : "Design and
implementation of a tool for financial forecasting analysis of companies requesting credit".
This tool will enable financial analysts to produce objective financial statements while
ensuring the availability, consistency and durability of the data being manipulated. To
establish a good basis for the work, a study of the specifications was carried out. This
preliminary study made it possible to focus the problem, to define the interest of the
subject and to bring out a constructive criticism of the existing situation. The solution
chosen after the criticism defines the guideline that led us to the analysis and design phase.
In this chapter, the system to be implemented has been modelled through several diagrams
that are part of an object approach considered appropriate for this project. This approach
justifies the use of the UML (Unified Modeling Language) modeling language coupled with
the 2TUP (Two Track Unified Process) process. The 2TUP allowed the system to be broken
down into its functional and technical axes. These two (2) axes will produce a functional
analysis (static and dynamic) and a generic design. From their merger will come the detailed
design of the system. After the modeling, the realization was effective by the means of the
SQL Server Database Management System (DBMS) and ASP.NET MVC technology with
their tools.
Mémoire de Master – TSOGBETSE I. K. iv CIC - UTBM

SOMMAIRE
DEDICACE................................................................................................................................................................. i
REMERCIEMENTS ................................................................................................................................................. ii
RESUME .................................................................................................................................................................. iii
ABSTRACT .............................................................................................................................................................. iv
SOMMAIRE ............................................................................................................................................................. v
LISTE DES PARTICIPANTS ...............................................................................................................................vii
LISTE DES TABLEAUX ...................................................................................................................................... viii
LISTE DES FIGURES ............................................................................................................................................. ix
GLOSSAIRE.............................................................................................................................................................. x
INTRODUCTION GENERALE ............................................................................................................................1
CHAPITRE 1 : CADRE D’ETUDE ...................................................................................................................2
1. PRESENTATION DU CIC-UL ....................................................................................................................3
2. PRESENTATION DE L’UTBM ...................................................................................................................3
3. PRESENTATION DE CERGI SA ................................................................................................................4
CHAPITRE 2 : ETUDE DU CAHIER DES CHARGES ..............................................................................8
1. PROBLEMATIQUE ET PRESENTATION DU SUJET ...........................................................................9
2. ETUDE ET CRITIQUE DE L’EXISTANT ................................................................................................ 11
3. PROPOSITIONS ET CHOIX DE SOLUTION ..................................................................................... 14
4. PLANNING PREVISIONNEL DE REALISATION .............................................................................. 17
CHAPITRE 3 : ANALYSE ET CONCEPTION .......................................................................................... 20
1. PRESENTATION DE LA METHODE D’ANALYSE ............................................................................ 21
2. PRESENTATION DE L’OUTIL DE MODELISATION ....................................................................... 23
3. ETUDE DETAILLEE DE LA SOLUTION................................................................................................ 24
CHAPITRE 4 : REALISATION ET MISE EN OEUVRE ........................................................................ 56
1. MISE EN ŒUVRE ...................................................................................................................................... 57
2. PRESENTATION DE L’APPLICATION ................................................................................................. 64
CHAPITRE 5 : EXPLOITATION................................................................................................................... 69
1. CONFIGURATION MATERIELLE ET LOGICIELLE ........................................................................... 70
Mémoire de Master – TSOGBETSE I. K. v CIC - UTBM

2. DEPLOIEMENT ET SUIVI ........................................................................................................................ 71

CHAPITRE 6 : UTILISATION ....................................................................................................................... 75
2. MAINTENANCE......................................................................................................................................... 80
CONCLUSION GENERALE .............................................................................................................................. 81
REFERENCES BIBLIOGRAPHIQUES ............................................................................................................. 82
TABLE DES MATIERES ...................................................................................................................................... 84
ANNEXES .............................................................................................................................................................. 89
Mémoire de Master – TSOGBETSE I. K. vi CIC - UTBM

LISTE DES PARTICIPANTS
Intervenants Fonctions Rôles
TSOGBETSE Etudiant en 2ème année de master

Réalisateur
Israël Kodjo Génie Logiciel /CIC-UTBM
M. ATCHONOUGLO Maître de Conférences à l’Université de Lomé Directeur de

Kossi Directeur du CIC mémoire
M. KPEGLO Ingénieur Informaticien Maître de

Boris Directeur Technique Adjoint à CERGI SA stage
M. DOLEAGBENOU Développeur d’applications Référent

Rodrigue Chef projet à CERGI SA métier
Mémoire de Master – TSOGBETSE I. K. vii CIC - UTBM

LISTE DES TABLEAUX
Tableau 1 : Planning prévisionnel ...................................................................................................................................................17

Tableau 2 : Cas d'utilisation du projet ..........................................................................................................................................25
Tableau 3 : Packages et détails ........................................................................................................................................................36
Tableau 4 : Description de la classe " DOSSIER "......................................................................................................................54
Tableau 5 : Description de la classe " FORMULE " ...................................................................................................................54
Tableau 6 : Description de la classe " INDICATEUR " ..............................................................................................................55
Tableau 7 : Description de la classe " PRET " .............................................................................................................................55
Tableau 8 : Coût matériel correspondant à l’architecture de déploiement ...................................................................62
Tableau 9 : Coût des licences d'utilitaires....................................................................................................................................63
Tableau 10 : Coût humain de la solution .....................................................................................................................................63
Tableau 11 : Configuration matérielle requise ..........................................................................................................................70
Tableau 12 : Maintenance des erreurs courantes.....................................................................................................................80
Mémoire de Master – TSOGBETSE I. K. viii CIC - UTBM

LISTE DES FIGURES
Figure 1 : Organigramme de CERGI SA .......................................................................................................................................... 6

Figure 2 : Plan de localisation de CERGI SA .................................................................................................................................. 6
Figure 3 : Diagramme de Gantt du planning prévisionnel ...................................................................................................18
Figure 4 : Processus de développement en Y ............................................................................................................................23
Figure 5 : Diagramme de cas d'utilisation " Gestion des dossier " ....................................................................................27
Figure 6 : Diagramme de cas d'utilisation " Transcription des données d'analyse " ..................................................28
Figure 7 : Diagramme de cas d'utilisation " Production des documents comptables et états " ...........................29
Figure 8 : Diagramme de cas d'utilisation " Paramétrage "..................................................................................................29
Figure 9 : Diagramme de cas d'utilisation " Administration système " ............................................................................30
Figure 10 : Diagramme de classes participantes " Gérer les investissement " ..............................................................34
Figure 11 : Diagramme de classes participantes " Gérer les objectifs de production ou de consommation " 35
Figure 12 : Diagramme de classes participantes " Gérer les amortissements d'emprunt " .....................................35
Figure 13 : Diagramme de classes participantes " Consulter les comptes d'exploitation et le BFR " ..................35
Figure 14 : Diagramme de packages .............................................................................................................................................37
Figure 15 : Diagramme d'activités " Rééchelonner dossier " ...............................................................................................38
Figure 16 : Diagramme d'activité " Définir taux d'exécution " ............................................................................................39
Figure 17 : Diagramme de séquences " Gérer utilisateur "...................................................................................................40
Figure 18 : Diagramme de séquences " Gérer amortissement emprunt "......................................................................41
Figure 19 : Diagramme de déploiement ......................................................................................................................................44
Figure 20 : Diagramme de composants .......................................................................................................................................45
Figure 21 : Diagramme de classes " Administration système "...........................................................................................46
Figure 22 : Diagramme de classes " Paramétrage ".................................................................................................................47
Figure 23 : Diagramme de classes " Gestion dossier " ...........................................................................................................48
Figure 24 : Diagramme de classes " Gestion investissement " ............................................................................................49
Figure 25 : Diagramme de classes " Production & Consommation " ...............................................................................50
Figure 26 : Diagramme de classes " Amortissement emprunt " .........................................................................................51
Figure 27 : Diagramme de classes " Documents transversaux ".........................................................................................52
Figure 28 : Diagramme de classes global ....................................................................................................................................53
Figure 29 : Maquette de l'application ...........................................................................................................................................64
Figure 30 : Arborescence des menus de l'application ............................................................................................................65
Figure 31 : Concept MVC ...................................................................................................................................................................65
Figure 32 : Formulaire de création de dossier ...........................................................................................................................66
Figure 33 : Formulaire de matière première en fenêtre modale ........................................................................................67
Figure 34 : Ecran des investissements détaillés .........................................................................................................................67
Figure 35 : Ecran des objectifs de consommation de matières premières .....................................................................68
Figure 36 : Ecran de connexion........................................................................................................................................................76
Figure 37 : Ecran d'accueil .................................................................................................................................................................77
Figure 38 : Ecran de recherche de dossier ..................................................................................................................................78
Figure 39 : Ecran de fiche signalétique de dossier ...................................................................................................................79
Figure 40 : Ecran paramètres de dossier ......................................................................................................................................79
Mémoire de Master – TSOGBETSE I. K. ix CIC - UTBM

GLOSSAIRE
ATULL Association Togolaise des Utilisateurs de Logiciels Libres

ASP Active Server Pages
BCEAO Banque Centrale des États de l'Afrique de l'Ouest
BEAC Banque des États de l'Afrique Centrale
BFR Besoin en Fonds de Roulement
CIC Centre Informatique et de Calcul
CGI Common Gateway Interface
CEMAC Communauté Economique et Monétaire des Etats de l’Afrique Centrale
CERGI Conseil Etude Réalisation et Gestion Informatique
DAAS Direction des Affaires Administratives et Scolaires
GL Génie Logiciel
IBIS Integrated Banking Information System
LABTIC Laboratoires des Technologies de l’Information et de la Communication
OCAM Organisation Commune Africaine et Mauricienne
SQL Structured Query Language
SRI Systèmes et Réseaux Informatiques
TRI Taux de Rentabilité Interne
2TUP Two Track Unified Process
UML Unified Modeling Language
UEMOA Union Economique et Monétaire des Etats de l’Afrique de l’Ouest
UL Université de Lomé
UTBM Université de Technologie de Belfort Montbéliard
Mémoire de Master – TSOGBETSE I. K. x CIC - UTBM

INTRODUCTION GENERALE
Dans sa grande mission de pallier les insuffisances humaines en matière de calcul, de

conservation d’informations et de gestion des entreprises, l’informatique est présente dans
la quasi-totalité des domaines de la vie professionnelle et privée. Grâce aux progrès
fulgurants en électronique et en automatisation, elle occupe bien évidemment une place
importante dans les sciences appliquées, les industries, les entreprises, l’enseignement, les
banques, les assurances ou encore le commerce.
La technologie joue un rôle clé dans l’industrie bancaire, pour faciliter la gestion des
opérations comptables et des services. Au fil des décennies, la banque a évolué grâce à
l’informatique (Mounier-Kuhn, 2013). Néanmoins, en dehors des nouvelles solutions
bancaires à l’instar du mobile Banking, les systèmes d’information bancaires sont
aujourd’hui en lente progression vers le web. Afin de contribuer à cette migration des
systèmes informatiques bancaires vers le web, nous avons effectué notre stage du 26 mars
au 14 septembre 2018 à CERGI SA, une société d’ingénierie de services informatiques
bancaires. Nous avons eu à développer une application qui permettra aux institutions de
crédits de faire l’étude des dossiers de demande de prêt en vue de déterminer leur
éligibilité. Le projet est formulé autour du thème de mémoire de fin de formation :
« Conception et mise en place d’un outil d’analyse financière prévisionnelle des
entreprises demandeuses de crédits ».
Ce document a pour objet de fournir un rapport détaillé sur les étapes suivies pour la
réalisation du projet. Il est subdivisé en six (6) chapitres. Le premier chapitre présentera le
cadre théorique et pratique de l’étude. Le deuxième se chargera de l’étude du cahier des
charges qui n’est rien d’autre que l’étude préliminaire du sujet. Il comprend la
problématique, la présentation du sujet et son intérêt, l’étude et la critique de l’existant, les
propositions et choix de solution puis le planning prévisionnel de réalisation. Le chapitre
trois du mémoire sera consacré à l’analyse et à la conception. Dans cette partie, la méthode
d’analyse et l’outil de modélisation seront présentés. Ensuite la modélisation proprement
dite sera exposée dans l’étude détaillée de la solution. Après l’étape de modélisation, nous
passeront au chapitre consacré à la réalisation et à la mise en œuvre. Ce dossier présente
les outils matériels et logiciels utilisés dans le processus de développement de même que
l’application de par son architecture, ses interfaces et ses codes sources. Le chapitre suivant
est celui destiné à l’exploitation. Il précise les configurations matérielles et logicielles
nécessaires à une bonne exploitation de la solution. Il fournit aussi les procédures de
déploiement et de suivi de l’application. Enfin, le dernier chapitre permet à l’utilisateur final
de prendre en main le produit.
Mémoire de Master – TSOGBETSE I. K. Page 1 sur 103 CIC - UTBM

CHAPITRE 1 : CADRE D’ETUDE
Premier chapitre
CADRE D’ETUDE

Cadre d’étude
INTRODUCTION
Le présent projet implique trois (3) institutions. Sur le plan pédagogique, notre formation
est le fruit du partenariat entre l’Université de Lomé (UL) par le biais du CIC et l’Université
de Technologie de Belfort Montbéliard (UTBM). En vue de préparer les étudiants à
l’insertion professionnelle, un stage pratique en entreprise est inclus dans le programme
de formation. Dans le cadre de ce stage, notre structure d’accueil est une société de
développement de services informatiques bancaires. Elle est dénommée CERGI SA.
Cependant, le travail qui nous incombe ne porte pas sur CERGI mais plutôt sur les activités
de ses clients. Afin de mieux définir le périmètre du sujet, nous avons été placés dans le
contexte d’un établissement de crédit de la sous-région.
Dans cette première partie, les institutions participantes au projet seront présentées.
1. PRESENTATION DU CIC-UL
Le Centre Informatique et de Calcul (CIC) est une école de formation supérieure créée en
1988. Situé dans l’enceinte de l’Université de Lomé et sous sa présidence, ses locaux
s’érigent en face de la Direction des Affaires Administratives et Scolaires (DAAS).
Avec pour objectif d’assurer une formation technologique répondant aux demandes du
marché, le CIC forme en Génie Logiciel (GL) et en Systèmes et Réseaux Informatiques (SRI).
Jusqu’en 2015, la Licence Professionnelle était le seul diplôme délivré au bout de trois (3)
années de formation. Depuis février 2016, le CIC sous l’égide de l’Université de Lomé, en
partenariat avec l’Université de Technologie de Belfort Montbéliard a mis sur pied, avec la
participation active de l’Institut Africain d’Informatique, un master international en
informatique. Ce master couvre deux (2) ans et permet aux diplômés de cycle licence de
poursuivre leurs études en bénéficiant d’une formation avancée.
Par ailleurs, le Centre Informatique et de Calcul abrite en son sein une académie CISCO, un
laboratoire de logiciels libres (LABTIC) de même que l’Association Togolaise des Utilisateurs
de Logiciels Libres (ATULL).
2. PRESENTATION DE L’UTBM
Créée en 1999, l’Université de Technologie de Belfort Montbéliard (UTBM) est un

établissement public à caractère scientifique, culturel et professionnel. Membre du réseau
des universités de technologie en France, elle est née de la fusion de deux établissements
d’enseignement supérieur : l’Ecole Nationale d’Ingénieurs de Belfort (1962) et l’Institut

Cadre d’étude
Polytechnique de Sevenans (1985). L’UTBM compte plus de 3000 étudiants locaux comme
internationaux en formation d’ingénieur, masters et doctorat. Elle offre 9 formations
d’ingénieurs, 7 masters et 3 unités de recherche (UTBM, 2017).
Au sein du parterre des universités partenaires de l’UTBM figure l’Université de Lomé.
3. PRESENTATION DE CERGI SA
Défini comme Conseil Etude Réalisation et Gestion Informatique, CERGI SA est une société
anonyme de développement de services informatiques bancaires. Grâce à son réseau
d’ingénieurs, d’experts et de partenaires, les solutions logicielles développées par CERGI
sont exploitées par des institutions financières réparties dans les espaces UEMOA (Union
Economique et Monétaire des Etats de l’Afrique de l’Ouest) et CEMAC (Communauté
Economique et Monétaire des Etats de l’Afrique Centrale).
Le cabinet CERGI a pour objectif d’apporter un appui stratégique et couvrir la totalité des
fonctionnalités métiers et supports des banques et établissements financiers dans le strict
respect des instructions des autorités de régulation (BCEAO, BEAC) et des législations
internationales. Il nourrit ainsi la vision d’offrir des solutions logicielles de gestion les plus
adaptées aux activités et à l’évolution du secteur bancaire et financier africain.
3.1. Statut
L’entreprise prend la dénomination de : Conseil Etude Réalisation et Gestion Informatique
par abréviation CERGI. Créée à Abidjan (Côte d’Ivoire) en 1991 à l’initiative de M. Yao Dodzi
DOGBO, CERGI Afrique Sarl est née du rachat du fonds de commerce de la filiale africaine
du Groupe français, Société Générale de services et de Gestion (SG2-Afrique).
Devenue en 2003 CERGI Banking Services SA, elle a poursuivi sa structuration en 2015 avec
la création de CERGI SA à Lomé en vue d’une configuration de Groupe. CERGI SA étant
reconnu légalement comme Société Anonyme siégeant à Lomé (TOGO), quartier Avenou,
5330 Immeuble Eros 2ème étage, Boulevard du 30 Août.
3.2. Mission
CERGI a pour mission de fournir aux banques et établissements financiers (Fonds de
Garantie, Crédit-Bail et Leasing, Systèmes Financiers Décentralisés) un progiciel de gestion
bancaire. Ce progiciel dénommé IBIS (Integrated Banking Information System) se veut
intégré, complet, fortement paramétrable, performant et économique, le tout conçu
strictement selon les instructions des autorités de régulation.

Cadre d’étude
3.3. Activités
Les activités de la société sont multiples. Elles consistent entre autres à :
౼ développer des modules évolutifs de services bancaires ;

౼ déployer, configurer et assurer le suivi des solutions IBIS auprès des banques et
institutions financières clientes ;
౼ offrir aux utilisateurs une formation de qualité en vue d’un transfert de compétences
efficient pour l’exploitation optimale du Core Banking ;
౼ assurer des services de maintenance de proximité pour apporter dans les meilleurs
délais, une assistance de qualité à la clientèle ;
౼ garantir une téléassistance à travers des infrastructures de télémaintenance, help
desk, hotline, FAQ.
3.4. Quelques réalisations

Au chapitre des réalisations de CERGI, on compte les 64 modules du progiciel IBIS autour
des 14 centres d’intérêt que sont :
౼ Noyau comptable
౼ Sécurité
౼ Gestion commerciale
౼ Opérations d’agence
౼ Gestion des engagements
౼ Crédit-Bail
౼ Fonds de Garantie
౼ Trésorerie
౼ Déclarations réglementaires
౼ Mobile Banking
౼ E-Banking
౼ Business Intelligence
౼ Moyens Généraux
౼ Interfaces
Par ailleurs, le cabinet possède à son actif, une plateforme de notation de contreparties
dénommée Scoring Center.

Cadre d’étude
3.5. Organigramme
La figure 1 dresse l’organigramme de CERGI SA.
ASSEMBLÉE GÉNÉRALE
CONSEIL D'ADMINISTRATION
CABINETS EXTERNES
-JURIDIQUE & FISCAL PRÉSIDENT DIRECTEUR SECRÉTARIAT
GÉNÉRAL
-BANQUE & FINANCE
DIRECTEUR GÉNÉRAL
ADJOINT
DIRECTEUR ADMINISTRATIVE DIRECTEUR COMPTABLE &

& COMMERCIAL FINANCIER DIRECTEUR TECHNIQUE
DIRECTEUR
Administration & Comptabilité Finance TECHNIQUE ADJOINT
Marketing
Relations publiques
Recherche,
Informatique Développement
Innovaton Tech.
interne & Maintenance
& Etude
Figure 1 : Organigramme de CERGI SA
3.6. Plan de localisation

La société CERGI SA est située à Lomé, quartier Avenou, au 2ème étage de l’immeuble Eros
5330 au bord du boulevard du 30 août comme l’illustre la figure 2.
Figure 2 : Plan de localisation de CERGI SA

Cadre d’étude
CONCLUSION
Ce stage recommandé par la formation du master CIC-UTBM, se déroule à CERGI SA. Et le

projet qui nous est confié est axé sur le volet gestion du risque crédit des activités des
établissements financiers.
Le contexte du projet étant défini, l’étude du cahier des charges représente la prochaine
étape.

CHAPITRE 2 : ETUDE DU CAHIER DES CHARGES
Deuxième chapitre
ETUDE DU CAHIER
DES CHARGES

Etude du cahier des charges
INTRODUCTION
Le cahier des charges est le document formel qui traduit l’expression des besoins des
utilisateurs dans le cadre du projet. Il décrit également les solutions à mettre en œuvre
pour répondre aux attentes des utilisateurs. Aussi, ce document permet aux différentes
parties prenantes de s’accorder sur les objectifs et les résultats à atteindre à la fin du projet.
L’étude du cahier des charges servira de socle à la définition des spécifications et à la

conception du produit à réaliser. Plus loin, il fera objet de référence lors de l’évaluation de
la solution implémentée. Les grandes lignes de ce dossier portent sur la problématique et
la présentation du sujet, ensuite l’étude et la critique de l’existant, les propositions et choix
de solution puis le planning prévisionnel de réalisation.
1. PROBLEMATIQUE ET PRESENTATION DU SUJET
1.1. Problématique du sujet

Les projets de création, de reprise ou d’extension d’entreprise nécessitent souvent des
financements que les entrepreneurs sont incapables de fournir dans l’immédiat. Ces
derniers font donc recours aux prêts. L’incertitude quant à la possibilité ou la volonté des
clients de remplir leurs obligations représente pour les institutions financières un risque de
crédit. Le crédit étant une anticipation de recettes futures pour les institutions financières,
il comporte un risque d’insolvabilité qui augmente en période de récession (Bah O, 2008).
L’appréciation du risque d’insolvabilité a donc une importance capitale pour l’octroi ou le
refus d’un prêt bancaire. Un crédit n’est accordé que si le banquier estime que la probabilité
de remboursement excède celle de non-remboursement.
Ainsi, l’ensemble des traitements comptables qui permettent de donner une appréciation
sur les risques futurs liés à un projet représente l’analyse financière prévisionnelle. La
complexité de cette étude réside en partie dans son caractère prévisionnel. Les documents
analysés émanent d’une simulation financière établie le plus souvent sur une durée
minimale de trois (3) ans.
Le processus étant long et complexe, les analystes sont constamment confrontés à des
risques d’erreurs et à la lourdeur des traitements manuels. Ce qui traduit une lenteur dans
l’étude des projets. Aussi, le souci de disponibilité des données vis-à-vis des acteurs
impliqués reste une inquiétude. En ce qui concerne les interdépendances des données
manipulées, les défaillances dans le paramétrage engendre des incohérences.

Ainsi la quête d’efficacité dans les traitements, les calculs et les interprétations des
indicateurs financiers suscite quelques réflexions. Comment simplifier les tâches de
l’analyse financière prévisionnelle afin de réduire au maximum la marge d’erreur ?
Comment automatiser et optimiser les différents traitements ? Quelles méthodes utiliser
pour assurer un paramétrage souple et évolutif du métier ?
1.2. Présentation du sujet

En réponse à la problématique, et conformément à l’intégration des TIC dans la quasi-
totalité des secteurs d’activités, un outil informatique serait la solution la plus convenable.
Ce qui explique la formulation du thème de stage exprimé comme suit : « Conception et
mise en place d’un outil d’analyse financière prévisionnelle des entreprises
demandeuses de crédits ».
Il sera question dans un premier temps, d’étudier l’actuel système de gestion de institutions
financières en matière d’analyse financière prévisionnelle et d’en faire ressortir ses forces
et ses faiblesses. Ensuite, il faudra produire une solution informatique répondant aux
besoins tout en palliant les faiblesses décelées.
Le produit de ce projet prend corps dans un contexte de retraitement d’informations

purement comptables. Et il est destiné aux banques, aux fonds de garantie et aux autres
établissements de crédits. Il servira d’instrument pour la mesure de l’éligibilité au prêt dans
les cas de création et de reprise d’entreprise. La solution prendra en compte les entreprises
de tous les secteurs d’activités hormis les institutions financières.
1.3. Intérêt du sujet

1.3.1. Objectifs
L’objectif général du projet est d’équiper les établissements de crédits d’un outil comptable
leur permettant d’effectuer efficacement l’analyse financière prévisionnelle des projets de
leurs clients.
Plus spécifiquement, le produit devra permettre :
౼ de recueillir et de stocker de façon cohérente les données manipulées ;

౼ de constituer et de suivre de bout en bout les dossiers de prêt ;
౼ de générer automatiquement les données et documents intermédiaires ;
౼ de calculer automatiquement les ratios et les indicateurs financiers déductibles ;
౼ d’assurer la synchronisation des interdépendances suite aux mises à jour ;
౼ de fournir les états financiers ;

౼ de garantir la flexibilité et l’évolutivité des paramétrages ;

౼ d’assurer la disponibilité des informations tout en sécurisant les accès.
1.3.2. Résultats attendus

Les aboutissements souhaités du présent projet se dressent sur deux (2) volets :
 Sur le plan exploitation

౼ une gestion et un suivi efficaces des dossiers (prévisionnels financiers) ;
౼ les retraitements de l’analyse financière fortement assistés et pilotés par l’outil ;
౼ une exportation des états financiers ;
౼ une disponibilité des informations pour chaque acteur impliqué.
 Sur le plan pédagogique

౼ un dossier de conception et réalisation de la solution ;
౼ une version exploitable de la solution mise en place ;
౼ un guide d’exploitation et un guide d’utilisation.
2. ETUDE ET CRITIQUE DE L’EXISTANT
2.1. Etude de l’existant

Une connaissance claire et précise du système de gestion régissant actuellement l’analyse
financière au sein des établissements de crédit est fortement recommandée pour la
réalisation de ce projet. Dans cette dynamique, des interviews, des fiches de collecte
d’information et des recherches personnelles sont les moyens d’investigation utilisés. Parmi
nos sources, nous comptons notre maître de stage, son assistant et le département des
opérations de notre institution de référence.
L’analyse financière prévisionnelle peut être répartie dans les cinq (5) niveaux d’opérations
décrits ci-après :
 Constitution du dossier
C’est la première étape du processus d’analyse financière. Elle est enclenchée lorsque le
demandeur de crédit adresse au département des opérations les documents de son projet
y compris le business plan (plan financier). Un analyste (souvent un comptable) du
département des opérations se charge dès lors de la conduite de l’étude.

Pour les dossiers d’analyse financière, la banque dispose d’un fichier Excel personnalisable.
Ce fichier contient plusieurs feuilles qui représentent les différents documents d’indicateurs
financiers pilotant une analyse financière. Dans ce fichier, des macros sont implémentées
pour améliorer la navigation entre les feuilles. Ainsi, à chaque dossier de prêt son fichier
Excel.
Le prototype de fichier Excel est donc cloné pour le nouveau dossier de prêt réceptionné.
Ensuite l’analyste renseigne les informations générales (le nom du projet, l’unité des
données, l’année de réalisation, la nature du projet, etc.) dans la feuille dédiée.
(Voir Annexe a : Informations générales d’un dossier de prêt)
 Collecte des données
L’étude dans sa globalité est basée sur des informations chiffrées fournies avec le plan
financier du demandeur. L’analyste prend donc le temps de retranscrire toutes les données
dans les feuilles appropriées. Les feuilles concernent entre autres les investissements
détaillés, les taux d’exécution, les amortissements, les objectifs de production, le calendrier
de mobilisation des ressources, etc. Les futurs traitements reposent sur les données
collectées. (Voir Annexe b : Investissements détaillés, Annexe c : Objectifs de production et de CA)
 Retraitements et constitution des documents comptables intermédiaires
Les traitements étant récursifs, le jargon comptable désigne par retraitements les
différentes opérations effectuées sur les indicateurs financiers en vue d’obtenir d’autres
indicateurs avec des interprétations particulières. Pour ce faire, il est important de
paramétrer les feuilles en définissant les formules de toutes les données calculées. Ce
paramétrage est assuré par le département des opérations de concert avec le département
des risques.
A l’issue des retraitements, les documents comptables intermédiaires (coût investissement,

besoins en fonds de roulement, échéancier des investissements, tableau d’analyse des
charges, synthèse des emprunts, comptes d’exploitation prévisionnels, …) sont mis à jour
automatiquement conformément aux paramétrages préétablis. Les documents produits
dans l’étude peuvent être imprimés sous la forme de fichier PDF.
(Voir Annexe d : Comptes d’exploitation prévisionnels en PDF)
 Déduction du bilan prévisionnel et calcul des ratios
Les retraitements faits, le processus débouche sur les documents finaux que sont le bilan
prévisionnel et les ratios. Ces derniers indicateurs feront l’objet de référence lors de
l’interprétation des données.

Par ailleurs, des tests de sensibilité sont faits compte tenu de la variation éventuelle des
produits ou matières. Les résultats de ces tests sont répercutés sur les documents
comptables afin de prendre en compte une marge raisonnable en vue d’avoir des
prévisions plus réalistes. (Voir Annexe e : Bilan prévisionnel)
 Interprétations
La finalité de l’analyse financière prévisionnelle pour un établissement de crédits est de

déterminer si un projet est éligible ou pas à un prêt bancaire. Dans le contexte des fonds
de garantie, il s’agit de vérifier si l’on peut cautionner un prêt en mettant à disposition des
fonds comme garantie.
L’étude se termine par l’interprétation des résultats obtenus. Les interprétations prennent
en considération un lot d’éléments standards mais aussi d’autres facteurs internes de
l’institution. A la fin de son travail, l’analyste transmet le fichier Excel de même que ses
conclusions à la Direction Générale à qui revient la décision finale.
2.2. Critique de l’existant

Le système d’informations actuel répond tant bien que mal aux attentes des analystes.
Toutefois, il est sujet à certaines faiblesses et risques potentiels. Les informations ne sont
conservées que par duplication et archivage des fichiers Excel utilisés. Dans ces conditions,
les données ne sont pas à l’abri de perte ou d’altération aussi longtemps que l’accès aux
fichiers n’est pas restrictif. Aussi, l’archivage implique l’emploi des ressources
supplémentaires à l’instar du papier et des salles spécialisées. Ce qui représente des frais à
prendre en considération.
Par ailleurs, la collecte et surtout les retraitements des données comptables sont lourds,
souvent fastidieux et donc lents compte tenu du mode opératoire quasi-manuel en
vigueur. Face à cette situation, la possibilité d’incohérence et d’erreurs n’est pas exclue.
Ainsi, il se pose également le problème de fiabilité des résultats produits. Or étant dans un
environnement de finance, la moindre marge d’erreur est susceptible d’entraîner des
conséquences déplorables.
De plus, la méthode actuelle souffre d’un déficit de disponibilité et d’accessibilité des

informations en temps réel vis-à-vis des différentes parties prenantes, posant ainsi une
entorse à la fluidité du workflow. Les difficultés de suivi, de contrôle et d’évaluation sont
de ce fait récurrentes. En conséquence, il est compliqué d’avoir des informations claires et
concises en termes d’inventaire et de statistiques.
Au regard de ces insuffisances et vulnérabilités, les performances et la qualité de traitement

du système d’analyse financière sont à remettre en cause. Quelles sont alors les solutions
envisageables ?

3. PROPOSITIONS ET CHOIX DE SOLUTION
3.1. Spécifications de la solution

La solution à apporter requiert des spécifications qui peuvent être réparties en deux (2)
volets :
 L’aspect fonctionnel
 L’aspect sécurité
3.1.1. Aspect fonctionnel

La mission assignée consiste à faciliter l’analyse financière prévisionnelle dans les
institutions qui offrent du crédit et plus encore la garantie sur ces crédits. Il est question de
combler judicieusement les exigences et les contraintes relatives aux différentes
opérations.
La solution à apporter devra permettre :
౼ d’organiser le workflow en matière d’analyse ;

౼ de gérer les investissements, les productions et consommations ;
౼ de dresser l’amortissement des emprunts ;
౼ de mesurer les différentes rentabilités de l’activité projet ;
౼ de produire des états financiers décisionnels ;
౼ d’avoir un système d’information souple et évolutif aussi loin que l’analyse
financière est concernée.
3.1.2. Aspect sécurité

Les futurs utilisateurs du système possèdent différentes attributions. Dans ce cas de figure,
les droits d’utilisateurs et l’authentification nécessitent une attention particulière. Cela
implique que tout utilisateur de la solution doit être lié à un profil bien défini en fonction
de sa plage d’opérations encore appelée habilitations.
Les profils désignent des rôles qui doivent être quant à eux construits suivant un certain
nombre de contrôles granulaires sur des privilèges spécifiques.

3.2. Approches de solution

Considérant les tendances technologiques actuelles, les benchmarks des méthodes
d’organisation du travail (MOT), l’étude de l’existant et les IHM (Interfaces Homme-
Machine), il apparait clairement que la solution à apporter devra être un système
informatique.
Au sein du système d’information bancaire, bien qu’étant lentes au changement, les

applications informatiques sont progressivement en migration vers le web. Dans cette
dynamique, afin de répondre aux spécifications décrites plus haut, nous proposons deux
(2) solutions informatiques et plus précisément des applications web.
3.2.1. Première solution : acquisition d’une application

La première solution repose sur l’acquisition d’une application déjà disponible sur le
marché.
Nos recherches nous ont conduit à des solutions d’analyses rétrospectives d’entreprises
existantes sur lesquelles se base la projection dans le futur. Ayant en ligne de mire les
spécifications, certains logiciels d’élaboration de plan financier répondent un tant soit peu
aux critères. Parmi les trois (3) logiciels : Sage Analyse Financière, HannaH – HannaHLisa
et The Business Plan Shop, le dernier est celui que nous jugeons répondre au mieux à
l’aspect fonctionnel.
The Business Plan Shop est un logiciel en ligne qui accompagne les entrepreneurs pour
la création, la reprise et aussi le pilotage financier de leurs entreprises. Voici ses avantages
et inconvénients.
 Avantages :
౼ Il propose une gamme de fonctionnalités qui touchent pratiquement toutes les
fonctionnalités métiers de l’analyse financière prévisionnelle.
౼ Il est intuitif dans l’utilisation et ne nécessite pas de formation particulière.
౼ Il prend en compte les analyses à échelle mensuelle
౼ Il ne nécessite pas de frais d’installation, ni de maintenance
 Inconvénients :
౼ Il ne prend pas en compte les paramètres nécessaires pour une analyse approfondie
(coefficients d’inflation et de production, année de croisière, taux imposition, ...).
౼ Il est mono utilisateur.
౼ Sa durée d’étude maximale est limitée à cinq (5) ans.
౼ Il est impossible de modifier l’application pour le conformer aux besoins spécifiques.
(Voir Annexe f : The Business Plan Shop, Activité ; Annexe g : The Business Plan Shop, Résultats)

3.2.2. Deuxième solution : développement d’une application

La deuxième solution consiste à concevoir et à réaliser une application web
multiplateforme. Il s’agit de développer un logiciel interagissant avec une base de données
qu’il nous revient d’implémenter. Cette solution devra tenir compte de toutes les
spécifications décrites plus tôt. En voici les avantages et l’inconvénient.
 Avantages :
౼ La totalité des processus métiers et besoins spécifiques sera prise en compte.
౼ Les systèmes d’informations bancaires auront à disposition un outil complet et
évolutif en matière d’analyse financière prévisionnelle.
౼ La maintenance de l’application ne nous engendrera aucune difficulté majeure.
౼ Les acteurs (stagiaires) que nous sommes, auront renforcé leurs capacités et auront
acquis davantage d’expérience utile à notre carrière.
౼ Notre structure d’accueil, aura à son actif un module supplémentaire à
commercialiser.
 Inconvénient :
La complexité des retraitements comptables auxquels nous ne sommes pas familiers

pourraient porter entorse à la complétude du développement dans les délais impartis.
3.3. Solution retenue

Après études, analyses et comparaison des deux (2) propositions, le choix est porté sur le
développement d’une application qui répondra aux besoins spécifiques et tiendra compte
des divers paramètres. Elle représente la meilleure solution pour nous (stagiaire), pour la
structure d’accueil (CERGI SA) et également pour les institutions.
Les raisons qui expliquent notre choix sont essentiellement :
౼ l’absence ou l’incomplétude de certaines fonctionnalités dans la première solution ;

౼ l’impossibilité de réadaptation ;
౼ la première solution n’apporte aucune valeur ajoutée à notre structure d’accueil.
Le logiciel développé est une plateforme web. Pour cela, conformément à la politique
technique de l’entreprise, il sera utilisé les technologies ASP .NET et comme système de
gestion de base de données (SGBD), Microsoft SQL Server.

4. PLANNING PREVISIONNEL DE REALISATION
Le planning prévisionnel du travail est présenté dans le tableau 1 et le diagramme de Gantt

correspondant à la figure 3.
Tableau 1 : Planning prévisionnel
Activités Date de début Date de fin
Insertion et élaboration du planning 26 mars 29 mars
Collecte des informations 26 mars 06 avril
Elaboration du cahier des charges 03 avril 13 avril
Etude détaillée 16 avril 25 mai
Rédaction du dossier d’analyse et de conception 28 mai 01 juin
Programmation et validation des réalisations 04 juin 10 août
Rédaction du dossier de réalisation 13 août 14 août
Rédaction du dossier d’exploitation et du guide

14 août 17 août
d’utilisation
Tests du logiciel 25 juin 24 août
Pré-soutenance (présentation du projet / application) 27 août 29 août
Autres corrections 30 août 14 septembre

Cahier des charges
Figure 3 : Diagramme de Gantt du planning prévisionnel

Cahier des charges
CONCLUSION
Le cahier des charges présente de façon globale le système à mettre en place. Il comporte
les informations utiles pour la conception et le développement de l’application.
Dans ce document, il a été question de définir l’étendu du projet en nous appuyant sur
l’existant par rapport auquel une critique et des propositions de solutions ont été faites. Le
choix de la solution optimale et le planning prévisionnel de réalisation ont été les derniers
points qu’ont abordés le cahier des charges.

CHAPITRE 3 : ANALYSE ET CONCEPTION
Troisième chapitre
ANALYSE ET CONCEPTION

Analyse et Conception
INTRODUCTION
Le dossier d’analyse et de conception qui fait suite au cahier des charges représente une
étape indispensable dans la réalisation d’un projet informatique. Il décrit le fonctionnement
du système d’information à travers des abstractions présentées sous la forme de modèles.
Le présent projet consiste à mettre en place un outil d’analyse financière prévisionnelle en

prenant en compte l’étendu de cette dernière dans les fonds de garantie. Ceci étant, il faut
adopter une démarche pour la réalisation de ce module bancaire. Dans un premier temps,
nous présenterons la méthode d’analyse, dans un second temps l’outil de modélisation
puis suivra l’étude détaillée de la solution.
1. PRESENTATION DE LA METHODE D’ANALYSE
L’analyse et la conception des solutions informatiques ont connu deux (2) approches
majeures au fil du temps (Booch G et al, 1999) :
 L’approche systémique
 L’approche objet
L’approche systémique ou fonctionnelle repose sur la décomposition en sous-systèmes des

solutions informatiques. Elle reste un moyen efficace pour la conception des logiciels.
Cependant, l’évolution et la complexité croissante des systèmes informatiques font fléchir
cette approche devant les contraintes d’évolutivité.
Pour pallier ces insuffisances, l’approche objet a été introduite. Cette dernière s’appuie sur
la manipulation des objets à partir des langages et des méthodes. Sa vision externe définit
les actions qu’il sera possible de mener sur le système tandis que la vision interne prend
en compte sa structure.
Dans le cadre de ce projet, l’approche objet est celle retenue. En conséquence, parmi les
multiples méthodes, nous utiliserons le processus unifié 2TUP avec le langage UML.
1.1. Présentation du langage UML

Langage de modélisation unifié, UML (Unified Modeling Language) se définit comme un
langage de modélisation graphique et textuel destiné à comprendre et décrire des besoins,
spécifier et documenter des systèmes, esquisser des architectures logicielles, concevoir des
solutions et partager des angles de perception.

Le langage UML 2.0 s’articule autour de treize (13) diagrammes. Chacun d’eux est dédié à
la représentation d’un système logiciel suivant un point de vue particulier (Roques P, 2007).
Par ailleurs, UML modélise le système suivant deux modes de représentation :
 Les diagrammes structurels ou statiques

 Les diagrammes d’interaction ou dynamique
Ces deux représentations sont nécessaires et complémentaires pour schématiser la

composition du système et les interactions de ses composantes.
Dans la modélisation des solutions informatiques, UML ne propose pas l’ordre qui doit
régir les diagrammes. C’est ainsi que les méthodes viennent renforcer le langage pour
parfaire l’approche objet. Les méthodes imposent au langage l’ordre et la démarche. Pour
ce projet, nous retenons le processus 2TUP.
1.2. Présentation du processus 2TUP

Le 2TUP (2 Track Unified Process) est une méthode de développement qui implémente les
principes des Processus Unifiés. Un Processus Unifié possède plusieurs traits distinctifs :
౼ il est construit sur UML ;

౼ il est itératif et incrémental ;
౼ il est centré sur l’architecture ;
౼ il est conduit par les exigences de l’utilisateur ;
౼ il est piloté par les risques.
Le processus 2TUP apporte une réponse aux contraintes de changement continuel

imposées aux systèmes d’information. Dans cette dynamique, il renforce le contrôle sur
leurs capacités d’évolution et de correction.
La caractéristique principale du 2TUP consiste à constater que toute évolution imposée au

système d’information peut se décomposer et se traiter parallèlement, suivant un axe
fonctionnel et un axe technique. A l’issue des évolutions du modèle fonctionnel et de
l’architecture technique, la réalisation du système consiste à fusionner les résultats des deux
(2) branches, ce qui donne la forme d’un processus de développement en Y. La séparation
initiale permet de capitaliser à la fois la connaissance métier (branche gauche) et le savoir-
faire technique (branche droite). Les étapes préconisées par le 2TUP lors du développement
d’un système sont schématisées à la figure 4 (Roques P, 2007).

Branche fonctionnelle Branche technique
Capture des besoins Capture des besoins

fonctionnels techniques
Analyse Conception générique
Conception préliminaire
Conception détaillée
Codage et test
Recette
Figure 4 : Processus de développement en Y
2. PRESENTATION DE L’OUTIL DE MODELISATION
L’outil retenu pour la modélisation de notre analyse et conception est le Sybase

PowerDesigner 16.5. Dans ce chapitre nous répondrons à ces questions :
 Qu’est-ce que le PowerDesigner ?

 Quels sont les atouts de PowerDesigner ?
2.1. Qu’est-ce que PowerDesigner ?

PowerDesigner est une solution de modélisation et de gestion de métadonnées destinée
aux architectures de données, aux architectures d’informations et aux architectures
d’entreprise. PowerDesigner est l’édition international incluant la partie française
PowerAMC.
PowerDesigner prend en charge les méthodologies et notations de modélisation standard

et permet de procéder à la génération de code de façon automatique. Il est capable de
réaliser tous les types de modèles informatiques.

2.2. Quels sont les atouts de PowerDesigner ?

Les atouts de PowerDesigner sont entre autres :
౼ L’amélioration de la productivité
౼ La prise en charge des environnements ouverts
౼ L’inclusion des fonctionnalités de personnalisation
౼ La capacité d’adaptation à la complexité des entreprises
౼ La fourniture des outils d’analyse
3. ETUDE DETAILLEE DE LA SOLUTION

Dans ce chapitre, il sera question de représenter les différents diagrammes d’UML
conformément à la démarche 2TUP. Ainsi, nous modéliserons les diagrammes statiques et
dynamiques suivant les trois (3) niveaux ci-après :
 L’étude fonctionnelle
 L’étude technique
 La conception du système
3.1. Etude fonctionnelle

L’aspect fonctionnel de notre étude est construit sur les trois (3) étapes suivantes :
 La capture des besoins fonctionnels
 L’analyse fonctionnelle statique
 L’analyse fonctionnelle dynamique
3.1.1. Capture des besoins fonctionnels

La capture des besoins fonctionnels est la première étape de la branche gauche du cycle
en Y. Elle formalise et détaille les processus évoqués lors de l’étude de l’existant. Elle
permettra de définir le contexte fonctionnel du système, en décrivant les différents usages
du futur système vis-à-vis des acteurs.
Dans cette partie, nous identifierons les cas d’utilisation fonctionnels du système, ensuite
nous présenterons les diagrammes illustrant les relations entre les cas d’utilisation et les
acteurs puis nous décrirons ces cas d’utilisation.
3.1.1.1. Identification des cas d’utilisation fonctionnels

Un cas d’utilisation est un ensemble de séquences d’actions réalisées avec le système et
produisant un résultat observable intéressant pour un acteur particulier. Il exprime les

interactions acteur-système et apporte une valeur ajoutée à l’acteur concerné. Chaque cas
d’utilisation spécifie un comportement attendu du système considéré comme un tout, sans
imposer le mode de réalisation de ce comportement.
Notre étude nous a permis de repérer un certain nombre de cas d’utilisation réalisés par
les acteurs suivant classés dans l’ordre hiérarchique des traitements :
౼ L’Administrateur
౼ Le Responsable du Département des Opérations (D.O)
౼ L’Analyste
౼ Le Consultant
౼ Le Directeur Général
Les cas d’utilisation sont résumés dans le tableau 2 ci-dessous :
Tableau 2 : Cas d'utilisation du projet
CAS D’UTILISATION ACTEURS
S’authentifier Tout acteur
Créer dossier Responsable D.O
Mettre à jour dossier Responsable D.O
Rééchelonner dossier Analyste
Gérer dossier Valider dossier Directeur Général

Responsable D.O,
Analyste,
Consulter dossier
Consultant,
Directeur Général
Mettre à jour formule Analyste
Définir paramètre/norme Analyste
Ajouter indicateur financier Analyste

Gérer indicateur financier
Retirer indicateur financier Analyste
Renseigner les investissements détaillés Analyste
Définir taux d’exécution des
Analyste
Gérer les investissements investissements initiaux
Paramétrer renouvellement des
Analyste
investissements
Gérer les produits Analyste

CAS D’UTILISATION ACTEURS
Gérer les objectifs de Gérer les matières premières Analyste

production et de Renseigner les estimations des objectifs Analyste
consommation Estimer l’évolution des prix Analyste
Renseigner les charges fixes Analyste
Gérer les amortissements d’emprunt Analyste
Etablir le plan de financement Analyste
Etablir le calendrier de mobilisation des fonds et emprunts Analyste

Définir les taux de rentabilité
Analyste
différentielle
Gérer les rentabilités Estimer la rentabilité des actionnaires Analyste

Estimer la rentabilité des fonds propres Analyste
Estimer la rentabilité économique Analyste
Opérer les tests de sensibilité Analyste
Consulter les investissements
Consulter les amortissements
d’emprunt
Consulter les tableaux d’analyse des
charges
Consulter les comptes d’exploitation Analyste,
Consulter les documents
prévisionnels et le BFR Consultant,
comptables
Directeur Général
Consulter la trésorerie prévisionnelle
Consulter le TRI et les rentabilités du
projet
Consulter le bilan prévisionnel
Consulter les ratios
Analyste,
Imprimer les documents comptables Consultant,
Directeur Général
Gérer profil et habilitations Administrateur
Gérer utilisateur
Gérer compte Administrateur

3.1.1.2. Diagramme de cas d’utilisation

Le diagramme de cas d’utilisation est un diagramme UML utilisé pour donner une vision
globale du comportement fonctionnel d’un système logiciel. Dans un diagramme de cas
d’utilisation les utilisateurs appelés acteurs interagissent avec le système sous la forme de
cas d’utilisation comme le montre la figure suivante.
Cas d'utilisation Cas d'utilisation

<<extend>>
descendant d'extension
Cas d'utilisation
Acteur
Cas d'utilisation
Relations <<include>>
inclus
Pour des raisons de clarté et de compréhension, le diagramme de cas d’utilisation est

décomposé en plusieurs catégories d’opérations : gestion des dossiers, transcription des
données d’analyse, production des documents comptables et états, paramétrage et pour
terminer administration système.
 Gestion des dossiers
<<include>>
Créer dossier
Mettre à jour <<include>>

dossier
Responsable D.O
Rééchelonner << fragment >>

dossier <<include>> S'authentifier
Analyste
Consulter dossier <<include>>

Consultant
Valider dossier
<<include>>
Directeur Général
Figure 5 : Diagramme de cas d'utilisation " Gestion des dossier "

 Transcription des données d’analyse
Retirer indicateur
Ajouter indicateur
financier
financier
Gérer indicateur <<include>>

financier
Renseigner les Définir taux Paramétrer

investissements d'exécution renouvellement
détaillés
Gérer les <<include>>

investissements
Gérer les Gérer les Renseigner les

produits matières estimations des
premières objectifs
Gérer les objectifs

<<include>>
de production et
de consommation
Estimer l'évolution
des prix
<<include>> << fragment >>

Renseigner les
charges fixes S'authentifier

amortissements
d'emprunt
Analyste
Etablir le plan de <<include>>
financement
Etablir le calendrier <<include>>

de mobilisation des
fonds et emprunts
Définir les taux de Estimer la

rentabilité rentabilité des
différentielle actionnaires
rentabilités
Estimer la Estimer la
rentabilité rentabilité des
économique fonds propres
Opérer les tests <<include>>
de sensibilité
Figure 6 : Diagramme de cas d'utilisation " Transcription des données d'analyse "

 Production des documents comptables et états
Consulter les
investissements
Analyste
Consulter les
amortissements
d'emprunt
Consultant
Consulter les
tableaux d'analyse
des charges
Directeur Général
Consulter les Consulter les comptes

d'exploitation
documents
prévisionnels et le BFR
comptables
Utilisateur
Consulter la trésorerie
<<extend>>
prévisionnelle
Imprimer les
documents Consulter le tri et les
rentabilités du projet
comptables
<<include>>
<<include>> Consulter le bilan
prévisionnel
<< fragment >>

S'authentifier
Consulter les
ratios
Figure 7 : Diagramme de cas d'utilisation " Production des documents comptables et états "
 Paramétrage
Mettre à jour <<include>>

formule
<< fragment >>

Définir paramètre <<include>> S'authentifier
Analyste
Définir norme
<<include>>
Figure 8 : Diagramme de cas d'utilisation " Paramétrage "

 Administration système
Gérer profil et
habilitations
<<include>> << fragment >>

Gérer utilisateur S'authentifier
Administrateur
Gérer compte
Figure 9 : Diagramme de cas d'utilisation " Administration système "
3.1.1.3. Description textuelle des cas d’utilisation

Un cas d’utilisation représente un ensemble de séquences d’interactions entre le système
et ses acteurs. Ainsi, la description de la dynamique du cas d’utilisation consiste à recenser
toutes les actions perpétrées afin d’en faire une présentation textuelle. Un cas d’utilisation
doit avoir un début et fin clairement identifiés. Il doit préciser quand ont lieu les interactions
et quels sont les messages échangés. Il faut également ressortir les variantes possibles,
telles que les cas nominaux, les cas alternatifs, les cas d’erreurs ou d’exceptions, tout en
ordonnant de façon séquentielle les descriptions pour améliorer leur lisibilité.
Chaque fiche de description textuelle sera constituée d’un sommaire d’identification puis
de la description des enchainements.
Les fiches de description textuelle élaborées pour quelques cas d’utilisation du projet sont
les suivantes :

 Cas d’utilisation : « Créer dossier »
Sommaire d’identification
Titre : Créer dossier
Résumé : Ce cas d’utilisation permet au responsable D.O d’enregistrer un dossier
Acteur : Responsable du Département des Opérations
Date de création : 10/05/2018 Date de mise à jour : _ _/_ _/_ _ _ _
Version : 1.0 Responsable : Israël K. TSOGBETSE
Description des scénarii

Pré conditions
 Le système est opérationnel
 L’utilisateur est authentifié
Scénario nominal
1. L’utilisateur accède à la page Dossier et choisit l’option Nouveau

2. Le système présente un formulaire à remplir
3. L’utilisateur remplit le formulaire et valide la saisie
4. Le système contrôle les informations saisies par l’utilisateur (A1) (A2)
5. Le système enregistre le dossier et envoie un message de succès à l’utilisateur
Scénario alternatif
 A1 : Les informations saisies sont incorrectes

Ce scénario se déclenche au point 4 du scénario nominal lorsque l’utilisateur saisit des
informations non conformes aux contraintes du système.
6. Le système envoie un message invitant l’utilisateur à entrer des informations correctes
Les enchaînements reprennent au point 3 du scénario nominal.
 A2 : Les informations saisies correspondent à un dossier existant

Ce scénario se déclenche au point 4 du scénario nominal lorsque l’utilisateur saisit des
informations similaires à celles d’un autre dossier enregistré.
7. Le système envoie un message invitant l’utilisateur à donner plus de précision car un tel
dossier existe déjà
Les enchaînements reprennent au point 3 du scénario nominal

Post conditions
 Nouvel enregistrement de dossier créé
 Le journal est mis à jour
 Le système est prêt pour une nouvelle opération

 Cas d’utilisation : « Renseigner les investissements détaillés »
Titre : Renseigner les investissements détaillés
Résumé : Ce cas d’utilisation permet à l’analyste d’enregistrer ou de mettre à

jour les valeurs des investissements détaillés d’un dossier
Acteur : Analyste

Pré conditions

 Le système est en mode analyse
Scénario nominal
1. L’utilisateur accède à la page Investissements détaillés

2. Le système présente un tableur
3. L’utilisateur saisit les valeurs des investissements
4. Le système vérifie et normalise les valeurs saisies, puis calcule et affiche
automatiquement les totaux des rubriques
5. L’utilisateur valide le tableur en cliquant sur Enregistrer
6. Le système enregistre les nouvelles valeurs et envoie un message de succès à
l’utilisateur
Post conditions
 Nouvelles valeurs d’investissement enregistrées


 Cas d’utilisation : « Renseigner les estimations des objectifs de production »
Titre : Renseigner les estimations des objectifs de production
Résumé : Ce cas d’utilisation permet à l’analyste d’enregistrer ou de mettre à

jour les données intervenant dans la génération des objectifs de
production d’un dossier
Acteur : Analyste

Pré conditions

 Le système est en mode analyse
 Des produits sont ajoutés au dossier courant
Scénario nominal
1. L’utilisateur accède à la page Objectifs de production et déroule la partie à remplir

2. Le système présente les tableurs Quantité produite et Coefficients
3. L’utilisateur saisit les quantités produites en année de croisière pour chaque produit
et les coefficients de production pour chaque matrice produit-année
4. Le système vérifie et normalise les valeurs saisies
5. L’utilisateur valide les tableurs en cliquant sur Enregistrer les quantités et coefficients
6. Le système enregistre les nouvelles valeurs, recalcule les objectifs de production et
envoie un message de succès à l’utilisateur
Post conditions
 Nouvelles valeurs de quantité produite et de coefficient de production enregistrées

 Actualisation des objectifs de production et des objectifs de consommation

3.1.2. Analyse fonctionnelle statique

L’analyse fonctionnelle statique des cas d’utilisation du projet sera composée de :
 Diagrammes de classes participantes

 Diagramme de packages
3.1.2.1. Diagrammes de classes participantes

Les diagrammes de classes participantes permettent de formaliser sous forme de classes
et d’associations les concepts métier pour chaque cas d’utilisation. Ces diagrammes
préliminaires n’ont pas d’objectif d’exhaustivité. Ils servent uniquement à démarrer la
découverte des classes du modèle d’analyse pour la partie de l’application délimitée par
un cas d’utilisation. La réunion de tous les diagrammes, après élimination des classes et
associations redondantes, doit représenter le squelette du modèle statique d’analyse.
Pour quelques cas d’utilisation, voici les classes candidates identifiées :
 Gérer les investissements
dossier indicateur_additif amortissement

1..1 1..1
0..*
1..1 1..1 renouvellement

investissement
0..*
0..*
0..* indicateur
annee 1..1
taux_execution
duree_renouvellement 0..* 1..1 1..1
1..1 0..*
echeancier
investissement_estimation 0..*
0..*
Figure 10 : Diagramme de classes participantes " Gérer les investissement "

 Gérer les objectifs de production et de consommation
1..1
1..*
produit dossier matiere

0..* 1..1
1..1 0..*
1..1
1..1 1..1 1..1 1..1
coeff_produit coeff_matiere
0..*
0..*
0..* 0..*
0..* 0..*
0..*
1..1 annee 1..1
objectif_production objectif_consommation
0..* 1..1
1..1 0..*
Figure 11 : Diagramme de classes participantes " Gérer les objectifs de production ou de consommation "
 Gérer les amortissements d’emprunt
amortisssement_pret
0..*
0..*
1..1
1..1
pret annee
1..1 0..* dossier 0..* 1..1
1..1
1..1
cout_actuariel
0..*
0..*
Figure 12 : Diagramme de classes participantes " Gérer les amortissements d'emprunt "
 Consulter les comptes d’exploitation prévisionnels et le BFR
bfr_parametre 0..*
bfr_estimation 0..*
0..*
1..1
1..1 1..1
0..*
indicateur annee
1..1
exploitation 1..1 0..*
1..1
0..*
dossier 0..*
1..1
Figure 13 : Diagramme de classes participantes " Consulter les comptes d'exploitation et le BFR "

3.1.2.2. Diagramme de packages

La notion de paquetage ou « package » est une technique qui permet d’illustrer le
partitionnement des modèles tout en préservant la cohérence de l’ensemble. Un
paquetage est un ensemble d’éléments de modélisation : des classes, des associations, des
objets, des composants.
A partir de ce découpage, le système est réparti dans les huit (8) paquetages que voici :
Tableau 3 : Packages et détails
PACKAGES ELEMENTS
౼ Gestion des comptes d’utilisateurs

Administration système
౼ Gestion des habilitations
౼ Configurations
Paramétrage ౼ Paramètres et données par défaut
౼ Gestion des formules
౼ Gestion des clients
Gestion dossier
౼ Gestion et suivi des dossiers
౼ Coûts d’investissement
Gestion investissement ౼ Taux d’exécution des investissements initiaux
౼ Renouvellement, échéancier, …
౼ Evolution des prix
Production & ౼ Objectifs de production et de chiffre d’affaire
Consommation ౼ Objectifs de consommation de matières premières
౼ Analyse des charges
౼ Tableaux d’amortissement des emprunts
Amortissement emprunt ౼ Synthèse des emprunts
౼ Coût actuariel des emprunts
౼ Plan de financement
౼ Calendrier de mobilisation de ressources
Documents transversaux ౼ Compte d’exploitation, BFR, trésorerie
౼ Rentabilités
౼ Bilan, ratio, seuil de rentabilité
౼ Sensibilité du chiffre d’affaire

౼ Sensibilité des matières premières
Tests de sensibilité
౼ Sensibilité des charges
౼ Sensibilité coûts investissement

Le diagramme de packages est la représentation graphique des relations existant entre les
packages composant un système.
La figure 14 présente le diagramme de packages du projet.
TESTS DE SENSIBILITE DOCUMENTS

TRANSVERSAUX
GESTION INVESTISSEMENT
PRODUCTION &
CONSOMMATION
GESTION DOSSIER PARAMETRAGE
AMORTISSEMENT
ADMINISTRATION SYSTEME EMPRUNT
Figure 14 : Diagramme de packages
3.1.3. Analyse fonctionnelle dynamique

L’analyse fonctionnelle dynamique des cas d’utilisation du projet sera composée de :
 Diagrammes d’activités
 Diagrammes de séquences
3.1.3.1. Diagrammes d’activités

Le diagramme d’activités est un diagramme comportemental, représentant les règles
d’enchainement d’évènements dans le système. Il permet d’une part de consolider la
spécification d’un cas d’utilisation et d’autre part de concevoir une méthode. Il se présente
comme un organigramme qui décrit les enchainements dans le déroulement d’un cas

d’utilisation ou d’un ensemble de cas d’utilisation. Une activité représente une exécution
d’un mécanisme, un déroulement d’étapes séquentielles. Le passage d’une activité vers une
autre est matérialisé par une transition. Les transitions sont déclenchées par la fin d’une
activité et provoquent le début immédiat d’une autre.
Ci-après deux (2) des diagrammes d’activités du projet :
 Diagramme d’activités du cas d’utilisation : « Rééchelonner dossier »
Sélectionner dossier en mode analyse
Choisir option paramètres
Afficher formulaire des paramètres généraux
Saisir et valider infomations
[ informations incorrectes ]
[ données existantes sur plage à retirer ]
Vérification
Notifier perte de données

[ informations correctes ]
Confirmer opération
Enregistrer mises à jour
Actualiser références de dossier
Afficher message de réussite d'opération
Figure 15 : Diagramme d'activités " Rééchelonner dossier "

 Diagramme d’activités du cas d’utilisation : « Définir taux d’exécution »
Sélectionner dossier en mode analyse
Choisir option taux d'exécution
Afficher tableur
Saisir infomation
[ information non valide ]

Vérification
[ information correcte ]
Corriger automatiquement saisie
Enregistrer mises à jour
Actualiser références
Afficher message de réussite d'opération
Figure 16 : Diagramme d'activité " Définir taux d'exécution "
3.1.3.2. Diagrammes de séquences

Le diagramme de séquences est la représentation graphique des interactions entre les
acteurs d’un cas d’utilisation et le système selon un ordre chronologique. Ces
communications sont reconnues comme des messages. Il est difficile de représenter toute
la dynamique d’un système sur un seul diagramme. Aussi la dynamique globale sera

représentée par un ensemble de diagrammes de séquences, chacun étant généralement

lié à une sous fonction du système. Voici deux (2) des diagrammes de séquences du projet.
 Diagramme de séquences du cas d’utilisation : « Gérer utilisateur »

Gérer utilisateur _
<<boundary>> <<control>> <<entity>>

Ecran Utilisateur CTRL Utilisateur
Administrateur
ref
S'authentifier()
Accéder à la page
opt [Créer utilisateur]

Créer utilisateur
Saisir informations Afficher formulaire

Envoyer les informations
Vérifier
alt Informations non conformes
Envoyer message d'erreur
Informations conformes
Enregistrer utilisateur
Envoyer message de succès
opt [Modifier utilisateur]
Sélectionner utilisateur
opt [Modifier informations] Trouver utilisateur
Retourner informations utilisateur
Afficher formulaire
Modifier informations

Vérifier
Informations conformes Enregistrer modifications
opt [Changer statut]
alt Statut actif
Désactiver utilisateur
Statut inactif
Activer utilisateur
Enregistrer la modification
Figure 17 : Diagramme de séquences " Gérer utilisateur "

 Diagramme de séquences du cas d’utilisation : « Gérer amortissement emprunt »

Gérer emprunt _
<<boundary>> <<control>> <<entity>> <<entity>>
Ecran Emprunt CTRL Emprunt Dossier
Analyste
ref S'authentifier()
Rechercher dossier Trouver liste des dossiers
Retourner liste des dossiers

Sélectionner dossier
Ouvrir mode analyse
Accéder aux emprunts
opt [Créer ou éditer un emprunt]
alt Créer
Créer emprunt
Editer
Sélectionner emprunt à éditer Trouver emprunt
Retourner emprunt
Afficher formulaire
Saisir informations
Vérifier
Informations conformes Enregistrer emprunt

opt [Consulter synthèse des emprunts]
Observer synthèse de emprunts Trouver liste des emprunts
Construire et retourner tableau de

synthèse Retourner liste des emprunts
Figure 18 : Diagramme de séquences " Gérer amortissement emprunt "
3.2. Etude technique

L’aspect technique de l’étude repose sur les deux (2) étapes suivantes :
 La capture des besoins techniques

 La conception générique

3.2.1. Capture des besoins techniques

La capture des besoins techniques, par complémentarité avec celle des besoins
fonctionnels, couvre toutes les contraintes qui ne traitent ni de la description du métier des
utilisateurs, ni de la description applicative. La spécification technique est une activité de la
branche droite du Y. cette étape est primordiale pour la conception d’architecture.
Dans cette partie après l’identification des cas d’utilisation techniques, nous aborderons les
notions d’architecture client/serveur et 3-tiers.
3.2.1.1. Identification des cas d’utilisation techniques

Un cas d’utilisation technique est destiné à l’exploitant. C’est une séquence d’actions
produisant une valeur ajoutée opérationnelle ou purement technique. Les cas d’utilisation
techniques sont absolument distincts des cas d’utilisation de la branche gauche ; ils ne
produisent aucune valeur ajoutée fonctionnelle. La branche droite recouvre en effet tous
les services techniques dont un utilisateur bénéficie, parfois même sans s’en rendre compte.
Les cas d’utilisation techniques et attentes opérationnelles extériorisés par le projet sont
les suivants :
౼ L’utilisateur devra travailler avec des entités sous forme d’objets, ce qui implique la
mise en œuvre des mécanismes de persistance et de gestion du cycle de vie des
objets ;
౼ Plusieurs utilisateurs peuvent travailler en parallèle, ce qui inclut la mise en place des
mécanismes d’intégrité devant empêcher la mise à jour simultanée d’une même
entité par deux utilisateurs différents ;
౼ Les utilisateurs internes doivent pouvoir travailler sans connexion internet, ce qui
requiert un déploiement avec un mode d’accès hétérogène (avec ou sans internet) ;
dans cette logique, il faudra mettre en place un dispositif qui assurera l’intermédiaire
entre l’application et le transport des données à travers le réseau.
La mise en place d’une telle application exige une architecture client/serveur en 3-tiers.
3.2.1.2. Architecture client/serveur

L’architecture client/serveur désigne un mode de communication, à travers un réseau, entre
deux types de machines : l’un qualifié de client envoie des requêtes ; l’autre qualifié de
serveur attend les requêtes des clients et y répond. Un serveur est généralement une
machine très puissante en termes de capacité d’entrée-sortie, de puissance de calcul et de
connexion réseau. Les clients sont souvent des ordinateurs personnels ou des appareils
individuels.

Il existe une grande variété de logiciels serveurs et de logiciels clients en fonction des
besoins à servir : un serveur web qui publie des pages web demandées par des navigateurs
web ; un serveur de messagerie électronique qui envoie des mails à des clients de
messagerie ; un serveur de données servant à communiquer des données stockées dans
une base de données, et d’autres encore.
 Caractéristiques d’un processus client :

౼ Il établit la connexion au serveur à destination d’un ou plusieurs ports réseaux ;
౼ Lorsque la connexion est acceptée par le serveur, il communique comme le prévoit
la couche applicative du modèle OSI.
 Caractéristiques d’un processus serveur :
౼ Il attend une connexion entrante sur un ou plusieurs ports réseaux ;

౼ A la connexion d’un client ou d’un autre serveur sur le port en écoute, il ouvre un
socket local au système d’exploitation
౼ Suite à la connexion, le processus serveur communique avec le client suivant le
protocole prévu par la couche applicative du modèle OSI.
3.2.1.3. Architecture 3-tiers

L’architecture à trois (3) niveaux ou 3-tiers est un modèle logique d’architecture applicative
qui vise à modéliser l’application comme un empilement de trois (3) couches logicielles. Il
constitue une extension du modèle client/serveur.
Les trois (3) niveaux jouent des rôles différents clairement définis à savoir :
౼ La présentation des données : correspondant à l’affichage, la restitution sur le poste

de travail, le dialogue avec l’utilisateur ;
౼ Le traitement métier des données : correspondant à la mise en œuvre de l’ensemble
des règles de gestion et de la logique applicative ;
౼ L’accès aux données persistantes : correspondant aux données qui sont destinées à
être conservées sur la durée, voire de manière définitive.
Dans cette approche, les couches communiquent entre elles au travers d’un « modèle
d’échange », et chacune d’entre elles propose un ensemble de services. Les services d’une
couche sont mis à disposition de la couche supérieure. On s’interdit par conséquent qu’une
couche invoque les services d’une couche plus basse que la couche immédiatement
inférieure ou plus haute que la couche immédiatement supérieure.
Le rôle de chacune des couches et leur interface de communication étant bien définis, les
fonctionnalités de chacune d’entre elles peuvent évoluer sans induire de changement dans

les autres couches. Cependant, une nouvelle fonctionnalité de l’application peut avoir des
répercussions sur plusieurs d’entre elles. Il est donc essentiel de définir un modèle
d’échange assez souple, pour permettre une maintenance aisée de l’application.
3.2.2. Conception générique

La conception générique consiste à développer la solution qui répond aux spécifications
techniques recueillies plus haut. Cette conception est entièrement indépendante des
aspects fonctionnels spécifiés en branche gauche. Elle reste donc une activité de la branche
droite et constitue à établir les préconisations dont la mise en œuvre permettra d’utiliser
des composants et idiomes efficaces lors du développement et du déploiement.
Pour présenter l’architecture matérielle et logicielle de notre projet nous proposons les
diagrammes suivants :
 Diagramme de déploiement
 Diagramme de composants
3.2.2.1. Diagramme de déploiement

Le diagramme de déploiement sert à représenter l’utilisation de l’infrastructure physique
par le système et la manière dont les composants du système sont répartis ainsi que les
relations entre eux.
Selon l’architecture matérielle adoptée, voici le diagramme de déploiement à la figure 19.
POSTE CLIENT 1 SERVEUR D'APPLICATION

<< LAN >> << LAN >>
Navigateur : IIS
Chrome, Firefox
<< LAN >> SERVEUR DE BASE DE DONNEES

<< LAN >> CONTRÔLEUR DE DOMAINE
Windows Server SQL Server

Datacenter
PARE-FEU << LAN >>
<< WAN - VPN >>
<< LAN / WAN >>
POSTE CLIENT 2
Navigateur : << LAN >> SERVEUR DE SAUVEGARDE SERVEUR DE BASE DE DONNEES

Chrome, Firefox (REPLICATION)
Windows Storage
Server SQL Server
Internet
Figure 19 : Diagramme de déploiement

3.2.2.2. Diagramme de composants

Le diagramme de composants représente les concepts connus de l’exploitant pour installer
et dépanner le système. Il décrit les composants métier et leurs dépendances dans
l’environnement de réalisation. Un composant métier est un composant dont la fonction
est de distribuer les services d’un ou de plusieurs objets métier de l’entreprise. L’intégration
de composants métiers hétérogènes justifie notre recours au style d’architecture 3-tiers.
A la figure 20, le diagramme de composants associé à notre projet.
.NET
Routes Controller Base de données :

SQL Server
..
.
.
Interface
Model : DAL, ORM : Entity

View : Razor,
Service Framework
Output
Figure 20 : Diagramme de composants
3.3. Conception du système

Dans cette partie, nous nous intéresseront particulièrement au diagramme de classes de
conception.
Le diagramme de classes est un schéma utilisé pour présenter les classes et les interfaces
des systèmes ainsi que les différentes relations sémantiques entre celles-ci. Ce diagramme
est de type statique car il fait abstraction des aspects temporels et dynamiques. Une classe
décrit les responsabilités, le comportement et le type d’un ensemble d’objets. Les éléments
concepts de classe (attributs, méthodes), de relation (association, agrégation, composition,
héritage) et de multiplicité.
Pour des raisons de clarté, les diagrammes de classes de conception seront d’abord
présentés par module puis le diagramme de classe global du système suivra.

3.3.1. Diagramme de classes par modules

Relativement aux paquetages prédéfinis dans l’analyse fonctionnelle, nous allons détailler
les sept (7) modules suivants :
 Administration système
 Paramétrage
 Gestion dossier
 Gestion investissement
 Production et consommation
 Amortissement emprunt
 Documents transversaux
Pour mémoire, les tests de sensibilité se répercutent sur les quatre (4) derniers modules.
3.3.1.1. Module administration système
UTILISATEUR
- user_id : int COMPTE
- user_nom : String
- compte_id : int
- user_prenom : String
1..1 - compte_login : String
- user_sexe : String
- compte_password : String
- user_adresse : String 0..*
- compte_actif : boolean
- user_contact1 : String
- user_courriel : String 0..* 0..*
- user_poste : String
- user_statut : int
0..*
journal
1..1 - journal_date : Date
MENU + afficherLog ()
- menu_id : int PROFIL
1..1
- menu_nom : String - profil_id : int
- menu_url : String 1..*
- profil_nom : String
- menu_img : String 0..*
- profil_actif : boolean
- menu_num_ordre : int
0..*
0..*
HABILITATION OPERATION
1..* - operation_id : int
- habilitation_id : int
- operation_nom : String
- habilitation_nom : String
Figure 21 : Diagramme de classes " Administration système "

3.3.1.2. Module paramétrage
0..*
INDICATEUR
- ind_code : String 1..*
- ind_ref : String
1..1
- ind_libelle : String
- ind_sens : char 0..*
- ind_type : String
- ind_sys_code : int DOCUMENT
- ind_affiich_gras : boolean
- doc_code : String
- ind_affich_min : boolean
- doc_titre : String
- ind_num_ordre : int
1..1
1..1
FORMULE
0..*
- formule_id : int TYPE_ACTIVITE
- formule_valeur : String - type_act_id : int
0..* - formule_detail : String 0..1 - type_act_libelle : String
1..*
- formule_somme : boolean - type_act_detail : String
+ calculerVal () : long
Figure 22 : Diagramme de classes " Paramétrage "

3.3.1.3. Module gestion dossier
Administration système
UTILISATEUR
- user_id : int Paramétrage
- user_nom : String
- user_prenom : String TYPE_ACTIVITE
- user_sexe : String - type_act_id. : int
- user_adresse
.. : String - type_act_libelle : String
1..1
- user_contact1 : String - type_act_detail : String
- user_courriel : String
- user_poste : String
- user_statut : int
1..1
0..*
DOSSIER ANNEE
0..* - dossier_id : int - annee_id : int
1..*
- dossier_nom_projet : String - annee_val : int
- dossier_annee_real : int
1..*
1..*
- dossier_annee_expl : int
- dossier_nature : String
- dossier_unite_donnee : String
- dossier_etat : int
- dossier_nb_annee_etude : int
1..1 - dossier_annee_croisiere : int
- dossier_annee_bfr : int annee_estimastion
CLIENT - dossier_annee_impot : int - annee_taux_fonds_prop : int
- client_id : int - dossier_taux_imprevu : int - annee_fonds_prop : double
- client_matricule : int - dossier_taux_imposition : int - annee_taux_emprunt : int
- client_nom_reduit : String - dossier_taux_dividende : int - annee_emprunt : double
- client_contact : String - dossier_sensible_ca : int - annee_fonds_prop_actu_ext : double
- client_adresse : String - dossier_sensible_invest : int
- client_ville : String - dossier_date_creation : Date
- client_pays : String - dossier_derniere_modif : Date
Figure 23 : Diagramme de classes " Gestion dossier "

3.3.1.4. Module gestion investissement
Gestion dossier INVESTISSEMENT

- invest_montant_ht : double taux_execution
- invest_taxe : double
DOSSIER
- invest_montant_ttc : double
- dossier_id : int
- dossier_nom_projet : String
- dossier_annee_real : int
- dossier_annee_expl : int renouvellement
- dossier_nature : String
- dossier_etat : int 0..*
- dossier_annee_croisiere : int
- dossier_annee_bfr : int echeancier
- dossier_annee_impot : int DUREE_RENOUV
- dossier_taux_imprevu : int - duree_rnv_id : int
1..1
- dossier_taux_imposition : int 0..* - duree_rnv_val : int
- dossier_taux_dividende : int
- dossier_sensible_ca : int
- dossier_sensible_invest : int amortissement
0..*
- dossier_date_creation : Date
- dossier_derniere_modif : Date 1..*
.
INDICATEUR
- ind_code : String
- ind_ref : String
- ind_sens : char
- ind_type :..String
1..1
- ind_sys_code : int
- ind_affiich_gras : boolean INVEST_ESTIMATION
- ind_affich_min : boolean 1..1
# invest_estim_id : int
- ind_num_ordre : int 0..*
# invest_estim_val : double
0..*
annee_estimation Paramétrage
- annee_taux_fonds_prop : int
- annee_fonds_prop : double
- annee_taux_emprunt : int
1..1
- annee_emprunt : double
- annee_fonds_prop_actu_ext : double
Figure 24 : Diagramme de classes " Gestion investissement "

3.3.1.5. Module production et consommation
COEFF_PRODUIT
Gestion dossier - coeff_prod_id : int
0..* - coeff_prod_val : int
1..1
- coeff_prod_annee : int
DOSSIER INDICATEUR
- dossier_id : int PRODUIT
- ind_code : String
- dossier_nom_projet : String - produit_id : int - ind_ref : String
- dossier_annee_real : int 1..1 - produit_nom : String OBJ_PRODUCTION_CA - ind_libelle : String
- dossier_annee_expl : int - produit_qte_croisiere : int - obj_prod_id : int - ind_sens : char
0..* 1..1
- dossier_nature : String - produit_qte_sensible : int - obj_prod_qte : int - ind_type : String
..
- dossier_unite_donnee : String - produit_inflation : int 0..*
- obj_prod_pv_unite : double - ind_sys_code : int
- dossier_etat : int - obj_prod_pv_sensible : double - ind_affiich_gras : boolean
- dossier_nb_annee_etude : int 1..1 - obj_prod_ca : double - ind_affich_min : boolean
- dossier_annee_croisiere : int - ind_num_ordre : int
+ calculerTotalCA () : double
- dossier_annee_bfr : int
- dossier_annee_impot : int 0..*
1..*
- dossier_taux_imprevu : int
- dossier_taux_imposition : int MATIERE Paramétrage 0..*
- dossier_taux_dividende : int - matiere_id : int

- dossier_sensible_ca : int - matiere_nom : String 1..1
- dossier_sensible_invest : int - matiere_qte_unite : int
- dossier_date_creation : Date - matiere_qte_croisiere : int
- dossier_derniere_modif : Date - matiere_inflation : int
. 0..*
1..1
OBJ_CONSOMMATION ANA_CHARGE
- obj_conso_id : int - ana_charge_montant : double
- obj_conso_qte : int - ana_charge_montant_sensible : double
- obj_conso_prix_unite : double - ana_charge_part_ca : int
0..* - obj_prod_pv_sensible : double - ana_charge_part_ca_sensible : int
- obj_prod_montant : double + calculerChargeVariable () : double
COEFF_MATIERE + calculerTotalConso () : double
0..*
- coeff_mat_id : int
- coeff_mat_val : int
- coeff_mat_annee : int
annee_estimation
1..1
- annee_fonds_prop : double 1..1
- annee_taux_emprunt : int
- annee_emprunt : double 0..*
- annee_fonds_prop_actu_ext : double
Figure 25 : Diagramme de classes " Production & Consommation "

3.3.1.6. Module amortissement emprunt
Gestion dossier PRET

- pret_id : int
DOSSIER
- pret_type : String
- dossier_id : int - pret_montant : double
- dossier_nom_projet : String - pret_taux_interet : int
1..1 0..*
- dossier_annee_real : int - pret_duree : int
1..*
- dossier_annee_expl : int - pret_differe : int
- dossier_nature : String - pret_duree_prem_exercice : int
- dossier_unite_donnee : String - pret_commission : int
1..1
- dossier_etat : int - pret_frais_dossier : int
- dossier_nb_annee_etude : int + calculerCoutActuTRI () : float
1..1
- dossier_annee_impot : int 1..1
- dossier_taux_imprevu : int 0..*
- dossier_taux_imposition : int
- dossier_taux_dividende : int
PRETEUR
COUT_ACTUARIEL
- dossier_sensible_ca : int - preteur_code : String
. - cout_act_id : int - preteur_nom_reduit : String
- dossier_sensible_invest : int
- cout_act_flux_fin : int
- dossier_date_creation : Date
- cout_act_eco_impot : int
- dossier_derniere_modif : Date
- cout_act_flux_net : int 1..*
+ calculerEcoImpot () : double
0..*
1..*
annee_estimation PRET_AMORTISSEMENT 1..1
- annee_taux_fonds_prop : int 1..1 - pret_amort_id : int

- annee_fonds_prop : double - pret_amort_capital_rest : double TYPE_PRETEUR
- annee_taux_emprunt : int - pret_amort_principal : double - type_preteur_id : id
- annee_emprunt : double 1..1 - pret_amort_interet : double - type_preteur_libelle : String
- annee_fonds_prop_actu_ext : double 0..*
- pret_amort_annuite : double
+ calculerTotalCapital () : double
+ calculerTotalPrincipal () : double
+ calculerTotalInteret () : double
+ calculerTotalAnnuite () : double
Figure 26 : Diagramme de classes " Amortissement emprunt "

3.3.1.7. Module documents transversaux
Paramétrage
Gestion dossier INDICATEUR
BFR_PARAM
- ind_code : String
DOSSIER - bfr_param_id : int
0..*
1..1 1..1 - ind_ref : String
- dossier_id : int - bfr_param_val : double - ind_libelle : String
0..*
- dossier_nom_projet : String - ind_sens : char
..
- dossier_annee_real : int FONDS_PROPRES - ind_type : String
- dossier_annee_expl : int - ind_sys_code : int 1..1
1..1 - fonds_prop_id : int 0..*
- dossier_nature : String - ind_affiich_gras : boolean
0..* - fond_prop_val : double 1..1
- dossier_unite_donnee : String - ind_affich_min : boolean
- dossier_etat : int - ind_num_ordre : int
- dossier_annee_bfr : int 1..1 1..1 1..1 1..1 1..1
- dossier_annee_impot : int
- dossier_taux_imprevu : int FINANCEMENT
- dossier_taux_imposition : int - finance_id : int
0..*
- dossier_taux_dividende : int - finance_val : double

- dossier_sensible_ca : int
- dossier_sensible_invest : int
BFR
- dossier_date_creation : Date 0..* - bfr_id : int 0..*
- dossier_derniere_modif : Date - bfr_val : double
0..*
1..1
1..1
EXPLOITATION
- exploitation_id : int 0..*
.
PRET - exploitation_val : double
- pret_id : int
- pret_type : String 1..1
- pret_montant : double
- pret_taux_interet : int
1..* - pret_duree ... : int
RENTABILITE
- pret_differe : int - rentabilite_id : int
- pret_duree_prem_exercice : int - rentabilite_val : double 0..*
- pret_commission : int
- pret_frais_dossier : int
0..*
+ calculerCoutActuTRI () : float
Amortissement emprunt RATIO

- ratio_id : int 0..*
- ratio_val : int
1..1 0..*
annee_estimation
0..* 0..*
- annee_fonds_prop : double 1..1
- annee_taux_emprunt : int SEUIL
- annee_emprunt : double 1..1 - seuil_id : int
- annee_fonds_prop_actu_ext : double 1..1 - seuil_val : double
0..*
Figure 27 : Diagramme de classes " Documents transversaux "

3.3.2. Diagramme de classes global

CLIENT
- client_id : int
taux_execution
- client_matricule : int DOCUMENT
- client_nom_reduit : String TYPE_ACTIVITE 1..1
FORMULE
0..* - doc_code : String
- client_contact : String - type_act_id : int 0..* - formule_id : int
1..1 - doc_titre : String
- client_adresse : String - type_act_libelle : String - formule_valeur : String
1..1
- client_ville : String - type_act_detail : String INVESTISSEMENT - formule_detail : String
- formule_somme : boolean 0..*
- client_pays : String renouvellement
UTILISATEUR - invest_montant_ht : double
0..*
+ calculerVal () : double
- user_id : int - invest_taxe : double
- user_nom : String 1..1 - invest_montant_ttc : double
1..1
1..1 - user_prenom : String
- user_sexe : String
0..* 1..* 0..*
- user_adresse : String
0..* echeancier
- user_contact2 : String DOSSIER 0..*
COMPTE - user_courriel : String - dossier_id : int
- compte_id : int - user_poste : String - dossier_nom_projet : String 1..1 DUREE_RENOUV
0..*
- compte_login : String - user_statut : int - dossier_annee_real : int - duree_rnv_id : int 1..* 1..1 1..* 1..1
- compte_password : String - dossier_annee_expl : int - duree_rnv_val : int
- compte_actif : boolean - dossier_nature : String
1..1 FONDS_PROPRES amortissement
0..*
- fonds_prop_id : int
INDICATEUR
- dossier_etat : int BFR_PARAM - fond_prop_val : double 0..* - ind_code : String
0..*
0..* 0..*
- dossier_nb_annee_etude : int - ind_ref : String
journal 1..1
0..*
- bfr_param_id : int
- dossier_annee_croisiere : int - bfr_param_val : double 1..1
- journal_date : Date 0..* - ind_sens : char 1..1
+ afficherLog () : String - dossier_annee_impot : int 1..1
- ind_type : String
1..1
- dossier_taux_imprevu : int 0..* - ind_sys_code : int
0..* - dossier_taux_imposition : int - ind_affiich_gras : boolean
1..1
- dossier_taux_dividende : int - ind_affich_min : boolean 1..1
1..1
OPERATION - dossier_sensible_ca : int - ind_num_ordre : int
1..1
- operation_id : int - dossier_sensible_invest : int FINANCEMENT

- dossier_date_creation : Date PRETEUR
- operation_nom : String 1..1
- finance_id : int 1..1 1..1 1..1 0..* 1..1
1..1 - dossier_derniere_modif : Date 1..* - preteur_code : String
- preteur_nom_reduit : String 0..* - finance_val : double 0..*
1..1
1..*
1..1 0..* 0..* 1..* 1..1
TYPE_PRETEUR
BFR
MENU PRODUIT - type_preteur_id : id PRET
- bfr_id : int 0..*
- menu_id : int - produit_id : int 1..* - type_preteur_libelle : String - pret_id : int
0..* - bfr_val : double
- menu_nom : String - produit_nom : String - pret_type : String
ANNEE
- menu_url : String - produit_qte_croisiere : int - pret_montant : double
0..*
- menu_img : String - annee_id : int - pret_taux_interet : int
- produit_qte_sensible : int COUT_ACTUARIEL
- menu_num_ordre : int - annee_val : int - pret_duree : int 0..*
- produit_inflation : int
- cout_act_id : int - pret_differe : int
- cout_act_flux_fin : int
1..1 1..1 1..1 0..* 1..1 - pret_duree_prem_exercice : int EXPLOITATION
1..* - cout_act_eco_impot : int - pret_commission : int
- cout_act_flux_net : int - exploitation_id : int
OBJ_PRODUCTION_CA - pret_frais_dossier : int - exploitation_val : double
- obj_prod_id : int + calculerEcoImpot () : double + calculerCoutActuTRI () : float
- obj_prod_qte : int
1..1
0..* - obj_prod_pv_unite : double 0..* 1..1
- obj_prod_pv_sensible : double PRET_AMORTISSEMENT

- obj_prod_ca : double - pret_amort_id : int 0..*
0..*
+ calculerTotalCA () : double - pret_amort_capital_rest : double 0..*
0..* 0..* - pret_amort_principal : double INVEST_ESTIMATION
COEFF_PRODUIT - pret_amort_interet : double RENTABILITE
PROFIL # invest_estim_id : int
- coeff_prod_id : int OBJ_CONSOMMATION - pret_amort_annuite : double - rentabilite_id : int 0..* # invest_estim_val : double
- profil_id : int - coeff_prod_val : int - rentabilite_val : double
- obj_conso_id : int
- profil_nom : String - coeff_prod_annee : int
1..1 - obj_conso_qte : int 0..*
- profil_actif : boolean 0..*
- obj_conso_prix_unite : double
0..* 0..*
- obj_prod_pv_sensible : double ANA_CHARGE
0..* COEFF_MATIERE - obj_prod_montant : double
- ana_charge_montant : double RATIO
- coeff_mat_id : int + calculerTotalConso () : double
- ana_charge_montant_sensible : double
- coeff_mat_val : int 0..* - ratio_id : int
- ana_charge_part_ca : int
1..*
- coeff_mat_annee : int 0..* - ratio_val : int
- ana_charge_part_ca_sensible : int
+ calculerChargeVariable () : double
HABILITATION
0..* 0..*
- habilitation_id : int 1..* 1..1
- habilitation_nom : String
MATIERE
1..1 1..1 1..1
- matiere_id : int
0..*
1..1 - matiere_nom : String 1..1
- matiere_qte_unite : int annee_estimation
- matiere_qte_croisiere : int
0..* SEUIL
1..1 - annee_taux_fonds_prop : int
1..1 - seuil_id : int
0..* - matiere_inflation : int - annee_fonds_prop : double
- annee_taux_emprunt : int 1..1 - seuil_val : double
0..*
1..1 - annee_emprunt : double 1..1
- annee_fonds_prop_actu_ext : double 1..1
Figure 28 : Diagramme de classes global

Le diagramme de classes global présenté à la figure 28 regroupe les diagrammes des

différents modules précédemment représentés. C’est le diagramme le plus important dans
toutes les méthodes orientées objet. Il permet d’élaborer le modèle physique de la base de
données sur laquelle l’application tournera.
Description de quelques classes
 Classe DOSSIER
Tableau 4 : Description de la classe " DOSSIER "
Désignation Signification Type Longueur

dossier_id Identifiant du dossier int 11
dossier_nom_projet Nom du projet String 128
dossier_annee_real Année de réalisation des investissements int 4
dossier_annee_expl Année de démarrage de l’exploitation int 4
dossier_nature Nature du projet (nouveau ou extension) String 16
dossier_unite_donnee Unité des données millier/million/milliard String 16
dossier_etat Etat du dossier (en attente, en cours, …) int 1
dossier_nb_annee_etude Nombre d’années couvertes par l’étude int 4
dossier_annee_croisiere Année de croisière int 4
dossier_annee_bfr Année de mise en place du BFR int 4
dossier_annee_impot Année de départ du paiement d’impôts int 4
dossier_taux_imprevu Taux d’imprévu dans les investissements int 3
dossier_taux_imposition Taux d’imposition pour le projet int 3
dossier_taux_dividende Taux de distribution de dividendes int 3
dossier_sensible_ca Taux de baisse du chiffre d’affaire global int 3
dossier_sensible_invest Taux de hausse du coût du projet int 3
dossier_date_creation Date de création du dossier Date 10
dossier_dernière_modif Date de la dernière modification Date 19
 Classe FORMULE
Tableau 5 : Description de la classe " FORMULE "

formule_id Identifiant de formule int 11
formule_valeur Composition de la formule String 1024
formule_detail Détails de la formule String 512
formule_somme Désigne la somme des sous rubriques bool 1
calculerVal() Calculer la valeur de l’indicateur double 16

 Classe INDICATEUR
Tableau 6 : Description de la classe " INDICATEUR "

ind_code Code de l’indicateur String 8
ind_ref Référence du poste dans le plan comptable String 4
ind_libelle Libellé de l’indicateur String 64
ind_sens Sens dans un état financier (actif, passif, néant) char 1
ind_type Type d’état financier (bilan, compte résultat, …) String 4
ind_sys_code Code du système comptable utilisé int 1
ind_affich_gras Poste à afficher en gras bool 1
ind_affich_min Poste à afficher en miniature bool 1
ind_num_ordre Numéro d’ordre d’affichage int 2
 Classe PRET
Tableau 7 : Description de la classe " PRET "

pret_id Identifiant du prêt int 11
pret_type Type de prêt String 32
pret_montant Montant du prêt double 16
pret_taux_interet Taux d’intérêt du prêt int 4
pret_duree Durée du prêt en nombre d’années int 4
pret_differe Nombre d’années en différé int 2
pret_duree_prem_exercice Durée entre prêt et fin du 1er exercice int 2
pret_commission % de commission d’engagement int 4
pret_frais_dossier % des frais de dossier int 4
calculerCoutActuTRI() Calculer le TRI des coûts actuariels float 4
CONCLUSION
Ce dossier d’analyse et de conception est une œuvre pilotée par le langage UML couplé
avec la démarche 2TUP. Il a permis de ressortir, en fonction des objectifs du projet et de
l’existant, les besoins fonctionnels et techniques de notre projet. A partir de l’outil de
modélisation choisi, les diagrammes UML montrant les aspects statiques et dynamiques de
notre système ont été représentés. Le dossier d’analyse et de conception constituera une
véritable charpente pour la phase de programmation.

CHAPITRE 4 : REALISATION ET MISE EN OEUVRE
Quatrième chapitre
REALISATION ET
MISE EN OEUVRE

Réalisation et mise en œuvre
INTRODUCTION
La présentation du cahier des charges et du dossier de conception a conduit à déterminer

les flux d’information dans le périmètre du projet et les traitements qui y sont effectués. Le
dossier de réalisation et de mise en œuvre constitue le quatrième document du projet.
Cette étape comprend deux volets que sont la mise en œuvre et la présentation de
l’application.
1. MISE EN ŒUVRE
1.1. Choix matériels

La réalisation de la solution a nécessité un ordinateur portant les caractéristiques ci-
dessous :
Marque et modèle ACER Aspire 4810T
Processeur et fréquence Genuine Intel® CPU U4100 @ 1.30GHz (2 CPUs), ~1.3GHz
Mémoire RAM 4 Go
Disque Dur 250 Go
Ecran Generic PnP Monitor 12’
Système d’exploitation Windows 8.1 Professionnel 64 bits (6.3, version 9600)
Par ailleurs, un serveur local a été utilisé pour les tests. Ces caractéristiques sont les
suivantes :
Marque et modèle Lenovo ThinkServer TD 340
Système d’exploitation Windows Server 2012 DataCenter
౼ Microsoft SQL Server 2014 Entreprise

Utilitaires
౼ IIS

1.2. Choix logiciels

La rubrique des logiciels choisis est scindée en deux (2) parties :
 Outils de développement
 Langages et technologies
1.2.1. Outils de développement
 Système de gestion de base de données (SGBD) : Microsoft SQL Server
Microsoft SQL Server est un système de gestion de base de données relationnel utilisant le
langage SQL. C’est un outil qui puise sa force de plusieurs de ses caractéristiques. Il est
originellement multi-base et multi-schéma avec un système de threads managés. En
dehors des possibilités de sauvegarde à chaud, d’administration centralisée et
manipulation de SIG (Système d’Information Géographique), SQL Server permet de faire la
programmation procédurale par le biais de son langage Transact – SQL.
Le choix de la version 2014 de ce SGBD s’inscrit dans la politique de la structure d’accueil

qui a adopté les produits Microsoft.
 Environnement de développement intégré (EDI) : Visual Studio
Conçu par Microsoft, Visual Studio est une suite logiciel de développement d’application
pour les systèmes d’exploitation Windows et Mac Os. Il regroupe des outils qui permettent
de générer des applications bureautiques, mobiles, des web services et applications web.
Cette dernière est celle qui intéresse le présent projet.

 Serveur web : IIS
IIS (Internet Information Services) est un serveur web dédié au systèmes d’exploitation
Windows. Il met à disposition une plateforme d’administration sécurisée pour
l’hébergement des web services ainsi qu’aux applications web. Le serveur IIS prend en
charge plusieurs techniques et langages web à l’instar de CGI, ASP .NET et PHP.
1.2.2. Technologies
 Framework : ASP .NET MVC
ASP .NET est un framework de programmation permettant de construire des pages web
avec du HTML, du CSS, du JavaScript et du langage serveur C#. Il se décompose en deux
(2) grandes logiques de codage : le WebForms et le MVC. Le WebForms ajoute une couche
d’abstraction qui permet de générer du HTML à partir des objets familiers en
environnement de développement Windows. Cette abstraction masque la complexité du
travail à réaliser ainsi que toutes les spécificités de la programmation d’applications web.
Par contre, le MVC n’a pas pour principe d’offrir une couche d’abstraction mais plutôt de
fournir un cadre de réalisation des applications web grâce au design pattern model, view,
controller. Ce dernier s’avère très utile pour les projets de taille importante ou encore pour
les projets dont la méthodologie est centrée sur des tests.

 Object-Relationnal Mapping (ORM) : Entity Framework
Entity Framework (EF) est un outil qui permet de créer une couche d’accès aux données
d’une base de données relationnelle. Il fait partie des technologies ADO .NET qui dressent
un support pour la programmation des applications orientées objet. L’objectif principal de
l’EF est de faciliter aux développeurs le traitement des données dans une table en séparant
l’accès aux données de leur gestion ce qui permet de réduire le code tout en améliorant sa
maintenance. Ainsi, la mise à profit de cet ORM nous a permis d’utiliser l’approche
CodeFirst qui inéluctablement convient à la nature de ce projet.
 Librairie JavaScript : JQuery
JQuery est une bibliothèque JavaScript libre et multiplateforme qui vient compléter le
HTML et le CSS des applications ou sites web. Elle change le comportement des pages en
déterminant le contenu et l’apparence par l’ajout d’une couche d’interactivité. Aussi, JQuery
pallie les défauts de compatibilité de navigateurs du langage JavaScript. Elle permet la
manipulation du DOM, des évènements, des effets visuels et par le biais d’AJAX, elle accroît
la dynamicité des pages web.
 Librairie de mise en forme : Bootstrap
Bootstrap est une collection d’outils utile à la création du design des applications et sites
web. Il embarque des composants HTML, CSS et JavaScript. Par ailleurs, il comporte un
système de grille simple et efficace pour mettre en ordre l'aspect visuel d'une page web. Il
apporte du style aux différents composants d’une page web.

1.3. Sécurité de l’application

Le système présente deux (2) niveaux majeurs de sécurité :
 Sécurité de la plateforme web

 Sécurité de la base de données
1.3.1. Sécurité de la plateforme web

L’application est accessible uniquement via son portail d’authentification. Une foi sur la
page d’authentification, l’utilisateur renseigne son nom d’utilisateur ainsi que son mot de
passe qui est comparé au mot de passe crypté en base de données. Au cas les informations
sont conformes, l’utilisateur accède à la page d’accueil. Dans le cas contraire, l’utilisateur
se voit contraint de saisir à nouveau ses paramètres d’identification. Si le mot de passe est
erroné à cinq (5) essais consécutifs pour le même compte d’utilisateur, ce dernier est alors
momentanément désactivé.
Toute tentative de modification d’URL sans authentification préalable débouche sur une
redirection vers le portail d’authentification. Afin d’éviter l’interception des données et
requêtes en cours de traitement, le transfert des données via les cookies a été
soigneusement évité. L’utilisateur connecté, n’a accès qu’aux pages et actions que son
profil autorise.
Grâce à la charpente des technologies LINQ, Razor, AJAX, et autres, les attaques de type
injection, XSS (Cross-Site Scripting) et falsification de requêtes inter-sites (CSRF) sont
évitées.
L’application retrace toutes les actions effectuées par les utilisateurs à partir du journal des
opérations.
1.3.2. Sécurité de la base de données

A l’installation du serveur Microsoft SQL Server, un utilisateur par défaut (dbo) est créé.
Pour des raisons de sécurité, un schéma avec un nouvel utilisateur seront créés pour la
base de données.
Mise à part la réplication automatique, la sauvegarde planifiée de la base de données est

implémentée.
Plus de détails seront donnés dans le guide d’exploitation.

1.4. Evaluation financière de la solution

L’estimation des coûts de la solution retenue est scindée en trois (3) :
 Le coût matériel
 Le coût des licences
 Le coût humain
Le matériel et les licences bien qu’étant considérés comme un prérequis déjà en place, nous
jugeons nécessaire de faire ressortir leur évaluation financière.
1.4.1. Coût matériel
Tableau 8 : Coût matériel correspondant à l’architecture de déploiement
Prix unitaire Montant

Matériel Description Quantité
(F CFA) (F CFA)
Contrôleur de domaine, HPE ProLiant DL380

serveurs d’application et Gen9 Serveur 2.1GHz 1 607 100 4 6 428 400
de BD RAM : 16Go
HP E STOREEASY
1450 1.6GHz RAM : 8
Serveur de sauvegarde 3 951 000 1 3 951 000
Go
DDR4 HDD: 4 x 1To
Disque dur : 2To -

213 187 2 426 374
échangeable à chaud
Accessoires
Disque dur : 300Go -
172 600 2 345 200
échangeable à chaud
TOTAL 11 150 974
(PC21 SARL, 2018)

1.4.2. Coût des licences

Tableau 9 : Coût des licences d'utilitaires
Prix unitaire Montant

Désignation Quantité
(F CFA) (F CFA)
License Microsoft Windows Server 2016

4 181 700 4 16 726 800
Datacenter FRE OLP 16Lic
Windows Server 2016 FRE OLP USER CAL 26 000 5 130 000
Windows Server 2016 FRE OLP DEVICE CAL 21 000 5 105 000
Microsoft Windows Storage Server 2016 R2
462 180 1 462 180
Standard
License Microsoft SQL Server 2017 Enterprise FRE

9 338 615 2 18 677 230
OLP 2Lic
SQL Server 2017 Enterprise FRE OLP USER CAL 141 840 5 709 200
SQL Server 2017 Enterprise FRE OLP DEVICE CAL 141 840 5 709 200
TOTAL 37 519 610
1.4.3. Coût humain

Tableau 10 : Coût humain de la solution
Coût horaire Nombre Montant

Désignation
(F CFA) d’heures (F CFA)
Chef projet sénior 200 000 40 8 000 000
Analystes 100 000 72 7 200 000
Superviseur 50 000 120 6 000 000
Concepteur et développeur 10 000 944 9 440 000
Formations 40 000 25 1 000 000
TOTAL 31 640 000

2. PRESENTATION DE L’APPLICATION
2.1. Présentation
Notre solution est une application web destinée à l’analyse financière prévisionnelle des
projets de création d’entreprise ou de reprise d’activités. C’est un outil hautement
paramétrable qui permet de faire une étude de dossier approfondie en vue de déterminer
si un projet est éligible à un prêt bancaire ou pas et dans quelles proportions. A partir des
estimations tirées du plan d’affaire, l’application produit les états financiers en tenant
compte des divers paramètres de précision et d’objectivité. Ces états représentent une
véritable base décisionnelle pour les établissements de crédits. Au-delà de l’échelle des
banques, elle est également conçue pour les fonds de garantie.
Le produit comporte plusieurs unités fonctionnelles réparties en sept (7) principaux

modules à savoir :
౼ Administration système
౼ Paramétrage
౼ Gestion de dossier
౼ Investissements
౼ Production et consommation
౼ Amortissements d’emprunt
౼ Etats financiers (documents transversaux)
2.2. Architecture de l’application
2.2.1. Maquette
Les compartiments de l’application se présentent comme le montre la figure 29.
Menus
Titre de l’écran
Contenu
Nom de l’ordinateur Nom de l’utilisateur [ Profil ]
Figure 29 : Maquette de l'application

2.2.2. Structure
Voici la structure de notre logiciel, représentée à la figure 30.
Figure 30 : Arborescence des menus de l'application
2.2.3. Architecture de code

Comme design pattern, nous avons adopté le MVC (Modèle – Vue – Contrôleur). Cette
architecture attribue un rôle spécifique à chacune des composantes.
 Le modèle est chargé d’interagir avec la base de données.

 La vue est chargée de présenter la mise en forme des pages (composants
graphiques).
 Le contrôleur est essentiellement chargé de la synchronisation du modèle et de la
vue. Il reçoit les évènements de l’utilisateur et enclenche les actions à effectuer.
Contrôleur
Modèle
Vue
Figure 31 : Concept MVC

2.3. Script de création de la base de données

Le script ayant permis de créer la base de données est :
CREATE DATABASE [ANAFIN_PREV]
CONTAINMENT = NONE
GO
ALTER DATABASE [ANAFIN_PREV] SET COMPATIBILITY_LEVEL = 120
GO
Après l’exécution de ce script, la base de données est créée et prête à recevoir les
restrictions de schéma et d’utilisateurs qui seront décrites dans le guide d’exploitation.
En ce qui concerne la création des tables, l’ORM Entity Framework présenté plus haut offre
la possibilité de créer automatiquement les tables à partir de la structure des classes
définies dans les fichiers modèle du code. C’est la méthode Code First ; elle crée
dynamiquement les tables et assure la persistance des données via le contexte de base de
données implémenté à base des classes entités.
2.4. Quelques interfaces

Voici quelques interfaces de notre application.
 Formulaires
Figure 32 : Formulaire de création de dossier

Figure 33 : Formulaire de matière première en fenêtre modale
 Ecrans à tableur
Figure 34 : Ecran des investissements détaillés

Figure 35 : Ecran des objectifs de consommation de matières premières
CONCLUSION
Dans ce dossier, les différents outils ayant contribué à la mise en œuvre du produit ont été
décrits. De même, il a été question de présenter l’application de par son architecture et
quelques-unes de ses interfaces. La fin de ce dossier conclut le rapport de réalisation du
projet.
Nous disposons à cette étape, les éléments essentiels pour l’élaboration du manuel
d’exploitation.

CHAPITRE 5 : EXPLOITATION
Cinquième chapitre
EXPLOITATION

Exploitation
INTRODUCTION
Le dossier de réalisation et de mise en œuvre qui a précédé présente l’application et les

outils ayant servi à sa matérialisation. Néanmoins, il est nécessaire de remplir au préalable
un certain nombre de conditions pour sa mise en place en environnement de production.
De même l’utilisateur doit disposer d’une politique d’administration et de maintenance en
vue de garantir un bon usage de l’application.
Dans ce document, il sera présentée la configuration matérielle et logicielle puis les normes
de déploiement et de suivi de l’outil.
1. CONFIGURATION MATERIELLE ET LOGICIELLE
1.1. Configuration matérielle

Pour la mise en exploitation de notre application, les serveurs et les postes clients doivent
avoir les caractéristiques indiqués dans le tableau 11.
Tableau 11 : Configuration matérielle requise
Configuration minimale Configuration recommandée
Processeur : 1.7 GHz , 64 bits Processeur : 2.1 GHz , 64 bits

Serveur d’application RAM : 8 Go RAM : 16 Go
HDD: 60 Go HDD: 300 Go
Processeur : 1.7 GHz , 64 bits Processeur : 2.1 GHz , 64 bits

Serveur de base de
RAM : 8 Go RAM : 16 Go
données
HDD: 1 To HDD: 2 To
Processeur : 1.7 GHz, 64 bits Processeur : 2.1 GHz, 64 bits
Poste client RAM : 2Go RAM : 4 Go
HDD : 60 Go HDD : 300 Go
1.2. Configuration logicielle

 Système d’exploitation Windows Server 2012 ou version ultérieure requis.
 Base de données SQL Server Management Studio 2014 ou version ultérieure
recommandée.
 Configuration de Internet Information Services (IIS) sur le serveur d’application

Exploitation
2. DEPLOIEMENT ET SUIVI
2.1. Déploiement de l’application

Le déploiement se fera en trois (3) étapes :
 Création de la base de données

 Configuration de l’application
 Déploiement dans le gestionnaire de services (IIS)
2.1.1. Création de la base de données

La première étape dans le déploiement de l’application consiste à créer la base de données,
son schéma et le nouvel utilisateur. Pour se faire, lancer le SSMS (SQL Server Management
Studio) sur le serveur de base de données et se connecter. Ensuite ouvrir une fenêtre de
nouvelle requête et exécuter le script suivant :
CREATE DATABASE [ANAFIN_PREV]

CONTAINMENT = NONE
GO
ALTER DATABASE [ANAFIN_PREV] SET COMPATIBILITY_LEVEL = 120
GO
USE [ANAFIN_PREV]
GO
CREATE LOGIN [anafin] WITH PASSWORD ='***************'
GO
CREATE USER [afp_user] FOR LOGIN [anafin]
GO
ALTER ROLE [db_owner] ADD MEMBER [afp_user]
GO
ALTER ROLE [db_datareader] ADD MEMBER [afp_user]
GO
ALTER ROLE [db_datawriter] ADD MEMBER [afp_user]
GO
CREATE SCHEMA [afp] AUTHORIZATION [afp_user]
GO
2.1.2. Configuration de l’application

Après la création de la base de données, décompresser le fichier ANAFIN_PREV.rar du
support d’installation dans le répertoire par défaut des applications IIS :
« C:\inetpub\wwwroot ».
Afin d’assurer la connexion entre l’application et la base de données, il faut conformer la

chaine de connexion du fichier de configuration à l’instance de la base de données créée.
Ce fichier n’est rien d’autre que le fichier Web (Web.config) situé à la racine du répertoire

Exploitation
de l’application. Dans le fichier, renseigner la valeur adéquates de la chaîne de connexion

dans la propriété connectionString.
Nom du serveur **********
2.1.3. Déploiement dans le gestionnaire des services (IIS)

L’application va être déployée sur IIS, le serveur web par défaut de votre système
d’exploitation Windows.
Après l’activation du serveur et de ses composants, ouvrir le gestionnaire de services IIS.

Démarrer > Panneau de configuration > Outils d’administration > Gestionnaire de Services Internet (IIS)
Dans la fenêtre du Gestionnaire de Services Internet (IIS), dérouler l’arborescence à gauche

jusqu’au nœud « Default Web Site ». Ce nœud correspond au répertoire par défaut des
application IIS. Ensuite sous le nœud, choisir « Convertir en application » dans le menu
contextuel du dossier décompressé « ANAFIN_PREV ». Dans la boîte de dialogue qui
s’affiche, cliquer sur « OK ».
L’application est déployée. Dès lors, elle est prête à être lancée. Faire un clic droit sur
l’application puis Gérer une application > Parcourir.

Exploitation
2.2. Suivi de l’application

Pour un bon suivi de l’application, il est indispensable de disposer d’une politique de
sauvegarde et d’un cahier d’évènements.
2.2.1. Sauvegarde de la base de données

L’absence d’une politique de sauvegarde des données d’une application pourrait coûter
chère à la vie d’une entreprise. Il est donc nécessaire d’instaurer une politique de
sauvegarde. Voici une proposition de sauvegarde complète sur disque avec SSMS.
1. Après la connexion à l’instance appropriée du moteur de base de données SQL Server,

dans l’Explorateur d’objets, cliquer sur le nom du serveur pour développer son
arborescence
2. Développer Bases de données, puis sélectionnez la base de données ANAFIN_PREV
3. Cliquer avec le bouton droit sur la base de données, pointer sur Tâches, puis cliquer
sur Sauvegarder. La boîte de dialogue Sauvegarder la base de données s'affiche
4. Dans la section Destination de la rubrique Général, sélectionner Sauvegarde sur : Disque.
5. Supprimer si nécessaire les fichiers de sauvegarde existants
6. Cliquer sur Ajouter pour ouvrir la boite de dialogue Sélectionner la destination de la
sauvegarde
7. Entrer le chemin en précisant la date dans la zone de texte Nom de fichier et valider.
(Ex : E:\MSSQL\BAKUP\ANAFIN_PREV_20180812.bak)
Les sauvegardes complètes doivent suivre une fréquence hebdomadaire ou mensuelle en

fonction du volume et de l’importance des informations manipulées. Lorsque le volume de
la base de données augmente considérablement, il est recommandé de faire des
sauvegardes de type différentiel.
2.2.2. Cahier des évènements

Durant le cycle de vie de l’application, l’administrateur a pour responsabilité d’assurer le
bon déroulement des opérations. Aussi longtemps que l’administrateur dans sa tâche, ne
peut tout constater, il est prévu un document dans lequel les erreurs ou incidents qui se
produisent au cours de l’exploitation doivent être mentionnés. Ces relevés serviront de
support pour une maintenance voire une réadaptation. La structure du document dans
lequel seront mentionnées ces informations se présente comme suit :
Date Heure Description Profil de l’utilisateur

Exploitation
CONCLUSION
Ce cinquième dossier, guide d’exploitation a pour objet de permettre à l’exploitant de

mettre en place toutes les configurations nécessaires au fonctionnement de l’application,
de disposer d’une politique de sauvegarde et d’adopter des pratiques qui faciliteront la
maintenance du logiciel.

CHAPITRE 6 : UTILISATION
Sixième Partie
UTILISATION

Utilisation
INTRODUCTION
Le guide d’utilisation est un document nécessaire pour la prise en main d’une application.
Il permet de se familiariser aux fonctionnalités et est d’une grande utilité dans le cadre de
la formation des futurs utilisateurs. Ce présent dossier nous permet de documenter notre
application.
1. PRESENTATION DE L’APPLICATION
 Lancement de l’application
Avant le lancement de l’application, les conditions suivantes doivent être remplies :
౼ Les services du SSMS sont démarrés sur le serveur de base de données

౼ Le serveur web IIS est opérationnel
౼ Le poste client est connecté au réseau local (ou internet si implémenté)
Ces conditions étant réunies, l’utilisateur peut accéder à l’application à partir de son
navigateur (Google Chrome, Mozilla Firefox) de son poste client en saisissant dans la barre
d’adresse d’un onglet du navigateur l’URL de l’application. Il est possible de créer un
raccourci de l’application sur le bureau du client pour qu’il y soit directement lancé.
Une fois l’application lancée, l’utilisateur accède à la page d’authentification où il renseigne

son nom d’utilisateur et son mot de passe.
Figure 36 : Ecran de connexion

Utilisation
 Présentation des menus standards
Une fois le portail de connexion passé, l’utilisateur se retrouve sur la page d’accueil qui se
présente comme suit dans le cas où l’utilisateur aurait le profil Super Admin.
Figure 37 : Ecran d'accueil
L’application dispose de deux (2) types de barre de menus : les menus dits standards qu’on
retrouve sur la page d’accueil et les menus du mode analyse auxquels on accède en passant
par le menu spécialisé « Analyse ».
Parmi les menus dits standards, on distingue :
౼ Le menu « Administration » qui prend en charge la gestion des utilisateurs et des

comptes ;
౼ Le menu « Paramétrage » qui sert à définir les paramètres systèmes aussi bien pour
l’analyse que pour les modules complémentaires ;
౼ Le menu « Dossier » qui permet d’accéder à la liste des dossiers et d’effectuer
toutes les opérations corollaires à l’instar de la création de nouveau dossier et client,
du changement d’état et d’édition des informations ;
౼ Le menu spécialisé « Analyse » qui permet de sélectionner un dossier et d’entrer
dans son mode analyse ;
౼ Le menu « Mon compte » qui permet à l’utilisateur connecté de consulter ses
informations personnelles et lui offre la possibilité de changer son mot de passe ;
౼ Respectivement à l’extrême gauche et droite, figurent les icones « Accueil » pour
afficher la page d’accueil et « Déconnexion » pour fermer la session.

Utilisation
 Mode analyse
Le mode analyse est un espace de travail dédié à l’étude complète d’un dossier. Il
représente le cœur du métier de l’analyse financière prévisionnelle. L’analyste pour y
accéder doit cliquer sur le menu « Analyse » pour rechercher le dossier à étudier.
Figure 38 : Ecran de recherche de dossier
L’écran ci-dessus permet d’afficher les cinq (5) premiers dossiers correspondants aux filtres
renseignés par l’analyste.
1. Renseigner le filtre identifiant, ou nom du projet et/ou nom de la contrepartie. Noter

que « % » comme valeur de filtre identifiant renvoie tout simplement les cinq (5)
premiers dossiers enregistrés.
2. Cliquer sur le bouton « Rechercher » pour afficher les résultats.
3. Double-cliquer sur un élément pour ouvrir le dossier en mode analyse.
Après cette étape, nous débouchons sur la fiche signalétique, figure 39, du dossier double-
cliqué et nous avons accès aux différents menus du métier.

Utilisation
Figure 39 : Ecran de fiche signalétique de dossier
Les menus suivants avec leurs sous menus permettent d’explorer tous les écrans impliqués
dans l’analyse financière prévisionnelle.
Cependant avant d’entamer toute étude, il est obligatoire de renseigner et enregistrer les
paramètres généraux du dossier à partir du menu « Paramètre », figure 40.
Figure 40 : Ecran paramètres de dossier
Le nombre d’années d’étude et l’année de réalisation des investissements permettront de

générer les années couvertes par la durée de l’étude. A partir de cette étape, les différentes
estimations peuvent être renseignées pour l’analyse proprement dite.

Utilisation
2. MAINTENANCE
La maintenance sera régie par les erreurs constatées au cours de l’utilisation de

l’application. Pour cela, nous définissons ici les actions à mener en cas de certaines erreurs.
Ces erreurs sont scindées en deux(2) parties : les erreurs courantes et les autres erreurs.
 Maintenance des erreurs courantes
Certaines erreurs qualifiées de courantes au cours de l’utilisation de l’application sont

résumées dans le tableau ci-dessous avec les actions de réparations à mener.
Tableau 12 : Maintenance des erreurs courantes
Code erreur Description Action à mener
La connexion a échoué
(Firefox) Impossible de se connecter Notifier l’erreur à
Cette page est inaccessible au serveur web l’administrateur
(Chrome)
Vous n’êtes pas autorisé à Cliquer sur Retour à la

403 non autorisé
accéder à cette page page d’accueil
La page à laquelle vous Vérifier si l’URL est bien

404 not found
tentez d’accéder n’existe pas saisie
 Maintenance des autres erreurs
En ce qui concerne les autres cas d’erreur, l’utilisateur doit informer l’administrateur de
l’application par l’intermédiaire du cahier des évènements.
CONCLUSION
Une solution informatique n’a d’importance que si elle est utilisable et accessible par les
utilisateurs visés. L’utilisation de l’application, sa compréhension et son apprentissage se
réalisent au fur et à mesure qu’on s’applique à son emploi. Ce guide rendra plus facile le
premier contact et servira de référence pour toute éventuelles difficultés rencontrées.

CONCLUSION GENERALE
Ce document est le fruit du projet sur lequel nous avons eu à travailler durant six (6) mois
de stage effectués à CERGI SA dans le cadre de notre formation. Il comprend les phases
d’étude, de conception et de réalisation qui représentent les étapes inéluctables dans le
processus de développement logiciel. Notre travail a porté sur la « Conception et mise en
place d’un outil d’analyse financière prévisionnelle des entreprises demandeuses
de crédits ». Le choix de ce sujet a été motivé par le souci d’apporter une contribution au
développement technologique et économique du Togo en particulier et de l’Afrique en
général. C’est après une observation soutenue que nous avons constaté que la situation
fonctionnelle de la gestion des crédits dans les institutions financières de la sous-région
subsaharienne est léthargique en raison des méthodes quasi-manuelles en vigueur.
Le champ bien que vaste, nous avons réalisé une réelle possibilité d’implantation de notre
application d’analyse financière prévisionnelle, car elle améliorerait les conditions de
conservation, de traitement et de consultation des informations impliquées dans la gestion
des risques qui apparaît encore complexe pour nos institutions. Cet outil informatique est
une aubaine en ce sens qu’il fournit aux décideurs des informations non seulement utiles
à la gestion de la banque, mais aussi à la prise des décisions rationnelles. Notre application
est composée de sept (7) modules. Le premier module nommé « Administration » permet
de gérer les utilisateurs du système, leurs comptes et les habilitations. Le second
« Paramétrage » gère toutes les configurations métiers utiles à l’analyse. Ensuite, nous
avons le module « Gestion dossier » qui pilote le workflow de l’étude. Le quatrième module
est celui des « Investissements ». Il prend en compte les investissements détaillés, les taux
d’exécution, l’échéancier des investissements, les renouvellements et les amortissements
d’investissement. Les valeurs d’investissement servent à alimenter l’actif immobilisé du
bilan. Nous avons également le module « Production et consommation » qui permet
d’évaluer la consommation de matières premières et la production de chiffre d’affaires qui
en découle dans le cycle d’exploitation de l’entreprise. Le sixième module est celui des
« Emprunts ». Il permet de constater les amortissements de prêts et alimente une partie du
plan de financement. Enfin nous avons le module des « Etats financiers » ou encore
documents transversaux. C’est l’ensemble des documents qui exploitent les données des
trois (3) modules précédentes pour produire des états qui feront l’objet d’interprétation.
Quand bien même, nous nous sentons satisfaits par nos recherches et travaux, nous ne
serons pas convaincus d’avoir fait de ce travail une parole d’évangile. Nous sommes donc
ouverts à toute remarque constructive et nous présentons nos excuses pour les éventuelles
coquilles qui se seraient glissées dans ce mémoire. En perspective, nous envisageons
aborder les interprétations automatiques et le volet banque de l’analyse financière.

REFERENCES BIBLIOGRAPHIQUES
 Ouvrages
౼ Lauzel P, Teller R (1999). Le contrôle de gestion et budget. Sirey, Paris, 352 p.
౼ Cohen E (1997) L’analyse financière. Economica, publication inconnu, non paginé.
౼ Marion A, Asquin A, Everaere C, Vinot D, Wissler M (2012). Diagnostic de la

performance de l'entreprise. Dunod, Paris, 302 p.
౼ Lavaud R (1969). Comment mener une analyse financière. Dunod, Paris, 118 p.
౼ BUISSART C (1999). Analyse financière. Foucher, publication inconnu, 240 p.
౼ Hounkou E, Dannon P, Wele P (2010). Cours de Gestion financière, FASEG/ Université

d'Abomey Calavi.
౼ Barraux J (1997). Entreprise et performance globale outils évaluation pilotage.

Economica, Paris, 256 p.
౼ Pr El Mallouki, Pr Fekkak (2014). Analyse financière. Editeur inconnu, 118 p.
౼ Mounier-Kuhn P (2013). Mémoires vives : 50 ans d’informatique chez BNP Paribas.

BNP Parisbas, Paris, 196 p.
౼ Bah O (2008). La Gestion du Risque de Crédit : un enjeu majeur pour les Banques.
Maitrise Banque Assurance Finance, Université de Dakar Bourguiba, non paginé.
౼ De Servigny A, Zelenko I (2010). Le risque de crédit : Nouveaux enjeux bancaires.

Dunod, Paris, 336 p.
౼ Booch G, Jacobson I, Rumbaugh J (1999). The Unified Software Developpement

Process. Addison-Wesley, Boston, 463 p.
౼ Roques P, Vallée F (2007). UML 2 en action, De l’analyse des besoins à la conception.

Eyrolles, Nice, 381 p.
 Sites web
౼ Manager Go (2014). Pourquoi faire une analyse financière ? [en ligne]. Disponible
sur <https://www.manager-go.com/finance/analyse-financiere.htm> (consulté
12.04.2018)

౼ UTBM (2017). Université Technologique : Repères [en ligne]. Disponible sur

<https://www.utbm.fr/utbm/universite-de-technologie/> (consulté 05.2018)
౼ FAGACE (2014). Fonds Africain de Garantie et de Coopération Economique :

Capital social [en ligne]. Disponible sur <http://www.le-
fagace.org/fr/fagace/capital-social> (consulté 05.2018)
౼ Alphorm (2013). Formation CSharp Révisé [en ligne]. Disponible sur

<https://www.alphorm.com/tutoriel/formation-en-ligne-programmer-en-csharp-6>
(consulté tout au long du projet)
౼ Alphorm (2015). Formation Asp net [en ligne]. Disponible sur

<https://www.alphorm.com/tutoriel/formation-en-ligne-asp-net-mvc-4-70-486>
౼ Microsoft (2018). Documentation Asp.net [en ligne]. Disponible sur

<https://docs.microsoft.com/en-us/aspnet/mvc> (consulté tout au long du projet)
౼ Asp MVC (2018). Documentation Asp.net [en ligne]. Disponible sur

<https://www.asp.net/mvc> (consulté tout au long du projet)
౼ EF Tutorial (2018). Documentation Entity Framework [en ligne]. Disponible sur

<http://www.entityframeworktutorial.net/code-first/what-is-code-first.aspx>
౼ PC21 SARL (2018). Cotations [en ligne]. Disponible sur <https://www.pc21.fr>

(consulté 30.07.2018)
౼ Wikipédia (2018). [en ligne]. Disponible sur <https://fr.wikipedia.org/> (consulté

tout au long du projet)
 Notes de cours
౼ Koussoube S, (2016-2017). Conception et programmation orientées objets
౼ Lamrous S, (2016-2017). Gestion de projet
౼ Andjao T, (2017-2018). Sécurité des systèmes informatiques
౼ Wilson C, (2017-2018). Interface homme/machine et perception

TABLE DES MATIERES
DEDICACE................................................................................................................................................................. i
REMERCIEMENTS ................................................................................................................................................. ii
RESUME .................................................................................................................................................................. iii
ABSTRACT .............................................................................................................................................................. iv
SOMMAIRE ............................................................................................................................................................. v
LISTE DES PARTICIPANTS ...............................................................................................................................vii
LISTE DES TABLEAUX ...................................................................................................................................... viii
LISTE DES FIGURES ............................................................................................................................................. ix
GLOSSAIRE.............................................................................................................................................................. x
INTRODUCTION GENERALE ............................................................................................................................1
CHAPITRE 1 : CADRE D’ETUDE .......................................................................................................................2
INTRODUCTION ...................................................................................................................................................3
1. PRESENTATION DU CIC-UL ....................................................................................................................3
2. PRESENTATION DE L’UTBM ...................................................................................................................3
3. PRESENTATION DE CERGI SA ................................................................................................................4
3.1. Statut........................................................................................................................................................4
3.2. Mission ....................................................................................................................................................4
3.3. Activités...................................................................................................................................................5
3.4. Quelques réalisations ........................................................................................................................5
3.5. Organigramme.....................................................................................................................................6
3.6. Plan de localisation ............................................................................................................................6
CONCLUSION ........................................................................................................................................................7
CHAPITRE 2 : ETUDE DU CAHIER DES CHARGES ....................................................................................8
INTRODUCTION ...................................................................................................................................................9
1. PROBLEMATIQUE ET PRESENTATION DU SUJET ...........................................................................9
1.1. Problématique du sujet ....................................................................................................................9
1.2. Présentation du sujet ..................................................................................................................... 10
1.3. Intérêt du sujet.................................................................................................................................. 10

1.3.1. Objectifs ...................................................................................................................................... 10

1.3.2. Résultats attendus................................................................................................................... 11
2. ETUDE ET CRITIQUE DE L’EXISTANT ................................................................................................ 11
2.1. Etude de l’existant ........................................................................................................................... 11
2.2. Critique de l’existant ....................................................................................................................... 13
3. PROPOSITIONS ET CHOIX DE SOLUTION ..................................................................................... 14
3.1. Spécifications de la solution ........................................................................................................ 14
3.1.1. Aspect fonctionnel .................................................................................................................. 14
3.1.2. Aspect sécurité ......................................................................................................................... 14
3.2. Approches de solution................................................................................................................... 15
3.2.1. Première solution : acquisition d’une application ...................................................... 15
3.2.2. Deuxième solution : développement d’une application ......................................... 16
3.3. Solution retenue ............................................................................................................................... 16
4. PLANNING PREVISIONNEL DE REALISATION .............................................................................. 17
CONCLUSION ..................................................................................................................................................... 19
CHAPITRE 3 : ANALYSE ET CONCEPTION ............................................................................................... 20
INTRODUCTION ................................................................................................................................................ 21
1. PRESENTATION DE LA METHODE D’ANALYSE ............................................................................ 21
1.1. Présentation du langage UML .................................................................................................... 21
1.2. Présentation du processus 2TUP ............................................................................................... 22
2. PRESENTATION DE L’OUTIL DE MODELISATION ....................................................................... 23
2.1. Qu’est-ce que PowerDesigner ? ................................................................................................ 23
2.2. Quels sont les atouts de PowerDesigner ? ............................................................................ 24
3. ETUDE DETAILLEE DE LA SOLUTION................................................................................................ 24
3.1. Etude fonctionnelle ......................................................................................................................... 24
3.1.1. Capture des besoins fonctionnels .................................................................................... 24
3.1.1.1. Identification des cas d’utilisation fonctionnels ................................................. 24
3.1.1.2. Diagramme de cas d’utilisation ................................................................................ 27
3.1.1.3. Description textuelle des cas d’utilisation ............................................................ 30
3.1.2. Analyse fonctionnelle statique ........................................................................................... 34

3.1.2.1. Diagrammes de classes participantes .................................................................... 34

3.1.2.2. Diagramme de packages ............................................................................................. 36
3.1.3. Analyse fonctionnelle dynamique .................................................................................... 37
3.1.3.1. Diagrammes d’activités ................................................................................................ 37
3.1.3.2. Diagrammes de séquences ......................................................................................... 39
3.2. Etude technique ............................................................................................................................... 41
3.2.1. Capture des besoins techniques ....................................................................................... 42
3.2.1.1. Identification des cas d’utilisation techniques .................................................... 42
3.2.1.2. Architecture client/serveur .......................................................................................... 42
3.2.1.3. Architecture 3-tiers ........................................................................................................ 43
3.2.2. Conception générique........................................................................................................... 44
3.2.2.1. Diagramme de déploiement ...................................................................................... 44
3.2.2.2. Diagramme de composants ....................................................................................... 45
3.3. Conception du système................................................................................................................. 45
3.3.1. Diagramme de classes par modules ................................................................................ 46
3.3.1.1. Module administration système ............................................................................... 46
3.3.1.2. Module paramétrage .................................................................................................... 47
3.3.1.3. Module gestion dossier................................................................................................ 48
3.3.1.4. Module gestion investissement ................................................................................ 49
3.3.1.5. Module production et consommation ................................................................... 50
3.3.1.6. Module amortissement emprunt ............................................................................. 51
3.3.1.7. Module documents transversaux ............................................................................. 52
3.3.2. Diagramme de classes global ............................................................................................ 53
CONCLUSION ..................................................................................................................................................... 55
CHAPITRE 4 : REALISATION ET MISE EN OEUVRE ............................................................................... 56
INTRODUCTION ................................................................................................................................................ 57
1. MISE EN ŒUVRE ...................................................................................................................................... 57
1.1. Choix matériels ................................................................................................................................. 57
1.2. Choix logiciels ................................................................................................................................... 58
1.2.1. Outils de développement .................................................................................................... 58

1.2.2. Technologies ............................................................................................................................. 59

1.3. Sécurité de l’application ................................................................................................................ 61
1.3.1. Sécurité de la plateforme web ........................................................................................... 61
1.3.2. Sécurité de la base de données......................................................................................... 61
1.4. Evaluation financière de la solution ......................................................................................... 62
1.4.1. Coût matériel ............................................................................................................................ 62
1.4.2. Coût des licences ..................................................................................................................... 63
1.4.3. Coût humain .............................................................................................................................. 63
2.1. Présentation ....................................................................................................................................... 64
2.2. Architecture de l’application ....................................................................................................... 64
2.2.1. Maquette .................................................................................................................................... 64
2.2.2. Structure...................................................................................................................................... 65
2.2.3. Architecture de code.............................................................................................................. 65
2.3. Script de création de la base de données ............................................................................. 66
2.4. Quelques interfaces ........................................................................................................................ 66
CONCLUSION ..................................................................................................................................................... 68
CHAPITRE 5 : EXPLOITATION ....................................................................................................................... 69
INTRODUCTION ................................................................................................................................................ 70
1. CONFIGURATION MATERIELLE ET LOGICIELLE ........................................................................... 70
1.1. Configuration matérielle ............................................................................................................... 70
1.2. Configuration logicielle ................................................................................................................. 70
2. DEPLOIEMENT ET SUIVI ........................................................................................................................ 71
2.1. Déploiement de l’application ...................................................................................................... 71
2.1.1. Création de la base de données........................................................................................ 71
2.1.2. Configuration de l’application ........................................................................................... 71
2.1.3. Déploiement dans le gestionnaire des services (IIS)................................................. 72
2.2. Suivi de l’application....................................................................................................................... 73
2.2.1. Sauvegarde de la base de données ................................................................................. 73
2.2.2. Cahier des évènements ......................................................................................................... 73

CONCLUSION ..................................................................................................................................................... 74
CHAPITRE 6 : UTILISATION ........................................................................................................................... 75
INTRODUCTION ................................................................................................................................................ 76
2. MAINTENANCE......................................................................................................................................... 80
CONCLUSION ..................................................................................................................................................... 80
CONCLUSION GENERALE .............................................................................................................................. 81
REFERENCES BIBLIOGRAPHIQUES ............................................................................................................. 82
TABLE DES MATIERES ...................................................................................................................................... 84
ANNEXES .............................................................................................................................................................. 89

ANNEXES
Annexe a : Informations générales d'un dossier de prêt
Annexe b : Investissements détaillés

Annexe c : Objectifs de production et de CA
Annexe d : Comptes d'exploitation prévisionnels en PDF

Annexe e : Bilan prévisionnel
Annexe f : The Business Plan Shop, Activité

Annexe g : The Business Plan Shop, Résultats

Conception Et Mise en Place D Un Outil D

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

Conception Et Mise en Place D Un Outil D

Transféré par

Droits d'auteur :

Formats disponibles

MINISTERE DE L’ENSEIGNEMENT SUPERIEUR MINISTERE DE L’ENSEIGNEMENT SUPERIEUR,

ET DE LA RECHERCHE DE LA RECHERCHE ET DE L’INNOVATION

01 BP 1515 Lomé 01 – TOGO UTBM – 90010 BELFORT CEDEX

MEMOIRE DE FIN DE FORMATION

CONCEPTION ET MISE EN PLACE

Soutenu le 19/09/2018 par :

TSOGBETSE Israël Kodjo

Devant le Jury composé de

Président : M. PINDRA Nadjime, Maître de Conférences

Examinateur : M. HOETOWOU Yaovi, Ingénieur de Conception en Informatique

Directeur de mémoire : M. ATCHONOUGLO Kossi, Maître de Conférences

Maitre de stage : M. KPEGLO Boris, Ingénieur Informaticien

Je dédie ce mémoire à mes Parents

Mémoire de Master – TSOGBETSE I. K. i CIC - UTBM

Nous exprimons nos reconnaissances

 à Monsieur ATCHONOUGLO Kossi, Directeur du CIC et Directeur de ce mémoire

 à Monsieur LAMROUS Sid, co-responsable de la formation master à UTBM, pour sa

 à Monsieur BOROZE Tchamye Tcha-Esso, Directeur Adjoint du CIC et à Monsieur

 à Monsieur KPEGLO Boris, Ingénieur Informaticien, Directeur Technique Adjoint à

 aux membres du jury qui ont accepté ce travail ;

 au corps professoral de CIC-UTBM pour la qualité de la formation ;

 aux membres de la Team Scoring, nommément Monsieur KASSA Stéphane,

 à Monsieur NONDOH-ADABI Noël du service informatique interne de CERGI SA

 à nos camarades de la promotion 2016-2018 pour l’esprit de partage et d’entraide ;

Mémoire de Master – TSOGBETSE I. K. ii CIC - UTBM

Mémoire de Master – TSOGBETSE I. K. iii CIC - UTBM

Mémoire de Master – TSOGBETSE I. K. iv CIC - UTBM

Mémoire de Master – TSOGBETSE I. K. v CIC - UTBM

2. DEPLOIEMENT ET SUIVI ........................................................................................................................ 71

Mémoire de Master – TSOGBETSE I. K. vi CIC - UTBM

LISTE DES PARTICIPANTS

Intervenants Fonctions Rôles

TSOGBETSE Etudiant en 2ème année de master

M. ATCHONOUGLO Maître de Conférences à l’Université de Lomé Directeur de

M. KPEGLO Ingénieur Informaticien Maître de

M. DOLEAGBENOU Développeur d’applications Référent

Mémoire de Master – TSOGBETSE I. K. vii CIC - UTBM

LISTE DES TABLEAUX

Tableau 1 : Planning prévisionnel ...................................................................................................................................................17

Mémoire de Master – TSOGBETSE I. K. viii CIC - UTBM

LISTE DES FIGURES

Figure 1 : Organigramme de CERGI SA .......................................................................................................................................... 6

Mémoire de Master – TSOGBETSE I. K. ix CIC - UTBM

ATULL Association Togolaise des Utilisateurs de Logiciels Libres

UTBM Université de Technologie de Belfort Montbéliard

Mémoire de Master – TSOGBETSE I. K. x CIC - UTBM

Dans sa grande mission de pallier les insuffisances humaines en matière de calcul, de

Mémoire de Master – TSOGBETSE I. K. Page 1 sur 103 CIC - UTBM

CHAPITRE 1 : CADRE D’ETUDE

Mémoire de Master – TSOGBETSE I. K. Page 2 sur 103 CIC - UTBM

Créée en 1999, l’Université de Technologie de Belfort Montbéliard (UTBM) est un

Mémoire de Master – TSOGBETSE I. K. Page 3 sur 103 CIC - UTBM

Au sein du parterre des universités partenaires de l’UTBM figure l’Université de Lomé.

Mémoire de Master – TSOGBETSE I. K. Page 4 sur 103 CIC - UTBM

౼ développer des modules évolutifs de services bancaires ;

3.4. Quelques réalisations

Mémoire de Master – TSOGBETSE I. K. Page 5 sur 103 CIC - UTBM

DIRECTEUR ADMINISTRATIVE DIRECTEUR COMPTABLE &

Figure 1 : Organigramme de CERGI SA

3.6. Plan de localisation

Figure 2 : Plan de localisation de CERGI SA

Mémoire de Master – TSOGBETSE I. K. Page 6 sur 103 CIC - UTBM

Ce stage recommandé par la formation du master CIC-UTBM, se déroule à CERGI SA. Et le