Mise en oeuvre d'une solution de gestion centralisée de la fiche signalétique client (FSC)

Université Abdelmalek Essaadi
Faculté des Sciences

Projet de Fin d'Etudes

Pour l'Obtention du Diplôme

Master Spécialisé

Option : Qualité Logiciel

Sujet

MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA
FICHE SIGNALETIQUE CLIENT (FSC)

POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC

Réalisé par : M. Abdelkarim Aziz	Sous la direction de : M. Mostapha Bouterfass(Atlashore) M. Mohammed Hilout (Atlashore) M. Mohammed Khaldi (FST)

Année Universitaire

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

Fiche de Stage

Nom de l''Entreprise :

Atlashore

Adresse :

332, N°23, Bd Roudani, Casablanca

Responsable de stage :

Mostapha Bouterfass (Directeur Technique)

Date de Stage :

Du 1 mars 2010 au 30 juin 2010

Résumé de stage :

Mise en oeuvre d'une solution de gestion centralisée de la fiche signalétique client (FSC) pour le compte de crédit agricole du Maroc.

Mot Clé :

Struts, Hibernate, Spring, Acegi Security, Oracle 10g, WebSphere 6.0

Travail effectué:



Développement et 0ptimisation d'un Batch.

Génération d'une partie de la couche Hibernate, Spring et Struts avec JAG. Développement et intégration des différents écrans du projet.

Fiabilisation des Clients.

Gestion des Habilitation. Motivations de stage :



J'ai été affecté tout au long de mon stage à une équipe d'ingénieurs expérimentés en développement JEE.

Projet professionnel à mettre en place.

Riche panel de technologies.

Contact direct avec le client (Déplacement au siège central du Crédit Agricole). Réunions.

Equipe très accueillant.

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

Remerciement

Je tiens tout d'abord à remercier Mr Samir SALEK Directeur Général d'AtlaShore et Mr Mustapha BOUTERFASS Directeur Technique de m'avoir accueilli dans son entreprise.

J'exprime aussi mes sincères remerciements à Mohammed HILOUT Chef de projet, ainsi qu'à toute l'équipe AtlaShore pour leur disponibilité et leur collaboration à la réalisation de ce travail.

J'exprime également toute ma gratitude à mon encadrant pédagogique Mr Mohammed KHALDI qui a accepté d'encadrer ce travail.

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

Abréviation

Abréviation		Désignation
CAM		Crédit Agricole du Maroc
h FSC		Fiche Signalétique Client
PP		Personne Physique
PM		Personne Morale
AIA		Application Agence
CSP		Catégorie socio-professionnelle
RC		Registre de Commerce
FS		Fiche Signalétique
JDBC		Java Database Connectivity
WPS		Websphere Portal Server
J2EE		Java 2 Enterprise Edition
UML		Unified Modeling Language
SGBD		Système de Gestion de Base de Données
API		Application Programming Interface
XML		eXtensible Markup Language
JSP		JavaServer Pages
MVC		Model View Controller
EJB		Enterprise JavaBeans
SQL		Structured query language
CVS		Concurrent Versions System
MAJ		Mise A Jour
RADEEJ		Régie Autonome Distribution d'Eau & Eléctricité d'El Jadida
SODEP		Société d'Exploitation des Ports
BCP		Banque Centrale Populaire
AIX		Advanced Interactive eXecutive
WCS		Workplace Collaboration Service
WSE		Workplace Service Express
AOP		Aspect-Oriented Programming
IoC		Inversion of Control
HTTP		HyperText Transfer Protocol
POJO		Plain Old Java Object
RMI		Remote Method Invocation
ORM		Object-relational mapping
HQL		Hibernate Query Language
SVN		Subversion
CVS		Concurrent Versions System
SI		Système d'information
	« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»		MEMOIRE DE FIN D'ETUDE

Liste des figures

Figure 1 : Architecture 3tiers ....8 Figure 2 : Diagramme de contexte de projet 10 Figure 3 : Cycle en V plus on descend et plus on s'intéresse aux détails du projet.13
Figure 4 : Architecture matérielle du CAM .14
Figure 5 : Planning du projet FSC		.16
Figure 6 : Diagramme de la phase avant vente		.17
Figure 7 : Question/Réponse		18
Figure 8 : schéma de la phase de recette		..19
Figure 9 : Planning de stage		22
Figure 10 : choisir votre base de données		23
Figure 11 : Propriétés de la base de données		..24
Figure 12 : interface d'accueil de JAG		..25
Figure 12 .1 : Page 404		.27
Figure 13 : écran Alert Figure 14 : Diagramme de cas d'utilisation backoffice et chargé clientèle Figure 15 : Diagramme de cas d'utilisation Affectation Client Groupe Figure 16 : Diagramme de séquence Authentification Figure 17 : Diagramme de séquence gestion des habilitations				.28 32 32 33 ...35
Figure 18 : Diagramme de séquence gestion client groupe				36
Figure 19 : Diagramme de séquence archiver client				..37
Figure 20 : Diagramme de classe du système				38
Figure 21 : Découpage logique utilisé				42
Figure 22 : page d'authentification				44
Figure 23 : page accueil				..44
Figure 24 : page identité client				..45
Figure 25 : insérer la date délivrance				46
Figure Incohérence : incohérence des champs				..46
Figure 26 : Informations personnelles .				..46
Figure 27 : informations Banques				.47
Figure 28 : Information Logement				.47
Figure 29 : informations adresse Principale				.48
Figure 30 : informations adresse Courrier				48
Figure 31 : informations contact				49
Figure32 : Exploitation Agricole				49
Figure 33 : page Traitement				50
Figure 34 : Clients à fiabilisés				51
Figure 35 : Schéma du Framework Struts				57
Figure 36 : Architecture du Framework Spring				..60
Figure 37 : Architecture du Framework Hibernate				61
	« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»		MEMOIRE DE FIN D'ETUDE

Liste des Tableaux

Tableau 1 : Matrice de définition des profils d'utilisateurs ..27

Tableau 2 : Description Des cas d'utilisation ..33

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

Table des matières

Fiche de Stage

Remerciement

Abréviation

Introduction

Chapitre 1 Présentation du l'organisme d'acueil 1. Presentation Atlashore 1.1. Description générale 1.2 Solutions Atlashore			1 2 21 3
Chapitre 2 présentation de Stage, contexte génerale du projet			4
1 Le stage			5
1.1 Thème de stage			5
1.2 Objectifs de stage			6
2 Le Projet			6
2.1 Contexte de projet			6
2.2 Objectifs de projet			8
2.3 Résultat & Produit Attendus			9
2.4 Description des besoins			10
2.4.1 Diagramme de contexte			10
2.4.2 Fonctionnalités demandées			10
2.5 gestion de projet			12
2.6 Aspect Technologique			13
2.6.1 architecture fonctionnelle du SI du CAM			13
2.6.2 Architecture technique du SI du CAM			14
2.6.3 Outils de développement			15
2.7 Planning du projet			15
2.7.1 La phase d'appel d'offre			16
2.7.2 La phase d'étude			18
2.7.3 La phase de réalisation			19
Master QL			Page 7 sur 74
	« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»			MEMOIRE DE FIN D'ETUDE
2.8 problèmes rencontrés en équipe & individuelement					20
2.9 Planning réalisé constitue mes responsabilités durant le stage					22
2.9.1 Création de BATCH					23
2.9.2 Géneration du code avec JAG					23
2.9.3 Gestion des habilitations					26
2.9.4 Fiabilisation Clients					27
Synthèse					29
Chapitre 3 Modélisation UML........................		......................30
1 Modélisation UML.............................................		................................31
1.1 Diagrammes de cas d'utilisations........................		................................31
1.2 description des cas utilisations ........................		................................33
1.3 Diagrammes de séquence....................................		..............................34
1.4 diagramme de classe du système...........................		..............................39

Synthèse........................................................................................ .41

Chapitre 4 Mis en oeuvre de projet.....................	......................42
1. Architecture Logiciel mis en oeuvre.....................	..........................43		2. Interfaces de travail effectué..............................
.........................45
Synthèse.........................................................	.......................53

Conclusion et perspectives...........................................54

Bibiolgraphie 55

Annexes

Annexe 1 Struts 57

Annexe 2 Spring 59

Annexe 3 Hibernate 62

Annexe 4 Acegi Security 63

Annexe 5 SFD 67

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

Introduction

Soucieuses d'offrir toujours de nouveaux services à leurs clients, les banques sont parmi les premiers opérateurs économiques à intégrer les nouveautés dans le domaine informatique. Grâce au système réseaux, les banques entrent dans une nouvelle phase de développement très intéressante.

Les banques marocaines n'échappent pas à cette règle, en effet, le secteur bancaire a connu des changements majeures ces dernières années devenant un marché concurrentiel par excellence. Cette concurrence rude a imposé les banques de se doter de base de données fiables et à jour à même de leur permettre de toucher le maximum de segment de clientèle possible grâce aux techniques de marketing directe, de prospection et de la CRM.

Le secteur bancaire est également un marché très réglementé et régi par les directives de la banque centrale Banque Al Maghreb. Ceci se comprend au vu des risques majeures sur les grandeurs macro économiques mais aussi au vu des risques sécuritaires (blanchiment d'argent, financement terrorisme,...)

Mon stage s'inscrit dans ce cadre, en effet le crédit agricole a fait appel à Atlashore pour réaliser une solution informatique, cette solution s'intitule « Fiche Signalétique Client (FSC) ».

Cette solution se focalisant sur une fiche signalétique des clients centralisée, en prenant en compte divers traitements, tels que la gestion de la Fiche Signalétique, Paramétrage, sécurité du projet et fiabilisation des tiers (Clients) etc....

Le présent rapport trace les phases du déroulement du projet. Il est organisé en quatre chapitres.

Le premier chapitre comporte une présentation de l'organisme d'accueil.

Le deuxième chapitre est consacré à l'étude du projet. Il comporte d'une part une présentation de stage et ses objectifs, d'autre part une description détaillé du projet, compris un planning contenue l'ensemble des taches réalisées durant le stage.

Le troisième chapitre présente la modélisation UML. Il présente les diagrammes adoptés dans notre projet.

Le quatrième chapitre décrit les étapes de la réalisation et la mise en oeuvre des différentes parties du projet dont j'ai participé.

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

Premier Chapitre

Présentation de l'organisme

D'accueil

Z7 Présentation d'Atlashore Z7 Solutions Atlashore

Cette partie traitera la présentation De l'organisme D'accueil Atlashore ainsi Que ses principes réalisation (Solutions)

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

1. Présentation d'Atlashore : 1. 1 Description générale :

Atlashore est une société spécialisée dans l'édition et l'intégration de logiciels. Elle a été crée en 2005 par un groupe d'ingénieurs marocains avec un capital de 500.000,00 DH.

La société Atlashore dispose d'une équipe de professionnels informaticiens spécialisés dans l'ingénierie informatique, le développement des solutions métiers et spécifiques dans les environnements web et embarqués. Atlashore compte un effectif global environ quinze personnes.

Dès le démarrage de ses activités, AtlaShore a mis au point un environnement de développement spécifique E@syWorkTM à même de garantir la production de logiciel selon les normes et standards les plus exigeants dans l'industrie logicielle. Cet environnement couvre les volets suivants :

· Outils de génération.
· Chartes graphiques.

· Bibliothèques & Librairies.
· Couches "métiers"

Atlashore a su gagner la confiance de plusieurs organismes de grande renommée aussi bien dans le secteur public et privé qu'à l'international, en l'occurrence :

Secteur public			Secteur privé			International
						· RADEEJ
·		BCP	·	N2S Technologies - Paris		· RADEM
·		AKWA GROUPE	·	CENTRALIS - Bruxelles		· PARLEMENT
·		Crédit AGRICOLE				· MARSA MAROC
·		CJD				· Secrétariat d'état d'Eau
·		COSUMAR
		·	ORGANON
		·	ATRETIS
	« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»						MEMOIRE DE FIN D'ETUDE

1. 2 Solutions Atlashore :

Atlashore propose quatre solutions destinées au marché marocain, particulièrement les organismes publics. Ces progiciels sont aujourd'hui en exploitation dans plusieurs organismes.

INDEXOTM : progiciel intégré de gestion de relevé d'index et d'encaissement par les terminaux mobiles. C'est une solution optimisée pour la gestion des clients des opérateurs de distribution multi fluides: eau et électricité



AFOSTM : progiciel intégré de gestion de la force de vente, destinée aux opérateurs de la distribution disposant de flottes et vendeurs itinérants.



MAW@RIDTM : progiciel intégré de gestion de développement des ressources humaines basé sur le concept de l'emploi. Cette solution représente les apports suivants: Déploiement des référentiels RH de l'Organisation, Mise en oeuvre du processus d'appréciation et rationalisation de la répartition des effectifs.



PATRIMOSTM : progiciel intégré de gestion de patrimoine prise en compte durant tout le cycle de vie, adaptée aux administrations publiques et aux grandes entreprises.

Toutefois, la solution PATRIMOSTM reste le produit phare pour Atlashore. Il génère plus de 50 % de CA et profite d'une bonne image de marque sur le marché confirmé par la stabilité de la solution et sa couverture fonctionnelle.

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

Deuxième Chapitre

Présentation du Stage

Contexte Générale du projet

? Sujet de stage

? Objectifs de stage

? Cadre Générale du projet

? Résultat attendu du projet

? Planning du projet

? Planning de stage constitue mes responsabilités durant le stage

Cette partie traitera Le stage effectué
Au sein de la société Atlashore, ainsi que
Le projet en totalité dont ma mission.

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

1 . Le stage

Dans cette partie je serai consacrée au thème du stage, avant d'énumérai mes objectifs personnels sur ce dernier. Enfin, nous aborderont le projet en tant que tel en réalisant une présentation de celui-ci, en prenant en compte les différentes phases importantes du projet, et en s'attardant sur le planning général mis en oeuvre. Puis je terminerai par exposer le travail que j'ai effectué depuis le début de mon stage, compris mes responsabilités, missions, réunions, déplacement, contact avec le client et l'esprit d'équipe acquis en travaillant bien sûr au sein d'une équipe en plein évolution en m'appuyant sur le planning de stage réalisé, également présenté dans cette partie.

1.1 Thème du stage :

J'ai été affecté tout au long de mon stage à une équipe d'ingénieurs expérimentée en développement JEE de 7 personnes dont 4 Consultants techniques et 3 consultants fonctionnels.

Le projet objet de mon stage s'intitule : « Mise en oeuvre d'une solution de gestion centralisée de La Fiche Signalétique Client (FSC) », l'objectif étant d'organiser et centraliser la fiche signalétique des clients CAM dans l'ensemble des agences liée au serveur central que ça soit au niveau national ou autres agences situées à l'étranger.

Cette solution a été développée dans un environnement purement JEE. Un panel de technologie et d'outils ont été mis en oeuvre pour réaliser notre projet. Parmi lesquelles:

Langages : java, jsp, html, css, javascript, sql, plsql(création batch sera détaillé par la suite).

Frameworks: struts (dont validator), Spring, Hibernate, Acegi security.

Environnement de développent : Eclipse.

Travail collaboratif : CVS

Serveur déploiement :websphère 6.1(CAM),tomcat 6(Atlashore).

Générateur du code : JAG6.1 (détaillé par la suite)

SGBD : oracle 10g version Entreprise.

Logiciel Client Oracle : Toad for oracle8.5

Je reviendrai plus en détaille sur ces technologies dans les parties qui suit.

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

1.2 Objectifs de stage:

J'avais personnellement plusieurs objectifs à atteindre dont le premier était de se former sur certaines technologies avancées telles que Spring, Struts, Hibernate, Acegi Security et l'optimisation sous oracle et d'acquérir un bagage technique intéressant pour pouvoir suivre l'évolution technologique dans le domaine JEE. Cet objectif est attient car j'ai travaillé sur un riche panel de technologies qui sont particulièrement très demander sur le marché de l'emploi actuellement.

Mon deuxième objectif été de participer à l'ensemble de cycle de vie du projet mais malheureusement n'été pas le cas parce que lors de ma rentrer au stage la conception de ce dernier été déjà faite par conséquent j'ai pu participer à plusieurs phase notamment le développement sous différents couches, la génération du code en utilisant le fameux logiciel du SUN « JAG », j'ai également participé aux livraisons client (déplacement vers rabat), validation du produit en relation avec le front(voir directement avec le client).en fait il a été particulièrement enrichissant de participer à ces différentes phases au cours de mon projet et de voir autre chose que de prendre un tel sujet et le développer individuellement sans aucun responsabilité.

En fin mon dernier objectif était de m'intégrer et de participer à la vie d'une équipe de développement. Cet objectif a été pleinement atteint car je me suis très bien intégré à cette équipe. Ainsi je remercie de tout mon coeur l'ensemble des membres de l'équipe JEE et l'autre de .NET car, ils ont été très accueillant dés le début et cela ma très bien aidé pour progresser et prendre des responsabilités.

2. Le projet :

2.1 Contexte du projet :

Les dernières années, le développement des applications des entreprises est devenu de plus en plus exigeant de point de vue conception, architecture, test et déploiement. De ce fait, plusieurs concepts tels que l'orienté objet, la séparation des couches et les architectures 3 tiers sont indispensables afin de rendre ce développement plus aisé et que ces applications répondent aux exigences des entreprises à savoir la modularité, la maintenance et l'évolutivité.

L'approche objet est devenue une réalité incontournable. Les concepts de base de cette dernière sont moyennement stables et éprouvés. De nos jours, programmer objet c'est bénéficié d'une panoplie d'outils, communautés d'aide technique et fonctionnelle et bien sur des langages performants. C'est vraiment une solution technologique incontournable. Ce n'est plus une mode, mais un réflexe quasiautomatique dés qu'on cherche à concevoir des solutions informatiques complexe qui doivent résister à des évolutions incessantes.

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

La séparation par couches de responsabilités d'une application sert à découpler au maximum une couche de l'autre afin d'éviter l'impact d'évolutions futures de celleci. [Www SUN] :

En générale on trouve les couches suivantes :

La couche de présentation contient les différents types de clients, léger (Web, JSP) ou lourd (Swing, WinForm),

La couche application : contient la partie sécurité dans notre cas.

La couche de service contient les traitements (contrôleurs d'Use Case UML) représentant les règles métier,

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,

La couche d'accès aux données contient les usines d'objets métier, c'est à dire les classes chargées de créer des objets métier de manière totalement transparente, indépendamment de leur mode de stockage (SGBDR, Objet, Fichiers, ...).:

L'architecture à 3 niveaux (architecture 3-tiers), a un niveau intermédiaire en plus de celle du Client/serveur, c'est-à-dire que l'on a généralement une architecture partagée entre : [www SUN]

Client : Demande de ressources.

Le serveur d'application (appelé aussi middleware) : le serveur fournit les ressources en faisant appel à un autre serveur.

Le serveur secondaire (généralement un serveur de base de données), fournit un service au premier serveur.

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE



Figure 1 : Architecture 3tiers (Www sinuscom)

En résumé :

Ce projet rentre dans le cadre du chantier de la segmentation de la clientèle, l'enrichissement et la mise à jour des bases de données client.

2.2 Objectifs du projet :

Notre solution informatique au sein la société Atlashore, consiste à la mise en oeuvre d'une solution de gestion centralisée de la Fiche Signalétique Client.

Ce système doit permettre aux différents employés d'accéder à notre page d'accueil, selon leurs profils, depuis n'importe quelle machine via le Web, aux backoffice de gérer les différentes clients à fiabiliser, paramétrage, affectation du groupe et aux employés de suivre l'avancement des fiches signalétiques en temps réel, ce système doit être sécurisé contre des intrusions internes ou externes (cette partie de sécurité sera détaillée par la suite).





Centraliser la gestion de la fiche signalétique client

Enrichir les données relatives au client (personnes physiques et personnes morales) par l'intégration de nouveaux champs dans la fiche signalétique, notamment pour les besoins du reporting réglementaire (se sont des rapports exiger par la loi, dans notre cas le crédit agricole doit transmettre chaque année des états réglementaire à Bank al Maghreb contenant le détail des clients enregistré avec leurs fiches signalétiques).

Garantir l'unicité des données client grâce à la centralisation de la fiche signalétique et aux contrôles élaborés.

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE



Fiabiliser les données clients à travers l'élaboration de contrôles automatiques.



Identification des fiches signalétiques contenant des données non fiables pour faciliter l'opération de fiabilisation.



Sécurisé la fiche signalétique client en ajoutant des contrôle d'autorisation et d'authentification.

2.3 Résultats & Produits attendus :



Fiche signalétique client

Cette fiche sera centralisée, directement connectée au référentiel central et accessible aux utilisateurs via une interface web. Les données du référentiel ainsi que la base agence seront mises à jour en temps réel. En effet, un flux devra être envoyé du central à l'agence après chaque mise à jour de la fiche signalétique.



Module Identification des fiches signalétiques à fiabilisé :

Des règles de gestion devront être identifiées dans la phase de conception, pour permettre d'identifier les fiches signalétiques à fiabiliser en se basant sur des champs à contrôler automatiquement.

En s'appuyant sur ses règles de gestion, nous avons réalisé un batch qui va tourner chaque nuit sur le serveur référentiel, par conséquent nous récupérons les clients à fiabilisés, ils seront par la suite affiché dans la partie alerte du projet, en se basant bien sûr sur les fiche signalétique déjà enregistrés.



Module de paramétrage des contrôles automatiques :

Les champs de la fiche signalétique comme déjà signalés peuvent être facultatifs ou obligatoires selon des règles de gestion définies et évolutives. Un écran de paramétrage de ces règles devra être prévu et mis à la disponibilité de l'administrateur de la solution

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE



Application agence

2 .4 Description des besoins :
2.4.1 Diagramme de contexte

Flux de mise à jour des données client en temps réel



Module Fiche
Signalétique
Client centralisé

Création / MAJ / Fiabilisation

Consultation



Référentiel client
central

Solution cible



Figure 2 : Diagramme de contexte de projet 2. 4.2 Fonctionnalités demandées :

Création d'une nouvelle fiche signalétique client

Lors de la création d'une nouvelle fiche signalétique client, l'utilisateur commence par spécifier la nature du client : personne physique ou morale.

Selon la nature de la personne, le système propose soit une fiche dédiée à la personne physique soit une fiche dédiée à la personne morale.



Recherche, consultation

La recherche d'une FS peut se faire sur la base :

Du nom / prénom / raison sociale saisis totalement ou en partie (chaine de caractère au début, au milieu ou à la fin de ces champs).

D'un des éléments d'identification (CIN, RC (registre de commerce), identifiant fiscal...)



Le système affiche ensuite, selon les habilitations, les données de la FS Modification d'une fiche signalétique existante

L'utilisateur recherche la FS à modifier. La recherche aboutit selon les habilitations de l'utilisateur connecté.

Les champs de la FS sont identiques à ceux de la création, les règles de contrôles sont identiques et s'appliquent aussi sur le stock des FS sauf pour :

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

Champ Mineur : dans le cas où l'âge du client dépasse 18 ans alors que mineur est toujours à Oui 4 un message non bloquant est affiché à l'utilisateur pour lui demandant d'inviter le tuteur à donner l'autorisation pour la modification du statut du client.

Archivage d'une fiche signalétique

Une fiche signalétique peut être archivée : l'utilisateur clique sur le bouton « archiver ». Le système contrôle si le client a des comptes actifs. Si oui, un message l'informant de l'impossibilité de l'archivage est affichée, et l'opération est arrêtée.

S'il n'existe aucun compte actif pour le client, un message de confirmation « voulez vous vraiment archiver cette fiche ? » est affiché. Si l'utilisateur confirme, la FS est enregistré à l'état archivé. La FS reste consultable mais non modifiable. Aucun compte ne peut être créé avec le matricule de la fiche. Une fiche archivée peut être réactivée.



Création et gestion des clients joints

Si la création concerne un client joint (composé de plusieurs personnes), le système permet de créer autant de fiches signalétiques que de personnes. Une de ces fiches est identifiée comme une fiche pivot dont les informations seront importées vers la fiche du client joint. L'utilisateur peut modifier les informations de la fiche du client joint avant de valider.



Impression d'une FS vierge

Un bouton d'impression du canevas de la FS (PP ou PM) doit être mis en place. Il permet d'éditer une fiche signalétique vierge à remettre au client pour remplissage des informations le concernant.



Changement de la nature du client

Cette fonctionnalité ne doit pouvoir être active qu'au niveau du central.

Il doit être possible de changer la nature de la personne (passer d'une PP à une PM ou d'une PM à une PP) malgré que le format et le contenu des deux types de fiches soient différents.

Pour cela, une fonctionnalité est à prévoir au même titre que celle de modification, l'utilisateur clique sur le menu « changer la nature d'un client ». L'application affiche un écran de recherche (fonctionnalité de recherche d'un client). L'utilisateur sélectionne la fiche signalétique du client parmi les résultats proposés et clique sur « afficher ». La FS est affiché en consultation.

L'utilisateur peut alors cliquer sur « basculer ce client vers une PP » ou « basculer ce client vers une PM » selon la nature initiale du client. Un message est alors affiché invitant l'utilisateur à confirmer « voulez vous vraiment modifier la nature de ce client ? Certaines informations risquent d'être perdues ».

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

Après confirmation de l'utilisateur, une nouvelle fiche signalétique, avec la nouvelle nature du client est créée. Le client garde le même matricule, seuls les champs communs entre une PP et une PM sont récupérés (les autres informations propres à la nature initiale du client sont perdues).

L'utilisateur ne peut valider la nouvelle fiche que s'il renseigne tous les champs obligatoires en respectant les mêmes contrôles que lors de la création d'une nouvelle FS.

Paramétrage des contrôles :

Les administrateurs de la solution doivent pouvoir modifier les contrôles automatiques sur les champs de la fiche signalétique à travers un écran de paramétrage développé pour ce besoin.

Exemple de contrôle à modifier :

Identifiant fiscal : champ numérique sur 20 caractères, obligatoire si la forme juridique l'exige. Les formes juridiques qui exigent le renseignement de l'identifiant fiscal sont : 21, 22, 24, 25, 26, 40. (L'ajout d'une valeur de forme juridique qui exige le renseignement de l'identifiant fiscal doit se faire facilement à travers l'écran de paramétrage)



Import/Export

L'export des fiches signalétiques sur des fichiers de type (Excel, Txt,...) doit être possible.

L'import à a partir de fichiers du même type doit être également prévu. 2.5 Gestion du projet :

Pour réaliser la gestion du projet Atlashore, Crédit Agricole du Maroc utilisent le modèle du cycle en V. ce dernier est un modèle conceptuel de gestion de projet, il permet en cas d'anomalies, de limiter un retour aux étapes précédentes.

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE



Figure 3 : Cycle en V plus on descend et plus on s'intéresse aux détails du projet.

Les phases de la partie montante doivent renvoyer de l'information sur les phases en vis-à-vis lorsque des défauts sont détecter afin d'améliorer le logiciel. Cela signifie que lorsqu'on réalise les spécifications, il faut également imaginer au même moment les tests de validation. De même, lorsqu'on réalise la conception détaillée, il faut penser aux éventuels tests unitaires. Ce procédé est identique pour chaque niveau du cycle. Ainsi, une fois que le développement de l'application est effectué. Les tests unitaires vont valider la conception détaillée, les tests d'intégration vont valider la conception architecturale et ainsi de suite.

2.6 Aspect technologique :

2.6.1 Architecture fonctionnelle du CAM

L'environnement applicatif actuel du CAM repose sur un système d'information agence (décentralisé), un système d'information central (en cour de centralisation) dédiées aux différents besoin existants (Monétique, système comptable...).

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

2.6.2 Architecture Technique du SI du CAM

La nouvelle architecture technique du crédit agricole du Maroc est composée : D'un centre de production au niveau du siège.

D'un site de secours

D'autres sites : Agence, direction régionales, et services centraux



Tous ces sites sont reliés entre eux par trois types de connexion réseau : LAN : Local Area Network, (pour les connexions en local),

MAN : Metropolitan Area Network, (pour les réseaux étendus), WAN : Wide Area Network. (pour les connexions à distance) ;



Figure 4 : Architecture matérielle du CAM L'architecture technique repose sur les technologies suivantes :



Le système d'exploitation Unix (Aix 5.3).

Le système de gestion de base de données (SGBDR) oracle version 10.

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE



Une architecture d'application n-tiers avec séparation des couches données (persistance), services applicatifs et présentations, avec poste client légère utilisant un browser standard (Internet Explorer 6).

Une infrastructure réseau, en cours d'évolution en termes de débit pour supporter

Le fonctionnement des postes de travail et pour faire face aux contraintes induit par la localisation de l'ensemble des applications de CAM.

2.6.3 Outils de développement :

Il est à préciser que la norme de développement actuellement suivie au sein du CAM respecte l'architecture J2EE, de ce fait la solution doit être souple et évolutive et doit suivre les standards J2EE.

Afin qu'ion reste cohérent avec le système actuel du CAM nous devront respecter les normes suivants :

1. Environnement de développement :



Framework STRUTS, l'objectif étant de créer une application Web sur le modèle MVC 2(Modèle - Vue - Contrôleur).



Framework HIBERNATE pour la persistance de données.

Framework Acegi Security pour la partie sécurité de la solution

Le choix technique de la couche services n'est pas imposé par CAM

2. Serveur de base de données : ORACLE 10gR2

3. Serveur d'application : WEBSPHERE 6.0.2.31

4. Browser : Internet Explorer 6 (parmi les problèmes majeurs rencontrés) 2.7 Planning du projet :

Il est possible de distinguer trois phases principales, la phase de conception avec le choix de l'architecture proposée, la phase de réalisation et la phase de recette qui est pratiquement effectué en parallèle avec la phase de réalisation.

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE



Figure 5 : Planning du projet FSC

Comme la montre la figure ci-dessus, la globalité du projet FSC, de l'appel d'offre jusqu'au dépoilement se découpe en 6 phase :



L'appel d'offre (Lancement) Cadrage

Conception ou Etude

Réalisation

Recette

Dépoilement

Par la suite nous présentons les phases suivantes : Appel d'offre, Etude, Réalisation 2.7.1 La phase d'appel d'offre :

Comme le montre la figure, cette phase se découpe également en quatre étapes :



Lancement de l'appel d'offre

La préparation des soumissions

L'évaluation, comporte évaluation administrative, technique et financière Adjudication

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE



Figure 6 : Diagramme de la phase appel d'offre

1. Comme le montre la figure ci-dessus, la phase d'avant vente débute lorsque le client, en l'occurrence Crédit Agricole, envoie son appel d'offre. Ce dernier est donc un dossier rédigé par le client où sont présents les éléments suivants : le cadre, les attentes du projet, les besoins du client et les exigences générales.

2. Lorsque le prestataire en l'occurrence Atlashore reçoit l'appel d'offre de client, il rédige une proposition commerciale dans laquelle il présente dans un premier temps son entreprise, les aspects financière, les outils qu'il utilise, et les compétences qu'il dispose.

Dans un deuxième temps, le prestataire montre également qu'il a bien compris les enjeux du rapport et essaye de répondre aux différentes questions du client. Enfin et dans un dernier temps le prestataire essaye de présenté une solution dont il répond parfaitement aux exigences de l'appel d'offre, en fait dans ce cas si le prestataire si a déjà la solution ou certains modules, cela sera un avantage pour lui de garantir son proposition commerciale.

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE



Figure 7 : Question/Réponse

3. Une fois que le client a reçu la réponse commerciale du prestataire, on va arriver dans une phase d'échange principalement constituée de question/réponse. Ensuite le prestataire réalise une soutenance chez client durant laquelle présente il résume et explicite tous les choix effectué dans la proposition commerciale. En fin si la réponse du client est positive, un contrat est rédigé entre le client et le prestataire.

Une fois contrat rédigé l'appel d'offre devient marché. 2.7.2 La phase d'études (Conception) :

En fait dans cette phase de nombreux documents sont réalisés en collaboration avec le client (Atlashore et Crédit agricole)

Des conditions de confidentialité ont cessé de récupérer toutes les documents nécessaires à la production d'un logiciel tel que PPL, DAT .... De ce fait j'ai eu l'opportunité de récupérer le SFD (Spécification fonctionnelle détaillé).

Donc le SFD est le résultat des travaux menés lors des ateliers d'analyse des besoins fonctionnels, ainsi que les maquettes validés avec l'équipe informatique de crédit agricole et récapitule les spécifications de nouveau système <Fiche signalétique>.

Vous trouvez le sommaire de SFD dans la partie annexe.

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

2.7.3 La phase de réalisation :

La phase de réalisation débute après par la rédaction du dossier de conception .cette phase se découpe en trois étapes :

Rédaction de dossier de conception Développement Test unitaire (Test interne) Test d'intégration (chez le client)

Lorsque les écrans ont été développé, l étape de recette peut débuter, plusieurs niveau de tests sont réalisés au cours de cette dernière comme le montre la figure suivant :



Figure 8 : schéma de la phase de réalisation

Ainsi, le premier niveau de test est effectué par les développeurs. En effet, ces derniers réalisent toute une série des tests unitaires sur les écrans justes développés.une fois que le développeur considère l'écran terminé, c'est-à-dire que ces tests unitaires sont positifs, l'écran en question subit le deuxième niveau de test après bien sûr une livraison chez le client, soit les tests d'intégrations.

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

Comme la montre la figure 8 le test d'intégration est réalisé chez le client (CAM), celui-ci alors en collaboration avec l'équipe d'Atlashore font des tests d'intégration plus pour tester le bon fonctionnellement du projet en entier, puis l'équipe d'Atlashore font se qu'on appel le dépoilement du projet sur le serveur centrale du crédit agricole équipé par web sphère. Ensuite l'ensemble des fonctionnalités décrit dans le SFD attendu par le client seront testé par une autre direction des testeurs.une fois cette phase est effectuée, le client un PV (procès verbal) à Atlashore dans lequel sont référencées la livraison ainsi que les différentes remarques faites par le client sur le projet, telles que les anomalies détectées.

2.8 Problèmes rencontrés en équipe et individuellement : Quelque Complexité technique rencontrés :

1. Fichier de validation configurable (en équipe).

2. Synchronisation entre les applications agences et la fiche signalétique : génération d'un fichier texte contenant l'ensemble des traitements (modification, création ...) effectué par un employé sur le client en correspondance (en équipe).

3. Compatibilité avec web sphère (jdk 1.4) (en équipe)

4. Le cadre d'exécution du logiciel est fixé à IE6 (en équipe)

5. Temps d'exécution de batch est très élevé (individuellement)

6. Comprendre le métier du projet (individuellement)

Problème 1 (paramétrage de fichier XML) :

La complexité de développement du module Paramétrage d'un fichier XML qui gère les contraintes de gestion n'été pas bien estimé, ainsi que le temps de développement de ce dernier est élevé ce qui rend le module un autre projet à développé par conséquent Atlashore a l'abonnée.

		« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»	MEMOIRE DE FIN D'ETUDE
	Problème 2 (JDK 1.4) :

Compatibilité avec la version de web sphère installé au serveur référentiel du crédit agricole, alors au lieu de développé avec la version 3 d'Hibernate on n'été obligé de passer à une version inférieure ce qui rend le travail plus couteux en terme du temps et du codage.



Problème 4 (Temps d'exécution) :

A ce niveau, j'ai rencontré un problème avec le temps d'exécution du batch, puisque le temps écoulé de son exécution été plus de 12 Heures, afin de pallier à ce problème, j'ai décidé de passer à l'optimisation sous Oracle, et après un certain temps j'ai pu diminuer le temps d'exécution de ce batch de plus que 12 heures à 1h 30min, bien sur on gérant plus que 3,5 million de la ligne de données.



Problème 6 (Comprendre Métier) :

J'ai évidement rencontré des difficultés sur le projet qui était de 2 types :

La compréhension de l'aspect métier, et des problèmes divers techniques. Mais j'avais la chance d'être dans un équipe très sympathique et toujours prés à m'aider.

Tout au long du projet j'ai eu des difficultés avec les conceptions car elles étaient peu précise et n'utilisaient aucun formalisme particulier (nom des tables set colonnes non significatifs).

Dans le développement des écrans, j'avais un problème au niveau de l'intégration avec la couche métier puis que je devrai comprendre tout le code métier mis en oeuvre par l'équipe, ceci m'a pris un peu temps, mais finalement j'arriverai à comprendre l'ensemble du code grâce au aides de l'équipe .

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

2.9 Planning réalisé constitue mes responsabilités durant le stage :



Figure 9: Planning de stage

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

2.9.1 Création de batch:

Fiabiliser une fiche signalétique signifie la correction des informations incohérents présenter dans cette fiche.

En s'appuyant sur les règles de gestion mis lors de la phase de conception, nous avons réalisé un batch en PLSQL qui va s'exécuter chaque nuit sur le serveur référentiel du crédit agricole, par conséquent nous récupérons les clients à fiabilisés, ils seront par la suite affiché dans la partie alerte du projet, en se basant bien sûr sur les fiche signalétique déjà enregistrés.

2.9.2 Génération du code avec JAG :

JAG est un générateur du code java/JEE intitulé « java application generator », il permet de générer du code JEE en lui offrant un modèle de donnée relationnel. JAG nous a générer disant 30% du code, par conséquent nous avons gagné plus du temps à la phase de développement.

Configuration requise :



Java JRE 1.4 ou version ultérieure.

Une base de données en cours d'exécution : JAG prend en charge actuellement Mysql, PostgreSQL, Oracle.

Configuration d'un projet JAG :

Vous facilement configurer votre projet en se connectant à votre base de données :



Figure 10 : choisir votre base de données

Pour entrer les informations de connexion de votre base de données dans JAG, vous devez cliquer sur le 'Datasource' noeud de configuration dans l'application d'arbre JAG .les paramètres que vous devrez configurer est les suivants :

		« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»	MEMOIRE DE FIN D'ETUDE
	Type de base de données : Oracle dans notre cas. jdbc url : L'URL de connexion JDBC vers la base de données. Nom utilisateur : le nom d'utilisateur de la base de données Mot de passe : Entrer votre mot de passe de la base de données.



Figure 11: Propriétés de la base de données

Maintenant que nous avons configuré notre projet, il reste que choisir les couches en question.

En fin cliquer sur le buttons sous dessous pour que JAG fait son travail.



« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE



Figure 12 : interface d'accueil de JAG.

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

2.9.3 Gestion des habilitations :

Sécurisation du projet :

Sur internet, mais aussi au coeur même d'une entreprise ou encore sur le réseau d'une banque tel que notre cas, le risque de compromission de données sensibles peut conduire à des catastrophique en termes économique ou légaux. La sécurité est donc une partie très importante pour notre client qui est Crédit agricole du Maroc. Pour ces raisons Atlashore à bien saisie les dimensions de la sécurité chez les banques, par conséquent nous avons choisie de travailler avec le fameux Framework Acegi Security (plus de détail dans la partie Annexes).



Sécurisation des URL :

La sécurisation des requête http s'appuis sur un système de filtrage des requêtes en provenance de la couche présentation autrement dit, le browser. Nous décidons donc de ne permettre qu'à un certain type d'utilisateurs d'accéder à une URL donnée.

Dans notre cas par exemple, que l'utilisateur de type chargé clientèle qui peut créer une nouvelle fiche signalétique.



Profils utilisateurs :

Les principale difficultés avec les utilisateurs du système est qu'ils sont tous différents, de ce fait il y autant d'opinions affirmés d'utilisateur sur la façon de s'y prendre. Pour construire un système efficace, il est nécessaire de définir des profils d'utilisateurs, selon différents critère de manipulation de la solution, voici une matrice qui décrit le filtrage des autorisations selon les critères d'utilisateurs :

	« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»			MEMOIRE DE FIN D'ETUDE
Autorisations par Parties du projet
		Chargé Clientèle	BackOffice
Création de la FS physique ou morale		x	x
Consultation de la FS		x	x
Paramétrage		x	x
Traitement		x	x
Affectation du groupe		x	x
Passation de fiche		x	x
Changer la nature d'un client		x	x
Archiver un Client		x	x

Tableau 1 : Matrice de définition des profils d'utilisateurs

En cas d'interdiction d'accès l'utilisateur est redirigé vers une page 404.Cette page contient une description détaillé de problème, ainsi que 2 solutions portés à l'utilisateur permettant de revenir à la page précédente ou bien à la page d'accueil.

Voici l'extrait de la page 404 :





Figure 12.1 : Page 404.

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

2.9.4 Fiabilisation des clients :

En se basant sur le batch mis en place au dessus, plus l'ajout d'une nouvelle table à la base de donnée, cette dernière qui va jouer le rôle d'un indicateurs des informations non cohérents de chaque tier (client), notre système s'engage et récupère l'ensemble des clients à fiabilisé. En fait l'utilisateur du crédit agricole est prévu par une Alert mis en accueil de la solution, ou bien il utilise carrément un système de recherche mis en place, il permet aux utilisateurs de trouver les clients en question par des critères de recherche.



Figure 13 : écran Alert



Cette partie sera plus détaillée au chapitre mis en oeuvre du projet.

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

Synthèse:

Dans ce chapitre, d'abord nous avons vu le sujet et mes objectifs de stage, puis une description en entier du projet compris :



Contexte du projet

Objectifs

Résultat attendu par crédit agricole Description des besoins du projet Aspect technologique du projet

Ainsi que le planning général, mis en place par Atlashore pour ce projet.
En fin nous avons terminé par un planning général de stage compris :



L'intégration dans l'équipe de travail

Développement sous les différentes couches du projet

Développement de la partie sécurité et la partie fiabilisation du projet

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

Troisième Chapitre

Modélisation du projet

? Diagrammes de cas d'utilisations ? Diagramme de séquences

7 Diagramme de classe

Ce chapitre traitera la phase la plus importante du cycle de vie d'un logiciel à savoir la phase UML.

Elle sera présentée dans ce chapitre

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

1. Modélisation UML

Dans l'optique de réaliser une solution informatique modulaire, facile à maintenir et orienté objet, le formalisme UML s'est imposé comme l'outil le plus adéquat pour la modélisation de ce projet. En effet UML nous a permet de bénéficier de la simplicité de l'orienté objet plus précisément les frameworks utilisés dans ce projet.

Par la suite nous allons présenter quelque diagramme UML de ce projet :

1. 1 Diagramme Cas D'utilisation :

Selon UML les diagrammes de cas d'utilisation offre un premier pas pour comprendre les interactions entre le système et ses différents acteurs.

Cas d'utilisation backoffice/chargé clientèle :

Ce diagramme présente le cas d'utilisation de deux profils d'utilisateurs de notre système :



Backoffice. Chargé clientèle.

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE



Figure 14: Diagramme de cas d'utilisation backoffice et chargé clientèle

Cas d'utilisation affectation Client Groupe :

Nous présentons dans ce diagramme l'affectation d'un client à un groupe donné.



Figure 15 : Diagramme de cas d'utilisation Affectation Client Groupe

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

1. 2 Description des cas d'utilisation :

Nous décrivons ci-dessous quelques cas d'utilisation les plus importants :

Le premier tableau concerne le cas d'utilisation backoffice et la personne chargé clientèle :

Cas d'utilisation	backoffice et chargé clientèle
Acteur	Backoffice
Description	Il a comme objectif de superviser la clientèle à fiabiliser, ainsi que d'affecter des clients à des groupe prédéfinies.
Scénarios	Authentification requise. Gestion habilitations Traiter les clients non fiables. Changer d'agence pour les clients Affecter un client à un tel groupe Consulter la fiche signalétique d'un client
Acteur	Chargé clientèle
Description	Il a comme objectif la gestion des clients de crédit agricole, et d'archiver des clients qui meurent par exemple.
Scénarios	Authentification requise. Gestion habilitation Création des nouvelle FS. Archiver un client. Consulter un client déjà existant. Imprimer une fiche vide Gestion des alert en cas de fiabiliser un tel client.

Tableau 2 : Description Des cas d'utilisation

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

1. 3 Diagramme de séquence :

Un diagramme de séquence donne une représentation temporelle des objets et leurs interactions.

1. 3.1 Scénario Authentification requis :

Avant d'entrer au menu du projet et faire l'ensemble des autres scénarios l'utilisateur doit se connecter en utilisant son login + mot de passe.

Le diagramme qui suit présente l'enchainement de la phase d'authentification.



Figure 16 : Diagramme de séquence Authentification 1. 3.2 Scénario gestion habilitations :

Après l'authentification de l'utilisateur il y tout un Framework derrière, il valide l'authentification de dernier utilisateur connecter avec les droits qu'il a tout en récupérant ses derniers de la base de donnée.

Tout au long de session de l'utilisateur, il a la possibilité d'accéder qu'aux services dont il est autorisé. Dans le cas contraire il sera redirigé vers une page d'erreur 404.

Le diagramme qui suit présente la gestion des habilitations.

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE



Figure 17 : Diagramme de séquence gestion des habilitations

1. 3.3 Scénario affecté client à un tel groupe

Le backoffice ou superviseur a le droit d'affecter un client à une groupe prédéfinie tels que AKWA,Bank Populaire,ONA .. . Groupe.

Le diagramme qui suit présente ce dernier scénario :

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE



Figure 18 : Diagramme de séquence gestion client groupe

1. 3.4 Scénario Archiver Client

En principe tous les scénarios qui restent ont presque la même logique au niveau d'interactions objets, par conséquent je présenterai ce scénario qui décrit un droit donné pour le chargé clientèle et non plus le backoffice.

L'archivage se fait pour les clients meurent par exemple.

Le diagramme qui suit présente l'enchainement de la phase d'archivage d'un client :

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE



Figure 19 : Diagramme de séquence archiver client 1. 4 Diagramme de classe :

Le diagramme de classes présente la structure statique du système en termes de classes et de relations. Nous commençons par présentons ce diagramme, puis nous donnons une description de quelques classes contenues dans ce dernier.

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE



Figure 20 : Diagramme de classe du système

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

En fait ce diagramme est composé des tables s'appelles « «table de paramètre » et d'autre tables du projet.

Quelques tables de paramètre sont :



Activite

Banque

Categorieresidence

region

codepostale ville

filiere

conjointEnfant

prefecture profession profil

province entite

typeLogement

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

Synthèse :

Dans ce chapitre nous avons présenté un pourcentage de la solution conceptuelle mis en place pour ce projet, ceci par la présentation séquentielle des scénarios du projet.

Le résultat de ce chapitre sera exploité directement dans la phase de réalisation, qui justement, sera présenté dans la partie qui suit.

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

Quatrième Chapitre

Mis en oeuvre du projet

rZ7 Architecture du projet

rZ7 Travail effectuérZ7 Interfaces

Ce chapitre traitera la dernière phase du cycle du
développement à savoir la phase de construction.

Elle sera présentée dans ce chapitre

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

1. Architecture du projet :

Le concept de l'architecture 3 tiers vient pour remédier aux problèmes de la maintenance, de la réutilisation et la monté en charge, ce qu'on appelle scalabilité (c'est-à-dire la capacité d'un système ou de ses composant, à être utilisé sur des plateformes de taille inférieure ou très supérieure) d'une solution informatique, les solutions basées sur ce type d'architecture sont divisées en plusieurs niveaux logiques, comme la montre la figure suivante.



Figure 21: Découpage logique utilisé

Couche de Présentation :



Cette couche correspond à la présentation de l'interface graphique, l'enchainement des pages et la logique applicative. En d'autres termes, c'est la partie visuelle de l'application que pourra observer l'utilisateur. Elle est basée sur le modèle MV et utilise la technologie Struts et les JSP. Cette couche est interconnectée avec la couche application.

Nous avons utilisé le frameworks Struts pour l'implémentation de cette couche

		« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»	MEMOIRE DE FIN D'ETUDE
	Couche Application :

Cette couche assure la sécurité de la solution informatique, elle joue le rôle d'un pont qui sépare la partie présentation des autre parties en d'autre terme chaque requête provenant du client est filtré par cette couche avant qu'elle arrive au traitement métier du projet.

Nous avons utilisé le frameworks Acegi security pour l'implémentation de cette couche.



Couche Service :

C'est véritablement au sein de cette couche que sont réalisées toutes les actions de traitement du projet, elle est constituée des objets métier identifiés lors de la phase de conception après l'élaboration des diagrammes de classes.

Ainsi cette couche comporte les objets techniques généraux qui comportent les méthodes servant à l'accès aux bases de données.

Cette couche utilise le Frameworks Spring.



Couche de Persistance :

Le rôle de cette couche est d'insérer, de mettre à jour, de supprimer, ou de rechercher les objets métiers dans la base de données. Elle contient donc le gestionnaire de persistance des objets métiers (DAO). Cette couche de persistance utilise le Framework Hibernate. La connexion de Hibernate avec la base se fait via un driver JDBC.

2. Interfaces de travail effectué : Fenêtre d'authentification :

La fenêtre d'authentification permet aux employés d'accéder à la solution FSC, en utilisant un login et un mot de passe, ces derniers vont être vérifiés en utilisant les informations résidantes dans la base de données. Ces informations aussi seront enregistrées dans la session Acegi pour valider les droits d'accès de chaque utilisateur.

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE



Figure 22 : page d'authentification

Fenêtre Accueil :

La fenêtre d'accueil divisée en 3 parties principales, à savoir :

Gestion client à gauche Module Traitement et paramétrage en haut de la page.

La partie en milieu présente l'Alerts, elle affiche l'ensemble des clients à fiabilisés.

Dans cette partie Alerts L'utilisateur a la possibilité de cliquer sur un client, il sera redirigé en mode création client dont il effectué les changements nécessaire à la fiabilisation d'un client.

En haut à droite de la page le nom, type d'utilisateur, date de connexion, numéro d'agence sont rappelés. Le bouton fermé la session est présenté en haut à droite de la page avec l'aide.

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE





Figure 23 : page accueil Scénario fiabilisé un client physique non fiable.

Lorsque l'utilisateur clique sur un tel client dans la partie « Alert », il sera redirigé en mode création de celui-ci, les écrans suivant illustrent cette phase de modification :

Ecran 1 : information sur l'identité de client tel que la nature de pièce d'identité, sa date délivrance et sa date d'expiration.



Figure 24 : page identité client





« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE



Figure 25 : insérer la date délivrance

Ecran 2 : vous trouverez dans ses écran des champs mis en couleur rouge, justement, ils expriment que le champ en question est incohérent et il doit être fiabiliser.

Figure Incohérence : incohérence des champs

Ecran 3 : cet écran comporte les informations personnelles de client choisi à fiabilisé.



Figure 26 : informations personnelles

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

Ecran 4 : cet écran présente la partie banque de client de tel sorte, si elle client à d'autre compte sur d'autre banques, l'utilisateur peut les mentionnés en cas de consensus de client.



Figure 27 : informations Banques

Les écrans suivants présents les cordonnées des clients.

Ecran 5 : cet écran présente le type de logement (locataire, logé en famille,...), et est ce que ce logement est financé par CAM ou non.



Figure 28 : informations logement

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

Ecran 5 : présente les informations en détail sur l'adresse principale du client.



Figure 29 : informations adresse principale

Ecran 6 : présente les informations en détail sur l'adresse principale du client, tel que le numéro de l'appartement, le quartier et le code postale ainsi que le code région en trois parties : province, cercle et la commune. La solution offre à l'utilisateur d'entrer plusieurs adresse client relatifs au même client.



Figure 30 : informations adresse courrier Ecran 7 : présente les contacts de client (Tél, fax, email).

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE



Figure 31 : informations contact

Ecran 8 : il présente des informations sur l'exploitation agricole du client, bien évidement, s'il a une exploitation quelque part.

Après qu'il rentre les informations nom exploitation et code région, le système affecte automatique l'information zone agro climatique et l'irrigation par l'ORMVA (Office Régionaux de Mis en Valeur Agricole).

L'irrigation par l'ORMVA signifie « est- ce-que cette zone agriculture est irriguer par l'ORMVA ou non.

Comme la figure 32 montre, avec le buttons « plus » verte en bas, l'utilisateur a la possibilité d'entrer plusieurs exploitations agricoles dont le client possède.



Figure 32 : exploitation agricoles

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

Fenêtre Traitement :



Figure 33 : page Traitement

C'est la partie fiabilisation client présenté précédemment dans la partie planning de stage, en effet cette fenêtre est accessible pour les utilisateurs ayant le profil backoffice, ils peuvent chercher des clients en utilisant les critères de recherche par agence, type de personne et champs de renseignent situé au milieu de la figure cidessus.

Chercher maintenant les clients en question, par coucher les champs désirer, un écran s'affiche présente les clients rechercher.

L'écran résultat est le suivant :



« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

Figure 34 : Clients à fiabilisés

La première colonne du tableau « codeTier », contient les codes des clients. La deuxième colonne « nom », contient les noms des clients.

Le reste des colonnes représente les infos sur le client.

La dernière colonne le plus importante présente les champs incohérents de client en vis à vis.

A ce niveau là, le backoffice a la possibilité de choisir les clients dont il veut fiabilisés et valider l'opération par un clique sur le bouton « A Fiabiliser » , ou bien lancer une nouvelle recherche par cliquer sur le bouton « Nouvelle recherche » dans le cas d'insatisfaction des résultats.



Lorsque le backoffice clique sur « A Fiabiliser », le client en question se met dans la page « alerts », et le scénario dont on a parlé au dessus se répète, qui est fiabiliser un client non fiable.

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

Synthèse :

Ce chapitre, qui a été consacré à la présentation de l'architecture mis en oeuvre et les différentes interfaces de ma mission en stage, prend fin. La conclusion de notre rapport fera l'objet de la section suivante.

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

Conclusion et perspective

Ces 4 mois de stage au sein de la société Atlashore m'ont permis de découvrir la réalité d'un projet en milieu professionnel. J'ai du affronter les difficultés liés à un projet de ce qualité, en particulier projet FSC. Ce projet été un projet court mais très intense et il a fallu produire des livraisons de qualité dans des délais bien déterminés.

J'ai pu découvrir en participant au développement du projet la rigueur nécessaire à la satisfaction du client surtout un client tel que le crédit agricole du Maroc, et les bonnes pratiques nécessaires à la réalisation d'un projet de qualité.je me suis rendre compte aussi sur l'importance de la coopération dans l'équipe, et de dialoguer avec le client. D'un point de vue technologique, le projet été très intéressant puisque j'ai étudié et utilisé un vaste panel de technologie (Struts, Spring, Hibernate, Acegi Security) et d'outils (Maven, CVS, AndroMDA, JAG) autour de JEE.

Mes mission ont été variées et intéressante et même si j'ai beaucoup travaillé sur la partie batch ainsi que la partie sécurité du projet.

Ce projet a été donc une période très intéressante et sympathique pour moi, j'ai énormément appris sur le plan technologique mais aussi en termes d'organisation du projet (respect de délai), d'autant plus que le rythme était un petit peu élevé de tel sorte que les taches doivent terminer dans une telles date, ce qui rend le travail plus professionnel.

Ce stage été donc une excellente opportunité pour ma futur vie professionnelle, et je pense que les connaissances acquis m'en servira aussi dans le cadre de développement JEE.

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

Bibliographie

Livres Eyrolles :



Spring Par la pratique 2.0 de julien Dubois.

SQL pour ORACLE 3eme Edition de Cristain Soutou. Sécurité Informatique principe et méthode de laurent bloch. Spring In Action de Craiy Walls avec ryan

Hibernate 3.0 de anthony Patricio

Site Internet:

WWW.developpez.com WWW.springsource.org WWW.hibernate.org www.apache.org

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

Annexes

Struts 7Spring 7Hibernate

7 Acegi Security

7SFD

Cette partie présente une petite description Des frameworks mis en oeuvre dans ce projet

Ainsi qu'un sommaire du document SFD (Spécification fonctionnelle détaillés)

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

Les principaux Frameworks JEE présentés dans ce projet sont les suivants :

Struts : Framework de la couche Présentation.

Hibernate : Framework de la couche de Persistance.

Spring : Framework réalisant les interactions entre les différentes couches de l'application.

Acegi Security : Framework Open Source dont l'objectif est de proposer un système complet de gestion de la sécurité. Il peut être utilisé de manière indépendante mais fonctionne de manière optimale avec Spring. Il s'agit d'ailleurs d'une solution très répandue au sein de la communauté Spring.

Annexe 1

Struts

Struts, sous son véritable nom, "Apache Struts", est un framework open source développé par la apache Software Fondation utilisé pour faciliter le développement des applications web JEE. Son but premier est de faciliter la mise en oeuvre d'une architecture MVC (Modèle-Vue-Contrôleur). Pour cela, Struts combine deux technologies: JSP et Servlets, dans le but de séparer la présentation, les données, et les transactions. Ceci permet donc d'obtenir une meilleure subdivision et structuration du code d'une application web. Par conséquent, la maintenabilité et la modularité de l'application pour des développements futurs sont facilitées.

Pour notre application, Struts est essentiellement utilisé dans la couche Présentation. Ceci, permet donc de réaliser, à ce premier niveau, une première distinction entre l'IHM et les traitements.



Figure 26: Schéma du Framework Struts

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

Si on associe la figure ci-dessus avec le modèle MVC, nous avons les correspondances

Suivantes :

L'Action Servlet constitue le Contrôleur La JSP constitue la Vue L'Action constitue le Modèle

1) Le contrôleur, soit l'Action Servlet, représente le coeur de la couche Présentation, car toutes les requêtes du client transitent par lui.

2) Si la requête du client contient des paramètres, notamment lors de saisies de champs d'un formulaire, les paramètres sont envoyés dans un objet de type Action-Form.

3-4) Le modèle, appelé Action, réalise les différents traitements en fonction de la requête, et peut faire appel à la couche Métier si nécessaire.

5-7) Une fois de plus, le contrôleur fait appel au fichier Struts-config pour savoir vers quelle JSP rediriger la réponse. De plus, si l'action a besoin de renvoyer des paramètres à la JSP, elle peut le faire, via un objet de type ActionForm.

6) La réponse est renvoyée au client.

C'est toujours à partir du fichier de configuration Struts-config que le contrôleur sait quel objet de type ActionForm est associé à quelle Action.

Les objectifs de ce framework de Présentation sont donc de fournir un cadre de travail constitué d'un ensemble de classes génériques afin de :



Faciliter les développements en implémentant dans les classes de base les comportements génériques standards et les méthodes squelettes, en laissant aux sous-classes le soin d'implémenter les méthodes abstraites.

Homogénéiser les développements.

Permettre une meilleure évolutivité et maintenance : une modification sur les classes de base du Framework permettra à toutes les sous-classes de bénéficier des nouvelles fonctionnalités.

Gérer de manière homogène les erreurs (exceptions renvoyant sur les pages d'erreurs).

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

Annexe 2

Spring

Spring est un Framework open Source JEE pour les applications n-tiers facilitant leur développement ainsi que leurs phases de tests. Il faut savoir que Spring est considéré comme un conteneur léger. En voici, une définition :

Spring s'appuie principalement sur l'intégration de trois concepts clés :

Inversion de contrôle ou injection de dépendances Programmation orientée aspect Couche d'abstraction

La programmation orientée aspects sépare les considérations techniques des descriptions métiers dans une application. Elle va donc permettre d'extraire les dépendances entre modules et de gérer depuis l'extérieur ces modules en les spécifiant dans des composants du système à développer, nommés "aspects".

Quant à la couche d'abstraction, elle permet d'intégrer d'autres frameworks et bibliothèques avec une plus grande facilité. En effet, grâce à cette dernière, Spring ne concurrence pas d'autres frameworks dans une couche spécifique d'un modèle architectural MVC, mais s'avère être un framework multi-couches pouvant s'insérer au niveau de toutes les couches : modèle, vue, et contrôleur. Cette couche d'abstraction permet donc à Spring d'intégrer Hibernate pour la couche de Persistance, ou encore Struts pour la couche Présentation.

Il faut savoir que Spring propose une multitude de façon d'utiliser son conteneur léger. Une des plus utilisée est celle faisant appel aux notions de fabrique de Beans et de contexte d'application, permettant de dialoguer et de configurer son conteneur léger.

La fabrique de Beans(BeanFactory) est l'interface de base permettant aux applications reposant sur le conteneur léger de Spring d'accéder à ce dernier. Elle définit les fonctionnalités minimales dont dispose l'application pour interagir avec celui-ci. Les méthodes proposées par cette interface permettent donc d'interroger le conteneur concernant les objets dont il à la charge.

Pourquoi utiliser Spring ?

Spring est composé de plusieurs modules disponibles sous forme de fichiers jar. Ainsi, on peut n'ajouter au projet que la partie que l'on souhaite utiliser. De plus,





« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

Spring fournit des services de type fonctionnel comme par exemple la gestion de transactions.

Voici quelques uns des avantages de Spring :



Découplage des composants logiciels. Moins de dépendances entre les différents modules.

Diminue la quantité de code par l'intégration des Frameworks tiers. Permet de mettre en oeuvre la programmation orientée aspect.

Un système transactionnel au niveau de la couche métier.

Rend simple les tests des applications multicouches (n-tiers).

Pas de dépendances entre le code et Spring grâce à la notion d'injection de dépendances. Ce qui permet de remplacer une couche sans impacter sur les autres.



Déploie et consomme des services Web.

Echange des objets par le protocole HTTP.

Facilite la maintenabilité de l'application.

Facilite la modularité et l'extensibilité de l'application Ainsi, la séparation des interfaces de leur implémentation permet d'utiliser par exemple, un framework différent pour la couche Présentation ou Persistance sans impacter sur les autres couches.

L'architecture de Spring :

La figure suivante représente l'organisation des modules et des fonctionnalités utilisés dans Spring :



Figure 27 Architecture du Framework Spring

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

Comme la montre la figure ci-dessus, Spring repose sur un socle technique constitué de deux modules principaux :





Spring Core : le conteneur léger. Ce module implémente le concept d'injection de dépendances (ou inversion de contrôle). Il est également responsable de la gestion de la configuration du conteneur.

Spring AOP : ce module permet d'intégrer la programmation orientée aspect(POA).

Sur ce socle viennent se greffer d'autres modules de plus haut niveau destinés à intégrer des Frameworks tiers, ou à fournir des fonctions de support. Ces modules sont les suivants :

Modules d'intégration de la persistance de données :



Spring DAO : permet de rendre abstrait la notion d'objets d'accès aux données.



Spring ORM : permet d'intégrer un framework de persistance. Spring JDBC : permet de simplifier l'utilisation de JDBC.



Spring Context : Module de gestion de contexte applicatif Permet d'assurer le dialogue entre Spring et l'application, indépendamment de la plateforme technique sur laquelle fonctionne cette dernière.

Spring Web : Module d'intégration de Framework Web (Struts par exemple).



Spring Remoting : Module de distribution d'objets.

Permet de transformer de simples classes Java en objets distribués RMI, Web Services ou autres.



Modules de support de la différente technologie JEE (JMX, JMS, JCA et EJB).

Annexe 3

Hibernate [ Wwwhibernate.com]

Hibernate est un Framework open source gérant la persistance des objets en base de données relationnelle. Ce dernier remplace les accès à la base de données par des appels à des méthodes objet de haut niveau. De plus, il permet de tirer partie des concepts de la programmation objet, tels que, l'héritage, le polymorphisme, les relations entre les classes, etc.

La figure suivante décrit l'architecture du framework Hibernate :

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE











Figure 28 Architecture du Framework Hibernate

SessionFactory : Permet de créer des objets sessions, puis réalise le mapping entre la session créée et la base de données relationnelle. Il est important de souligner que la session ne peut être mappée qu'avec une seule base de données.

Session : C'est un objet à courte durée de vie représentant la conversation entre l'application et l'entrepôt de persistance. Ce module permet d'encapsuler une connexion JDBC et de créer des objets de type transaction.

Objets persistants : Ce sont des objets à courte durée de vie, contenant l'état

de persistance et la fonction métier. Ce sont des objets de type JavaBeans ou



POJOs associés à une seule session. Ils deviennent libres dès la fermeture de

la session. Hors connexion, ils peuvent être utilisés par n'importe laquelle des

couches de l'application.

Objets non persistants : Ce sont des objets non associés à une session (ils peuvent en réalité être des instances de classes persistantes ou métiers, mais

en mode déconnecté).

Il faut savoir qu'Hibernate utilise :

L'API JDBC : permet de gérer la connexion à la base de données relationnelle.

L'API JNDI : permet de gérer la connexion aux sources de données L'API JTA : permet de gérer la connexion aux serveurs d'applications

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

Annexe 4

Acegi Security [ Wwwdeveloppez.com]



Acegi Security est un framework Open Source dont l'objectif est de proposer un système complet de gestion de la sécurité. Il peut être utilisé de manière indépendante mais fonctionne de manière optimale avec Spring. Il s'agit d'ailleurs d'une solution très répandue au sein de la communauté Spring.

Les avantages fournis par Acegi Security par rapport à une solution J2EE classique.

Principaux avantages

Le premier avantage d'Acegi Security est sa portabilité. Ne dépendant pas d'un serveur d'applications particulier, son utilisation est identique quel que soit le serveur utilisé.

Cette portabilité est particulièrement importante si l'application développée doit pouvoir être vendue à un grand nombre de clients possédant des systèmes hétérogènes. Dans le cadre d'une application développée en interne, il n'en reste pas moins dommage de se trouver bloqué sur un serveur d'applications uniquement à cause d'une problématique de sécurité.

Le deuxième avantage d'Acegi Security est qu'il fournit en standard un nombre de fonctionnalités beaucoup plus important qu'un serveur J2EE classique. Parmi les plus simples, et qui manquent cruellement dans la spécification J2EE, citons l'authentification automatique par cookie pour un nombre donné de jours, ainsi que la vérification qu'un utilisateur n'est pas déjà authentifié avec le login demandé.

Enfin, Acegi Security propose une excellente intégration avec les applications Web et
les Beans Spring. Concernant les applications Web, il propose des filtres de servlets
bien plus fins que ceux proposés par la norme J2EE. Pour les Beans Spring, il permet

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

d'utiliser la POA afin de sécuriser la couche métier de manière efficace et transparente.

Si nous reprenons les besoins de sécurité rappelés en début de chapitre, Acegi Security apporte les avantages suivants :



Gestion des utilisateurs : solution intégrée, complète et portable. Sécurisation des requêtes HTTP : disponible de manière plus fine que dans la norme J2EE.

Sécurisation de la couche de service : API complète, qui s'intègre dans les frameworks courants de POA (AOP Alliance, une API implémentée par Spring AOP, et AspectJ).



Sécurisation de la couche de domaine : listes de contrôle d'accès, qui peuvent être spécifiées au niveau de chaque objet de domaine.

Contrôle du code exécuté : non pris en compte par Acegi Security.



Les grands principes d'acegi sécurité :

Filtrage des accès :







« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE



Le principe mis en place par ACEGI pour sécuriser une ressource est relativement simple, une série de « filtres » sont interposés entre l'appelant et la ressource ellemême. Ces différents filtres ont chacun un rôle précis dans la chaîne de sécurisation. Nous allons voir aussi que l'on peut mettre ou ne pas mettre certains filtres en fonction des options que l'on choisit pour sécuriser la ressource mais aussi en fonction des besoins qui peuvent s'imposer.

ACEGI utilise la notion de « filter » définie dans la spécification sur les servlets (fichier web.xml) pour positionner ses propres filtres spécialisés dans la sécurité et les aspects (Spring AOP ou AspectJ), pour sécuriser les appels de méthodes ou les objets.

« MISE EN OEUVRE D'UNE SOLUTION DE GESTION CENTRALISEE DE LA FICHE SIGNALETIQUE CLIENT POUR LE COMPTE DE CREDIT AGRICOLE DU MAROC (CAM)»

MEMOIRE DE FIN D'ETUDE

Annexe 5

Sommaire de SFD(Atlashore)

Sommaire

Présentation du document

Présentation du projet Erreur ! Signet non défini.

I.1. Contexte du projet :

I.2. Objectifs du projet :

I.3. Résultats & Produits attendus : Erreur ! Signet non défini.

I.3.1. Fiche signalétique client Erreur ! Signet non défini.

I.3.2. Identification des fiches signalétiques à fiabiliser

I.3.3. Module de paramétrage des contrôles automatiques

I. Gestion Clients :

2.1 Créer un client

2.1 Consultation Client

II. Traitements :

2.1 Incohérence : Erreur ! Signet non défini.

III. Paramétrage : Erreur ! Signet non défini.