Mémoire BLU Kwensy Eli

Institut Africain d’Informatique GPO Consulting
Etablissement Inter-états d’Enseignement BP 23608 Libreville Gabon

Supérieur Tél. (+241) 07210070/ 05557524
BP : 2263 Libreville (Gabon) Site web : www.gpo-consulting.net
Tel. (00241) 07 70 55 00/07 70 56 00
E-mail : contact@gpo-consulting.net
Site web: www.iai-siege.net
E-mail: contact@iai-siege.net
MEMOIRE DE FIN DE CYCLE
En vue de l’obtention du diplôme d’ingénieur de conception en informatique
TABLE DES MATIÈRE

THEME
Système analytique et microfinance :
Conception et réalisation d’une plate-forme sécurisée de traitements et suivis des
informations et services micro-financiers.
Présenté et soutenu par :
BLU Kwensy Eli

Elève ingénieur en informatique
Superviseur IAI Maître de stage
Mr. HOUTSA Felix Mr. PODA Ghislain
Enseignant IAI Gérant de GPO Consulting
Année académique 2013-2014

Système analytique et microfinance : Conception et réalisation d’une plate-forme sécurisée de traitements et
suivis des informations et services micro-financiers
S
TABLE DES MATIÈRES........................................................................................................................................i
DEDICAcES.......................................................................................................................................................iii
REMERCIEMENTS.............................................................................................................................................iv
AVANT-PROPOS................................................................................................................................................v
RESUME...........................................................................................................................................................vi
ABSTRACT.......................................................................................................................................................vii
ABREVIATIONS...............................................................................................................................................viii
FIGURES...........................................................................................................................................................ix
TABLEAUX.........................................................................................................................................................x
INTRODUCTION GENERALE..............................................................................................................................1
PARTIE 1. PRESENTATION GENERALE...........................................................................................................2
Introduction..................................................................................................................................................3
CHAPITRE 1 : Présentation de la structure d’accueil et du sujet.............................................................3
1.1 Structure d’accueil........................................................................................................................3
1.2 Contexte et intitulé du sujet.........................................................................................................4
1.3 Problématique du sujet................................................................................................................5
1.4 Intérêts du sujet............................................................................................................................6
CHAPITRE 2 : Concepts liés au domaine.................................................................................................7
2.1 Institutions financières.................................................................................................................7
2.2 Les activités d’une microfinance...................................................................................................7
2.3 Dépôts et épargnes.......................................................................................................................8
2.4 Le crédit........................................................................................................................................9
2.5 Système analytique.....................................................................................................................10
Conclusion..................................................................................................................................................11
PARTIE 2. ANALYSE ET CONCEPTION..........................................................................................................12
Introduction................................................................................................................................................13
CHAPITRE 3 : Etude préliminaire..........................................................................................................14
3.1 Généralités sur les méthodes d’analyse et de conception..........................................................14
3.2 Choix d'une démarche................................................................................................................15
3.3 Présentation du processus unifié (UP)........................................................................................16
3.4 Présentation de l'eXtreme Programming (XP)............................................................................18
3.5 Présentation du langage de modélisation UML..........................................................................19
BLU Kwensy Eli - Institut Africain d’Informatique - 2014 Page i

CHAPITRE 4 : Analyse et conception de la plateforme.........................................................................24

4.1 Expression préliminaire des besoins fonctionnels......................................................................24
4.2 Expression des besoins non fonctionnels...................................................................................43
4.3 Expression détaillée des exigences fonctionnelles.....................................................................43
4.4 Identification des classes conceptuelles.....................................................................................46
4.5 Architecture logique de l’application..........................................................................................49
4.6 Architecture technique de la solution.........................................................................................51
Conclusion..................................................................................................................................................55
PARTIE 3. MISE EN ŒUVRE ET CONDUITE DE PROJET.................................................................................56
Introduction................................................................................................................................................57
CHAPITRE 5 : Mise en œuvre................................................................................................................58
5.1 La sécurité des applications web................................................................................................58
5.2 Choix des outils et des technologies d'implémentation..............................................................59
CHAPITRE 6 : Conduite de projet..........................................................................................................70
6.1 Gestion de projet........................................................................................................................70
6.2 Apports, difficultés et perspectives du projet.............................................................................72
Conclusion..................................................................................................................................................74
CONCLUSION GENERALE................................................................................................................................75
BIBLIOGRAPHIE...............................................................................................................................................76
ANNEXE..........................................................................................................................................................77
Annexe A : Certificat de sécurité auto signé utilisé pour la configuration du SSL.......................................77
Annexe B : Captures d’écran de l’application.............................................................................................78
BLU Kwensy Eli - Institut Africain d’Informatique - 2014 Page ii

DEDICACES
 A mes parents, BLU Koku Selom et GOGOVOR Kossiwa Ametoyowona

Pour l’amour dont vous ne cessez de me combler et le soutien que vous ne cessez de
m’accorder. Que Dieu vous procure bonne santé et longue vie ;
 A mon frère cadet BLU Kossikuma Luc, ma sœur aînée BLU Ama Sese

Pour les moments de joie que nous avons partagés et l’ambiance fraternelle dans laquelle
vous me faites vivre.
 A la mémoire de mon frère cadet BLU Augustin, paix à ton âme;
BLU Kwensy Eli - Institut Africain d’Informatique - 2014 Page iii

REMERCIEMENTS
J’aimerais remercier Dieu pour la persévérance, la santé, le courage et l’intelligence dont il m’a fait
grâce pour mener à bien ce travail.
J’aimerais également remercier :
 Dr. Souleymane KOUSSOUBE, Directeur Général de l’IAI;
 Mr. Ghislain PODA, gérant de GPO Consulting ;
 M. Félix HOUTSA pour ses conseils et sa supervision qui ont contribué à l’aboutissement de ce
travail;
 Pr. Ousmane Balira KONFE, enseignant à l’IAI, pour sa présence et ses suggestions très
motivantes lors de la réalisation du travail;
 Mr. Fleury MOUMBANGA, pour sa disponibilité et ses encouragements ;
 Ingénieur Ousseyni TIAMA, pour son encadrement et son suivi exceptionnels qui nous ont été
d’un grand soutien dans la réalisation de ce travail ;
 M. Djérabé Goldoum BENADJINGAR, coordonnateur de filière, pour l’encadrement des

étudiants de la filière Ingénieur;
 Pr. Jérôme AVOM, Directeur de l’Enseignement, pour ses cours très instructifs;
 Dr. Roger NOUSSI pour ses idées et remarques constructives;
 M. Maman MATY, enseignant à l’IAI, pour ses conseils et son ouverture d’esprit ;
 Tout le corps professoral et administratif de l’Institut Africain d’informatique ;
 Mlle Kadidiatou AMADOU ALI, M. Yawo GBINU, M. Koffi Edem ETOU, M. Koffi SANI
pour leurs soutiens et précieux conseils;
 Mes camarades (IAI 2011 - 2014) pour l’esprit de partage, la collaboration, le climat compétitif
dans lequel vous m’avez fait vivre pendant toute la durée de la formation;
 Mes amis de Libreville et du Togo.
BLU Kwensy Eli - Institut Africain d’Informatique - 2014 Page iv

AVANT-PROPOS
Le travail contenu dans ce document s’inscrit dans le cadre du programme de formation des
ingénieurs de conception des systèmes d’information de l’Institut Africain d’informatique (I.A.I). L’I.A.I
est une école Inter-états créée en 1971 dont le siège se trouve à Libreville au Gabon. Les Etats
actuellement impliqués sont le Bénin, le Burkina-Faso, le Cameroun, la République Centrafricaine, le
Congo Brazzaville, la Côte d’Ivoire, le Gabon, le Niger, le Sénégal, le Tchad et le Togo. La mission de
l’Institut Africain d’Informatique est de former des cadres supérieurs en informatique. Il forme entre
autres des ingénieurs de travaux en informatique, des maîtres ingénieurs en informatique de gestion et des
ingénieurs de conception en informatique. Dans le cursus de la formation des ingénieurs informaticiens,
l’IAI intègre en fin de la troisième année, un stage de formation pratique d’une durée de cinq(5) mois. Ce
stage vise à mettre les élèves-ingénieurs dans un environnement de conception d’applications
informatiques suffisamment importantes afin de permettre une insertion dans un contexte professionnel.
Le présent document marque l’aboutissement de trois (3) années de formation à l’I.A.I et de cinq (5) mois
de stage pratique à GPO Consulting. Il tient lieu de mémoire de fin d’étude d’ingénieur de conception en
informatique à l’I.A.I. Ce document est divisé en trois grandes parties. La première présentera la structure
d’accueil, le sujet d’étude et les concepts généraux liés à notre domaine d’étude, dans la deuxième partie,
il s’agira de l’analyse et de la conception du système notamment l’étude préliminaire, l’analyse et la
troisième partie de ce document sera consacrée à la mise en œuvre du système et à l’organisation du
projet logiciel.
BLU Kwensy Eli - Institut Africain d’Informatique - 2014 Page v

RESUME
La recherche et la mise en œuvre permanente de nouvelles stratégies d’innovation dans tous ses
domaines d’activités est la priorité de GPO Consulting. Dans un environnement économique hautement
concurrentiel, GPO Consulting s’est fixé certains objectifs dont celui d’offrir aux microfinances un
service de qualité permettant d’atteindre l’objectif d’efficacité dans le suivi de leurs activités. C’est dans
cet ordre d’idées qu’il nous a été demandé de mettre en place un système analytique de traitements et
d’analyse des activités d’une microfinance.
Pour atteindre cet objectif, nous avons étudié les activités d’une microfinance sur la base d’études
menées par des groupes d’experts du domaine et les applications d’entreprise. Nous avons adopté une
méthode basée sur un processus situé à mi-chemin entre UP et XP que nous avons jumelé avec le langage
de modélisation UML. Cette méthode nous a permis de réaliser, après une étape d'analyse et de
conception, une application Web couplée à une base de données. Cette solution à fonctionnalités
sélectives intègre la gestion des profils utilisateurs, un module d’automatisation des services financiers,
un système de notifications et un suivi des comptes d’épargne.
Mots clés : application Web, UP, XP, services financiers, microfinance, système analytique
BLU Kwensy Eli - Institut Africain d’Informatique - 2014 Page vi

ABSTRACT
Research and ongoing implementation of new strategies for innovation in all areas of its activities is
the GPO Consulting priority. In a highly competitive business environment, GPO Consulting has set
certain goals including to provide microfinances quality service to achieve the goal of efficiency in
monitoring their activities. It is in this vein that we were asked to develop an analytical system of
treatment and analysis of the activities of microfinance. To achieve this goal, we studied the activities of
microfinance on the basis of studies conducted by groups of domain experts and business applications.
Then we adopted an approach based on a process located halfway between UP and XP we paired with the
UML. This method has enabled us to realize, after an analysis and design stage, coupled with a Web
database application. This solution features selectively integrates the management of user profiles, a
financial services automation module, system notifications and track savings accounts.
Keywords : Web Application, UP, XP, financial services, microfinance, analytic system
BLU Kwensy Eli - Institut Africain d’Informatique - 2014 Page vii

ABREVIATIONS
Abréviations Signification
API Application Programming Interface
CSS Cascading Style Sheet
CVS Concurrent Versions System
DSS Digramme de Séquence Système
EJB Entreprise Java Bean
EL Expression Language
FTP File Transfer Protocol
HTML HyperText Markup Language
HTTP HyperText Transfert Protocol
IAI Institut Africain d’Informatique
IDE Integrated Development Environment
IP Internet Protocol
J2EE Java 2 Enterprise Edition
Java EE Java Enterprise Edition
JDBC Java DataBase Connectivity
JDK Java Developpement Kit
JEE Java Enterprise Edition
JNDI Java Naming and Directory Interface
JPA Java Persistence API
JPQL Java Persistence Query Language
JSE Java Standard Edition
JSF Java Server Faces
JSP Java Server Pages
JTA Java Transaction API
MVC Modèle Vue Contrôleur
OMG Object Management Group
PHP Hypertext Preprocessor
PME Petites et Moyennes Entreprises
PMI Petites et Moyennes Industries
SADT Structured-Analysis-Design-Technique
SGBD Système de Gestion de Bases de Données
SQL Structured Query Language
SSL Secure Socket Layer
TCP Transmission Contol Protocol
TLS Transport Layer Security
UML Unified Modeling Language
UP Unified Process
XML eXtensible Markup Language
XP eXtreme Programming
BLU Kwensy Eli - Institut Africain d’Informatique - 2014 Page viii

FIGURES
Figure 1 : Organigramme de GPO Consulting 4
Figure 2 : Phases du processus unifié 17
Figure 3 : Diagramme de contexte statique 25
Figure 4 : Diagramme de cas d'utilisation du package « Administration » 28
Figure 5 : Diagramme des cas d’utilisation du package « Suivi des activités » 28
Figure 6 : Diagramme des cas d’utilisation du package « Services financiers » 29
Figure 7 : Diagramme des cas d’utilisation global 30
Figure 8 : DSS cas d’utilisation « Octroyer un crédit » 44
Figure 9 : DSS cas d’utilisation « Créer compte épargne » 45
Figure 10 : DSS cas d’utilisation « Effectuer un transfert d’argent » 45
Figure 11 : DSS cas d’utilisation 46
Figure 12 : Diagramme des classes conceptuelles 48
Figure 13 : Découpage de notre application en couches 51
Figure 14: Architecture client/serveur 2-tiers 52
Figure 15 : Architecture Client/serveur 3-tiers 53
Figure 16 : Architecture technique de l'application 54
Figure 17 : Découpage en couches et Spécifications Java EE 62
Figure 18 : Découpage en couches et Framework Java EE 63
Figure 19 : Vue partielle du diagramme complété 64
Figure 20 : Vue partielle du diagramme de classes détaillé 65
Figure 21 : Diagramme de déploiement de notre application 68
Figure 22 : Diagramme de GANTT Prévisionnel 71
Figure 23 : Diagramme de GANTT réel 71
Figure 24: Ecran de connexion 78
Figure 25 : Interface d'administration : menu principal 78
Figure 26 : Gestion des agences 79
Figure 27 : Gestion des comptes d'utilisateur 79
Figure 28 : Enregistrement des informations concernant le client 80
Figure 29 : Octroi de crédit : Sélection d'un client existant 80
Figure 30 : Octroi de crédit : saisie des informations concernant le crédit 81
Figure 31: Demandes d’octroi de crédit en attente 81
Figure 32 : Traitement d'une demande d’octroi de crédit 82
Figure 33 : Diagrammes représentant le nombre de client par agence 82
Figure 34 : Rapport de guichet sur l'épargne 83
BLU Kwensy Eli - Institut Africain d’Informatique - 2014 Page ix

TABLEAUX
Tableau 1 : Méthodes de conception et critères d'évaluation............................................................................................ 16
Tableau 2 : Tableau récapitulatif des cas d'utilisation........................................................................................................ 26
Tableau 3 : Structuration des cas d'utilisation en package.................................................................................................. 27
Tableau 4 : Classification des cas d'utilisation en itérations................................................................................................ 31
Tableau 5 : Découpage en tâches du projet....................................................................................................................... 70
Tableau 6 : Intervenants au projet..................................................................................................................................... 71
Tableau 7 : Estimation des charges et coûts....................................................................................................................... 72
BLU Kwensy Eli - Institut Africain d’Informatique - 2014 Page x

INTRODUCTION GENERALE
Le secteur bancaire et financier est un domaine très actif de l’économie. Proposant des services de
transfert d’argent, d’hypothèques et d’octroi de crédits, les institutions s’inscrivant dans ce secteur sont de
plus en plus présentes. Les services offerts par les institutions financières, en l’occurrence les banques,
sont régis par des coûts généralement supérieurs aux revenus des populations pauvres ; ce qui fait que ces
dernières ne peuvent pas recourir aux services qu’offre une banque.
Compte tenu de tous ces aspects, des institutions, généralement à vocation sociale telles que les
microfinances ont développées des méthodes pour pouvoir améliorer la qualité des services financiers
auxquels les plus pauvres peuvent recourir. Les services de microfinance fournissent un ensemble de
produits financiers aux personnes exclues du système financier classique ou formel. Ils concernent en
général les habitants pauvres, des clients dépourvus d'un minimum de revenus ou des ménages aux
moyens limités. Les pays en voie de développement ont une majorité de population avec ce statut. C’est
le cas de la plupart des pays d’Asie, d’Amérique latine et d’Afrique.
Peu importe le pays concerné, avec cette majorité sans cesse croissante, le nombre des clients
d’une institution de microfinance peut atteindre plusieurs milliers ; ainsi celle-ci ressent généralement le
besoin d'améliorer ou d’informatiser son système d'information de suivi de ses activités. Mais l'art est
difficile ! Bien que les logiciels commercialisés de sources diverses ne manquent pas, les programmes
standards conçus pour la microfinance sont rarement une solution idéale, ne serait-ce que parce qu'il n'est
pas facile d'obtenir un appui technique sur place. Les institutions de microfinance en viennent donc à
élaborer une grande partie de leur système d’information de gestion de leurs activités pour qu'il réponde
réellement à leurs besoins notamment la prestation de services financiers comme le crédit, l’épargne ou le
transfert d’argent.
Conscient de toutes ces réalités, GPO Consulting, une entreprise spécialisée en conseil fiscal a pris
sur elle l’initiative de développement d’un tel système. L’aboutissement de notre travail dans cette
entreprise fut la mise en place d’un système d’automatisation des activités d’une microfinance qui offre
une fiabilité dans la prestation de services financiers, un contrôle plus efficace des états et documents de
synthèse produits.
Le présent mémoire présente ce travail en trois grandes parties. La première partie fait une
présentation générale du sujet et de la structure d’accueil en mettant à jour les principaux concepts liés au
sujet, la problématique et l’intérêt liés à celui-ci, la deuxième s’étend sur l’analyse du sujet et la
conception du système d’automatisation et la troisième développe les outils utilisés pour la mise en œuvre
du sujet et les aspects relatifs à la planification du projet.
BLU Kwensy Eli - Institut Africain d’Informatique - 2014 1

PARTIE 1. PRESENTATION GENERALE

Introduction
Dans cette partie, nous allons présenter dans un premier temps la structure au sein de laquelle nous
avons effectué notre stage de fin de formation, son domaine d’activités et ses vocations ; Nous passerons
ensuite à la présentation de notre sujet, de son contexte, la problématique s’y rattachant ainsi que ses
intérêts. Nous ferons par la suite un passage en revue des concepts liés au domaine d’étude dans lequel
s’inscrit notre sujet.
CHAPITRE 1 : Présentation de la structure d’accueil et du sujet

1.1 Structure d’accueil
GPO Consulting est une jeune entreprise spécialisée dans la formation et le conseil en fiscalité et
en comptabilité. Ses principaux axes de prestations sont :
L’assistance aux PME et PMI
 Assistance comptable : mise en place et suivi d’un système comptable ; élaboration des situations
périodiques et des ECF (Etats Financiers et Comptables) en fin d’exercice comptable.
 Assistance administrative : facilitation des relations avec les services administratifs extérieurs ;
aide à la compréhension et l’application de la législation sociale à la gestion du personnel.
 Assistance fiscale : conseils et déclaration fiscale.
Le contrôle de Gestion
 Contrôle budgétaire : analyse et détermination des écarts entre les prévisions et la réalité et
recherche des causes de l’écart.
 Analyse de gestion : appréciation de la qualité de la gestion financière et économique.
L’étude de faisabilité de projet

 Choix des investissements
 Etude de rentabilité de projets et détermination des besoins de fond de roulement.
L’ingénierie logicielle
GPO Consulting offre également des formations orientées gestion et comptabilité d’entreprise
notamment en :
 Organisation et gestion des stocks ;
 Gestion des immobilisations ;
 Contrôle de gestion ;
 Organisation et mise en place de comptabilité ;
 Initiation et perfectionnement à l’utilisation de logiciels de gestion comptable ;
 etc.
L’organigramme de GPO Consulting se présente comme suit :

Gérant
Assistante du
gérant
Pole technique
Pole Formation Pole Conseils et
développement
Consultant Consultant
Consultant Consultant
Contrôle de Externalisation
Comptabilité Fiscalité
gestion Paie
Figure 1 : Organigramme de GPO Consulting
1.2 Contexte et intitulé du sujet

Le système d’information est un élément essentiel de l’entreprise de nos jours. Les entreprises sont
prêtes à investir de fortes sommes afin d’obtenir un système d’information performant et adapté à leur
activité. C’est également un enjeu majeur pour la compétitivité de l’entreprise. Un système quel qu’il soit
doit contribuer à la performance de l’entreprise et en favoriser le progrès.
Au fil des années, les systèmes manuels utilisés dans la gestion du fonctionnement des institutions
financières ont démontré leur inefficacité. Cette dernière est d’autant plus flagrante que l’institution croit
en taille. L’inefficacité réside surtout dans la lenteur de la prestation des services financiers, la mauvaise
gestion de la clientèle et de volumes de données, la forte probabilité d’erreurs de montants durant les
opérations financières, la consolidation de données dans le cas d’une institution avec plusieurs agences. A
terme, ces risques entraînent une décroissance de la rentabilité et de la satisfaction de la clientèle de
l’institution concernée.
De plus, les tendances sont fortes pour l’adoption de solutions logicielles existantes. Dans ce cas,
ces solutions doivent être adaptées aux procédures de travail et aux opérations, qui varient fortement
d'une institution à une autre ; ce qui fait qu’elles sont inadaptées dans l’immédiat pour une institution
particulière. En outre, chaque solution revendiquant la qualification de logiciel de suivi des activités
d’une institution financière est différente, tant du point de vue de l'information qu'il vise que du type de

rapports qu'il produit et, surtout, des possibilités qu'il offre. Compte tenu de toutes ces divergences,
certains systèmes logiciels existants sont inappropriés pour une institution financière qui se veut
compétitive.
Au vu de tout ce qui précède, les motivations semblent plus qu’évidentes pour une institution
avertie de se doter, dans le but d’anticiper tous ces risques, d’un système performant, sécurisé et adapté à
toutes les spécificités de fonctionnement.
C’est dans cet ordre de préoccupations que GPO Consulting nous a attribué le sujet qui s’intitule
en ces termes : « Système analytique et microfinance : Conception et réalisation d’une plate-forme
sécurisée de traitements et suivis des informations et services micro-financiers. »
1.3 Problématique du sujet

Les institutions de microfinance, à l’instar de toute autre institution traite des données brutes en
entrée pour fournir des informations utiles en sortie. De ce fait, tout système ayant pour vocation de
s’intégrer dans le fonctionnement d’une microfinance doit proposer une série de procédures et d'actions à
effectuer pour saisir des données brutes, les transformer en information utilisable et transmettre cette
information aux utilisateurs sous une forme adaptée à leurs besoins.
Un tel système n’est pas un simple programme informatique ; il est bien plus et ne sert pas qu’à
effectuer des calculs. Notre travail n’est pas de concevoir un système d’information de gestion pour une
microfinance ou un système de comptabilité encore moins d’effectuer une gestion de ressources
humaines, mais de mettre en place un système capable de permettre à diverses personnes de
communiquer efficacement et aisément au sujet d’événements et d’activités qui touchent au travail de leur
organisation.
De ce point de vue, un système qui gère correctement un volume moyen d'activités peut
s'effondrer sous l'effet d'une masse de plus en plus grande d'informations. On peut au préalable envisager
de concevoir un système manuel mais à terme, de tels systèmes donnent lieu à l'accumulation de quantités
énormes de données non traitées. De ce fait, une institution mal préparée à une croissance rapide mettra,
en fin de compte, la qualité de ses services et sa santé financière en péril.
De plus beaucoup d’institutions de microfinance s’organisent en agences dépendant d’un siège
pour servir une clientèle abondante. Survient alors un problème récurrent lorsque les informations et
données à gérer sont éparses. En effet chaque agence dispose d’informations qui lui sont propres. Celles-
ci doivent être convoyées dans des délais raisonnables vers le siège pour assurer leur cohérence et leur
intégrité. Cependant, ces opérations sont sujettes à des retards qui handicapent le fonctionnement des
institutions.
Ces grandes préoccupations peuvent se synthétiser en ces questions :
 Comment faciliter l’octroi du crédit et en suivre le remboursement ?
 Comment effectuer un suivi efficace de l’épargne pour financer les opérations de crédit ?
 Comment mettre en place une plate-forme sécurisée facilitant les transferts et mouvements
financiers ?
 Quel système mettre en place pour traiter efficacement un volume important de données et les
restituer dans un délai raisonnable ?
 Quelle politique de sécurité adopter pour ne permettre l’accès qu’aux usagers autorisés et assurer
la confidentialité des données?
 Comment synthétiser et présenter les informations pour améliorer la prestation des services
financiers ?

Notre travail va consister à apporter des éléments de réponse à ces questions en nous focalisant sur
les objectifs fixés par le projet dans son contexte défini plus haut.
1.4 Intérêts du sujet

L’aboutissement du projet logiciel de développement d’un système analytique de traitement et de
suivi des activités et services micro-financiers permettra :
 D’offrir une série de procédures et d'actions effectuées pour saisir des données brutes, les
transformer en information utilisable et transmettre cette information aux utilisateurs sous une
forme adaptée à leurs besoins.
 A une microfinance de disposer d’un système capable de produire en temps voulu et de façon
précise des informations complètes sur ses opérations, et d’améliorer ses performances financières
pour mieux répondre aux besoins de sa clientèle.
 De révolutionner le travail des membres du personnel d'exécution en leur permettant d'assurer un
meilleur suivi de leur portefeuille et de mieux servir leurs clients, tout en travaillant avec une
clientèle de plus en plus nombreuse.
 Aux responsables de mieux suivre les tâches dont ils sont chargés, de mieux conseiller leur équipe
et d'identifier les aspects exigeant le plus d'attention.
 Aux microfinances de déterminer, en temps opportun et avec exactitude, la situation de leurs
revenus. La fiabilité de ce système peut faire la différence entre le succès et l'échec des opérations
de crédit.

CHAPITRE 2 : Concepts liés au domaine

Dans ce chapitre, nous ferons un passage en revue des principaux concepts et vocabulaires se
rapportant au corps de métier de la microfinance.
2.1 Institutions financières

« Les institutions financières sont des entreprises ou organisations d’affaires qui jouent le rôle de
mobilisateurs, de dépositaires d’épargnes et le rôle de pourvoyeurs de crédits ou de financements »
(BHOLE, 1999). Elles rendent également de nombreux services à la communauté.
Les institutions financières diffèrent des organisations d'affaires non financières (organisations
industrielles et commerciales) par leurs activités. Alors que les premières sont spécialisées en actifs
financiers tels que les dépôts, les prêts, les bourses de valeur, etc., les secondes s'occupent donc des actifs
réels comme les machines et équipements, les marchandises, etc.
Quels que soient leurs objectifs, les institutions financières ont en commun certaines
caractéristiques. Elles offrent une variété de crédits aux emprunteurs et donnent la possibilité aux prêteurs
d’accéder à une gamme variée d'actifs.
D’autres institutions offrent la couverture d'assurance ou d'autres avantages qui sont payés à leurs
clients ou épargnants sous condition de la réalisation de certains événements tels que la retraite, les
incendies ou l'expiration du contrat d'épargne.
2.2 Les activités d’une microfinance

La microfinance fait référence à l'offre de services financiers aux populations pauvres et à faibles
revenus, qui ont peu ou n'ont pas accès aux services financiers bancaires, dans le but de satisfaire les
besoins de leur ménage ou de leurs activités économiques et professionnelles. Les services financiers dont
il s'agit ici sont principalement de deux types, épargne et crédit, auxquels s'ajoutent dans certains cas les
assurances et les services de transfert.
Une institution de microfinance est une entreprise financière qui doit, à terme, couvrir ses
dépenses et dégager une marge sans appui extérieur pour être viable et continuer à offrir ses services. Par
ailleurs, les clients des institutions de microfinance ont besoin des services financiers pour, entre autres,
sécuriser leurs disponibilités et mener principalement des activités économiques.
Cependant, au-delà de leur fonction d'intermédiation financière, de nombreuses institutions de
microfinance jouent un rôle d'intermédiation sociale à travers notamment les modalités suivantes :
groupes de solidarité, formation des clients, renforcement de la confiance en soi, participation à la
gestion. Ainsi, la microfinance se définit souvent par les deux fonctions d'intermédiation sociale et
financière. La microfinance consiste à offrir des services financiers aux populations exclus du système
financier classique que constituent les banques notamment composées de petit travailleurs indépendants
ou organisés en groupements. Elle s'est développée en tant qu'approche de développement économique
qui s'intéresse spécifiquement aux populations à faible revenu. Les services financiers comprennent
généralement le micro-crédit et l'épargne. Certaines Institutions de microfinance proposent également des
services d'assurance et de paiement. Elles se caractérisent par leur proximité par rapport à leur clientèle et
par la flexibilité de leurs procédures d'octroi et de recouvrement qui sont peu contraignantes pour les
populations pauvres.

Le défi actuel de la plupart des institutions de microfinance est celui de l'institutionnalisation et de

la pérennité. Cette dernière n'est réalisable que si les institutions de microfinance parviennent à offrir des
services, adaptés aux besoins de leurs membres, que sont le micro-crédit et l'épargne. Il faut noter que
même si les institutions de microfinance distribuent du crédit aux populations à faible revenu, elles sont
tenues de suivre et de recouvrer entièrement l'ensemble des crédits distribués. Ce qui contribue à
l’assainissement de la qualité du portefeuille et l'assurance de la viabilité, voire la pérennité de
l'institution. Cet objectif est assigné en général au comité de crédit qui a pour rôles et responsabilités :
 D’assurer le suivi des prêts en cours et des prêts en retard
 De participer au recouvrement des prêts en retard
 De contrôler et d'adopter des pratiques de crédit
Ces responsabilités désignent l’activité d’analyse d'un crédit dont les principaux critères sont :
Objet, durée de crédit, montant du crédit, taux d'intérêt, différé, échéancier, garanties.
2.3 Dépôts et épargnes

Les dépôts peuvent être de deux sortes :
L'épargne volontaire
L'épargne volontaire est constituée de deux types :
 Les dépôts à vue constituent la catégorie la plus utilisée des produits d'épargne. Ils sont
caractérisés par la souplesse des conditions d'accès : faible montant exigé pour l'ouverture d'un compte,
proximité et accessibilité des caisses, possibilité d'effectuer de petits versements et liberté de retraits à
tout moment, facilité d'exécution des opérations. Les dépôts à vue permettent aux populations de garder
leurs économies en lieux sûrs, à l'abri des pressions familiales. Le livret de compte remis au déposant lui
permet de vérifier les opérations effectuées et le solde disponible dans le compte.
 Les dépôts à terme sont des dépôts bloqués pendant une période minimum de trois mois et qui sont
rémunérés par un taux prédéterminé. Les dépôts à vue sont très peu développés pour au moins deux
raisons. D'abord, les populations ont des revenus très faibles. Ensuite il s'avère que la motivation
essentielle de l'épargne demeure l'accès au crédit, même si d'autres motivations comme la sécurité et la
précaution existent.
L'épargne obligatoire
L'épargne obligatoire est en relation directe avec le crédit.
On trouve deux types d'épargne obligatoire :

 L'épargne préalable suit le postulat selon lequel un demandeur de crédit doit fournir un effort
financier minimum consistant à épargner régulièrement une certaine somme pendant une période à
déterminer. Ce qui devra prouver qu'il est capable d'apporter au moment de sa demande de crédit une part
des besoins de financement (au minimum 10 %). Cette épargne est bloquée et parfois non rémunérée.
 L'épargne de garantie sert à garantir le crédit consenti généralement à un individu ou à un groupe.

L'épargne de garantie est parfois utilisée en combinaison avec d'autres formes de garanties (cautions

solidaires de groupe). La mobilisation de l'épargne de garantie (ou selon les appellations : fonds de
garantie, fonds de groupe, épargne nantie) se fait selon trois procédés différents :
o Une constitution préalable de l'épargne par les moyens propres des demandeurs ;
o Un prélèvement sur le montant du crédit au moment de la mise en place du prêt. Ce montant
prélevé est bloqué comme garantie ;
o Une constitution de l'épargne au fur et à mesure que l'on rembourse le prêt. Ceci ne constitue plus
une garantie mais suppose une incitation à l'épargne.
2.4 Le crédit
Le crédit joue un rôle fondamental dans le fonctionnement d'une institution de microfinance. Le
lexique d'économie le définit comme un acte se traduisant par un prêt consenti en contrepartie d'une
promesse de remboursement dans un délai généralement convenu à l'avance. Cette définition reflète
mieux la notion de crédit dans nos localités. Dans son sens étymologique, octroyer du crédit à quelqu'un
signifie lui faire confiance. Ceci est dû au fait que les populations bénéficiaires de ces crédits ne disposent
pas de toutes les conditions et garanties nécessaires pour accéder aux services financiers des banques
classiques. En effet, les caisses sont généralement fondées sur les principes que sont l'union, la solidarité
et l’entraide mutuelle. Elles ont pour objectif de collecter l'épargne des adhérents afin de pouvoir mettre à
leur disposition des services de crédit contribuant à l'amélioration de leurs conditions de vie économique
et sociale. L'octroi de crédits doit être accompagné d'un suivi régulier et d'un encadrement dans le but
d'engendrer un impact positif sur la situation économique de ces membres. Les investisseurs qui
considèrent la microfinance comme un placement rentable sont davantage susceptibles de s'engager
durablement dans ce secteur. (NDAO, 2007)
Les institutions de microfinance utilisent deux méthodes pour servir sa clientèle, l'une fondée sur
un individu et l'autre sur un groupe:
- Crédits individuels : c'est le fait que les prêteurs du secteur informel accordent des crédits fondés
sur la connaissance personnelle des emprunteurs plutôt que sur une analyse de faisabilité complexe. Les
crédits sont octroyés à un seul individu avec un minimum de procédures bureautiques par rapport aux
secteurs formels.
- Crédits de groupe: ils sont appelés aussi crédits solidaires. Ils font appel au regroupement de 5 à
100 personnes (cela dépend de la politique de l'institution de microfinance) partageant les mêmes
sentiments. (MATABISHI, 2009)
2.5 Système analytique

Dans le fonctionnement d’une organisation, d’une entreprise ou d’une institution, un système
analytique permet d’offrir une vue synthétique sur le domaine d’activités de cette institution. Cette vue
synthétique peut être obtenue à travers des bilans et rapports produits à fréquence journalière,
hebdomadaire, mensuelle ou trimestrielle. Elle peut aussi être obtenue à travers des graphiques ou des
diagrammes. L’objectif d’un tel système est d’être assez concis pour permettre l’interprétation et
l’exploitation en vue de réorienter la politique de fonctionnement d’une entreprise qui s’en est dotée.
Cette décision de réorientation sera prise par les compétences qualifiées notamment les directions
d’entreprises.


Conclusion
Dans cette première partie nous avons présenté la structure d’accueil, exposé quelques concepts
liés à notre domaine d’étude et analysé le sujet sous ses aspects les plus importants. La deuxième partie va
nous permettre d’opter pour une démarche d’analyse et de conception en vue de répondre aux aspects,
notamment problématiques, dégagés dans la première partie.

PARTIE 2. ANALYSE ET CONCEPTION

Introduction
Un projet logiciel, quelles que soient sa taille et la portée de ses objectifs, nécessite la mise en
place d'un planning organisationnel tout au long de son cycle de vie. Le cycle de vie d’un logiciel désigne
toutes les étapes du développement du logiciel, de sa conception à sa disparition. L’objectif d’un tel
découpage est de permettre de définir des jalons intermédiaires permettant la validation du
développement logiciel, c’est-à-dire la conformité du logiciel avec les besoins exprimés, et la vérification
du processus de développement, c’est-à-dire l’adéquation des méthodes mises en œuvre. C'est ainsi qu'est
apparue la notion de méthode. Une méthode, dans le contexte informatique, peut être définie comme une
démarche fournissant une méthodologie et des notations standards qui aident à concevoir des logiciels de
qualité. Modéliser un système avant sa réalisation permet de mieux comprendre le fonctionnement du
système. C'est également un bon moyen de maîtriser sa complexité et d'assurer sa cohérence. Un modèle
est une représentation abstraite et simplifiée, d’une entité (système, etc.) du monde réel en vue de le
décrire ou de l’expliquer. Concrètement, un modèle permet de réduire la complexité d’un phénomène en
éliminant les détails qui n’influencent pas son comportement de manière significative. Il reflète ce que le
concepteur croit important pour la compréhension du système modélisé, les limites du système modélisé
dépendant des objectifs du modèle.
Nous entamons le développement de cette partie par une étude préliminaire au cours de laquelle
nous faisons un tour d’horizons des méthodes d’analyse et de conception les plus connues ; ceci étant
nous précisons parmi elles la démarche que nous allons adopter. La première section close, nous
effectuons, à proprement parler, l’analyse statique et dynamique de notre système, que nous compléterons
par son architecture.

CHAPITRE 3 : Etude préliminaire
3.1 Généralités sur les méthodes d’analyse et de conception

Les caractéristiques d’un projet logiciel notamment sa complexité, son envergure, les objectifs à
atteindre font de la discipline de développement logiciel une tâche dont la démarche de réalisation peut
fluctuer considérablement. En effet, en fonction des caractéristiques précédemment évoquées, les
méthodes d'analyse et de conception utilisées peuvent être diverses et variées. Les méthodes d’analyse et
de conception fournissent une méthodologie et des notations standards qui aident à concevoir des
logiciels de qualité. Il existe différentes manières pour classer ces méthodes, dont :
 La distinction entre composition et décomposition : Elle met en opposition d’une part les
méthodes ascendantes qui consistent à construire un logiciel par composition à partir de modules existants
et, d’autre part, les méthodes descendantes qui décomposent récursivement le système jusqu’à arriver à
des modules programmables simplement.
 La distinction entre fonctionnel (dirigée par le traitement) et orientée objet : Dans la stratégie
fonctionnelle (également qualifiée de structurée) un système est vu comme un ensemble hiérarchique
d’unités en interaction, ayant chacune une fonction clairement définie. Les fonctions disposent d’un état
local, mais le système a un état partagé, qui est centralisé et accessible par l’ensemble des fonctions. Les
stratégies orientées objet considèrent qu’un système est un ensemble d’objets interagissant. Chaque objet
dispose d’un ensemble d’attributs décrivant son état et l’état du système est décrit (de façon décentralisée)
par l’état de l’ensemble.
Toutefois, il est possible de classer les méthodes en quatre catégories bien explicites :
 Les méthodes cartésiennes ou fonctionnelles

Avec cette méthode, le système étudié est abordé par les fonctions qu'il doit assurer plutôt que par les
données qu'il doit gérer. Le processus de conception est vu comme un développement linéaire. Il y a
décomposition systématique du domaine étudié en sous-domaines, eux-mêmes décomposés en sous-
domaines jusqu'à un niveau considéré élémentaire. SADT (Structured-Analysis-Design-Technique) en est
un exemple.
 Les méthodes systémiques

Les méthodes systémiques sont des méthodes s'appuyant sur une approche systémique. Elles
définissent différents niveaux de préoccupation ou d'abstraction et proposent de nombreux modèles
complémentaires. Les méthodes systémiques sont souvent spécialisées pour la conception d'un certain
type de systèmes. Comme exemple de méthode systémique nous pouvons citer MERISE, AXIAL ...
 Les méthodes objet

Ce sont des méthodes consistant à créer une représentation informatique des éléments du monde réel
auxquels on s'intéresse, sans se préoccuper de l'implémentation, ce qui signifie indépendamment d'un
langage de programmation. Il s'agit donc de déterminer les objets présents et d'isoler leurs données et les
fonctions qui les utilisent. Pour cela des méthodes ont été mises au point. Entre 1970 et 1990, de
nombreux analystes ont mis au point des approches orientées objets, si bien qu'en 1994 il existait plus
d’une cinquantaine de méthodes objet. Toutefois seules trois (3) méthodes ont véritablement émergé :
 La méthode OMT de Rumbaugh

 La méthode BOOCH'93 de Booch

 La méthode OOSE de Jacobson
 Les méthodes agiles

Les méthodes de développement dites « méthodes agiles » (en anglais Agile Modeling) visent à
réduire le cycle de vie du logiciel (donc accélérer son développement) en développant une version
minimale, puis en intégrant les fonctionnalités par un processus itératif basé sur une écoute client et des
tests tout au long du cycle de développement.
L'origine des méthodes agiles est liée à l'instabilité de l'environnement technologique et au fait que le
client est souvent dans l'incapacité de définir ses besoins de manière exhaustive dès le début du projet. Le
terme « agile » fait ainsi référence à la capacité d'adaptation aux changements de contexte et aux
modifications de spécifications intervenant pendant le processus de développement. En 2001, 17
personnes mirent ainsi au point le manifeste agile dont la traduction est la suivante :
 Individus et interactions plutôt que processus et outils ;
 Développement logiciel plutôt que documentation exhaustive ;
 Collaboration avec le client plutôt que négociation contractuelle ;
 Ouverture au changement plutôt que suivi d'un plan rigide.
Grâce aux méthodes agiles, le client est pilote à part entière de son projet et obtient très vite une
première mise en production de son logiciel. Ainsi, il est possible d'associer les utilisateurs dès le début
du projet. Comme méthode agile nous pouvons citer eXtreme Programming (XP).
 Méthodes formelles
Par «formel», il faut comprendre l'établissement de règles strictes afin de structurer la «forme», le tout
au sens mathématique. En effet, la rigueur de cette discipline correspond bien à cette idée de règles. Une
utilisation de ces concepts est permise grâce à un langage formel, offrant une syntaxe ou des notations
(ensemblistes, logiques, etc...) à un énoncé. Le langage d'une méthode formelle forme sa sémantique.
Chaque énoncé et/ou expression possède ainsi une signification mathématique précise, qui n'a d'autre sens
que celui décrit par la syntaxe du texte. En l'occurrence, le but d'une méthode formelle est de proposer un
processus de production, ainsi que des outils permettant d'offrir une certaine «abstraction» (fournie par la
rigueur mathématique intrinsèque à chaque méthodologie) au logiciel à développer.
3.2 Choix d'une démarche

Le choix de la démarche se fera en prenant en compte des spécifications essentielles de la plateforme
à concevoir et des caractéristiques des principales méthodes de conception. Nous synthétisons dans ce
tableau les critères retenus pour évaluer ces méthodes :
Tableau 1 : Méthodes de conception et critères d'évaluation
Critères\Méthodes Méthodes Méthodes Méthodes Méthodes Méthodes
cartésiennes systémiques agiles (XP) objet formelles
Itératif     
Prise en charge de
projets d’envergure     
Incrémental     

Axé sur la
documentation     
Gestion des risques     
Simplicité de mise en
œuvre     
Langage de
modélisation     
Dialogue
entre les différents
intervenants du     
projet
Pilotage par les cas
d’utilisation     
Axé sur le
développement     
Pour des raisons d'efficacité, de rapidité et d'analyse complète, et compte tenu des critères retenus,
nous opterons pour un processus situé à mi-chemin entre UP (Unified Process), un cadre général très
complet de processus de développement, et XP (eXtreme Programming), une approche minimaliste
centrée sur le code. Le Processus Unifié s’est imposé comme processus de développement itératif pour la
construction des systèmes orientés objet. Ce processus est très souple et très ouvert, il incite à inclure des
pratiques judicieuses issues d’autres méthodes itératives, telles qu’eXtreme Programming. Le
développement itératif et incrémental offre les avantages suivants :
1. Diminution des échecs, amélioration de la productivité et de la qualité.
2. Gestion précoce des risques élevés (risques techniques) grâce aux cas d’utilisation.
3. Feed-back, implication des utilisateurs et adaptation précoces. Ces points permettent d’obtenir un
système élaboré qui répond plus étroitement aux besoins réels des parties prenantes.
4. Complexité gérée. L’équipe n’est plus épuisée par l’analyse ou la complexité des tâches.
5. Possibilité d’exploiter méthodiquement les leçons tirées d’une itération. Cela permet d’améliorer
le processus de développement lui-même, une itération après l’autre.
3.3 Présentation du processus unifié (UP)

3.3.1 Définition et principes
Le processus unifié est un processus de développement logiciel : il regroupe les activités à mener
pour transformer les besoins d'un utilisateur en système logiciel. (Mouadh, 2010). C'est un patron de
processus pouvant être adapté à une large classe de systèmes logiciels, à différents domaines
d'application, à différents types d'entreprises, à différents niveaux de compétences et à différentes tailles
d’entreprises.
Le processus unifié s'appuie sur les principes suivants :
> Centré sur l'architecture : L'architecture logicielle représente les aspects statiques et
dynamiques du système. L'architecture émerge des besoins de l'entreprise, tels qu'ils sont exprimés par les
utilisateurs et reflétés par les cas d'utilisation. L'architecture propose une vue d'ensemble de la conception
faisant ressortir les caractéristiques essentielles en laissant de côté les détails secondaires. Il faut noter que

tout produit est à la fois forme et fonction. L'une ou l'autre isolément ne saurait suffire. Les cas
d'utilisation et l'architecture doivent s'équilibrer pour créer un produit réussi. (LAHLOU, 2010)
> Piloté par les cas d'utilisation : Un cas d'utilisation représente une fonctionnalité qui satisfait
un besoin d'un utilisateur. Le processus suit une voie spécifique, en procédant par une série
d'enchaînement d'activités, dérivées d'un cas d'utilisation. Un cas d'utilisation est analysé, conçu,
implémenté et enfin testé. (LAHLOU, 2010)
> Itératif et incrémental : Vu que les projets à réaliser sont de plus en plus complexes et grands,
l'idée est de découper le travail en mini projets. Chacun d'entre eux représente une itération qui donne lieu
à un incrément. Les itérations désignent des étapes de l'enchaînement d'activités, tandis que les
incréments correspondent à des stades de développement du produit. (Jackobson, et al., 1999)
> Orienté par la réduction des risques : L’analyse des risques doit être présente à tous les stades
de développement d’un système. Il est important de bien évaluer les risques des développements afin
d’aider à la bonne prise de décision. Du fait de l’application du processus itératif, UP contribue à la
diminution des risques au fur et à mesure du déroulement des itérations successives. (Gabay, et al., 2008)
3.3.2 Les phases du processus unifié

Le processus unifié se déroule en quatre phases, création, élaboration, construction et transition.
Chaque phase répète un nombre de fois une série d'itérations. Et chaque itération est composée de cinq
activités : capture des besoins, analyse, conception, implémentation et test. (Jackobson, et al., 1999)
Figure 2 : Phases du processus unifié
 Création
C'est la première phase du processus unifié. Il s'agit de délimiter la portée du système, c'est-à-dire
tracer ce qui doit figurer à l'intérieur du système et ce qui doit rester à l'extérieur, identifier les acteurs,
lever les ambiguïtés sur les besoins et les exigences nécessaires dans cette phase. Il s'agit aussi d'établir
une architecture candidate, c'est-à-dire que pour une première phase, on doit essayer de construire une
architecture capable de fonctionner. Dans cette phase, il faut identifier les risques critiques susceptibles de
faire obstacles au bon déroulement du projet. (Jackobson, et al., 1999)
 Elaboration
C'est la deuxième phase du processus. Après avoir compris le système, dégagé les fonctionnalités
initiales, précisé les risques critiques, le travail à accomplir maintenant consiste à stabiliser l'architecture

du système. Il s'agit alors de raffiner le modèle initial de cas d'utilisation, voire capturer de nouveaux
besoins, analyser et concevoir la majorité des cas d'utilisation formulés, et si possible implémenter et
tester les cas d'utilisation initiaux. (Jackobson, et al., 1999)
 Construction
Dans cette phase, il faut essayer de capturer tous les besoins restants car il n'est pratiquement plus
possible de le faire dans la prochaine phase. Ensuite, continuer l'analyse, la conception et surtout
l'implémentation de tous les cas d'utilisation. A la fin de cette phase, les développeurs doivent fournir une
version exécutable du système. (Jackobson, et al., 1999)
 Transition
C'est la phase qui finalise le produit. Il s'agit au cours de cette phase de vérifier si le système offre
véritablement les services exigés par les utilisateurs, détecter les défaillances, combler les manques dans
la documentation du logiciel et adapter le produit à l'environnement (mise en place et installation).
(Jackobson, et al., 1999)
3.4 Présentation de l'eXtreme Programming (XP)

L'eXtreme Programming ou XP, est une méthode de développement de projet mise au point à la
fin des années 90 par Kent Beck, Ward Cunningham et Ron Jeffries.
XP doit son nom au fait qu'elle place l'activité de programmation au centre du projet, et qu'elle obtient ses
résultats en combinant et en poussant à l'extrême certaines pratiques de développement. XP est un
ensemble de pratiques qui couvre une grande partie des activités de la réalisation d'un logiciel, de la
programmation proprement dite à la planification du projet, en passant par l'organisation de l'équipe de
développement et les échanges avec le client. Ces pratiques n'ont en soi rien de révolutionnaire : il s'agit
simplement de pratiques de bon sens, mises en œuvre par des développeurs ou des chefs de projet
expérimentés, telles que :
· Un utilisateur à plein-temps dans la salle projet. Ceci permet une communication intensive et
permanente entre les clients et les développeurs, aussi bien pour l'expression des besoins que pour la
validation des livraisons.
· Écrire le test unitaire avant le code qu'il doit tester, afin d'être certain que le test sera
systématiquement écrit et non pas négligé.
· Programmer en binôme, afin d'homogénéiser la connaissance du système au sein des
développeurs, ainsi que de permettre aux débutants d'apprendre des experts. Le code devient ainsi une
propriété collective et non individuelle que tous les développeurs ont le droit de modifier.
· Intégrer de façon continue, pour ne pas retarder à la fin du projet le risque majeur de
l'intégration des modules logiciels écrits par des équipes ou des personnes différentes.
XP s'appuie sur les valeurs suivantes :
Communication : La communication est la composante fondamentale de tout travail en équipe.
XP installe la communication dans le projet à tous les niveaux.
Simplicité : Communication et retour d'information : ces dispositions sont menacées, à mesure
que le produit évolue et s'accroît, par la lourdeur et l'inertie du processus. Pour cette raison, XP érige la
simplicité en véritable discipline, tant au niveau de la conception que du processus lui-même (scénarios
utilisateur, séances de planifications, propriété collective du code, pas de spécialisations techniques).

Feedback : Le retour d'information permet de tracer et d'ajuster le processus en vue d'améliorer la

qualité, la maintenance et la productivité. A chacune des tâches de production, XP câble un mécanisme ou
une pratique permettant de valider cette production de manière quasiment continue.
Courage : La force d'une équipe même dotée d'une approche efficace ne se mesure pas tant à ce
qu'elle fait lorsque tout va bien, qu'à la manière dont elle affronte les difficultés. Pour cette raison XP
valorise également le courage.
Elle est bien adaptée pour des projets de taille moyenne où le contexte (besoins utilisateurs,
technologies informatiques) évolue en permanence.
L'eXtreme Programming repose sur des cycles rapides de développement (des itérations de
quelques semaines) dont les étapes sont les suivantes :
 Une phase d'exploration qui détermine les scénarios clients qui seront fournis pendant cette
itération ;
 Une phase de planning où l'équipe transforme les scénarios en tâches à réaliser et en tests
fonctionnels ;
 Une phase de mise en production où chaque développeur s'attribue des tâches et les réalise avec
un binôme ;
 Une phase de maintenance lorsque tous les tests fonctionnels passent, le produit est livré.
Le cycle se répète tant que le client peut fournir des scénarios à livrer. La première livraison est
généralement plus importante et n'est réalisée qu'après quelques itérations. Après la première mise en
production, les itérations peuvent devenir plus courtes (une semaine par exemple).
3.5 Présentation du langage de modélisation UML

3.5.1 Introduction
La description de la programmation par objets a fait ressortir l’étendue du travail conceptuel
nécessaire : définition des classes, de leurs relations, des attributs et méthodes, des interfaces, etc. Pour
programmer une application, il ne convient pas de se lancer tête baissée dans l’écriture du code : il faut
d’abord organiser ses idées, les documenter, puis structurer la réalisation en définissant les modules et
étapes de la réalisation. C’est cette démarche antérieure à l’écriture que l’on appelle modélisation ; son
produit est un modèle.
Les spécifications fournies par la maîtrise d’ouvrage en programmation impérative étaient souvent
floues : les articulations conceptuelles (structures de données, algorithmes de traitement) s’exprimant
dans le vocabulaire de l’informatique, le modèle devait souvent être élaboré par celle-ci. L’approche objet
permet en principe à la maîtrise d’ouvrage de s’exprimer de façon précise selon un vocabulaire qui, tout
en transcrivant les besoins du métier, pourra être immédiatement compris par les informaticiens, en
principe seulement, car la modélisation demande aux maîtrises d’ouvrage une compétence, un
professionnalisme qui ne sont pas aujourd’hui répandus.
3.5.2 Histoire des modélisations par objets

Les méthodes utilisées dans les années 1980 pour organiser la programmation impérative (notamment
Merise) étaient fondées sur la modélisation séparée des données et des traitements. Lorsque la

programmation par objets prend de l’importance au début des années 1990, la nécessité d’une méthode
qui lui soit adaptée devient évidente. Plus de cinquante méthodes apparaissent entre 1990 et 1995 (Booch,
Classe-Relation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE, etc.) mais aucune ne parvient à
s’imposer. En 1994, le consensus se fait autour de trois méthodes :
 OMT de James Rumbaugh (General Electric) fournit une représentation graphique des aspects
statique, dynamique et fonctionnel d’un système ;
 OOD de Grady Booch, définie pour le Department of Defense, introduit le concept de paquetage
(package) ;
 OOSE d’Ivar Jacobson (Ericsson) fonde l’analyse sur la description des besoins des utilisateurs
(cas d’utilisation, ou use cases).
Chaque méthode avait ses avantages et ses partisans. Le nombre de méthodes en compétition
s’était réduit, mais le risque d’un éclatement subsistait : la profession pouvait se diviser entre ces trois
méthodes, créant autant de continents intellectuels qui auraient du mal à communiquer.
Événement considérable et presque miraculeux, les trois gourous qui régnaient chacun sur l’une
des trois méthodes se mirent d’accord pour définir une méthode commune qui fédérerait leurs apports
respectifs (on les surnomme depuis « the Amigos »). UML (Unified Modeling Language) est né de cet
effort de convergence. L’adjectif unified est là pour marquer qu’UML unifie, et donc remplace. En fait, et
comme son nom l’indique, UML n’a pas l’ambition d’être exactement une méthode : c’est un langage.
L’unification a progressé par étapes. En 1995, Booch et Rumbaugh (et quelques autres) se sont
mis d’accord pour construire une méthode unifiée, Unified Method 0.8 ; en 1996, Jacobson les a rejoints
pour produire UML 0.9 (notez le remplacement du mot méthode par le mot langage, plus modeste). Les
acteurs les plus importants dans le monde du logiciel s’associent alors à l’effort (IBM, Microsoft, Oracle,
DEC, HP, Rational, Unisys etc.) et UML 1.0 est soumis à l’OMG.
3.5.3 Concepts du langage

UML se base sur un certain nombre de concepts que sont :
 Objet
On appelle objet un élément matériel ou immatériel, dans la réalité étudiée, qui satisfait aux principes
de distinction, de permanence et d'activité. Cela implique qu'un objet possède une identité, un état et un
comportement. Un objet communique avec ses utilisateurs (ou clients) par le biais de son interface.
L'interface d'un objet est la liste des services qu'il peut rendre et des ressources qu'il souhaite mettre à la
disposition de ses clients.
 Classe
Une classe est un ensemble d'objets sur lesquels on peut reconnaître des similitudes dans le champ
d'étude. Ces similitudes portent sur la façon de les identifier, sur les types d'états qu'ils peuvent prendre et
sur le rôle qu'ils jouent.
 Entité
Lors de la modélisation d'un système d'information certains objets sont porteurs d'informations
concrètes, manipulées, transmises ou mémorisées. On les qualifie d'objets informationnels. Une entité est
donc un ensemble d'objets sur lesquels on peut reconnaître la même structure et qui sont gérés de la même
façon.

 Acteur
UML n'emploie pas le terme d'utilisateur mais d'acteur. Les acteurs d'un système sont les entités
externes à ce système qui interagissent (saisie de données, réception d'information, ...) avec lui. Les
acteurs sont donc à l'extérieur du système et dialoguent avec lui. Ces acteurs permettent de cerner
l'interface que le système va devoir offrir à son environnement. Oublier des acteurs ou en identifier de
faux conduit donc nécessairement à se tromper sur l'interface et donc la définition du système à produire.
 Processus
Le terme processus vient du latin « progrès » et signifie littéralement « aller de l'avant » ; cela évoque
l'idée d'une marche progressive ou d'un plan déterminé à l'avance. On appelle processus l'organisation
d'un ensemble finalisé d'activités effectuées par des acteurs et mettant en jeu des entités, pour répondre à
un type d'événement.
3.5.4 UML en œuvre

UML n’est pas une méthode (i.e. une description normative des étapes de la modélisation) : ses
auteurs ont en effet estimé qu’il n’était pas opportun de définir une méthode en raison de la diversité des
cas particuliers. Ils ont préféré définir un langage graphique qui permet de représenter, de communiquer
les divers aspects d’un système d’information (aux graphiques sont bien sûr associés des textes qui
expliquent leur contenu). UML est donc un métalangage car il fournit les éléments permettant de
construire le modèle qui, lui, sera le langage du projet.
Il est impossible de donner une représentation graphique complète d’un logiciel, ou de tout autre
système complexe, de même qu’il est impossible de représenter entièrement une statue (à trois
dimensions) par des photographies (à deux dimensions). Mais il est possible de donner sur un tel système
des vues partielles, analogues chacune à une photographie d’une statue, et dont la juxtaposition donnera
une idée utilisable en pratique sans risque d’erreur grave.
UML 2.0 comporte ainsi treize types de diagrammes représentant autant de vues distinctes pour
représenter des concepts particuliers du système d’information. Ils se répartissent en deux grands
groupes :
 Diagrammes structurels ou diagrammes statiques (UML Structure)
 diagramme de classes (Class diagram)
 diagramme d’objets (Object diagram)
 diagramme de composants (Component diagram)
 diagramme de déploiement (Deployment diagram)
 diagramme de paquetages (Package diagram)
 diagramme de structures composites (Composite structure diagram)
 Diagrammes comportementaux ou diagrammes dynamiques (UML Behavior)
 diagramme de cas d’utilisation (Use case diagram)
 diagramme d’activités (Activity diagram)
 diagramme d’états-transitions (State machine diagram)
 Diagrammes d’interaction (Interaction diagram)
 diagramme de séquence (Sequence diagram)
 diagramme de communication (Communication diagram)
 diagramme global d’interaction (Interaction overview diagram)
 diagramme de temps (Timing diagram)

Ces diagrammes, d’une utilité variable selon les cas, ne sont pas nécessairement tous produits à
l’occasion d’une modélisation. Les plus utiles pour la maîtrise d’ouvrage sont les diagrammes d’activités,
de cas d’utilisation, de classes, d’objets, de séquence et d’états-transitions. Les diagrammes de
composants, de déploiement et de communication sont surtout utiles pour la maîtrise d’œuvre à qui ils
permettent de formaliser les contraintes de la réalisation et la solution technique.
 Diagramme de cas d’utilisation

Le diagramme de cas d’utilisation représente la structure des grandes fonctionnalités nécessaires
aux utilisateurs du système. C’est le premier diagramme du modèle UML, celui où s’assure la relation
entre l’utilisateur et les objets que le système met en œuvre.
 Diagramme de classes
Le diagramme de classes est généralement considéré comme le plus important dans un
développement orienté objet. Il représente l’architecture conceptuelle du système : il décrit les classes que
le système utilise, ainsi que leurs liens, que ceux-ci représentent un emboîtage conceptuel (héritage) ou
une relation organique (agrégation).
 Diagramme d’objets
Le diagramme d’objets permet d’éclairer un diagramme de classes en l’illustrant par des
exemples. Il est, par exemple, utilisé pour vérifier l’adéquation d’un diagramme de classes à différents cas
possibles.
 Diagramme d’états-transitions
Le diagramme d’états-transitions représente la façon dont évoluent (i.e. cycle de vie) les objets
appartenant à une même classe. La modélisation du cycle de vie est essentielle pour représenter et mettre
en forme la dynamique du système.
 Diagramme d’activités
Le diagramme d’activités n’est autre que la transcription dans UML de la représentation du
processus telle qu’elle a été élaborée lors du travail qui a préparé la modélisation : il montre
l’enchaînement des activités qui concourent au processus.
 Diagramme de séquence et de communication

Le diagramme de séquence représente la succession chronologique des opérations réalisées par un
acteur. Il indique les objets que l’acteur va manipuler et les opérations qui font passer d’un objet à l’autre.
On peut représenter les mêmes opérations par un diagramme de communication, graphe dont les nœuds
sont des objets et les arcs (numérotés selon la chronologie) les échanges entre objets. En fait, diagramme
de séquence et diagramme de communication sont deux vues différentes mais logiquement équivalentes
(on peut construire l’une à partir de l’autre) d’une même chronologie. Ce sont des diagrammes
d’interaction.
 Diagramme de déploiement

Le diagramme de déploiement permet de représenter l’architecture physique supportant

l’exploitation du système. Cette architecture comprend des nœuds correspondant aux supports physiques
(serveurs, routeurs…) ainsi que la répartition des artefacts logiciels (bibliothèques, exécutables…) sur ces
nœuds. C’est un véritable réseau constitué de nœuds et de connexions entre ces nœuds qui modélise cette
architecture.

CHAPITRE 4 : Analyse et conception de la plateforme
4.1 Expression préliminaire des besoins fonctionnels

4.1.1 Besoins fonctionnels
Compte tenu des différentes fonctionnalités recensées, l’application à mettre en place devra
permettre à un utilisateur:
 D’enregistrer les informations sur un client ou un employé ;
 D’ouvrir un compte d’épargne, d’y effectuer des opérations de compte et d’en consulter un
relevé ;
 D’octroyer un crédit ou un prêt à un client et de le suivre jusqu’à son remboursement ;
 D’effectuer un transfert d’argent ;
 De valider les opérations de transfert, d’octroi de crédit et d’ouverture de compte ;
 De produire des états de synthèse et des bilans périodiques sur les activités menées ;
 De gérer les régions et villes d’implantation des agences ;
4.1.2 Identification des acteurs

Les acteurs d'un système sont les entités externes à ce système qui interagissent (saisie de données,
réception d'information, ...) avec lui. Les acteurs sont donc à l'extérieur du système et dialoguent avec lui.
Ceci dit, les entités revendiquant ces qualifications dans le cadre de notre système, sont les suivantes :
 Le guichetier qui est chargé de mener les activités clientèle de premier rang comme par exemple
les opérations de déboursement ou de remboursement de crédit.
 Le gestionnaire de compte qui est chargé de gérer toutes les informations relatives à un compte
épargne notamment les mouvements financiers et au titulaire du compte épargne.
 Membre du comité de crédit qui est chargé de gérer la distribution du crédit conformément aux
politiques et procédures en s’assurant au préalable de la capacité financière du client.
 Le chef d’agence qui est chargé de valider d’ouverture de compte et d’octroi de crédit
 Le super Gestionnaire qui a le niveau de privilège le plus élevé et effectue toutes les tâches
métiers possibles sur le système
 L’administrateur qui est chargé de gérer les ressources du système ainsi que les comptes
utilisateurs
4.1.3 Diagramme de contexte statique

Cet élément de modélisation proposé par le langage UML donne un aperçu graphique du système
avec les intervenants directs sur celui-ci :

Figure 3 : Diagramme de contexte statique
4.1.4 Identification des cas d’utilisation

Cette phase va nous permettre d'identifier les différents cas d'utilisation de notre application. Par le
biais des cas d'utilisation, nous serons en contact permanent avec les acteurs du système en vue de définir
les limites de celui-ci, et ainsi éviter de trop s'éloigner des besoins réels de l'utilisateur final. Un cas
d'utilisation est une unité cohérente représentant une fonctionnalité visible de l'extérieur. Il réalise un
service de bout en bout, avec un déclenchement, un déroulement et une fin, pour l'acteur qui l'initie. Un
cas d'utilisation modélise donc un service rendu par le système, sans imposer le mode de réalisation de ce
service.
Les différents cas d'utilisation retenus pour notre métier sont les suivants :
Tableau 2 : Tableau récapitulatif des cas d'utilisation

Acteur principal/
Cas d'utilisation Description
Acteurs secondaires
Consulter journal système Administrateur Voir les événements enregistrés dans le journal
système
Gérer compte utilisateur Administrateur Créer, modifier ou de supprimer un compte
utilisateur
Gérer groupe utilisateur Administrateur Supprimer les utilisateurs d’un groupe donné
Gérer localité Administrateur Créer, modifier ou supprimer une région, une

ville ou une agence
Modifier plan tarifaire Administrateur, super Modifier les montants, coût et taux s’appliquant
gestionnaire aux services offerts.
Affecter personnel Chef d'agence Permet d’affecter un employé à un guichet et/ou
de définir un chef d’agence
Gérer Guichet Chef d'agence Créer, mettre à jour ou supprimer les
informations concernant un guichet
Modifier compte crédit Gestionnaire de compte Modifier les règlements relatifs à un compte de
crédit
Modifier relevé de compte Gestionnaire de compte Modifier les opérations relatives à un compte
d’épargne
Créer compte épargne Gestionnaire de Créer un compte d’épargne
compte/Chef d'agence
Octroyer un crédit Gestionnaire de Permet d’initier un processus d’octroi de crédit à
compte/membre un client
comité de crédit, Chef
d’agence
Consulter états de synthèse Guichetier Consulter les bilans d’activité et les rapports.
Consulter opérations compte crédit
Guichetier Consulter les détails sur les mouvements d’un
compte de crédit
Consulter plan tarifaire Guichetier Consulter les montants, coût et taux s’appliquant
aux services offerts
Consulter relevé de compte Guichetier Consulter toutes les opérations (retrait, dépôt)
dont le compte a fait l’objet
Enregistrer client Gestionnaire de compte Permet d’enregistrer un client dans le système
Enregistrer opération Guichetier Permet d’effectuer une opération de retrait ou

de dépôt sur un compte d’épargne
Enregistrer un règlement Guichetier Permet d’enregistrer le règlement d’une
échéance de crédit
Effectuer un transfert d'argent Guichetier/Chef Permet d’initier un processus de transfert
d'agence d’argent
Approuver un prêt membre du comité de Donner un avis d’approbation concernant une
crédit demande d’octroi de crédit
S’authentifier Se connecter au système

4.1.5 Structuration des cas d’utilisation en package

Pour améliorer notre modèle, nous allons organiser les cas d’utilisation et les regrouper en
ensembles fonctionnels cohérents. Pour ce faire, nous utilisons le concept général d’UML : le package.
C’est un mécanisme général de regroupement d’éléments en UML, qui peut être utilisé par exemple pour
regrouper des cas d’utilisation, mais aussi des acteurs, des classes, etc.
Tableau 3 : Structuration des cas d'utilisation en package

Package Cas d'utilisation
Consulter journal système
Gérer compte utilisateur
Gérer groupe utilisateur
Administration Gérer localité
Modifier plan tarifaire
Affecter personnel
Gérer Guichet
Consulter états de synthèse
Consulter opérations compte crédit
Suivi des activités
Consulter plan tarifaire
Consulter relevé de compte
Enregistrer client
Modifier compte crédit
Modifier relevé de compte
Enregistrer opération
Services financiers Enregistrer un règlement
Créer compte épargne
Effectuer un transfert d'argent
Octroyer un crédit
Approuver un prêt
S’authentifier

4.1.5.1 Diagramme des cas d’utilisation du package «Administration »
Figure 4 : Diagramme de cas d'utilisation du package « Administration »
4.1.5.2 Diagramme des cas d’utilisation du package « Suivi des activités »
Figure 5 : Diagramme des cas d’utilisation du package « Suivi des activités »

4.1.5.3 Diagramme des cas d’utilisation du package « Services financiers »
Figure 6 : Diagramme des cas d’utilisation du package « Services financiers »

4.1.5.4 Diagramme des cas d’utilisation global
Figure 7 : Diagramme des cas d’utilisation global

4.1.6 Classification des cas d’utilisation et découpage en itérations

L’une des caractéristiques de la méthode de conception que nous avons adoptée est qu’elle est
itérative dans le sens où elle propose d’effectuer des itérations lors de l’élaboration des différents
modèles en l’occurrence celui des cas d’utilisation ; ceci garantit que le modèle soit affiné et amélioré
après une itération. Aussi, chaque itération prend en compte un certain nombre de cas d’utilisation et peut
servir à ajouter de nouveaux incréments. Le nombre d’itérations est fortement déterminé par la priorité
fonctionnelle du cas d’utilisation. Elle sera haute en fonction du fait que le service rendu soit important
pour l’exploitation de l’application ; moyenne si la fonctionnalité est secondaire et basse dans tous les
autres cas. Les cas d’utilisation sont également classés en fonction du risque qu’ils font courir à la
réalisation du projet dans son ensemble. Les risques peuvent être de diverses natures ; un cas d’utilisation
constitue un service rendu à l’utilisateur du système. D’un point de vue technique, il consiste en la
manipulation d’un certain nombre de données conceptuelles destinés à être stockées dans un système de
données. Plus le nombre de concepts du domaine manipulé est élevé plus la réalisation du cas
d’utilisation sera complexe. Le tableau ci-dessous résume cette classification :
Tableau 4 : Classification des cas d'utilisation en itérations
Cas d'utilisation Priorité fonctionnelle Risques techniques Numéro d’itération

Consulter journal système Basse Bas 4
Gérer compte utilisateur Haute Bas 2
Gérer groupe utilisateur Moyenne Bas 2
Gérer localité Moyenne Bas 2
Modifier plan tarifaire Basse Haut 4
Affecter personnel Basse Moyen 2
Gérer Guichet Moyenne Bas 4
Modifier compte crédit Haute Haut 1
Modifier relevé de compte Basse Haut 2
Créer compte épargne Haute Moyen 1
Octroyer un crédit Haute Moyen 1
Consulter états de synthèse Basse Bas 4
Consulter opérations compte Haute Bas 3

crédit

Consulter plan tarifaire Basse Bas 4
Consulter relevé de compte Basse Bas 3
Enregistrer client Haute Bas 1
Enregistrer opération Haute Bas 3
Enregistrer un règlement Haute Bas 3
Effectuer un transfert d'argent Haute Haut 1
Approuver un prêt Moyenne Moyen 1
4.1.7 Description textuelle des cas d’utilisation

4.1.7.1 Cas d’utilisation « s’authentifier »
Sommaire d’identification
Acteur(s) : guichetier, gestionnaire compte, chef d’agence, administrateur
Titre : S’authentifier
Résumé : Ce cas d’utilisation permet à un utilisateur de s’authentifier
Date : 29/09/2014
Version : 0.1
Description des enchainements
Scénario nominal
1. Le système demande à l’utilisateur de saisir son login et son mot de passe
2. L’utilisateur saisit son login et son mot de passe et valide (A1)
3. Le système enregistre les informations saisies et informe l’utilisateur
Scénario alternatif
A1.Login ou mot de passe incorrect
1. Le système affiche un message à l’utilisateur l’informant de la situation
2. Retour au point 1 du scénario nominal
Post-condition
L’utilisateur est authentifié
L’événement est enregistré dans le journal système
4.1.7.2 Cas d’utilisation « Créer un compte utilisateur »

Acteur(s) : Administrateur
Titre : Créer un compte utilisateur
Résumé : Ce cas d’utilisation permet de créer un compte d’utilisateur
Date : 22/09/2014
Version : 0.1
Précondition

Administrateur authentifié
Scénario nominal
1. L’administrateur sélectionne l’employé pour lequel il veut créer un compte utilisateur
2. Le système affiche les détails de l’employé et les groupes utilisateur
3. L’administrateur sélectionne un ou plusieurs groupes utilisateur pour le compte utilisateur et
valide
4. Le système demande à l’administrateur de saisir les informations relatives au compte utilisateur
5. L’administrateur saisit le nom d’utilisateur et le mot de passe valide (A1)
6. Le système enregistre les informations fournies et informe l’administrateur
A2.Le nom d’utilisateur existe déjà
1. Le système affiche un message à l’administrateur l’informant de la situation
Post-condition
Compte d’utilisateur créé
4.1.7.3 Cas d’utilisation « gérer un compte utilisateur »

Titre : Gérer un compte utilisateur
Résumé : Ce cas d’utilisation permet de mettre à jour ou supprimer un compte utilisateur
Date : 22/09/2014
Version : 0.1
Précondition
Scénario nominal
1. L’administrateur sélectionne le compte utilisateur à supprimer ou à mettre à jour
2. Le système affiche les informations relatives au compte
3. L’administrateur supprime le compte ou renseigne le nom d’utilisateur et le mot de passe et
valide (A1, E1)
4. Le système enregistre les modifications et informe l’administrateur
A1.Le nom d’utilisateur fournit existe déjà
Scénario d’exception
E1. Le compte utilisateur ne peut être supprimé
2. Le cas d’utilisation se termine en échec
Post-condition
Le compte d’utilisateur est mis à jour ou supprimé

4.1.7.4 Cas d’utilisation « Gérer groupe utilisateur »

Titre : Gérer groupe utilisateur
Résumé : Ce cas d’utilisation permet de supprimer les utilisateurs d’un groupe donné
Date : 22/09/2014
Version : 0.1
Précondition
Scénario nominal
1. Le système affiche les groupes utilisateur
2. L’administrateur sélectionne le groupe à gérer
3. Le système affiche la liste des comptes utilisateur appartenant au groupe
4. L’administrateur sélectionne les comptes à supprimer et valide
5. Le système enregistre l’opération et informe l’administrateur que l’opération s’est bien déroulée
Post-condition
Les comptes utilisateur sont supprimés du groupe
4.1.7.5 Cas d’utilisation « Enregistrer client »

Acteur(s) : gestionnaire compte, chef d’agence, super gestionnaire
Titre : Enregistrer client
Résumé : Ce cas d’utilisation permet d’enregistrer un client
Date : 22/09/2014
Version : 0.1
Précondition
Utilisateur authentifié
Scénario nominal
1. Le système demande à l’utilisateur de saisir les informations
2. L’utilisateur saisit les informations relatives au client et valide (A1)
3. Le système enregistre les informations et informe l’utilisateur
A1. Les informations fournies sont invalides
1. Le système informe l’utilisateur que les informations saisies sont invalides
Post-condition
Client créé
4.1.7.6 Cas d’utilisation « Enregistrer opération »

Acteur(s) : guichetier, gestionnaire compte, chef d’agence, super gestionnaire
Titre : Enregistrer opération

Résumé : Ce cas d’utilisation permet d’effectuer une opération de retrait ou de dépôt sur un compte
d’épargne
Date : 23/09/2014
Version : 0.1
Précondition
Scénario nominal
1. L’utilisateur sélectionne le compte épargne pour lequel il veut effectuer une opération
2. Le système demande à l’utilisateur de fournir les informations (montant, type, …) concernant
l’opération
3. L’utilisateur fournit les informations et valide (A1, A2)
4. Le système enregistre l’opération et informe l’utilisateur
A1.La somme saisie pour un retrait est supérieure au solde du compte ou hors de la tranche autorisée
pour un retrait
1. Le système informe l’utilisateur de la situation
A2.La somme saisie pour un dépôt est hors de la tranche autorisée pour un dépôt
Post-condition
Opération de retrait ou de dépôt enregistrée selon l’opération
Compte débité ou crédité selon l’opération
4.1.7.7 Cas d’utilisation « Octroyer un crédit »

Titre : Octroyer un crédit
Résumé : Ce cas d’utilisation permet d’initier un processus d’octroi de crédit à un client
Date : 23/09/2014
Version : 0.1
Précondition
Scénario nominal
1. L’utilisateur sélectionne le client concerné pour un octroi de crédit
2. Le système affiche les détails du client et demande à l’utilisateur d’entrer les informations
concernant la demande d’octroi de crédit
3. L’utilisateur entre les informations et valide
5. L’utilisateur soumet la demande pour approbation à un comité de crédit
6. Le système notifie la demande d’octroi de crédit aux membres du comité (voir cas d’utilisation
« Approuver un prêt »)

7. Chaque membre du comité de crédit fournit le résultat de l’approbation (E1)

8. Le système enregistre la décision du comité de crédit
9. Le système notifie la demande d’octroi de crédit au chef d’agence
10. Le chef d’agence fournit la décision de décaissement concernant la demande de prêt (E2)
11. Le système enregistre la décision du chef d’agence et informe l’utilisateur
E1. Le comité de crédit rejette la demande de prêt
1. Le système enregistre la décision du comité et informe l’utilisateur
E2. Le chef d’agence rejette la demande de prêt
1. Le système enregistre la décision du chef d’agence et informe l’utilisateur
Post-condition
Le crédit est octroyé au client
4.1.7.8 Cas d’utilisation « Consulter opérations compte crédit »

Titre : Consulter opérations compte crédit
Résumé : Ce cas d’utilisation permet de consulter les détails sur les mouvements d’un compte de crédit
Date : 23/09/2014
Version : 0.1
Précondition
Scénario nominal
1. L’utilisateur sélectionne le compte de crédit concerné
2. Le système affiche les détails sur les mouvements
3. L’utilisateur consulte l’échéancier des remboursements et le calendrier des règlements
4.1.7.9 Cas d’utilisation « Modifier compte crédit »

Acteur(s) : chef d’agence, super gestionnaire
Titre : Modifier compte crédit
Résumé : Ce cas d’utilisation permet de modifier les règlements relatifs à un compte de crédit
Date : 22/09/2014
Version : 0.1
Précondition(s)
Scénario nominal
1. L’utilisateur sélectionne le compte de crédit concerné
2. Le système affiche le calendrier des règlements

3. L’utilisateur sélectionne le règlement à modifier

4. Le système demande à l’utilisateur de mettre à jour les informations à modifier
5. L’utilisateur met à jour les informations et valide
6. Le système enregistre les mises à jour et informe l’utilisateur
Post-condition
Le compte de crédit est modifié
4.1.7.10 Cas d’utilisation « Créer compte épargne »

Titre : Créer compte épargne
Résumé : Ce cas d’utilisation permet de créer un compte d’épargne
Date : 23/09/2014
Version : 0.1
Précondition
Scénario nominal
1. (Point d’extension : cas d’utilisation enregistrer un client)
2. Le système demande à l’utilisateur d’entrer les informations relatives à la création du compte
d’épargne
3. L’utilisateur entre les informations (n° client, date de création, …) et valide
5. L’utilisateur soumet la demande de création pour évaluation au chef d’agence
6. Le système notifie la demande au chef d’agence
7. Le chef d’agence fournit le résultat de l’évaluation et valide (E1)
8. Le système sauvegarde le résultat de l’évaluation et informe l’utilisateur
E1. Le chef d’agence rejette la demande de création de compte d’épargne
1. Le système sauvegarde le résultat de l’évaluation et informe l’utilisateur
Post-condition
Le compte d’épargne est créé
4.1.7.11 Cas d’utilisation « Consulter relevé de compte »

Titre : Consulter relevé de compte
Résumé : Ce cas d’utilisation permet de consulter toutes les opérations (retrait, dépôt) dont le compte a
fait l’objet
Date : 25/09/2014
Version : 0.1

Précondition
Scénario nominal
1. L’utilisateur sélectionne le compte d’épargne concerné
2. Le système affiche les détails du compte et la liste des opérations effectuées sur le compte
3. L’utilisateur consulte les détails
4.1.7.12 Cas d’utilisation « Modifier relevé de compte »

Titre : Modifier relevé de compte
Résumé : Ce cas d’utilisation permet de modifier les opérations relatives à un compte d’épargne
Date : 25/09/2014
Version : 0.1
Précondition
Scénario nominal
1. L’utilisateur sélectionne le compte d’épargne concerné
2. Le système affiche les détails du compte et la liste des opérations effectuées sur le compte (E1)
3. L’utilisateur sélectionne une opération et valide
4. Le système affiche les détails et demande à l’utilisateur de fournir les nouvelles données
5. L’utilisateur fournit les données et valide
E1. Le compte d’épargne n’a fait l’objet d’aucune opération
Post-condition
Le relevé de compte est modifié
4.1.7.13 Cas d’utilisation « Consulter états de synthèse »

Acteur(s) : guichetier, gestionnaire compte, chef d’agence, super gestionnaire, membre comité de crédit
Titre : consulter états de synthèse
Résumé : Ce cas d’utilisation permet de consulter les bilans d’activité et les rapports.
Date : 25/09/2014
Version : 0.1
Précondition


Scénario nominal
1. L’utilisateur sélectionne le bilan ou le rapport d’activités concerné
2. Le système affiche les informations présentes sur le bilan ou le rapport d’activités
3. L’utilisateur consulte les informations
4.1.7.14 Cas d’utilisation « Effectuer un transfert d’argent »

Titre : Effectuer un transfert d'argent
Résumé : Ce cas d’utilisation permet d’initier un processus de transfert d’argent
Date : 25/09/2014
Version : 0.1
Précondition
Scénario nominal
1. Le système demande à l’utilisateur de saisir les informations concernant le transfert d’argent
2. L’utilisateur saisit les informations sur le transfert (nom de l’expéditeur, ville de destination,
montant, …) et valide
4. L’utilisateur soumet la demande de transfert au chef d’agence pour validation
5. Le système notifie la demande au chef d’agence
6. Le chef d’agence fournit le résultat de la validation et confirme
7. Le système sauvegarde le résultat et informe l’utilisateur
E1. Le chef d’agence rejette la demande de transfert
1. Le système sauvegarde le résultat et informe l’utilisateur
Post-condition
Transfert effectué
4.1.7.15 Cas d’utilisation « Consulter plan tarifaire »

Titre : Consulter plan tarifaire
Résumé : Ce cas d’utilisation permet de consulter les montants, coût et taux s’appliquant aux services
offerts
Date : 25/09/2014
Version : 0.1

Précondition
Scénario nominal
1. L’utilisateur sélectionne le plan tarifaire
2. Le système affiche les détails sur les montants et les taux s’appliquant aux services
3. L’utilisateur consulte les montants
4.1.7.16 Cas d’utilisation « Gérer localité »

Titre : Gérer localité
Résumé : Ce cas d’utilisation permet de créer/modifier/supprimer une région ou une ville ou une agence
Date : 26/09/2014
Version : 0.1
Précondition
Scénario nominal
1. L’administrateur sélectionne la localité à gérer
2. Le système affiche les détails concernant la localité
3. L’administrateur effectue l’opération de création/modification ou de suppression la localité et
valide (A1, E1)
4. Le système enregistre l’opération et informe l’administrateur
A1.Modification/création : les informations fournies sont invalides
E2. La localité ne peut être supprimée
Post-condition
La localité est créée, modifiée ou supprimée
4.1.7.17 Cas d’utilisation « Gérer guichet »

Titre : Gérer guichet
Résumé : Ce cas d’utilisation permet de créer/mettre à jour/supprimer les informations concernant un
guichet

Date : 29/09/2014
Version : 0.1
Précondition
Scénario nominal
1. L’administrateur sélectionne le guichet à gérer
2. Le système affiche les détails concernant le guichet
3. L’administrateur effectue l’opération de mise à jour ou de suppression valide (A1, E1)
4. Le système enregistre l’opération et informe l’administrateur
A2.Mise à jour/création : les informations fournies sont invalides
E1. Suppression : Le guichet ne peut être supprimé
Post-condition
Le guichet est créé, mis à jour ou supprimé
4.1.7.18 Cas d’utilisation « Affecter personnel »

Acteur(s) : Administrateur, Chef d’agence, super gestionnaire
Titre : Affecter personnel
Résumé : Ce cas d’utilisation permet d’affecter un employé à un guichet et/ou de définir un chef d’agence
Date : 26/09/2014
Version : 0.1
Précondition
Scénario nominal
1. Le système affiche les employés de l’agence et les guichets de l’agence
2. L’utilisateur sélectionne un employé comme chef d’agence et valide
3. Le système enregistre la sélection et informe l’utilisateur
4. L’utilisateur sélectionne un guichet et valide
5. Le système demande à l’utilisateur d’affecter un employé au guichet
6. L’utilisateur sélectionne un employé comme guichetier et valide
7. Le système enregistre la sélection et informe l’utilisateur
Post-condition
Les employés sont affectés à leur domaine fonctionnel
Les événements sont enregistrés dans le journal système

4.1.7.19 Cas d’utilisation « Approuver un prêt »

Acteur(s) : membre comité de crédit
Titre : Approuver un prêt
Résumé : Ce cas d’utilisation permet de donner un avis d’approbation concernant une demande d’octroi
de crédit
Date : 29/09/2014
Version : 0.1
Scénario nominal
1. Le système affiche la liste des demandes en cours d’octroi de crédit
2. L’utilisateur sélectionne une demande devant faire l’objet d’une approbation
3. Le système affiche les détails concernant la demande d’octroi de crédit
4. (Point d’extension : Cas d’utilisation "consulter états de synthèse»)
5. L’utilisateur fournit son avis d’approbation et valide
6. Le système enregistre l’information et informe l’utilisateur
Post-condition
Avis d’approbation enregistré
4.2 Expression des besoins non fonctionnels

Cette étape a pour objet de formaliser et de détailler la partie « non fonctionnelle » de ce qui a été
produit au cours de l’étude préliminaire. Il s'agit des besoins qui caractérisent le système. Ce sont des
besoins en matière de performance, de type de matériel ou le type de conception. Ces besoins peuvent
concerner les contraintes liées à l'implémentation (langage de programmation, de système
d'Exploitation...) ou à l'interopérabilité générale. En effet, ces besoins peuvent être fixés par le client
(fonctions optionnelles), ou par le développeur (contraintes d'implémentation). Dans cette optique, notre
application devra satisfaire les spécifications suivantes :
 Etre une application Web ;

 Permettre une réplication des données pour assurer une haute disponibilité;
 Pouvoir supporter un nombre élevé de requêtes client simultanées;
 Utiliser une base de données relationnelle ;
 Les informations sensibles comme les mots de passe seront chiffrés ;
 Offrir des services de sécurité ;
 Offrir une interface conviviale et optimisée ;
 Fonctionner sur une plateforme applicative robuste ;
 Fonctionner en architecture applicative client/serveur ;
 Fonctionner en architecture logicielle en couches.

4.3 Expression détaillée des exigences fonctionnelles

Les cas d’utilisation décrivent les interactions des acteurs avec l’application que nous voulons
spécifier et concevoir. Lors de ces interactions, les acteurs produisent des messages qui affectent le
système informatique et appellent généralement une réponse de celui-ci. Nous allons isoler ces messages
et les représenter graphiquement sur des diagrammes de séquence système. Nous utilisons le terme de
diagramme de séquence « système » pour souligner le fait que nous considérons le système informatique
comme une boîte noire. Le comportement du système est décrit vu de l’extérieur.
4.3.1 DSS cas d’utilisation « Octroyer un crédit »
Figure 8 : DSS cas d’utilisation « Octroyer un crédit »

4.3.2 DSS cas d’utilisation « Créer compte épargne »
Figure 9 : DSS cas d’utilisation « Créer compte épargne »
4.3.3 DSS cas d’utilisation « Effectuer un transfert d’argent »
Figure 10 : DSS cas d’utilisation « Effectuer un transfert d’argent »

4.3.4 DSS cas d’utilisation « Affecter personnel »
Figure 11 : DSS cas d’utilisation
4.4 Identification des classes conceptuelles

La conception objet demande principalement une description structurelle et statique du système à
réaliser sous forme d’un ensemble de classes logicielles, éventuellement regroupées en packages.
Les meilleures classes candidates sont celles issues d’une analyse du domaine. L’étape
typiquement orientée objet de l’analyse est la décomposition d’un domaine d’intérêt en classes
conceptuelles représentant les entités importantes. Après analyse des cas d’utilisation nous avons pu
déceler les classes principales pouvant se définir ainsi. Nous allons passer en revue quelques
fonctionnalités offertes par notre système et en énumérer les plus importantes avant de passer à une
présentation sous forme de diagramme UML :
 L’authentification
Toute personne voulant accéder aux fonctionnalités de l’application devra disposer d’un compte
utilisateur. Grâce à ce compte utilisateur, il pourra exploiter différents niveaux de fonctionnalités selon

qu’il soit administrateur, chef d’agence ou membre du comité de crédit. Ces niveaux de fonctionnalités
représentent des rôles que peuvent partager plusieurs comptes utilisateurs.
 Ouvrir un compte épargne
Le compte épargne : c’est l’entité qui sera créée et qui regroupera toute les informations relative à
une épargne volontaire
Le client : il représente le titulaire du compte d’épargne
L’employé : il reçoit le client à un guichet peut enregistrer pour ce client un dépôt ou un retrait.
 Le transfert d’argent
Grace à cette fonctionnalité, un expéditeur se présentant dans une agence et fournissant les
informations requises notamment son nom et le montant à transférer, peut envoyer de l’argent vers une
autre agence. Les informations concernant le destinataire devront être aussi enregistrées.
 Octroi de crédit et encaissement des remboursements
L’application devra permettre de stocker les informations relatives à un crédit accordé à un
emprunteur. Aussi il devra permettre de suivre les remboursements grâce à un échéancier et de percevoir
les règlements grâce à un calendrier de remboursement.
Cette succincte analyse ne nous donne qu’un bref aperçu des entités conceptuelles. Nous
les représentons ci-dessous sous une forme plus exhaustive.

Figure 12 : Diagramme des classes conceptuelles

Ce modèle de données résulte des règles de gestion élaborées suite à une étude approfondie des
relations entre les différents concepts utilisés. Nous énumérons les plus importantes :
 Un employé est affecté ou non à un guichet.

 Un seul employé est désigné chef d’une agence.
 Un employé peut être gestionnaire de plusieurs comptes d’épargne.
 Un compte d’épargne n’a qu’un seul gestionnaire.
 Une opération s’enregistre et un règlement s’effectue à un guichet.
 Un guichet reçoit plusieurs règlements et opérations.
 Un client (particulier)/groupe est titulaire de plusieurs comptes.
 Un compte est détenu par un seul client (particulier)/groupe.
 Un client peut appartenir ou non à plusieurs groupes.
 Un groupe de clients a au moins un membre.
 Un client (particulier)/groupe peut souscrire ou non à plusieurs prêts.
 Un prêt a un ou plusieurs échéanciers selon qu'il soit rééchelonné ou pas.
 Un prêt est soldé suivant un calendrier de règlements.
 Un calendrier de règlements dépend d'un seul échéancier.
 Un employé possède un compte utilisateur.
 Un compte utilisateur déclenche ou non plusieurs événements.
 Un groupe utilisateur donné possède un et un seul rôle.
 Un groupe utilisateur peut contenir plusieurs comptes utilisateurs
 Un utilisateur peut appartenir à plusieurs groupes
 Lors d’un service de transfert d’argent on enregistre les informations d’envoi et de retrait
 Un transfert est validé, non validé ou mis en attente par le chef d’agence
 Le retrait (l’envoi) d’une somme lors d’un transfert d’argent s’effectue au niveau d’un guichet
4.5 Architecture logique de l’application

4.5.1 Généralités sur les architectures logicielles en couche
Dans le milieu professionnel, les applications doivent être robustes et travaillent généralement sur
des gros volumes de données. Pour cela, différents modèles existent pour organiser de façon logique ces
applications.
L'architecture en couches consiste à diviser une application en différents modules, qui constituent
autant de couches. L'objectif est de proposer une meilleure répartition des rôles (chaque module a un rôle
clairement défini), la séparation des traitements, ainsi qu'une réduction des dépendances entre les
services. Chaque module se doit d'être indépendant des autres pour permettre une meilleure
maintenabilité.
Une application peut aisément se diviser en trois couches distinctes : les données, le traitement de ces
données, et leur affichage.
 La couche de données
Elle regroupe le stockage et les mécanismes d'accès des données de façon à ce qu'elles soient
utilisables par l'application au niveau traitement.
 La couche de traitement

Elle concerne à la fois les tâches à réaliser par l'application sur les données et les traitements
nécessaires suite à une action venant de l'utilisateur : vérification d'authentification, calculs divers, etc.
 La couche présentation
Elle gère l'affichage des données et les interactions de l'application avec l'utilisateur. La séparation de
cette couche permet notamment de proposer plusieurs présentations pour une même application.
Cette architecture en 3 couches est communément désignée sous le paradigme MVC : modèle vue-
contrôleur.
En général il peut y avoir plus que trois couches entre l’application et la base de données. Cela
permet d’avoir une mineure dépendance entre les composants et, par exemple, on pourra changer de base
de données sans trop de problèmes. Une application multi-tiers permet de distribuer la charge de travail.
Cela permet d’améliorer l’utilisation du réseau et éviter sa saturation et de ses composants. Cela étant, ces
couches peuvent être subdivisées et d’autres s’y ajouter. On distingue :
 Le système de gestion de base de données (SGBD), qui stocke les données utilisées par
l'application ;
 La couche de persistance, qui gère le mécanisme de sauvegarde et de restauration des données ;
 La couche d'accès aux données, en charge de l'accès aux données et de leur manipulation,
indépendamment du SGBD choisi ;
 La couche d'objets métier est représentée par les objets du domaine, c'est à dire l'ensemble des
entités persistantes de l'application (Facture, Bon de Commande, Client, ...)
 La couche métier ou couche de services, gère la logique de l'application et les traitements à
effectuer sur les données, indépendamment de la provenance des données et de la façon dont elles
seront affichées une fois les traitements effectués ;
 La couche interface utilisateur, qui s'occupe à la fois d'afficher les données reçues par la couche
de services et d'envoyer à la couche de services les informations relatives aux actions de
l'utilisateur.
4.5.2 Choix de l’architecture logique

Nous adopterons pour notre application une architecture présentée sur la figure ci-après. Ce
découpage est parfaitement conforme aux spécifications préliminaires des besoins non fonctionnels que
nous souhaitons respecter pour notre application.
Figure 13 : Découpage de notre application en couches

4.6 Architecture technique de la solution

4.6.1 Généralités sur les architectures techniques
L'objectif premier d'un système d'information quel qu'il soit est de permettre à plusieurs
utilisateurs d'accéder aux mêmes informations. Pour cela il faut donc regrouper les informations utilisées
par l'entreprise. En terme technique, cela se traduit par la centralisation des données au sein d'une base de
données. L'évolution des systèmes d'information s'est donc basée sur une meilleure subdivision entre les
tâches à réaliser pour permettre l'exploitation de ces données par les utilisateurs finaux. Ceci permet de
structurer plus efficacement les informations ce qui entraîne à la fois une meilleure organisation de
l'entreprise et une meilleure efficacité technique. Cette subdivision a été facilitée par l'avènement des
technologies orientées objets qui s'appliquent aussi bien au modèle client-serveur qu'au modèle Internet.
Ces technologies permettent une séparation entre les différents composants du système. Il devient alors
possible de réaliser de nouvelles architectures permettant la mise à disposition des informations sous
différentes formes tout en diminuant les temps de développement. Ces technologies permettent également
de faire collaborer une grande diversité de systèmes. On parle alors d'architecture distribuée.
4.6.1.1 Présentation de l'architecture client/serveur

De nombreuses applications fonctionnent selon un environnement client/serveur, cela signifie que
des machines clientes (des machines faisant partie du réseau) contactent un serveur, une machine
généralement très puissante en termes de capacités d'entrée-sortie, qui leur fournit des services. Ces
services sont des programmes fournissant des données telles que l'heure, des fichiers, une connexion, etc.
Les services sont exploités par des programmes, appelés programmes clients, s'exécutant sur les machines
clientes. On parle ainsi de client FTP, client de messagerie etc. Lorsque l'on désigne un programme,
tournant sur une machine cliente, capable de traiter des informations qu'il récupère auprès du serveur
(dans le cas du client FTP il s'agit de fichiers, tandis que pour le client messagerie il s'agit de courrier
électronique).
4.6.1.1.1 Fonctionnement d'un système client/serveur
Un système client/serveur fonctionne selon la configuration suivante :
- Le client émet une requête vers le serveur grâce à son adresse et le port, qui désigne un service
particulier du serveur ;
- Le serveur reçoit la demande et répond à l'aide de l'adresse de la machine client et son port.
4.6.1.1.2 Types d'architectures réseaux

Il existe trois types d'architectures des réseaux qui sont :
4.6.1.1.2.1 Architecture à 1-tiers
Dans une approche d'application de type 1-tiers, les trois couches sont fortement et intimement liées,
et s'exécutent sur la même machine. Dans ce cas, on ne peut pas parler d'architecture client-serveur mais
d'informatique centralisée. Dans un contexte mono utilisateur, la question ne se pose pas, mais dans un
contexte multi utilisateurs, on peut voir apparaître deux types d'architectures mettant en œuvre des
applications 1-tiers :
Les applications sur site central ;
Les applications réparties sur des machines indépendantes communiquant par partage de fichiers.

4.6.1.1.2.2 Architecture à 2-tiers

L'architecture à deux niveaux (aussi appelée architecture 2-tiers, tiers signifiant tierce partie)
caractérise les systèmes clients/serveurs dans lesquels le client demande une ressource et le serveur la lui
fournit directement. Cela signifie que le serveur ne fait pas appel à une autre application afin de fournir le
service.
Figure 14: Architecture client/serveur 2-tiers
4.6.1.1.2.3 Architecture à 3-Tiers

Dans l'architecture à trois niveaux (appelée architecture 3-tiers), il existe un niveau intermédiaire,
c'est-à-dire que l'on a généralement une architecture partagée entre :
 Client
Dans un réseau informatique un client est l'ordinateur et le logiciel qui envoient des demandes à
un serveur. L'ordinateur client est généralement un ordinateur personnel ordinaire, équipés de logiciels
relatifs aux différents types de demandes qui vont être envoyées, comme par exemple un navigateur web,
un logiciel client pour le World Wide Web.
 Serveur d’applications
Dans un réseau informatique, un serveur est à la fois un ensemble de logiciels et l'ordinateur les
hébergeant dont le rôle est de répondre de manière automatique à des demandes envoyées par des clients
ordinateur et logiciel via le réseau. Les serveurs sont d'usage courant dans les centres de traitement de
données, les entreprises, les institutions, et le réseau Internet, où ils sont souvent un point central et sont
utilisés simultanément par de nombreux utilisateurs pour stocker, partager et échanger des informations.
Les différents usagers opèrent à partir d'un client: ordinateur personnel, poste de travail, ou terminal. Le
World Wide Web, la messagerie électronique et le partage de fichiers sont quelques applications
informatiques qui font usage de serveurs.
 Serveur de base de données

Dans l'architecture à trois tiers, les applications au niveau serveur sont délocalisées, c'est-à-dire
que chaque serveur est spécialisé dans une tâche (serveur web/serveur de base de données par exemple).
L'architecture à trois niveaux permet :
 Une plus grande flexibilité/souplesse ;
 Une sécurité accrue car la sécurité peut être définie indépendamment pour chaque service, et à
chaque niveau ;
 De meilleures performances, étant donné le partage des tâches entre les différents serveurs.

Figure 15 : Architecture Client/serveur 3-tiers
4.6.1.1.3 Architecture technique choisie

Le système que nous développons devra interconnecter plusieurs agences au siège d’une
institution de microfinance. Il sera déployé sur un serveur d’applications et accessible au travers de
navigateur Web installé sur les machines clientes de chaque agence. Les informations échangées sont
centralisées sur un serveur de bases de données situé au siège de la microfinance et transportées sur un
réseau local au sein du siège et via internet entre une agence et le siège. La figure qui suit présente
l’architecture technique de l’application.
Figure 16 : Architecture technique de l'application

Conclusion
Dans le premier chapitre de cette partie nous avons passé en revue les principales méthodes
d’analyse et de conception. Notre choix a consisté à jumeler deux des plus courantes ; la rigueur d’une
méthode basée sur le processus unifié et la rapidité offerte par l’eXtreme Programming nous a permis
d’identifier de façon transparente les fonctionnalités du système, de les représenter sous forme de modèles
explicatifs et de produire l’architecture technique de notre système.

PARTIE 3. MISE EN ŒUVRE ET CONDUITE DE PROJET

Introduction
Dans cette partie, nous parlerons dans un premier chapitre des technologies d’entreprise les plus
courantes, les services qu’elles offrent et des outils d’implémentation qui nous ont permis de concevoir et
de déployer notre application. Dans le second chapitre nous présenterons la planification et le suivi de
notre projet, notamment les personnes qui ont contribué à sa réalisation, son découpage en phases et en
tâches avec une présentation de l’estimation des charges globales du projet et un bilan sur le travail
effectué.

CHAPITRE 5 : Mise en œuvre
5.1 La sécurité des applications web

Les principales techniques relatives à la sécurité sont :
 L’authentification des utilisateurs : Authentification simple, Authentification forte ;
 L’authentification du serveur (certificat signé par une autorité supérieure) ;
 La confidentialité des communications : Services chiffrés par SSL/TLS (HTTPS, FTPS…) et la
technologie VPN ;
 Empêcher les intrusions (Firewall-IPS) ;
 Assurer l’intégrité et la confidentialité de nos documents (fichiers chiffrés).
Il existe plusieurs méthodes de sécurité. Nous présentons ici quelques-unes.
5.1.1 Contrôle d’accès

De nombreuses mesures sont aujourd’hui disponibles pour contrôler les accès; elles vont de la
mise en place d’identification et de mot de passe lors de l’accès, à la constitution d’un fichier historique
mémorisant toutes les transactions.
MOOV ET SES CLIENTS
5.1.2 Le cryptage
Le cryptage ou chiffrement consiste à transformer un texte en une chaîne de caractères en utilisant
une « clé de cryptage » ; le lecteur doit disposer de la clé de cryptage pour décrypter le texte. On distingue
deux familles d’algorithmes de chiffrement, correspondant à des emplois de nature différente :
 Les algorithmes à clé secrète, symétriques où émetteur et récepteur doivent posséder la même clé ;
 Les algorithmes à clé publique ou asymétriques : la clé de cryptage est diffusée librement et
l’information n’est lisible que par ceux qui possèdent la clé de décryptage qui est différente.
5.1.3 La signature
La signature digitale peut potentiellement remplir deux fonctions importantes dans les échanges de
documents électroniques : l’authentification et l’intégrité.
L’authentification apporte la preuve du signataire d’un message ou d’un document ;
L’intégrité permet de vérifier qu’aucune partie du document n’a été altérée après signature.
La signature électronique s’appuie sur un algorithme de cryptage à clé publique qui rend solidaire
le contenu du document et le mot de passe secret du signataire. Il s’agit d’une méthode connue sous le
nom de « hashage » implémentée par le SHA (Secure Hash Algorithm) et SHA-1, MD2, 4 et 5 (Message
Digest).
5.1.4 Les firewalls ou Pare-feux

Toute entreprise ouvrant son réseau sur l’internet encourt de nombreux risques, parmi lesquels :
 L’accès de personnes non autorisées aux données ou au système ;
 Des dommages causés, volontairement ou non, par un utilisateur ;
 Une attaque de virus ; l’interception des transmissions ;
 L’insécurité des échanges de données, etc.
Plutôt que d’avoir à sécuriser chaque ordinateur connecté au réseau, la solution consiste à installer
une passerelle, appelée firewall (pare-feu) qui filtre tout trafic indésirable.

5.2 Choix des outils et des technologies d'implémentation

5.2.1 Choix de la plateforme de développement
De plus en plus d’experts dans le monde du développement reconnaissent aujourd’hui la nécessité
d’applications distribuées, se démarquant par leur envergure en offrant des capacités transactionnelles et
de portabilité, et permettant l’optimisation, la sécurité et la disponibilité des technologies de
développement côté serveur. Les applications d’entreprise offrent les outils nécessaires pour implémenter
le fonctionnement métier d’une entreprise. Elles sont gérées de façon centralisée et interagissent souvent
avec d’autres applications d’entreprises. Les tendances actuelles des technologies de l’information
veulent que les applications d’entreprise soient conçues, développées et mises en production à un moindre
coût, dans des délais rapides et ce avec le minimum de ressources.
Les géants Oracle et Microsoft sont les deux principales entreprises offrant des spécifications pour
les applications d’entreprise. Oracle propose la plateforme Java EE. La première version des librairies
Java EE a été mise à disposition des développeurs en 1999. Aujourd’hui à sa version 7, Java EE offre une
plate-forme de développement et de déploiement en langage Java pour les applications distribuées à
plusieurs niveaux.
5.2.1.1 La plateforme Java EE

Java Enterprise Edition, ou Java EE (anciennement J2EE), est une spécification pour la technique
Java d'Oracle plus particulièrement destinée aux applications d’entreprise. Ces applications sont
considérées dans une approche multi-niveaux. Dans ce but, toute implémentation de cette spécification
contient un ensemble d’extensions au framework Java standard (JSE, Java Standard Edition) afin de
faciliter notamment la création d’applications réparties.
Pour ce faire, Java EE définit les éléments suivants :
 Une plate-forme (Java EE Platform), pour héberger et exécuter les applications, incluant outre
Java SE des bibliothèques logicielles additionnelles du Java Development Kit (JDK) ;
 Une suite de tests (Java EE Compatibility Test Suite) pour vérifier la compatibilité ;
 Une réalisation de référence (Java EE Reference Implementation), dénommée GlassFish ;
 Un catalogue de bonnes pratiques (Java EE BluePrints).
5.2.1.2 Pourquoi choisir Java EE ?

Il existe actuellement beaucoup d’autres plateformes de développement qui sont basées sur
d’autres langages. Les principaux avantages d’utiliser Java EE (et donc Java) sont la portabilité,
l’indépendance, la sécurité et la multitude de librairies proposées. Le développement d’applications
d’entreprise nécessite la mise en œuvre d’une infrastructure importante. Beaucoup de fonctionnalités sont
utilisées et développées, le but étant de produire des applications sûres, robustes et faciles à maintenir.
Certains services sont d’ailleurs récurrents comme : l’accès aux bases de données, l’envoi de mails,
les transactions, la sécurité, la gestion des fichiers, la gestion d’images, le téléchargement, le chargement
ou upload, la supervision du système...
C’est pour cela que l’architecture Java EE est intéressante car tous les éléments fondamentaux
sont déjà en place. Pas besoin de concevoir une architecture, des librairies et des outils spécialement
adaptés. Cela nécessiterait un temps et un investissement considérables.

Enfin, la plateforme Java EE est basée sur des spécifications, ce qui signifie que les
projets sont portables sur n’importe quel serveur d’applications conforme (Tomcat, JBoss,
WebSphere, GlassFish, ...) à ces spécifications. Cette implémentation est gratuite et permet de
bénéficier de la totalité de l’API sans investissement. La plateforme Java EE est la plus riche des
platesformes Java et offre un environnement standard de développement et d’exécution
d’applications d’entreprise multitiers.
5.2.1.3 Java EE : Spécifications & API

5.2.1.3.1 JDBC (Java DataBase Connectivity)
La technologie Java DataBase Connectivity (JDBC) permet de gérer les commandes SQL et les
dialogues avec les différents SGBD relationnels. Aussi considérée comme une API, JDBC permet de
faciliter l’obtention de connexions JDBC vers des sources de données (essentiellement des bases de
données, mais également annuaire...). L'API JDBC propose un ensemble de classes et d’interfaces pour se
connecter aux différents SGBD du marché mais également les paquetages de manipulation des données.
JDBC est une technologie sous-jacente à JPA.
5.2.1.3.2 JPA (Java Persistance API)
Java Persistence API (JPA) est un standard Java utilisé pour la persistance des données. Ce
mécanisme de persistance utilise le principe de mapping objet/relationnel et relationnel/objet afin de
permettre de stocker les objets dans la base de données et inversement de pouvoir lire les données
relationnelles et les transformer en objets. JPA s’appuie sur JDBC pour communiquer avec la base de
données mais permet d’éviter de manipuler directement les fonctionnalités de JDBC et le langage SQL.
L'API Java Persistence 2.0 propose les services suivants :
 La gestion de la persistance.
 Un langage de requête évolué : Java Persistence Query Language (JPQL).
 Un mécanisme de mapping objet/relationnel ORM à partir de métadonnées (fichiers XML ou
annotations).
5.2.1.3.3 JTA (Java Transaction API)
Cette API permet de mettre en place une gestion optimisée des transactions dans des applications
distribuées et offre également les mécanismes de commit et rollback. Le principe des transactions est de
considérer un ensemble d’opérations comme une seule. Ce type de service est obligatoire pour des
traitements bancaires. Par exemple, une application bancaire qui permet de réaliser des virements entre
deux comptes va d’abord débiter le premier compte et ensuite créditer le second compte. Si le débit puis
le crédit aboutissent sans problème, alors la transaction est validée. JDBC permet de gérer les
transactions sur une base de données locale mais si les données sont réparties, il faudra alors utiliser les
transactions JTA. JTA permet en effet de gérer les transactions distribuées qui font intervenir différentes
bases de données. Cette API est rarement utilisée directement par le développeur, mais plutôt en
association avec d'autres API.
5.2.1.3.4 Les EJB (Entreprise Java Bean)
Les EJB sont des composants métier distribués, c’est-à-dire qu’ils sont invocables par le réseau.
Un composant EJB est une classe qui possède des attributs et méthodes pour mettre en application la

logique métier. L’API EJB fournit un ensemble de services (persistance, transaction...) de gestion de
composants. Il existe plusieurs (trois) types d’EJB : les beans sessions, les beans entités et les beans
contrôlés par message.
 EJB session : il permet de maintenir des informations sur les clients et les traitements qu’ils
réalisent.
 EJB entité : c’est un composant persistant, son état est sauvegardé dans une base de données.
La mise en place d’EJB nécessite l’utilisation d’un serveur d’applications capable de gérer ces
EJB. Actuellement, les serveurs GlassFish, JBoss et Jonas existent dans le domaine du libre. Le serveur
Tomcat ne permet pas d’utiliser les EJB.
5.2.1.3.5 JNDI (Java Naming and Directory Interface)

L’API JNDI permet d’accéder à des services de nommage. Cette API est par exemple
utilisée pour se connecter à une source de données pour des accès à la base de données ou la gestion des
accès (associée aux Realms) à une application Java EE. JNDI permet d’implémenter un service de
nommage. L’ensemble des ressources que le serveur d’applications met à disposition via ces API de
services, doit être enregistré avec un nom logique unique, permettant aux applications de rechercher cette
ressource dans le serveur.
Client
Servlet API 3.0

Présentation
CDI
Injection de Logique Métier
Enterpri
dépendances Objets Métiers
se JavaB
eans 3.0 Accès aux données
JN Java
Java
DI Transacti

Persisten

ce API on API
2.1 2.1 Persistance
SGBD
Figure 17 : Découpage en couches et Spécifications Java EE

5.2.1.4 Java EE : frameworks
Client
PrimeFaces
Java Server Faces 2.2
Présentation
CDI
Injection de Logique Métier
Session
dépendances Objets Métiers
Beans/Ent
ity Beans Accès aux données
JN Java
DI Transacti

Eclipse
on API
Link
2.1 Persistance
SGBD
Figure 18 : Découpage en couches et Framework Java EE
5.2.1.4.1 EclipseLink
EclipseLink est un framework open source de mapping objet-relationnel pour les développeurs
Java. Il fournit une plateforme puissante et flexible permettant de stocker des objets Java dans une base de
données relationnelle et/ou de les convertir en documents XML. EclipseLink est dérivé du projet TopLink
de la société Oracle. Il supporte un certain nombre d'API relatives à la persistance des données et
notamment la JPA.
5.2.1.4.2 Entity Beans ou beans entités

Une entité est un objet léger du domaine de persistance. Typiquement, une entité représente une
table dans une base de données relationnelle ; et chaque instance d'entité correspond à une ligne dans cette
table. L'artefact de programmation primaire d'une entité est la classe de l'entité, même si les entités
peuvent utiliser des classes utilitaires. L'état persistant d'une entité est représentée soit par des champs
persistants ou des propriétés persistantes. Ces champs ou propriétés utilisent les techniques de mapping
objet / relationnel aux travers d’annotations pour mapper les entités et les relations entre elles à des
données relationnelles dans le système de stockage de données sous-jacent.
La spécification EJB 3.0 offre un ensemble d’annotations à apposer sur les classes ou les champs
concernés pour les identifier en tant que beans entités (annotation @Entity), définir la propriété
identifiante d’un bean entité (annotation @Id), les associations entre beans entités du modèle objet
(annotations @OneToMany, @ManyToMany).

Le diagramme ci-après donne une vue partielle des beans entités de notre domaine d’études :
Figure 19 : Vue partielle du diagramme complété
Tous les concepts métiers de notre domaine seront considérés comme des beans entités et pris en
charge par le conteneur Java EE.
5.2.1.4.3 Session beans ou beans sessions

Les principes fondamentaux de l'architecture métier définissent la création de services en tant
qu'intermédiaires entre les applications clientes et l'accès aux données. Au sein d'une architecture Java
EE, ce sont des EJB qui remplieront cette fonction : les beans sessions. Plus que de simples classes
composés de propriétés et de méthodes, ces beans sessions sont de véritables passerelles de services au
sein même de l'application, permettant à tout type de client de les interroger.
Qu'est-ce qu'un bean session ?

Un bean session est une application côté serveur permettant de fournir un ou plusieurs services à
différentes applications clientes. Un service sert, par exemple, à récupérer la liste des comptes d’un client
ou à enregistrer une opération de compte. Un bean session définit les étapes successives afin d'aboutir à
un objectif final. Les beans sessions constituent donc les briques de la logique métier d'une application.
Ils traitent les données et effectuent les opérations liées à la logique de l'entreprise.
Les beans sessions font office de pont entre les clients et les données. Ils sont divisés en deux
types : Stateless et Stateful. Le choix du type Stateless ou Stateful s'appuie sur l'interaction désirée entre
le client et le bean session.
Les beans sessions Stateless
Un bean session Stateless est une collection de services dont chacun est représenté par une
méthode. Stateless signifie que le service est autonome dans son exécution et qu'il ne dépend donc pas

d'un contexte particulier ou d'un autre service. Le point important réside dans le fait qu'aucun état n'est
conservé entre deux invocations de méthodes.
Lorsqu'une application cliente appelle une méthode d'un bean session, celui-ci exécute la méthode
et retourne le résultat. L'exécution ne se préoccupe pas de ce qui a pu être fait avant ou ce qui pourra être
fait après. Ce type d'exécution est typiquement le même que celui du protocole HTTP (mode déconnecté).
Une bonne pratique est de proposer des beans sessions Stateless généraux afin de pouvoir être
réutilisés dans d'autres contextes. L'avantage du type Stateless est sa performance. En effet, plusieurs
clients utilisent la même instance. La pratique la plus courante est de proposer des interfaces pour exposer
les différents services offerts.
Nous enrichissons donc notre diagramme de classes tel que présenté dans la suite ; Pour plus de
clarté dans la visibilité, nous ne représentons le concept que sur trois classes métier que sont « Client », «
Operation » et « CompteEpargne ».
Figure 20 : Vue partielle du diagramme de classes détaillé
5.2.1.4.4 JSF (2.2)

Java Server Faces (JSF) est un framework web récent tentant de réconcilier le monde du
développement Internet avec celui du développement rapide d’applications. Basé sur le langage Java, son
but est de permettre le développement d’applications web en se basant sur des composants graphiques de
haut niveau et un modèle événementiel abstrayant le développeur des tracas liés à l’utilisation du
protocole HTTP. En clair, il est question d’être plus productif dans la création des pages web. Il propose :
 Un ensemble d'APIs pour la représentation et la gestion des composants, de leur état, des
évènements, de la validation des entrées et la conversion des sorties, l'internationalisation et
l'accessibilité ainsi que la navigation inter-vues
 Un modèle évènementiel côté serveur

 Les Managed-Beans : ce sont des composants qui forment la couche contrôle de JSF
 Unified Expression Language (abrégé en EL) ou langage d'expressions unifié pour JSF et JSP 2.0.
Il permet de lier les composants aux managed-beans
L’un des plus grands avantages de la technologie Java Server Faces est qu’elle offre une séparation
transparente entre la logique de fonctionnement et la présentation des applications. Java Server Faces
permet de développer des applications Web qui implémente un niveau détaillé dans la séparation entre la
logique et la présentation qui sont traditionnellement offerts par les architectures graphiques côté client.
Cette séparation permet à chaque intervenant dans le processus de développement d’une application Web
de se focaliser sur le développement d’un composant précis et offre un modèle de programmation simple
permettant de relier les différents composants. L’API Servlet est une technologie sous-jacente à la
technologie Java Server Faces.
5.2.1.4.5 PrimeFaces (version 2.2)

PrimeFaces est une suite de composants open source pour les applications Java Server Faces
(JSF), créée par Primetek. Son intérêt principal réside dans la diversité et la qualité des composants
proposés. Ils sont nombreux, et répondent le plus souvent en standard aux besoins des applications. Ce
sont des composants graphiques avancés qui possèdent des fonctionnalités prêtes à l’emploi, aidant ainsi à
créer aisément des applications Internet riches. Elles intègrent et étendent toute la puissance et les
performances offertes par JSF.
5.2.1.5 GlassFish Server : Serveur Java EE

La norme Java EE ne spécifie pas seulement les API et services utilisés pour construire des
applications d’entreprise ; elle spécifie également l’infrastructure d’exécution de ces applications. Un des
avantages majeurs de Java EE est de faire abstraction de l'infrastructure d'exécution. En effet, Java EE
spécifie les rôles et les interfaces pour les applications, ainsi que l'environnement d'exécution dans lequel
les applications sont déployées. Ceci permet aux développeurs d'application de ne pas avoir à
reprogrammer les services d'infrastructure.
La présence de cet environnement d’exécution confère aux serveurs Java EE la dénomination de
serveur d’applications. Il existe plusieurs serveurs d’applications. Parmi les produits commerciaux on
peut citer Oracle WebLogic Server , IBM Websphere Application Server. Parmi les produits libres on
peut citer JBOSS, Oracle GlassFish Server. Les différences principales entre les différents serveurs
d’applications sont relatives aux opérations de déploiement, de packaging, etc… Par contre toutes les
fonctionnalités qui concernent strictement le fonctionnement des applications Java EE adhèrent aux
spécifications proposées. Un serveur d’applications s’installe et se lance comme un serveur web normal
(de fait il met à disposition des services typiques d’un serveur web). En plus il possède un panneau
d’administration accessible par un poste distant à travers lequel on peut définir les différents services. La
réalisation ou l’implémentation de référence de la plateforme Java EE est dénommée GlassFish. C’est elle
que nous allons utiliser pour déployer notre solution.

5.2.2 Déploiement de l’application

5.2.2.1 Configuration de la connexion sécurisée
Lors du fonctionnement de notre application, les informations seront transportées par TCP/IP.
Compte tenu de la sensibilité des informations en l’occurrence les données financières, le média de
transport doit être sécurisé. Un système de sécurisation a été créé dans cet objectif : le SSL. Le SSL
(Secure Socket Layer) est un protocole légèrement supérieur à la couche 4 du modèle OSI. Il a pour
objectif, tel qu'il est définit dans la RFC 2246, de fournir la confidentialité et l'intégrité des données entre
deux applications en communication. La version actuelle de SSL est la 3.1, connue sous le nom de TLS
(Transport Layer Security). Ce changement de nom marque le rachat du brevet SSL par l'IETF,
appartenant initialement à Netscape. TLS utilise le chiffrement pour crypter les données transitant dans
les datagrammes. Pour transporter toutes les informations indispensables à TLS, les certificats
numériques aux formats X.509 sont utilisés. Un certificat numérique est une sorte de « carte d'identité »
d'une entité informatique. Le certificat numérique d'un serveur va contenir la clé publique de celui-ci mais
également un certain nombre de champs, d'attributs, reliés à son identité. Ce certificat est optionnellement
signé par une autorité de certification. La structure même de l'Internet ne permet pas de distribuer
efficacement des clés tout en s'assurant que la prétendue clé d'un serveur appartient bien à celui-ci. Le
modèle de certificats X.509 permet de pallier à cette déficience en ajoutant l'identité à la clé. Le modèle
X.509 est en fait un ensemble de champs, qu'ils soient obligatoires ou optionnels.
Nous avons, pour notre application, généré un certificat (voir Annexe), configuré celle-ci et
paramétré le serveur Java EE pour qu’il prenne en charge la sécurisation de la connexion.
5.2.2.2 Diagramme de déploiement

Nous représentons sur le diagramme de déploiement l’architecture physique supportant
l’exploitation de notre système. Cette architecture comprend des nœuds correspondant aux supports
physiques (serveurs, routeurs…) ainsi que la répartition des artefacts logiciels (bibliothèques,
exécutables…) sur ces nœuds. C’est un véritable réseau constitué de nœuds et de connexions entre ces
nœuds qui modélise cette architecture. Un nœud correspond à une ressource matérielle de traitement sur
laquelle des artefacts seront mis en œuvre pour l’exploitation du système. Les nœuds peuvent être
interconnectés pour former un réseau d’éléments physiques. Notre application est déployée sur le serveur
d’applications GlassFish en deux modules : un module Web « microSAnalytics-web.war » regroupant la
logique de présentation, les routines de contrôle d’interface et de traitement des requêtes ; et un module
« microSAnalytics-ejb.jar » regroupant les routines de manipulation des données.

Internet
Figure 21 : Diagramme de déploiement de notre application
5.2.3 Outils de modélisation et environnement de développement

5.2.3.1 NetBeans IDE
NetBeans est environnement de développement intégré (ou IDE) racheté par Sun Microsystems
(eux-mêmes racheté par Oracle en 2009). Son parcours explique ainsi sa forte orientation pour le langage
Java bien que le logiciel, qui continue à évoluer, permette également de gérer des développements en
JavaScript, Python, XML, RubyC et C++ ainsi qu'en PHP et HTML5. NetBeans intègre la plupart des
fonctionnalités exigées d'un IDE moderne dont, bien sûr, un éditeur de code gérant l'auto indentation et la
colorisation syntaxique :
 Gestion des systèmes de versions CVS, Subversion, Mercurial, et ClearCase ;

 Analyses en « run » et débogage ;
 Explorateur de base de données ;
 Édition graphique d'interfaces et de pages Web ;
 En outre celui-ci permet la gestion des projets multi langage.

Son interface se compose par défaut d'un éditeur de code, d'un navigateur de projet, de fichiers ou
de services, d'un navigateur de sources et enfin, d'un éditeur de propriétés CSS. Nul doute que l'utilisateur
saura sans problème agencer et ajouter les fenêtres nécessaires à son usage.
5.2.3.2 DIA
C’est un logiciel de diagrammes multiplateforme : Fonctionnant sous GTK+, c’est un éditeur de
diagrammes Open Source indispensable sous Linux et Windows. Certes il n'en n'est pas encore au niveau
de Visio, le produit phare de ce type sous Windows, mais il offre des avantages: il est Open Source donc
extensible et il est gratuit. Dia permet aussi de créer des schémas de base de données grâce à une batterie
d'éléments dédiés aux diagrammes UML. Occurrences, nœuds, classes et attributs peuvent être reliés
grâce à une large palette de connecteurs. De plus grâce à son plugin UML2PHP5, il permet à partir d’un
bon modèle UML de générer une application web sous PHP 5.
5.2.3.3 Altova UModel

C’est un logiciel de modélisation UML abordable avec une interface visuelle riche et des caractéristiques
d'utilisation supérieures à la norme requise pour un outil de modélisation UML; il comprend de nombreuses
fonctionnalités sophistiquées fournissant aux utilisateurs les aspects les plus pratiques de la spécification UML.
5.2.3.4 JasperReports & iReport

5.2.3.4.1 JasperReports
JasperReports se base sur des fichiers XML (dont l'extension est en général .jrxml) pour la
présentation des états. Il peut être couplé à iReport (outil WYSIWYG) ou JasperStudio (plugin Eclipse
équivalent) pour faciliter sa mise en œuvre dans une application Java, classique ou orientée web. La
version complète de l'application se nomme JasperReports Server (JRS) depuis la V4 (anciennement
JasperServer) et propose un serveur d'application et la création de rapports web.
5.2.3.4.2 iReport
iReport est un logiciel open source, écrit entièrement en Java, permettant, par l’intermédiaire
d’une interface graphique riche, de créer des modèles de rapports au format .jrxml de JasperReports.
L’utilisation de ce logiciel permet de s’abstraire de la complexité de la syntaxe XML de
JasperReports, et de gagner du temps lors du développement de modèles de rapport. iReport permet une
prise en main complète de JasperReports via son interface graphique, par son support complet des tags
XML de la librairie, une interface WYSIWYG pour tous les éléments graphiques, un éditeur
d’expressions, la gestion des sous rapports. Un module intégré d’exportation, associé à un support des
connexions JDBC et des sources de données JasperReports, permet également de tester le rendu des
rapports directement depuis le logiciel.
IReport apporte à JasperReports un gain de productivité non négligeable, une fois l’outil pris en
main, par rapport à d’autres solutions de reporting pour Java non outillées.

CHAPITRE 6 : Conduite de projet

6.1 Gestion de projet
La gestion de projet ou conduite de projet est une démarche visant à structurer, assurer
et optimiser le bon déroulement d’un projet. Elle a pour vocation de relever les défis en mettant en place
une organisation et une planification de l’ensemble des activités visant à assurer l’atteinte des objectifs du
projet (qualité, coûts, délais), effectuer leur suivi, anticiper les changements à mettre en œuvre et les
risques, décider et communiquer.
6.1.1 Découpage du projet

La conduite d’un projet repose sur un découpage chronologique (phases) du projet en précisant ce
qui doit être fait (tâches) et par qui cela doit être fait (Ressources). Le découpage d’un projet en tâches
permet une meilleure allocation des ressources et une planification du projet dans le temps.
Ainsi afin de mener à bien notre projet, nous avons procédé à une répartition en phases
comprenant chacune des tâches à réaliser.
Tableau 5 : Découpage en tâches du projet

PHASES TACHES
Exploration du sujet - Lecture des articles liés à la microfinance

- Lecture des articles liés aux institutions financières
- Lecture des règlements de la Commission Bancaire de l’Afrique
Centrale
Analyse et conception - Etude des documents portant sur les méthodes de développement
- Modélisation des besoins du système à mettre en place
- Etude des documents relatifs aux architectures logicielles
Mise en œuvre - Choix des outils de développement

- Représentation de l’architecture de la solution
- Validation et test
Documentation - Rédaction
6.1.2 DIAGRAMMES DE GANTT

Le diagramme de GANTT est un outil permettant de modéliser la planification de tâches
nécessaires à la réalisation d'un projet. Nous modélisons ci-dessous le diagramme prévisionnel qui a
été élaboré au début de la réalisation du projet et ensuite le diagramme réel qui est celui obtenu à la fin du
projet.

Figure 22 : Diagramme de GANTT Prévisionnel
Figure 23 : Diagramme de GANTT réel
6.1.3 INTERVENANTS AU PROJET

Durant notre stage nous avons été en contact permanent avec plusieurs personnes :
Tableau 6 : Intervenants au projet

Intervenants Titre
Pr. Ousmane B. KONFE Enseignant chercheur à IAI et maître de stage
Mr. Felix HOUTSA Superviseur académique
Mr. Ghislain PODA Gérant de GPO Consulting et encadreur
Mr. Ousseyni TIAMA Ingénieur informaticien et responsable informatique à GPO

Consulting

6.1.4 ESTIMATION DES CHARGES DU PROJET

Tableau 7 : Estimation des charges et coûts
Ressources utilisées Coût
Ordinateur portable ASUS Modèle K73S intel core i5-2430m 459 000 FCFA
2,4GHZ
Système d’exploitation Windows 7 Gratuit
Connexion Internet Existante
NetBeans 7.4 (Environnement de développement intégré) Gratuit
Java, J2EE (Langage et plateforme de développement) Gratuit
Altova UModel, Edraw Max 7 (Outils de modélisation) Gratuit
iReport + JasperReports (Outils de reporting) Gratuit
Système de Gestion de Base de données MySQL 5.6 Gratuit
Serveur d'applications GlassFish Open Source Edition 4.0 Gratuit
Impress.js (Outils de présentation) Gratuit
Coût du stagiaire 150 000 FCFA x 5
TOTAL 1 209 000 FCFA
6.2 Apports, difficultés et perspectives du projet

6.2.1 Apports
Au cours de ce stage, il a été question pour nous de mettre en place une application
d’automatisation des activités d’une microfinance offrant une fiabilité dans la prestation de services
financiers et un contrôle plus efficace des rapports et bilans d’activité. En termes de réalisation du travail,
les fonctionnalités que nous avons mises en place concernent :
 Le service d’épargne ;
 Le service d’octroi de crédit ;
 Le service de transfert d’argent ;
 Affichage de la grille de transfert d’argent ;
 La production et le téléchargement de rapports d’activité et bilans périodiques;
 La gestion des utilisateurs et la création de groupes d’utilisateurs;
 La gestion des employés;
 La gestion des clients ;
 La gestion de notifications ;
 La gestion des guichets, agences, des villes, des régions ;
 L’affectation de personnel.

Ce projet nous a permis de mettre en pratique les enseignements reçus durant nos trois années de
formation à l’Institut Africain d’Informatique notamment en gestion des bases de données et en
programmation orientée-objet.
Ce stage a été également pour nous l’occasion d’évoluer dans le monde professionnel, et de
constater l’importance de gérer les projets informatiques en équipe et d’évaluer les risques du projet.
Aussi ce stage nous a permis l’acquisition d’une vision globale des procédures de prestation des services
micro-financiers
6.2.2 Difficultés
Nous avons rencontré plusieurs difficultés qui nous ont ralentis dans la réalisation de ce projet, il
s’agit de :
 La difficulté dans l’appropriation des technologies utilisées notamment la technologie Java EE;
 Le fonctionnement des composants offerts par la plate-forme Java EE.
 L’indisponibilité des infrastructures de test en environnement réel ;
 La délimitation du contexte de notre travail.
6.2.3 Perspectives
S’inscrivent dans les perspectives les aspects suivants des services micro-financiers que nous
n’avons pas pu mettre en place. Il s’agit :
 De l’octroi de prêts de groupe ;
 Du système de suivi et de recouvrement de prêts ;
 De la gestion des groupes d’utilisateurs ;
 De la gestion du plan tarifaire.
Aussi, notre plate-forme déployée en environnement réel nous permettra d’interconnecter le siège
d’une microfinance et ses agences. Nous pourrons envisager, dans une phase d’extension d’interfacer
notre plate-forme à un système de distributeurs automatiques et de ce fait exploiter toute la flexibilité
qu’offre la technologie Java EE.

Conclusion
Nous avons effectué dans cette partie notamment dans le premier chapitre, une étude approfondie
de la technologie et frameworks adoptées pour la mise en œuvre de notre application. Nous les avons
également identifiés au travers des couches de notre application raffinant au fur et à mesure notre
diagramme de classes. Ces choix technologiques précisés, nous avons élaboré le diagramme de
déploiement de notre application. Enfin nous avons énuméré les logiciels de modélisation et
environnement de développement utilisés tout au long du processus de développement de l’application.
Dans un second chapitre nous nous sommes penchés sur la planification en tâches de notre projet logiciel
et avons conclu par les bilans et perspectives s’en dégageant.

CONCLUSION GENERALE
Notre travail a consisté à concevoir un système sécurisé de traitement et de suivis des activités
d’une microfinance. Le système devait être robuste, tolérante aux pannes et fonctionner sur une
infrastructure internet. Nous avons alors exploité les services performants d’un serveur d’applications
Java EE pour mener ce projet à terme et proposer la majeure partie des fonctionnalités requises. Dans un
monde où l’intervention de l’homme est de moins en moins envisagée et les applications d’entreprises de
plus en plus connectées, ce thème offre une perspective dans laquelle les résultats de nos travaux
pourraient être une source d’informations non négligeables pour d’autres applications d’entreprise. La
microfinance s’inscrit dans un cadre économique de plus en plus croissant derrière celles des économies
fortes et très développées. Les meilleures institutions financières basent leur réussite sur une mine de
statistiques économiques et financières recueillies sur plusieurs années d’étude. Dans cet ordre idée il
serait envisageable d’opter pour une politique de visibilité dont le but est de publier des statistiques
financières et une autre d’exploitation dont le but est d’en utiliser pour se conformer aux normes
internationales et s’évaluer aux institutions les plus pérennes.

BIBLIOGRAPHIE
BHOLE, L.M. 1999. Financial Institutions and Markets : Structure, Growth and Innovations. New Delhi : s.n., 1999.
Gabay, Joseph et Gabay, David. 2008. UML 2 Analyse et conception : Mise en oeuvre guidée avec études de cas.
Paris : Dunod, 2008.
Jackobson, Ivar , Boosh, Grady et Rambaugh, James. 1999. Le processus unifié de développement logiciel. s.l. :
Eyrolles, 1999.
Jendrock, Eric, Cervera-Navarro, Ricardo et Evans, Ian. The Java EE 7 Tutorial, Release 7 for Java EE Platform.
LAHLOU, Laaziz. 2010. Conception et réalisation d'une application web pour la gestion des stocks cas d'étude
magasin de la faculté des sciences exactes de l'université de Bejaia. Université de Bejaia. 2010. Mémoire - Licence
Académique en Mathématique et Informatique Option Informatique.
MATABISHI, Amini KAMBALE. 2009. Risques de credit dans Une institution de micro finance en ville de Butembo,
cas de crédit congolais pour la reconstruction. [Mémoire - Université Catholique du Graben (U.C.G) - Licence]
Congo : s.n., 2009.
Mert Çalışkan, Oleg Varaksin. 2013. Primefaces CookBook. [trad.] Hebert Coelho de Oliveira Andy Bailey.
Birmingham : Packt Publishing Ltd, 2013. p. 328. ISBN.
Mouadh, Boutrid. 2010. Gestion du patrimoine immobilier OPGI de Khenchela. Centre Universitaire de Khenchela.
2010. Mémoire Licence en mathématique et informatique .
NDAO, Abdou. 2007. Gestion des risques dans les institutions de microfinance. [Mémoire - Université Cheikh anta
Diop - Master en finance et banque] Sénégal : s.n., 2007.

ANNEXE
Annexe A : Certificat de sécurité auto signé utilisé pour la configuration du SSL
Nom d'alias : s1as
Date de création : 15 mai 2013
Type d'entrée : PrivateKeyEntry
Longueur de chaîne du certificat : 1
Certificat[1]:
Propriétaire : CN=localhost, OU=GlassFish, O=Oracle Corporation, L=Santa Clara, ST=California, C=US
Emetteur : CN=localhost, OU=GlassFish, O=Oracle Corporation, L=Santa Clara, ST=California, C=US
Numéro de série : 3e90556f
Valide du : Wed May 15 06:34:00 GMT+01:00 2013 au : Sat May 13 06:34:00 GMT+01:00 2023
Empreintes du certificat :
MD5: 11:4E:F1:CE:EC:73:F4:24:BD:54:DB:74:41:3E:78:35
SHA1 : AB:A0:A4:D1:13:6B:7F:68:0F:D2:17:E1:6F:7C:D4:07:16:44:5D:B1
SHA256 :
41:81:B6:96:8E:09:03:E3:C3:77:B1:21:41:64:AB:39:17:20:78:35:6D:AC:66:28:80:01:A0:1F:CD:93:8D:7F
Nom de l'algorithme de signature : SHA256withRSA
Version : 3
Extensions :
#1: ObjectId: 2.5.29.14 Criticality=false

SubjectKeyIdentifier [
KeyIdentifier [
0000: DE 8B 3A FB BB 48 7D A0 9D 8E 59 E7 89 32 47 AD ..:..H....Y..2G.
0010: A2 A2 21 76 ..!v
]
]

Annexe B : Captures d’écran de l’application
Figure 24: Ecran de connexion
Figure 25 : Interface d'administration : menu principal

Figure 26 : Gestion des agences
Figure 27 : Gestion des comptes d'utilisateur

Figure 28 : Enregistrement des informations concernant le client
Figure 29 : Octroi de crédit : Sélection d'un client existant

Figure 30 : Octroi de crédit : saisie des informations concernant le crédit
Figure 31: Demandes d’octroi de crédit en attente

Figure 32 : Traitement d'une demande d’octroi de crédit
Figure 33 : Diagrammes représentant le nombre de client par agence

Figure 34 : Rapport de guichet sur l'épargne

Mémoire BLU Kwensy Eli

Transféré par

Droits d'auteur :

Formats disponibles

Mémoire BLU Kwensy Eli

Transféré par

Informations du document

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

Mémoire BLU Kwensy Eli

Transféré par

Droits d'auteur :

Formats disponibles

Institut Africain d’Informatique GPO Consulting

Etablissement Inter-états d’Enseignement BP 23608 Libreville Gabon

MEMOIRE DE FIN DE CYCLE

En vue de l’obtention du diplôme d’ingénieur de conception en informatique

TABLE DES MATIÈRE

Présenté et soutenu par :

BLU Kwensy Eli

Superviseur IAI Maître de stage

Mr. HOUTSA Felix Mr. PODA Ghislain

Enseignant IAI Gérant de GPO Consulting

Année académique 2013-2014

BLU Kwensy Eli - Institut Africain d’Informatique - 2014 Page i

CHAPITRE 4 : Analyse et conception de la plateforme.........................................................................24

BLU Kwensy Eli - Institut Africain d’Informatique - 2014 Page ii

 A mes parents, BLU Koku Selom et GOGOVOR Kossiwa Ametoyowona

 A mon frère cadet BLU Kossikuma Luc, ma sœur aînée BLU Ama Sese

 A la mémoire de mon frère cadet BLU Augustin, paix à ton âme;

BLU Kwensy Eli - Institut Africain d’Informatique - 2014 Page iii

J’aimerais également remercier :

 Dr. Souleymane KOUSSOUBE, Directeur Général de l’IAI;

 Mr. Ghislain PODA, gérant de GPO Consulting ;

 Mr. Fleury MOUMBANGA, pour sa disponibilité et ses encouragements ;

 M. Djérabé Goldoum BENADJINGAR, coordonnateur de filière, pour l’encadrement des

 Dr. Roger NOUSSI pour ses idées et remarques constructives;

 Tout le corps professoral et administratif de l’Institut Africain d’informatique ;

 Mes amis de Libreville et du Togo.

BLU Kwensy Eli - Institut Africain d’Informatique - 2014 Page iv

BLU Kwensy Eli - Institut Africain d’Informatique - 2014 Page v

BLU Kwensy Eli - Institut Africain d’Informatique - 2014 Page vi

BLU Kwensy Eli - Institut Africain d’Informatique - 2014 Page vii

BLU Kwensy Eli - Institut Africain d’Informatique - 2014 Page viii

BLU Kwensy Eli - Institut Africain d’Informatique - 2014 Page ix

BLU Kwensy Eli - Institut Africain d’Informatique - 2014 Page x

BLU Kwensy Eli - Institut Africain d’Informatique - 2014 1

PARTIE 1. PRESENTATION GENERALE

BLU Kwensy Eli - Institut Africain d’Informatique - 2014 2

CHAPITRE 1 : Présentation de la structure d’accueil et du sujet

L’étude de faisabilité de projet

L’organigramme de GPO Consulting se présente comme suit :

BLU Kwensy Eli - Institut Africain d’Informatique - 2014 3

Figure 1 : Organigramme de GPO Consulting

1.2 Contexte et intitulé du sujet

BLU Kwensy Eli - Institut Africain d’Informatique - 2014 4

1.3 Problématique du sujet

BLU Kwensy Eli - Institut Africain d’Informatique - 2014 5

1.4 Intérêts du sujet

BLU Kwensy Eli - Institut Africain d’Informatique - 2014 6

CHAPITRE 2 : Concepts liés au domaine

2.1 Institutions financières

2.2 Les activités d’une microfinance

BLU Kwensy Eli - Institut Africain d’Informatique - 2014 7

Le défi actuel de la plupart des institutions de microfinance est celui de l'institutionnalisation et de

2.3 Dépôts et épargnes

On trouve deux types d'épargne obligatoire :

 L'épargne de garantie sert à garantir le crédit consenti généralement à un individu ou à un groupe.

BLU Kwensy Eli - Institut Africain d’Informatique - 2014 8

2.5 Système analytique

BLU Kwensy Eli - Institut Africain d’Informatique - 2014 9

BLU Kwensy Eli - Institut Africain d’Informatique - 2014 10

BLU Kwensy Eli - Institut Africain d’Informatique - 2014 11