Rapport Projet fin d'étude metIT

Erreur ! Utilisez l'onglet Accueil pour appliquer Heading 1 au texte que vous souhaitez faire

apparaître ici.Remerciement

Avant toute chose, mes souhaits les plus chers seront de remercier vivement toutes les

personnes qui de près ou de loin se sont impliquées dans la réalisation de ce rapport, tant

par leur soutien opérationnel, que professionnel.

Je remercie tout d’abord mon encadrant de stage qui a bien voulu accepter de suivre mon

travail, me diriger et apporter des réponses à toutes mes questions tant opérationnelles que

d’ordre général, afin que je puisse mener ce projet à terme.

Merci également à toutes l’équipe du service pour leur sollicitude à me faire découvrir leurs

activités et qui ont toujours été très ouverts et accueillants, je voulais leur dire que j’ai passé

en leur présence des moments très enrichissant et sympathiques et qu’ils ont contribué à la

réussite de ce stage.

Je tiens bien sûr à remercier amplement tous le cadre professoral de l’ENSAK pour la

formation de qualité qu’ils nous assurent. Je souhaite que le travail réalisé soit à la hauteur

de leur espérances ainsi qu’aux attentes de mon encadrant.

1


apparaître ici.Table de matière

Introduction générale________________________________________________________________________8

Chapitre 1. Présentation de l’entreprise d’accueil______________________________________________12

1. Fiche technique_____________________________________________________________________12

2. Domaine d’activité de l’entreprise______________________________________________________13

3. Structure et organisations générale_____________________________________________________15

4. Présentation du service IHM___________________________________________________________17

4.1. Activités du service_____________________________________________________________17

4.2. Effectifs_______________________________________________________________________17

4.3. Schéma de traitement des demandes_______________________________________________18

Chapitre 2. Déroulement du stage___________________________________________________________20

1. Description_________________________________________________________________________20

2. Tâches____________________________________________________________________________21

Chapitre 3. Contexte Générale Du Projet_____________________________________________________24

1. Cahier de charge____________________________________________________________________24

1.1. Problématique_________________________________________________________________24

1.2. Présentation du besoin__________________________________________________________24

2. Analyse fonctionnelle________________________________________________________________25

2.1.1. Besoin fonctionnelle__________________________________________________________26

2.1.2. Besoin non fonctionnelle______________________________________________________27

3. Etude des solutions :_________________________________________________________________27

4. Planification________________________________________________________________________29

4.1. Diagramme de Gantt____________________________________________________________29

Chapitre 4. Etude détaillée du projet________________________________________________________31

1. Conception Générale_________________________________________________________________31

1.1. Architecture système____________________________________________________________31

1.2. Architecture coté client :_________________________________________________________32

1.3. Les acteurs____________________________________________________________________33

1.4. Modules de l’application_________________________________________________________33

2


apparaître ici.1.4.1. Consulter fonds de commerce__________________________________________________35

1.4.2. Administration_______________________________________________________________35

1.4.3. Gestion Client_______________________________________________________________35

1.4.4. Consultation Client___________________________________________________________36

2. Conception détaillée_________________________________________________________________37

2.1. Module Consultation fonds de commerce___________________________________________37

2.1.1. Cas d’utilisation______________________________________________________________37

2.1.2. Diagramme de séquence : Authentification________________________________________39

2.1.3. Diagramme de classe : Authentification___________________________________________41

2.1.4. Diagramme de séquence Consulter Fond De Commerce______________________________42

2.2. Module Consultation Dossier Clients________________________________________________43

2.2.1. Cas D’utilisation______________________________________________________________43

2.2.2. Diagramme de séquence Afficher Synthèse Client___________________________________44

2.3. Module Gestion Clients__________________________________________________________46


2.4. Module Administration__________________________________________________________47


2.4.2. Diagramme de séquence Gérer Compte (créer compte)______________________________48

2.4.3. Diagramme de classe Créer Compte______________________________________________49

2.4.4. Diagramme de séquence Gérer Compte (supprimer compte)__________________________50

2.4.5. Diagramme de classe Supprimer compte__________________________________________52

Chapitre 5. Réalisation____________________________________________________________________54

1. Outils de développement______________________________________________________________54

1.1. Eclipse/WebSphere_____________________________________________________________54

1.2. Web Storm____________________________________________________________________55

1.3. Mainframe/cobol_______________________________________________________________56

1.4. Spirit :________________________________________________________________________56

1.4.1. Architecture spirit____________________________________________________________57

1.5. Goal_________________________________________________________________________58

1.6. Web Service Java_______________________________________________________________59

2. Résultat et interprétation_____________________________________________________________60

2.1. Consultation du fonds de commerce________________________________________________60

2.1.1. Etape de sélection du fonds de commerce_________________________________________60

2.1.2. Etape Consultation Fonds de commerce__________________________________________61

3


apparaître ici.2.2. Dossier Client__________________________________________________________________64

2.2.1. Etape accès au dossier client____________________________________________________65

2.2.2. Ecran Déontologie____________________________________________________________66

3. Plan de maintenance corrective________________________________________________________67

Conclusion générale________________________________________________________________________69

Bibliographie et Webographie________________________________________________________________71

Glossaire_________________________________________________________________________________72

Résumé__________________________________________________________________________________73

Abstract__________________________________________________________________________________74

4


apparaître ici.Liste des figures

Figure 1-1Organigramme_____________________________________________________16

Figure 1-2 Schéma traitement des demandes_____________________________________18

Figure 3-1 Diagramme bête à cornes____________________________________________25

Figure 3-2 Diagramme de Gantt________________________________________________29

Figure 4-1 Architecture de l'application__________________________________________31

Figure 4-2 Architecture JS Moderne_____________________________________________32

Figure 4-3 Diagramme Acteurs_________________________________________________33

Figure 4-4 Modules de l'application_____________________________________________33

Figure 4-5 Module Consultation Fonds de Commerce______________________________35

Figure 4-6 Module Administration______________________________________________35

Figure 4-7 Modifier Gestion Client______________________________________________35

Figure 4-8 Module Consultation Client___________________________________________36

Figure 4-9 Diagramme Cas D'utilisation Du Module Consultation FDC_________________37

Figure 4-10 Diagramme de séquence Authentification______________________________39

Figure 4-11 Diagramme de classe Authentification_________________________________41

Figure 4-12 Diagramme de séquence Consulter FDC________________________________42

Figure 4-13 Diagramme Cas D'utilisation du module Consultation Dossier Client_________43

Figure 4-14 Diagramme de séquence Afficher Synthèse Client________________________44

Figure 4-15 Diagramme Cas D'utilisation du module Gestion Clients___________________46

Figure 4-16 Diagramme cas D'utilisation Du module Administration___________________47

Figure 4-17 Diagramme de séquence Créer Compte________________________________48

Figure 4-18 Diagramme de classe Créer Compte___________________________________49

Figure 4-19 Diagramme de séquence Supprimer Compte____________________________50

Figure 4-20 Diagramme de classe Supprimer Compte_______________________________52

Figure 5-1 Framework Spirit___________________________________________________56

Figure 5-2 Architecture Coté Client (architecture spirit)_____________________________57

Figure 5-3 Middleware Goal___________________________________________________59

Figure 5-4 Ecran de Choix du type d'arborescence_________________________________60

Figure 5-5 Ecran de choix pour Administrateur BPF________________________________61

5


apparaître ici.Figure 5-6 Ecran Consultation Client Particulier___________________________________62

Figure 5-7 Ecran Consultation Client Professionnels________________________________62

Figure 5-8 Ecran Consultation Client Entrepreneur_________________________________63

Figure 5-9 Export CSV________________________________________________________64

Figure 5-10 Description Graphique de l'onglet Information__________________________65

Figure 5-11 Ecran Synthèse Dossier Client Personne Morale_________________________66

Figure 5-12 Ecran Déontologie Dossier Client_____________________________________66

Figure 5-13 Maintenance Corrective____________________________________________67

6


apparaître ici.

INTRODUCTION GENERAL

7


apparaître ici.

Introduction générale

De nos jours, les banques, piliers de l’économie moderne, sont confrontés de plus en plus à

une concurrence axée sur les services.

Les systèmes informatiques ne représentent plus seulement un enjeu technologique et

économique, mais une nécessité stratégique.

Face à la complexité des systèmes d’information, la nécessité d’outils informatiques gérant

l’ensemble des activités des banques est devenue indispensable, et c’est dans ce cadre que

s’intègre le projet de gestion des clients des fonds de commerce.

Afin de bien assimiler le domaine dans lequel intervient ce projet de fin d’étude relatif aux

fonds de commerce, il est nécessaire de bien définir ce dernier.

Un fonds de commerce est un ensemble d'éléments corporels et incorporels indissociables

et destinés à attirer une clientèle, dans le but de vendre.

Parmi les éléments incorporels qui le composent on retrouve :

L'achalandage : ou client de passage, puisque la notion de clientèle désigne les clients

habitués.

La clientèle

Le droit au bail : correspond à l'indemnité versée par le locataire du fonds de

commerce au propriétaire de celui-ci.

L'enseigne

Le nom commercial : c’est le nom de la société qui partage son fonds de commerce

avec le partenaire.

Les marques, les brevets et les autorisations administratives.

Il est indispensable de bien distinguer le fonds de commerce d'une part, et les éléments qui

le composent d'autre part, en effet, celui-ci est plus que la somme des éléments le

composant.

8


apparaître ici.

Ainsi, il y aura toujours un fonds de commerce alors même que la totalité de ses éléments

auraient été amenés à disparaître, à être détruits ou bien vendus.

Mais il ne peut y avoir fonds de commerce sans clientèle, de la sorte, cette dernière est plus

qu'un élément du fonds de commerce, elle en est sa finalité.

D'une manière générale, la clientèle est la valeur qui représente les relations entre les fonds

et les personnes qui exploitent des biens et des services.

Ce qui se voit clairement sur la relation entre le siège d’une banque et ses agences, ainsi

chaque agence a ses propres clients donc son propre fonds de commerce partagé avec le

siège de la banque mais qui ne sera pas accessible à d’autres agences.

On peut dire alors que la clientèle est l’élément principal de tout fonds de commerce. Ainsi

l’objectif de cette application est de mieux gérer les activités de la banque de détail, et

d’améliorer l’interaction avec ses partenaires que ça soit des agences, des particuliers ou

des entrepreneurs qui partage des fonds de commerce avec la banque.

Ce rapport suivra une structuration bien précise, nous allons présenter dans un premier lieu

l’entreprise d’accueil BNP-PARIBAS-MEDIT, ses actionnaires, ses clients, ses principales

activités et son organisation, pour passer ensuite à une description détaillée du service dans

lequel s’est déroulé le stage en présentant l’activité du service, ses employés, les procédures

gérant ses activités et les tâches qui m’ont été affecté durant ce stage.

La deuxième partie du rapport concernera le projet, où il est nécessaire de fournir le cahier

de charge de l’application qui présentera les objectifs du projet et les besoins pour lesquels

nous sommes amenés à développer cette application. Nous devrons ensuite lister les

contraintes liées au projet, les besoins fonctionnels et non fonctionnels en plus d’une

planification des différentes étapes de développement (un diagramme de gant).

9


apparaître ici.

Il est ensuite nécessaire de passer à la conception du projet où nous allons présenter

l’architecture système et les acteurs de l’application. Cette dernière sera découpée en

plusieurs modules, chacun de ces modules sera détaillé à travers des diagrammes de cas

d’utilisation, de séquences et de classe. Il ne reste alors que la partie réalisation qui

présentera les résultats et interprétations de chaque composant, les technologies utilisés au

sein de l’application et une description du plan de la maintenance corrective.

10


apparaître ici.

CHAPITRE1

PRESENTATION DE L’ENTREPRISE

D’ACCUEIL

11


apparaître ici.

Chapitre 1. Présentation de l’entreprise

d’accueil

Ce chapitre présentera l’entreprise bnp-paribas-medit de manière générale, en proposant

une fiche technique de la société contenant des informations sur son état civil, son capital,

ses coordonnées, son effectif et ses actionnaires, nous aurons aussi à présenter son domaine

d’activité. MedIT est une société de développement informatique, nous traiterons alors les

différentes phases de développement sur lesquelles elle intervient.

L’organigramme et l’activité du service sur lequel j’ai été affecté sera aussi présenté sur ce

chapitre.

1. Fiche technique

Nom BnpParibas MedIT

Etat Civil Société Anonyme

Groupe BNP PARIBAS

Profession Développement informatique

Capital 46 212 800 Dirhams

Effectifs 430 Collaborateurs

Siege social NearShore-1100 Bd Al Qods SidiMaarouf-20000 Casablanca

Téléphone 212 (0) 5 29 00 51 00

Fax 212 (0) 5 29 00 51 99

Naissance 6 janvier 2004

12


apparaître ici.

2. Domaine d’activité de l’entreprise

Le Maroc est de nos jours considéré comme l’une des principales destinations d’Offshoring.

L’externalisation au Maroc fait bel et bien partie de l’actualité chez les sociétés

européennes, c’est ainsi que la société BnpParibas délocalise une partie de son service

informatique au Maroc créant ainsi l’entreprise MedIT en 2004.

Le domaine d’activité de cette société se focalise principalement sur le développement

informatique destiné à certaines entités de la société Mère. On retrouve alors parmi ses

principaux clients :

DSI BDDF: Direction du Système d’Information Banque de Détail en France.

IRB-IT: International Retail Banking Information Technologie.

BNPPLS: BNP Paribas leasing Solution.

GSSC: Global Shared Service Center.

Les activités de MedIT se résument généralement sur la réalisation de projets informatiques

destinés à ses principaux clients qui se charge de la partie spécification et conception.

Ainsi MedIT s’occupe :

Du codage.

Des recettes.

Des tests.

De la maintenance corrective (gestions des incidents et des anomalies).

De la maintenance évolutive.

De l’assurance qualité de l’application.

MedIT réalise aussi des prestations pour des partenaires locaux :

Support des fonctions d’administration.

Support système d‘information.

Audit sécurité.

13


apparaître ici.

L’industrie logicielle a souvent été pointée du doigt pour son manque de fiabilité tant sur le

plan du respect des délais que de la qualité des produits livrés. À cet égard, le Groupe BNP

Paribas s’est engagé dans une démarche d’amélioration de ses processus de gestion de

projet et de maintenance, et BNP Paribas MEDITERANEE IT est totalement inscrite dans cette

démarche.

Dans ce cadre, BNP Paribas MEDITERANEE IT a fait le choix de l’approche CMMI qui s'impose

comme un référentiel d'évaluation international, après quoi, elle a pu en avril 2009 se voir

accorder la certification CMMI-2.

14


apparaître ici.3. Structure et organisations générale

15


apparaître ici.

16

TMA-IHM

Mlle Wafaa BOUANANI

Chef d’équipe (CE)

TMA-IHM

M. Khalid MOUDEN Chef de projet (CP)

TMA-IHM

M.Mohamed

BOUCHATOUY Chef de projet (CP)

TMA-IHM

Mlle. Mariam HAZZAZChef de projet (CP)

Younes Bahba

Back-up Analyste Développeur

Samira MAHDAR


Youssef Bentbib


Analystes Développeurs

M. Mbarek RAYAD


M. Anas HINDI


Mlle. Soukaina LAMA


…

Figure 1-1Organigramme

https://directory.group.echonet/people/451486/org_chart





apparaître ici.

4. Présentation du service IHM

4.1. Activités du service

Le service IHM s’occupe de la réalisation des interfaces Homme-Machine des applications de

MedIT. Il est composé d’une trentaine de développeurs, de trois chefs de projets, de trois

back-up et d’un chef d’équipe.

Ce service est toujours en interaction avec le responsable du patrimoine ou l’expert IHM en

France, à travers des réunions en visio-conférence avec le chef d’équipe ou les chefs de

projets.

L’ensemble des travaux est classifié sur une famille d’activité : Projet/Evolution/Maintenance

Le service IHM gère les demandes reçus de la part des clients. Il existe plusieurs types de

demandes :

Demande de traitement d’incident de production (maintenance).

Demande de correction d’anomalies (maintenance).

Demande d’étude d’impact (évolution).

Demande d’évolution fonctionnelle (évolution).

Demande de création d’une nouvelle application (projet).

Plusieurs réunions sont programmées lors de la réalisation de tout projet informatique,

que ça soit entre le chef de projet et l’équipe de développeur, entre le chef d’équipe et

les développeurs ou entre les chefs de projet et le chef d’équipe.

4.2. Effectifs

CE (chef d’équipe) : Wafaa Bouanani.

CP (chef de projet) :

Mohammed Bouchatouy (backup Samira Mahdar).

Khalid Mouden (backup Younes Bahda).

Mariam El Hazzaz (backup Youssef bentbib).

Analyste assurance qualité, analyste risque : Hajar Bourahadi.

17


apparaître ici.

4.3. Schéma de traitement des demandes

Figure 1-2 Schéma traitement des demandes

Ce chapitre nous a permis de voir le niveau de maturité de MedIT à travers son organisation

interne, ses activités et sa structuration, nous aurons ainsi présenté l’entreprise d’accueil et

le plan sur lequel reposera notre projet qui suit la même démarche des projets développés

chez MedIT. Cette partie présentant l‘entreprise et ses activités nous permettra aussi de bien

comprendre le déroulement du stage qui sera présentera sur le chapitre suivant.

18


apparaître ici.

CHAPITRE2 :

DEROULEMENT DU STAGE

19


apparaître ici.

Chapitre 2. Déroulement du stage

Ce chapitre permettra de décrire en détail la conduite du projet au sein de METIT, les tâches

qui m’ont été affectées, et les différentes phases du déroulement du stage.

1. Description

L’entreprise MedIT utilise ses propres frameworks que ça soit coté client ou coté serveur.

Le service IHM utilise le framework VIOTO basé sur JSP, et SPIRIT nouvellement conçu et qui

est basé sur bootstrap, jquery, html5 et css.

Il était alors nécessaire de commencer le stage par une formation sur spirit et sur le principe

d’utilisation du middleware GOAL.

La formation se déroule en 15 jours et contient des présentations sur l’organisation, sur le

plan de maintenance utilisé par l’entreprise et sur la stratégie des tests suivie par le service,

en plus des travaux pratiques et de la documentation des différents composants du

framework. Un projet de gestion des clients des fonds de commerce m’a été proposé

comme sujet de stage, il était alors nécessaire au cours de la formation de rédiger une

conception pour le projet sous forme de diagrammes à partir d’une spécification envoyée

par les collaborateurs en France.

La conduite de ce projet se basera sur une méthode agile très utilisée (scrum), qui nous

permet d’avoir une meilleure visibilité en impliquant davantage l’utilisateur finale, elle

permet aussi d’assurer une flexibilité en cours du développement de l’application pour plus

de productivité.

Ainsi la conception de chaque module de l’application est développé à part, à travers des

diagrammes de séquence, des cas d’utilisation et des diagrammes de classe, et sera ensuite

validé par l’encadrant, il est aussi nécessaire de proposer une fiche de test unitaire avant de

commencer le développement.

20


apparaître ici.

Reste alors à coder le module en question, un compte rendu quotidien est envoyé à

l’encadrant avant de quitter le locale, ce compte rendu devra contenir le pourcentage

d’avancement du projet, la charge et les exigences restantes, ceci pour tout projet ou

anomalie en dehors du projet de fin d’étude.

Une réunion hebdomadaire est programmée avec le chef de projet et le chef d’équipe.

Scrum nous permettra ainsi à la fin de chaque module d’avoir un produit partiel testé et

utilisable, ce sont des itérations que l’on appelle sprint.

Chaque module terminé est intégrer aux autres, donnant naissance à une nouvelle version

de l’application (release), il est nécessaire dans ce cas de procéder à des tests de non

régression qui nous permettent de vérifier si le module nouvellement intégrer n’a pas

d’influence sur le bon fonctionnement des autres fonctionnalités de l’application.

2. Tâches

Tout projet au sein de MEDIT est développé suivant une méthode agile, ainsi une

spécification de chaque module à part est rédigée en France puis renvoyée vers MEDIT.

Cette spécification sera décrite à travers des diagrammes de séquences et de classes sur la

partie conception du rapport.

Il est nécessaire ensuite de créer un cahier de test, qui dans un premier temps contiendra les

exigences décrites sur la spécification, ce qui permettra au chef de projet de comparer les

exigences sur la spécification avec celles rédigées par le développeur sur le cahier de test

afin de le valider.

Après validation du cahier de test du module, le module en question est codé, pour ensuite

lui appliquer des tests unitaires afin de vérifier son bon fonctionnement et sa concordance

avec la spécification.

21


apparaître ici.

Le module est ensuite intégré, des tests de non régression sont nécessaires afin de vérifier si

l’intégration du module n’aura pas d’effet sur le fonctionnement d’un autre.

Ces étapes sont répétés pour chaque module à part.

Réception de la spécification.

Rédaction du cahier de test (partie exigences).

Validation du cahier de test par le chef de projet (comparaison des exigences du

cahier de test avec ceux de la spécification).

Développement du module.

Mise à jour du cahier de test (partie test unitaire).

Validation des tests par le chef de projet.

Test unitaires.

Intégration.

Test d’intégration et de non régression.

Ce chapitre nous a permis de décrire précisément la conduite d’un projet au sein de MEDIT,

ce qui fait certainement la différence au niveau de la qualité d’un projet par rapport à un

autre, Nous avons expliqué en détail le déroulement du stage, permettant ainsi d’avoir une

meilleure visibilité sur le plan du rapport.

Nous aurons ainsi présenté la conduite utilisée pour notre projet, reste alors à expliquer en

détail cette application de gestion des clients FDC sur le chapitre suivant.

22


apparaître ici.

CHAPITRE 3

CONTEXTE GENERALE DU

PROJET

23


apparaître ici.

Chapitre 3. Contexte Générale Du Projet

Ce chapitre va aborder plus particulièrement l’aspect fonctionnel du projet, il est ainsi

nécessaire dans un premier temps de présenter le contexte général du problème, l’objectif

du projet et le besoin pour lequel on est amené à développer cette application, pour

proposer ensuite une description fonctionnelle qui permettra de lister en détail les

fonctionnalités du projet et finir cette partie sur une planification.

1. Cahier de charge

1.1. Problématique

Face à une concurrence de plus en plus forte, les banques ne cessent d’améliorer la qualité

des biens et services offerts à leurs clients, ainsi l’informatisation doit de nos jours gérer tous

les aspects interne et externe liés au domaine des banques. Et plus que ça, une banque telle

que la bnp se doit de suivre l’avancement technologique du domaine informatique qui va

certainement assurer une meilleures performance, plus de robustesse, et plus de sécurité.

Et c’est dans ce cadre que ce projet de gestion des clients fonds de commerce intervient

pour améliorer la productivité et la qualité des services offerts par la banque.

De nos jours les banques ne cherchent plus à informatiser mais à améliorer les outils de

gestion qu’elle possède et à suivre l’avancement technologique.

1.2. Présentation du besoin

De nos jours l’informatisation de toute activité de l’entreprise est devenue primordiale,

encore plus si cette dernière exige une communication et une interaction entre l’entreprise

et ses différents collaborateurs, que ça soit des particuliers, des professionnels ou des

partenaires.

24


apparaître ici.

Et c’est le cas des fonds de commerce qui font intervenir plusieurs entités de la banque.

Ainsi la gestion de la clientèle des fonds de commerce est nécessaire, ceci de façons à

coordonner les utilisateurs amené à la gérer à travers un outil informatique.

Elle permettra donc d’améliorer la gestion de ces fonds et l’interaction avec les

collaborateurs assurant ainsi une meilleure productivité.

2. Analyse fonctionnelle

Diagramme bête à cornes

Figure 3-3 Diagramme bête à cornes

25


apparaître ici.2.1.1. Besoin fonctionnelle

Authentification.

Gestion du fonds de commerce :

Lister les arborescences (BDDF ou BPF), les entités (chaque

arborescence contient des entités) et les agences (chaque entité

possède plusieurs agences).

Lister les fonds de commerce selon le choix sur l’arborescence

(directions générales, Groupes, Entités, Agences).

Lister les clients du fonds de commerce.

Tri et filtrage des résultats.

Impression des résultats.

Administration

Gestion des utilisateurs (agent bancaire, propriétaire du compte) :

création, suppression.

Gestion des comptes FDC : création, suppression.

Gestion des clients (consultation du dossier client).

Afficher la vue synthèse client, elle contient des informations

générales sur le client.

Afficher la vue identité client, elle expose les informations sur l’identité

de la personne, physique soit elle ou morale, avec son lieu de

naissance ou de création, son statut professionnel etc.

Afficher la vue adresse (les coordonnées professionnelles et

personnelles).

Afficher la vue lien, qui présente les liens commerciaux du client.

26


apparaître ici.

Afficher la vue multicanale qui regroupe l’ensemble des informations

professionnelles du client.

Afficher la vue risque qui concerne la situation financière du client.

Afficher la vue déontologie permettant de visualiser le bilan des

activités antérieures du client.

2.1.2. Besoin non fonctionnelle

Evolutivité : le développement informatique nécessite d’avoir une flexibilité qui

permettra d’adapter l’application aux besoins qui changent au cours du temps, il est

donc impératif de facilité l’ajout et la suppression de fonctionnalité sans que cela ait

des répercutions sur le bon fonctionnement du programme.

Sécurité : l’application doit gérer des informations confidentielles et très

importantes, il alors est nécessaire d’assurer la sécurité et la confidentialité de ces

données.

Performance : l’application est destinée à un très grand nombre d’utilisateurs, ce qui

nécessite des ressources et une rapidité de réponse afin d’assurer son bon

fonctionnement.

3. Etude des solutions :

Cette application de gestion des clients des fonds de commerce est destinés aux

collaborateurs de la banque, il est donc nécessaire qu’elle soit disponible à l’extérieur du

réseau locale de l’entreprise (BnpParibas), ce qui nous mène à développer une application

web.

27


apparaître ici.

Reste alors à choisir une solution adéquate aux spécifiés et à la nature de cette application.

Il faut savoir que bnp MedIT travaille avec plusieurs solutions et dispose de l’environnement

requis pour le bon fonctionnement de ces solutions.

Ainsi le choix devra se faire entre les solutions disponibles sur MedIT comme le PHP, l’ASP,

J2EE (framework vioto) et spirit.

Ce projet de gestion des clients fonds de commerce, est destiné à un très grand nombre de

collaborateurs, ainsi la performance et la sécurité de l’application est un facteur important

pour le choix de la solution.

A ce jour le web s’oriente vers les approches SPA (simple page application) qui permettent

d’avoir des échanges plus léger entre le côté serveur et coté client, et qui est implémentée

sur spirit.

Ce dernier encapsule aussi les appels goal utilisée pour la communication avec l’ordinateur

central, ce qui nous permet de faciliter la communication.

Spirit est un framework JavaScript dont le fonctionnement est très similaire à angularJS,

nous avons ainsi la possibilité de faire plus de traitement coté client, d’alléger le coté serveur

et de sécuriser les échanges qui se feront en https.

Bnp possède aussi des serveurs disponibles, qui peuvent héberger notre application, mais le

choix de l’utilisation du mainframe est plus judicieux vu le très grand nombre d’utilisateurs

pour lesquels cette application est destiné.

Certaines fonctionnalités par contre peuvent être implémentées sur un serveur, nous

utiliserons pour cela des services web java, c’est le cas de l’administration où le nombre

d’utilisateurs est restreints aux administrateurs.

28

Erreur ! Utilisez l'onglet Accueil pour appliquer Heading 1 au texte que vous souhaitez faire apparaître ici.

4. Planification

4.1. Diagramme de Gantt

Figure 3-4 Diagramme de Gantt

Nous avons donc présenté sur ce chapitre les fonctionnalités de l’application coté utilisateur, et le besoin pour lequel elle a été développée.

Ainsi l’étape suivante devra se focaliser sur l’aspect technique du projet, nous devrons aussi détaillée chaque fonctionnalité. Cette étude sera

présentée sur le chapitre suivant.

29


apparaître ici.

CHAPITRE 4

ETUDE DETAILLEE DU PROJET

30


apparaître ici.

Chapitre 4. Etude détaillée du projet

Nous allons décrire dans un premier lieu la solution choisie pour développer cette

application, ce qui nous permettra de présenter l’architecture sur laquelle sera basé le

projet.

Pour ensuite présenter les modules et sous-modules qui le constituent, ces derniers seront

décrits puis associés à un diagramme de classe et de séquence.

Ceci nous permettra de bien assimiler la partie métier et le fonctionnement technique de

l’application.

1. Conception Générale

1.1. Architecture système

31


apparaître ici.

Figure 4-5 Architecture de l'application

Cette application de gestion client est basée sur une architecture client-serveur 3tiers. Elle

est composée d’une couche présentation gérée par le framework front-end spirit, d’une

couche métier constituée d’un serveur d’application et d’un mainframe et d’une couche de

donnée où se trouve le serveur de base de données.

Les appels métiers peuvent se faire soit directement entre les services web et le serveur de

base de données, soit via le middleware GOAL (développée par bnp) dans le cas d’un appel

d’un programme cobol sur l’ordinateur central (mainframe), il se peut aussi qu’un service

web communique avec le mainframe toujours en utilisant GOAL. Les échanges de donnée se

font généralement sous format JSON.

Nous pouvons alors citer trois types d’appels métier :

Communication directe des services web avec la base de données.

Communication des services web avec le mainframe via le middleware goal.

32


apparaître ici. Communication du font-end (tiers client) avec le mainframe (via goal).

1.2. Architecture coté client :

Le framework spirit se base sur le concept d’application SPA (simple page application), où

toute la présentation se fait sur une seule page index.html, et c’est un système de routage

qui s’occupe de faire correspondre chaque url à un template .tpl qui est chargé sur la page

index.

L’échange de pages html entre le serveur web et le navigateur n’est plus nécessaire

(web moderne).

Figure 4-6 Architecture JS Moderne

33


apparaître ici.1.3. Les acteurs

Figure 4-7 Diagramme Acteurs

1.4. Modules de l’application

Afin de faciliter le développement de l’application, il est nécessaire de la découper sur

plusieurs modules, ce qui permettra de traiter chacun de ces modules à part.

A travers une analyse des besoins fonctionnels cités sur le cahier de charge, ce projet de

gestion des clients FC (fonds de commerce) peut être divisé sur plusieurs parties.

Figure 4-8 Modules de l'application

34


apparaître ici.L’application est composée de quatre principaux modules : l’authentification, la consultation

des fonds de commerce, la consultation des clients et l’administration du site.

Authentification :

Il est nécessaire dans un premier lieu d’authentifier l’utilisateur, afin de charger un contexte

contenant les informations générales sur ce dernier, ceci lors de l’initialisation de

l’application, on pourra de ce fait connaitre le type d’utilisateur.

Ainsi un client détenteur d’un fonds de commerce sera directement redirigé vers la

consultation de son fonds.

Un client agent devra lister les fonds de commerce associés à son agence.

L’administrateur aura la possibilité de parcourir l’arborescence BDDF et BPF qui est constitué

de plusieurs entités et d’agences.

Consultation d’un fonds de commerce

Une fois l’utilisateur authentifié et redirigé vers les fonds de commerce qui le concerne, ce

dernier a la possibilité de visualiser l’ensemble des informations concernant ces fonds, il

pourra de ce fait connaitre les propriétaires et les informations les liant aux fonds.

La consultation FDC est divisée sur plusieurs onglet, on retrouve alors les fonds liés aux

clients particulier, ceux liés aux professionnels et d’autre aux entrepreneurs.

Consultation dossier client

Après l’authentification et la consultation FDC, l’utilisateur a la possibilité de visualiser les

informations concernant le propriétaire d’un fonds, ceci sur plusieurs vues.

Ainsi lors du passage d’un onglet à un autre des appels goal sont exécutés afin d’extraire les

informations nécessaires, sur cette partie les appels concernerons un seul composant cobol,

par contre leurs alimentations diffèrent selon la vue sélectionnée.

Administration

Cette partie sera implémentée par des services web java qui accèdent directement à la base

de données. L’administration devra offrir la possibilité de créer, supprimer et modifier des

comptes.

35


apparaître ici.

1.4.1. Consulter fonds de commerce

Figure 4-9 Module Consultation Fonds de Commerce

La consultation de fonds de commerce permettra de lister les clients associés au fonds en

question en plus de certaine informations qui représente un lien entre le propriétaire et le

FDC.

Les résultats peuvent être filtrés et triés, exportés ou imprimés.

1.4.2. Administration

Figure 4-10 Module Administration

1.4.3. Gestion Client

Figure 4-11 Modifier Gestion Client

36


apparaître ici.

1.4.4. Consultation Client

Figure 4-12 Module Consultation Client

Le module consultation lient permettra de visualiser une multitude d’informations réparties

sur des vues :

Vue synthèse : informations générale.

Déontologie : bilan de l’activité du client.

Vue adresse : coordonnées personnelles et professionnelles.

Vue lien : présente les liens commerciaux du client.

Vue risques : présente la situation financière du client.

Vue interlocuteur : liste les interlocuteurs du client, il s’agit des employés du

propriétaire du fonds.

Consultation d’un fonds de commerce :

Après l’initialisation de l’application, un contexte utilisateur est chargé, ce qui nous

permettra de savoir le type d’utilisateur connecté.

S’il s’agit d’un client particulier il est redirigé directement vers le fonds de commerce qu’il

détient.

Par contre s’il s’agit d’un agent, un appel goal est exécuté afin de lister les fonds de

commerce sur lesquels il intervient, dans le cas d’un administrateur ce dernier a la possibilité

de parcourir l’arborescence BDDF (banque de détail France) ou BPF (banque privée), il

pourra ainsi lister les fonds de commerce associé à l’agence choisie.

37


apparaître ici.

2. Conception détaillée

2.1. Module Consultation fonds de commerce

Acteur principal : Client, Agent, Administrateur.

Description : L’utilisateur pourra afficher un FDC, lister ses clients, consulter leurs

informations, imprimer ses résultats, trier et filtrer ses recherches.

Pré conditions : L’utilisateur doit être authentifié.

2.1.1. Cas d’utilisation

38

Utilisateur

Agent

Client Détenteur

FDC

Client BPF

Client BDDF

S’authentifier

Lister Agence

Lister BPF

Lister BDDF<<Include>

>

Filtrer

Résultat

Imprimer

Résultat

Consulter Fond De Commerce

Exporter en

Excel

Chercher Client

Lister Clients

<<Include>

>

<<Include>

><<Include>

> Entrepreneur

Professionnel

Particulier

Use Case

Figure 4-13 Diagramme Cas D'utilisation Du Module Consultation FDC


apparaître ici.

Un utilisateur peut être considérer comme un agent ou un détenteur FDC (l’utilisateur

administrateur n’est pas présent sur ce cas d’utilisation.

Seul un agent à la possibilité de lister les agences, il est donc nécessaire qu’il soit authentifié.

Lors de la consultation du fonds de commerce l’utilisateur peut lister les clients, filtrer le

résultat, l’imprimer et l’exporter, il est aussi possible de visualiser les FDC selon le type de

propriétaire (particulier, professionnel ou entrepreneur).

39


apparaître ici.

2.1.2. Diagramme de séquence : Authentification

40

Utilisateu

r

:

IHMSaisie

Objet1: : :

SaisirID

() EnvoiID ()

:

Système

Loop Chercher

Chercher (String

Résultat:

[While

(ID.Notfound)]

Alt

[If (ID.found)]

[Else

[If (TypeUtilisateur==Agent ||

Alt

[Else

Success (String ID, String

TypeUtilisateur)

SuccessClient (String ID, String

TypeUtilisateur)

Echec ()

Figure 4-14 Diagramme de séquence Authentification


apparaître ici.

Ce cas d’utilisation commence par la détection du poste connecté à l’application, ainsi la

saisie de l’id vue sur le diagramme n’est pas faite par l’utilisateur, elle se fait

automatiquement au lancement de l’application.

Un appel goal est exécuté afin de vérifier si l’identifiant envoyé correspond à un utilisateur

valide, dans le cas contraire un message d’erreur est affiché.

Par contre si l’authentification réussit, il est nécessaire de vérifier le type de l’utilisateur

(agent ou Administrateur) afin d’exécuter un autre appel qui permettra de charger le

contexte contenant les informations de l’utilisateur connecté.

Ce contexte sera ensuite stocké dans une mémoire cache situés sur le serveur web, cela

nous permettra d’éviter de faire des appels répétitives vers l’ordinateur central.

41


apparaître ici.

2.1.3. Diagramme de classe : Authentification

Figure 4-15 Diagramme de classe Authentification

42


apparaître ici.

2.1.4. Diagramme de séquence Consulter Fond De

Commerce

sd DIag.Seq.System

Util isateur IHM :Consulter Fond de commrece

Chercher PVente FDC

SendValue(Entite)

PVenteByEntite(Entite)

List<PVente>()

AfficherPVente(List<Pvente>)

SelectPVente()

SendValue(PVente)

FdcByPVente(PVente)

List<FDC>()

AfficherFDC(List<FDC>)

SelectFDC()

Figure 4-16 Diagramme de séquence Consulter FDC

Dans le cas d’un utilisateur agent ce dernier a la possibilité de sélectionner une entité, une

fois l’arborescence lister.

Une liste de ventes est ainsi restituer selon l’entité choisie, pour ensuite récupérer la liste

des FDC.

43


apparaître ici.Par contre pour un utilisateur détenteur d’un FDC, ce dernier est redirigé directement vers

son fonds de commerce.

2.2. Module Consultation Dossier Clients

Acteur principal : Client, Agent, Administrateur.

Description : L’utilisateur pourra visualiser les informations concernant le client sur

les différentes vues (identité, déontologie, …).

Pré conditions : L’utilisateur doit être authentifié, et doit accéder à un FDC pour

sélectionner le client.

2.2.1. C as D’utilisation

Ce module concerne la consultation des informations clients, qui vont être présentés sur

plusieurs vues.

L’accès à cette écran de consultation nécessite de visualiser dans un premier temps le fonds

de commerce qui lui est associé.

Tous les types d’utilisateurs peuvent accéder au dossier clients.

44

Utilisateur

Afficher Synthèse

Client Afficher Adresses

Affiche Identité

Afficher Lien Client

Afficher Risque

Afficher Déontologie

Lister interlocuteurs

Use Case

Figure 4-17 Diagramme Cas D'utilisation du module Consultation Dossier Client


apparaître ici.

2.2.2. Diagramme de séquence Afficher Synthèse Client sd Diag.Seq.MVC2

Utilisateur IHM GetInfoClient Client Professionnel EntrepreneurParticulier RDVPersonneMorale Dirigeant Dossier

alt

[If Client is Pro]

alt Else

[if Client is Particulier]

alt else

[else if (Client is Entrepreneur)]

alt FIN

[else]

ConsulterDossierClient()

SendIdClient()

Execute()

GetInfoClient() :Professionnel

Return()

GetInfoParticulier() :Particulier

Return()

GetInfoEntrepreneur() :Entrepreneur

return()

GetInfoPM() :PersonneMorale

GetDirigeant() :List<Dirigeants>

return() :l ist<Dirigeant>

return()

GetRDV() :List<RDV>

return()

GetDossier(idUnique)

GetConsultant() :List<Consultant>

return()

AfficherResultat()

Figure 4-18 Diagramme de séquence Afficher Synthèse Client

45


apparaître ici.

En accédant au dossier client, l’utilisateur renvoi l’identifiant client et recevra comme

réponse les informations concernant le client en question.

Nous pourrons dans ce cas vérifier le type de client afin de déclencher l’action

correspondante.

Si le client est particulier, professionnel ou entrepreneur, une fonction retournant la

synthèse du client en question est appelée, si par contre il s’agit d’une personne morale

(entreprise ou association), il est nécessaire extraire les informations concernant son

dirigeant.

46


apparaître ici.

2.3. Module Gestion Clients

Acteur principal : Administrateur.

Description : L’utilisateur pourra gérer les établissements, les dirigeants, les

interlocuteurs et les clients.

Pré conditions : L’utilisateur doit être authentifié, et doit un administrateur.

2.3.1. C as d’utilisation

Ce module s’occupe de la création et la modification :

Des établissements qui possèdent un fonds de commerce de la banque.

Les dirigeants d’établissement et d’agence.

Les interlocuteurs communiquant à la place des propriétaires des fonds de

commerce.

Les clients physique ou morale.

L’accès à ce module nécessite de passer par la consultation client.

47

Agent Bancaire

Gérer Etablissemen

t

Gérer Dirigeant

Gérer Interlocuteurs

Gérer Client

Gestion

Créer

Modifier

<<Extend>>

<<Extend>>

<<Extend>>

<<Extend>>

Figure 4-19 Diagramme Cas D'utilisation du module Gestion Clients


apparaître ici.

2.4. Module Administration

Acteur principal : Administrateur.

Description : L’administrateur pourra créer et supprimer des utilisateurs et des fonds

de commerce.

Pré conditions : L’utilisateur doit être un administrateur.

2.4.1. C as d’utilisation

48

Gestion

Utilisateur

Gérer compte

Créer

Utilisateur

Modifier

UtilisateurSupprimer

Utilisateur

Créer

Compte

Supprimer

Compte

Mettre Client En Relation

<<Extend

>><<Extend

>><<Extend

>>

<<Extend

>>

<<Extend

>><<Extend

>>

Use Case

Administrate

ur

Figure 4-20 Diagramme cas D'utilisation Du module Administration


apparaître ici.

2.4.2. Diagramme de séquence Gérer Compte (créer

compte)

sd Diag.Seq.MVC2

Admin AjoutForm CreerCompteFDC-Event FDC ClientDetenteur Agent

RemplirForm()

SendData(idClient, FDC)

AjouterFDC(FDC)

GetClient() :ClientDetenteur

retour() :ClientDetenteur

LierFDC()

LierAgent(idFDC)

AddFDC(idFDC)IsDone() :Boolean

Figure 4-21 Diagramme de séquence Créer Compte

La création d’un compte nécessite dans un premier temps d’ajouter un fonds de commerce,

de rechercher un client, puis de le lier au FDC créé.

Il est aussi nécessaire d’ajouter une liaison agent-client.

Pour ensuite faire correspondre l’agent précédent au FDC qu’on vient de créer.

49


apparaître ici.

2.4.3. Diagramme de classe Créer Compte

Figure 4-22 Diagramme de classe Créer Compte

50


apparaître ici.

2.4.4. Diagramme de séquence Gérer Compte (supprimer

compte)

51


apparaître ici.sd

AgentBancaire IHM:Suppression SypprimerCompte-Event FDC ListClient DossierAgent Adresse Liens DeleteFromAgency CLientDetenteur

loop

[foreach(client in ListClient)]

alt

[if(ClientNotInOther)]

alt

[if (Suppression Confirme)]

[else]

SelectFDC()

EnvoieDonnee(form)

DemandeConfirmation()

Reponse()

chercherFDC() :FDC

retour()

SetAgent(null)

SupprimerClient()

SupprimerDossier(idClient)

SupprimerAdresse(idClient)

SupprimerLien(idClient)

retournSucces()

DeleteFromList(idFDC)

DeleteFDCFromList(idFDC)

SuppressionConfirme()

RetourSansSuppression()

Figure 4-23 Diagramme de séquence Supprimer Compte

Sélection du fonds de commerce à supprimer.

Demander une confirmation.

52


apparaître ici. Validation de la confirmation.

Recherche du FDC.

Annuler la liaison de l’agent associé au fonds.

Vérifier si le client propriétaire du FDC possède d’autre fonds ceci en le comparant à

la liste des clients qu’il faudra extraire.

Si non supprimer le client, l’adresse, l’identité et le lien.

Suppression du fonds de commerce.

53


apparaître ici.2.4.5. Diagramme de classe Supprimer compte

uc temp

Diag.Class.Conception::Client

- idtUnique: int- idtRelationCommercial: int- RDVs: List<RDV>- nom: String- initial: String- adressesClient: List<Adresse>

+ GetClientInfo() : Object+ getidentifiantUtil isateur() : String+ getidtUnique() : int+ GetLienClient() : Lien+ setidtUnique(int) : void+ getidentifiantSiegeUtil isateur() : int+ getidtRelationCommercial() : int+ SetSynthese() : void+ SetIdentite() : void+ setidtRelationCommercial(int) : void+ getDossierClient() : void+ isAuthorised() : boolean+ SetRisque() : void+ getRDVs() : List<RDV>+ SetRelation() : void+ setRDVs(List<RDV>) : void+ getadressesClient() : List<Adresse>+ setadressesClient(List<Adresse>) : void

Diag.Class.Conception::ListClient

- ListClient: List<Client>- idFDC: String

+ getListClient() : List<Client>[]+ setListClient(List<Client>) : void

Diag.Class.Conception::Agence

- l ibelleAgence: String- codeAgence: int- ListFdcBddf: List<FDC>

+ chargerFDC() : void+ afficherFDC() : void

Diag.Class.Conception::FDC

- identifiantFDC: String- nomAgent: String- prenomAgent: String- ListClient: List<Client>

+ chargerClient() : void+ afficherClient() : void

Diag.Class.Conception::Dossier

- idDossier: String- idUnique: int

+ GetClientInfo() : Object+ GetLienClient() : Lien+ SetSynthese() : void+ SetIdentite() : void+ SetRisque() : void+ SetRelation() : void

Diag.Class.Conception::Lien

- idLien: String- idTitulaire: int- clientLiee: List<Liaison>

+ getclientLiee() : List<Liaison>+ setclientLiee(List<Liaison>) : void+ getidLien() : String+ setidLien(String) : void+ getidTitulaire() : int+ setidTitulaire(int) : void

Diag.Class.Conception::Adresse

- idClient: String- nomPrenom: String- typeAdresse: int- adr: String- changementResidenceDate: Date

+ getadr() : String+ setadr(String) : void+ getidClient() : String+ setidClient(String) : void+ getnomPrenom() : String+ setnomPrenom(String) : void+ gettypeAdresse() : int+ settypeAdresse(int) : void+ getchangementResidenceDate() : Date+ setchangementResidenceDate(Date) : void

Util isateur

Diag.Class.Conception::ClientDetenteur

- idClientDetenteur: String- FDCommerce: List<FDC>

+ GetClientInfo() : Object+ getidentifiantUtil isateur() : String+ getidentifiantSiegeUtil isateur() : int+ getidtUnique() : int+ GetLienClient() : Lien+ setidtUnique(int) : void+ getidentifiantSiegeUtil isateur() : int+ getidtRelationCommercial() : int+ SetSynthese() : void+ SetIdentite() : void+ setidtRelationCommercial(int) : void+ getDossierClient() : void+ isAuthorised() : boolean+ SetRisque() : void+ getRDVs() : List<RDV>+ SetRelation() : void+ setRDVs(List<RDV>) : void+ getadressesClient() : List<Adresse>+ setadressesClient(List<Adresse>) : void

Util isateur

Diag.Class.Conception::Agent

- idAgent: String- nomAgent: String- prenomAgent: String- nomAbregeAgent: String

+ getidAgent() : String+ getidentifiantUtil isateur() : String+ setidAgent(String) : void+ getidentifiantSiegeUtil isateur() : int+ getnomAgent() : String+ setnomAgent(String) : void+ getprenomAgent() : String+ isAuthorised() : boolean+ setprenomAgent(String) : void+ getnomAbregeAgent() : String+ setnomAbregeAgent(String) : void

0..1 1..*

1

1

1..* 1..*

1

1

11

1..*

1

1..* 1..*

1

Affecter

1..*

Figure 4-24 Diagramme de classe Supprimer Compte

Cette partie nous a permis d’expliquer en détail les fonctionnalités du projet, et

l’architecture sur laquelle se base l’application. Reste alors à fournir un bilan sur le travail

réalisé et de présenter des perspectives pour l’application, cette dernière sera livrée avec

plusieurs documents qui lui sont associés.

54


apparaître ici.

CHAPITRE 5

REALISATION

55


apparaître ici.

Chapitre 5. Réalisation

Ce chapitre va aborder les principales étapes de réalisation du projet, les outils de

développement utilisés et le plan de maintenance qui sera appliqué sur le projet, en plus des

scénarios de test effectués sur les modules de l’application.

1. Outils de développement

1.1. Eclipse/WebSphere

WebSphere est une marque du groupe IBM. Le nom de WebSphere renvoie généralement à

la plate-forme applicative "WebSphere Application Server" (WAS).

Elle couvre un ensemble de solutions d’IBM qui permettent de développer, déployer et

d'utiliser des applications d'entreprise, même dans des cas complexes faisant appel à des

applications et des matériaux hétérogènes.

Parmi les gammes de WebSphere, on citera les éléments suivants :

Une gamme de serveurs d'application basés sur J2EE et EJB : WebSphere Application

Server.

WebSphere Portal : une gamme d'outils permettant de développer et de maintenir un

portail d'entreprise, tout en permettant, le cas échéant, d'y inclure des applications utilisées

par celle-ci, au moyen de diverses interfaces et autres solutions d'intégration.

WebSphere Commerce, solution destinée à permettre le commerce via le Web.

Chacune des gammes proposées ci-dessus comporte à chaque fois plusieurs variantes

adaptées selon la complexité des besoins et la taille de l'entreprise.

Sur notre projet le serveur WebSphere et l’IDE Eclipse seront tous les deux utilisés lors du

développement des services web java.

56


apparaître ici.

1.2. Web Storm

A l’exception des services web qui implémenterons le module administration, les autres

modules utiliserons des appels goal depuis le local (tiers client), ainsi l’ide utilisé sera

webStorm, il sera aussi associé à grunt afin d’automatiser certaines tâches comme la

concaténation (regrouper tous les fichiers JavaScript sur un même fichier nom_projet.js),

l’offuscation ou minification (c’est un procédé par lequel le code devient impénétrable, non

interprétable par un humain mais qui peut être compilée ou interpréter par une machine).

WebStorm sera aussi associé à JSHint qui permettra de contoller le code avant de procéder

au build, ce control peut concerner la déclaration de variable inutilisable, l’utilisation de

boucle vide, d’un id dupliquée coté html, etc.

57


apparaître ici.

1.3. Mainframe/cobol

C’est l’ordinateur central qui contient les composants cobol utilisée sur notre application, la

communication se fera avec le middleware goal en utilisant json comme format d’échange.

Un code ims se référant à la transaction et un autre code (mnémonique) correspondant à

l’opération à lancer devront être communiqué lors de l’envoi de la requête.

L’utilisation de cet ordinateur central peut être justifiée par le grand nombre de clients qui

nécessite l’utilisation d’une centaine de serveurs à administrer, et qui devront assurer

l’intégrité et la confidentialité des données, il est alors plus judicieux d’utiliser un mainframe.

Le système d’exploitation utilisé sur cet ordinateur est un système 64bit appelé Z/OS.

1.4. Spirit :

C’est un framework front-end développée par bnp, basé sur le concept SPA, il possède un

système de routage lui permettant de faire correspondre chaque url à un template et un

traitement donné, il est aussi composé de composant UI prédéfinis qui facilite

considérablement le développement des interfaces (UITable, AutoComplete, UIError,

UIForm, Validator,…), et de certains composants bancaires.

58

Figure 5-25 Framework Spirit


apparaître ici.

L’implémentation de spirit possède de plus une servlet java qui permet de simplifier les

appels en utilisant le middleware goal, c’est sur cette partie que se trouve les stubs (fichier

de description des appels goal).

1.4.1. Architecture spirit

Figure 5-26 Architecture Coté Client (architecture spirit)

L’architecture de Spirit est composée d’un serveur web qui contient des ressources

applicatives nécessaire pour le bon fonctionnement du framework front-end spirit (les

librairies spirit.js, spirit.css, bootstrap et jquery), et d’une zone mémoire réservée au

contexte utilisateur, qui est généralement utilisé sur la majorité des applications

développées chez MedIT, ainsi pour éviter des appels GOAL répétitives il est plus judicieux

de charger le contexte à partir d’une mémoire cache.

Les appels métier sont aussi implémentés sur spirit, ceci sur une servlet qui facilite la

communication avec les services web et l’ordinateur central, cette dernière contient aussi

des fichiers de configuration nécessaires à spirit.

59


apparaître ici.

1.5. Goal

Chaque jour des millions de transactions de clients sont effectués à travers le monde, que ça

soit des dépôts, des virements ou autre, l’utilisation de serveurs pour une banque est

devenue inconcevable, puisque cela nécessite une centaine de serveurs qui doivent être

administré et maintenue, ainsi la plupart des banques utilise des mainframes qui malgré

leurs prix, cela permet de faire des économies.

Un mainframe est un ordinateur central puissant qui centralise les données et les

traitements d’un système d’information. C’est une ancienne architecture où le client qui

pouvait communiqué avec le mainframe n’était qu’un simple terminal.

Le principe de fonctionnement des applications transactionnelles se base sur ce qui suit :

Lorsqu’un utilisateur envoie une requête au serveur (central), ce dernier alloue des

ressources (mémoires, programme de traitement, CPU …) pour traiter cette demande et

renvoie la réponse à l’utilisateur. A l’origine, les utilisateurs se connectaient directement au

central via des terminaux passifs, il n’y avait donc pas de problèmes de compréhension entre

le central et le terminal.

Cependant, les progrès de la bureautique ont progressivement amené les entreprises à

changer leurs terminaux pour des PC. Ceci a pour conséquence de rompre le lien direct entre

la machine central et l’utilisateur.

Afin de résoudre ce problème BNP Paribas a développé le middleware GOAL afin d’établir

une communication entre les ordinateurs et le mainframe, permettant ainsi de développer

et exécuter des traitements de type client/serveur.

60


apparaître ici.

Figure 5-27 Middleware Goal

1.6. Web Service Java

Certains composants applicatifs du projet sont déjà utilisés sur d’autres applications et sont

par conséquent déjà développés sur le mainframe, c’est le cas de certaines fonctionnalités

concernant les clients fonds de commerce.

Sur cette partie, les services web java concernant les fonctionnalités d’administration, ces

services web peuvent à leur tour faire des appels goal afin de communiquer avec

l’ordinateur central.

Vu que le projet est une application web, il est plus judicieux d’utiliser le format d’échange

JSON pour plus de rapidité et de performance, ainsi les services à développer se basant sur

l’architecture REST.

Afin de sécuriser les échanges, il est nécessaire d’utiliser le protocole https.

Le support des services rest sur java se fait via la spécification JSR (JAVA SPECIFICATION

REQUEST) et qui sera implémenter par JERSEY.

Nous utiliserons l’API JAX-RS qui facilitera le développement de ce genre de service.

61


apparaître ici.

2. Résultat et interprétation

2.1. Consultation du fonds de commerce

Cette transaction permet au titulaire d’un fonds de commerce ou aux collaborateurs

bancaires de la BNP Paribas de consulter un Fond De Commerce et de lister les clients qui

sont en relation direct avec ce même FDC.

2.1.1. Etape de sélection du fonds de commerce

Cette étape représente le point d’entrée de la transaction, elle permet de choisir le fonds de

commerce qu’on désire consulter, tout en notant que deux types de FDC sont disponibles,

BDDF (Banque De Détail de France) et Compte BPF (Banque Privée de France).

Pour un titulaire de fonds de commerce, il est dirigé vers son propre compte directement et

ne peut avoir accès aux autres.

L’agent BNP a le droit sur tous les fonds de commerce qui lui sont attribués dans son agence.

Quant à l’administrateur de l’application, il doit passer par une arborescence développant la

direction régionale, le groupe, l’entité puis l’agence.

L’ajout et la modification se fait dans une fenêtre indépendante et qui s’ouvre suite au clic

sur le bouton correspondant.

Figure 5-28 Ecran de Choix du type d'arborescence

62


apparaître ici.

Ci-dessous la vue de l’écran d’identification pour un administrateur BDDF :

Figure 5-29 Ecran de choix pour Administrateur BPF

Nous pouvons initier le passage à la fenêtre consultation des clients du FDC en cliquant sur le

bouton suivant.

Au clic sur le bouton arrêter, l’utilisateur est délogé et la transaction est stoppée.

2.1.2. Etape Consultation Fonds de commerce

Dès que le FDC est choisi, l’utilisateur est ré acheminé vers un écran lui montrant les clients

du FDC sélectionné, triés par type de clients (Entrepreneur, Professionnel, Particulier) avec

son nom, identifiant et collaborateur affilié en haut de page.

Vu le nombre important de clients et leurs informations et pour ne pas encombrer l’écran,

les détails de chaque client sont affichés dans trois vues différentes.

63


apparaître ici.

Figure 5-30 Ecran Consultation Client Particulier

Au clic sur le lien de l’onglet Professionnels, l’écran affiche l’ensemble des clients de ce

même type.

Figure 5-31 Ecran Consultation Client Professionnels

64


apparaître ici.

En cliquant sur l’onglet Entrepreneurs, l’écran affiche les informations des clients de ce

même type.

Figure 5-32 Ecran Consultation Client Entrepreneur

Les clients sont affichés à raison de 100 par écran, ce pourquoi les boutons suivant et

précédent permettent de naviguer entre tous les clients récupérés.

Le bouton radio permet de sélectionner un client, pour pouvoir accéder à son dossier en

cliquant sur le lien « Accéder Dossier Client », ceci lance une nouvelle transaction qui sera

développée et présentée dans la suite du rapport.

Le bouton Exporter permet de réaliser un export en format Excel, pour garder l’anonymat

des clients, les données sont envoyées en masquant le nom et raison social et sont

remplacées par un identifiant personne.

65


apparaître ici.

Figure 5-33 Export CSV

2.2. Dossier Client

Le dossier client permet de consulter de manière plus approfondie les informations du client

sélectionné à partir du fonds de commerce.

Il offre une visibilité sur les informations privées et professionnelles du client ainsi que ses

contrats, ses activités transactionnelles …etc.

Il permet de gérer le compte d’un client BNP, lui proposer des contrats, lui vendre des

services, mais il sert aussi à faire un suivi plus efficace de son compte et seuls les agents de

BNP Paribas peuvent naviguer entre les différents modules de ce dossier.

Dans ce projet, on se focalisera sur le module informations comme étant le seul module

permis à être visionné par les utilisateurs qui ne sont pas collaborateurs BNP.

66


apparaître ici.

Figure 5-34 Description Graphique de l'onglet Information

2.2.1. Etape accès au dossier client

Cette étape est le point d’entrée de la transaction Accéder Dossier Client. Après avoir choisi

un client dans le FDC et lancer la transaction, un écran de synthèse s’affiche pour lancer le

dossier client.

Appartenant au module informations, la vue synthèse vient s’ajouter à six autres vues qui

traite et affiche des informations de types différents.

Il existe différentes mises en page selon le type client :

Personne Physique

Personne Morale Entreprise

Personne Morale Association

La synthèse est la première vue que l’utilisateur rencontre à l’entrée du dossier, lui

permettant d’avoir des informations générales sur le client interrogé.

67


apparaître ici.

Figure 5-35 Ecran Synthèse Dossier Client Personne Morale

2.2.2. Ecran Déontologie

La vue Déontologie permet de faire un bilan sur les activités antérieures du client et de

dresser un bilan sur ces comportements de point de vue déontologique et de crédibilité.

Figure 5-36 Ecran Déontologie Dossier Client

La transaction Créer compte rendu permet de faire un commentaire sur l’état

déontologique du client.

La transaction Gérer Client rapprochés permet d’afficher la vue LIENS pour voir les relations

transactionnelles du client.

68


apparaître ici.

3. Plan de maintenance corrective

Le plan de maintenance de ce projet de gestion des clients FDC va suivre le même plan de

maintenance sur lequel l’entreprise se base pour la majorité de ses projets.

Les demandes de maintenance proviennent des collaborateurs en France quel que soit leur

type (correctif ou évolutif), ces demandes sont reçues par les chefs de projet (CP).

Généralement la déclaration des anomalies (maintenance corrective) se fait sur une

application de gestion d’anomalie (jira) qui permet de faire le suivie.

Le collaborateur en France doit transmettre le code de transaction (afin d’identifier

l’application) en plus d’une ou de plusieurs captures d’écran montrant l’anomalie (sur l’app

de suivi jira) et du degré de priorité, le chef de projet doit alors affecter cette tâches à un des

développeurs de son équipe tout en estimant une charge (durée de résolution), dans le cas

où l’anomalie ne provient pas du local, le développeur peut dans ce cas ajouter un

commentaire informant l’ensemble des collaborateurs concernés par l’anomalie (en France

et au Maroc) toujours sur jira, tous en spécifiant sur l’étape de progression que l’anomalie

n’a pas pu être reproduite (résolue).

Figure 5-37 Maintenance Corrective

69


apparaître ici.

Nous aurons ainsi présenté les différentes parties de notre application et les démarches

choisies pour le développement de ce projet.

Le besoin pour lequel cette application est développée a certainement été satisfait.

Reste alors à définir des perspectives qui peuvent être envisageable pour suivre l’évolution

et le changement que ça soit au niveau des besoins ou du domaine informatique.

70


apparaître ici.

Conclusion générale

Durant ce stage, nous avons été amenés à réaliser un projet de fin d’études au sein de la

BNP Paribas Méditerranée IT, ce qui nous a permis de plonger au cœur de la réalité du

monde informatique bancaire, et de nous évoluer au métier.

Néanmoins, la conception et l’élaboration de notre projet n’ont pas été sans contraintes,

d’une part la complexité du système bancaire, la volumétrie des données à considérer, ainsi

que la spécificité de la terminologie utilisée, ont accentué la difficulté des traitements que

nous avons eu à effectuer.

D’autre part, l’utilisation de nouveaux outils, aussi bien SPIRIT, GOAL ou WebSphere, que

le respect des normes et des procédures, imposées par le Groupe BNP Paribas nous ont initié

aux exigences du monde professionnel et au travail au sein d’une structure formelle.

Toutefois, nous estimons que les objectifs visés par notre stage de fin d’études qui

consistaient en la participation à la rationalisation de l’utilisation des informations des Client

Fonds De Commerce, ont été atteints.

Après avoir clarifier et analyser le besoin sur la partie cahier de charge, à travers un

diagramme bête à cornes et une classification des besoins fonctionnelles et non fonctionnelles,

on était amenés à décrire l’architecture sur laquelle se basera l’application, les outils et les

technologies qui seront utilisés, pour ensuite passer à la conception détaillée, qui explique

plus en détail le fonctionnement de chaque module à part à travers un cas d’utilisation, un

diagramme de classe et autre de séquence.

Un prototype de chaque module de l’application avec des jeux de données simulés a été

ensuite présenté lors des réunions programmé avec le chef de projet, ce qui a permis d’avoir

des résultats à interpréter sur la partie réalisation du rapport.

Il était ensuite nécessaire d’implémenter les appels goal et de développer les services web

nécessaires.

Des tests unitaires sont appliqués sur chaque composant à part.

71


apparaître ici.

Nous avons ainsi pu développer cette application de gestions des clients fonds de commerce

qui satisfait certainement le besoin de la banque Bnp Paribas, toute fois des projets de ce

genre nécessite d’être très prudent et exigeant sur la sécurité de l’application et sur les

scénarios d’utilisation de cette dernière, ainsi on n’est pas à l’abri d’anomalie qui devront

être gérés en suivant le plan de maintenance de Bnp MEDIT.

Ce large domaine lié au métier des banques ne cesse d’évoluer, ainsi comme perspective,

cette application de gestion des clients fonds de commerce devra s’adapter au besoin

changeant de la banque.

Pour conclure, notre période de réalisation de ce projet ainsi que la formation que nous

avons suivie au sein de la société ont été très instructives, tant au niveau professionnel que

relationnel, elles nous ont permis, en effet, de renforcer nos connaissances par la pratique et

d’en acquérir de nouvelles.

En outre, nos relations professionnelles ont été enrichies, en appréhendant au quotidien

autre chose que la structure organisée du monde du travail, en nous intégrant à une équipe,

et en participant activement, à toute la partie informelle de ce monde.

72


apparaître ici.

Bibliographie et Webographie

[1] Cahier de charge disponible sur l'intranet

[2] Document de spécification disponible sur l'intranet

[3] Document Plan de maintenance disponible sur Intranet.

[4] Document Stratégie de test disponible sur Intranet.

[5] Documents de formation spirit disponible sur Intranet.

[6] Banque de détail Récupéré sur lesechos:

http://www.lesechos.fr/finance-marches/vernimmen/definition_banque-de-detail.html

[7] lesechos Disponible sur l'adresser: http://www.lesechos.fr/finance-marches/vernimmen/definition_banque-privee.html

[8] Les cles de la banque disponible sur http://www.lesclesdelabanque.com/Web/Cdb/Entrepreneurs/Content.nsf/DocumentsByIDWeb/7KMGKP?OpenDocument#contener[9] Document Organisation disponible sur Extranet: b2e.echonet

[10] Présentation Spirit, GOAL disponible sur Intranet.

[11] REST WEB SERVICE Vogella disponible à l'adresse: http://www.vogella.com/tutorials/REST/article.html

73


apparaître ici.

Glossaire

FDC (fonds de commerce) : ensemble des éléments corporels et incorporels liés à la vente

d’un bien ou d’un service, la principale caractéristique d’un FDC est sa clientèle.

BPF : banque privée de France, elle offre des services financiers aux particuliers avec un

patrimoine net important.

BDDF : Banque de détail de France, elle offre des services tels que la collecte des dépôts, les

crédits,… à des particuliers ou à des PME.

Déontologie client : bilan des activités antérieur d’un client.

Typologie client : personne morale ou physique.

CMM : Capability Maturity Model.

Person moral : une construction juridique qui peut être titulaire d’un fonds de commerce,

elle est généralement constituée par un regroupement de personnes physiques ou morales

qui souhaitent accomplir quelque chose en commun.

74


apparaître ici.

Résumé

Face à la complexité des systèmes d’information des établissements bancaires, et à une

concurrence accrue, les enjeux à venir pour ces derniers s’inscrivent sous le signe de

l’innovation. Dans cette optique, la BNP Paribas a mis en place des offres télématiques et par

la suite de nouveaux concepts ce qui a sollicité une étude permettant de donner à différents

niveaux de prise de décision les moyens pour déterminer et analyser les éléments qui

contribuent à leurs activités. Et de là, l’application « Gestion des Clients Fond De

Commerce » a vu le jour pour matérialiser cette stratégie de façon à gérer la relation entre le

client et le fonds de commerce auquel il est affilié.

Ainsi ce Projet de Fin d’Etude a pour objectif de concevoir et de réaliser une application

bancaire « Gérer FDC » permettant :

- La consultation des FDC ayant un compte à la BNP PARIBAS.

- L’obtention des états de synthèse des FDC.

- Le traitement des activités d’Achats ou de Ventes avec les clients.

- La centralisation des données ce qui facilitera les suivis des transactions.

- La génération de plusieurs états de sortie bancaires.

Après avoir présenté l’entreprise d’accueil, ses activités et le service sur lequel s’est déroulé

ce stage de fin d’étude. On a été amené à décrire le besoin, et lui appliquer une analyse

fonctionnelle. Pour ensuite présenter l’architecture sur laquelle se base le projet, en plus des

technologies et outils utilisées.

La conduite de ce projet a suivi une méthode agile, ainsi chaque module de l’application est

présenté à part, et possède sa propre conception détaillée et une phase de réalisation, à

75


apparaître ici.travers des diagrammes uml et des captures de certains écrans de l’application qui sont

interpréter et expliquer.

Abstract

During this internship in MedIT, we learnt a lot of things about banking. BnpParibas have

several entities all over the world, and to improve its yield in certain entities, they needed to

have technology watch, that way they can increase the performance of their applications

and improve their management system.

The purpose of this internship was to develop a project for client's management, we chose

for that an agile software development methodology called scrum, where we had to

implement the design-build for each separate module.

The application gathers three modules: the first one deals with the consulting goodwill's

information, the second one with the account's administration and the last one with the

consulting client's information.

First we exposed the organization's structure, then we described the activities I had to

accomplish in MedIT

We proceeded then to a study of the tender specifications, where we listed functional and

nonfunctional needs, we also presented a planning on Gantt graph.

The conception part consist on an explanation of the project and framework architecture,

and describe each functionality on a use case, sequence and class diagrams.

Finally we presented each interface (screens) with a description part, exposed the

maintenance plan and the tools we used.

76