credit scoring, l'octroi des cartes bancaires

Crédit scoring : L’octroi des cartes bancaires

Elaboré par : Encadré par : M. Marwen ALLAGUY M. Sami MAHFOUDHI M. Wissem TRABELSI M. Raed KOUKI

2OO8/2OO9

Institut des Hautes Etudes Commerciales de Carthage Credit scoring : Octroi des cartes bancaires

Nous tenons à remercier infiniment nos encadreurs, messieurs,

Sami Mahfoudhi et

Raed Kouki pour nous avoir conseillé et guidé tout au long de ce projet,

Nous remercions également l’ensemble de l’équipe pédagogique de la

licence en informatique d’administrations des affaires,

Nos vifs remerciements s’adressent à tous ceux qui nous ont soutenus,

en particulier nos parents.

Wissem TRABELSI

Marwen ALLAGUY

Remerciements 3


Avant-propos

Sortant de la filière Informatique Appliqué à la Gestion, parcours :

Administration des Affaires de l’Institut des Hautes Etudes Commerciales de

Carthage ; nous avons considéré que nous avons tendance à être plus analyste que

programmeur, c’est pour cette raison que nous avons choisi de nous diriger vers la

gestion des processus métier pour jouer le rôle de business analyst.

Durant toute la période du stage, nous n’avons cessé de collecter les

informations d’un établissement à un autre, d’une banque à une autre et d’être à

l’écoute de tous les acteurs possible du processus afin de détecter les besoins exacts

pour que notre système soit le plus efficace possible pour qu’il puisse intégrer Himilco

Platform.

4


Table des matières

Avant-propos………………………………….………………………………….……...3 Remerciement…………………………………………………………………………...4 Table des matières……………………………………………………………………….5 Table des figures………………………………………………………………………...6 Chapitre introductif………………………………….…………………………………..8 Chapitre I: Présentation générale ………………………………….………………......10 1. Présentation de la société HIMILCO MONETIQUE………………………….……11 2. Démarche adoptée………………………………….………………………………..15 3. Conclusion…….…………………………….………………………………………16 Chapitre II : Présentation du business process ……………………………….………..17 1. Processus d’affaires…………………………….…………………………………...18 2. BPM (gestion des processus métiers) ………………………………….…………...18 3. BPMN (Business Process Model Notation) ………………………………………...20 4. De BPMN à BPEL, de la modélisation à l’exécution ………………………………21 5. BPMS ……………………………………………………………………………….22 6. Conclusion ………………………………………………………………………….23 Chapitre III : Capture des besoins ……………………………………………………..24 1. Contexte du système ………………………………………………………………..25 2. Etude de l’architecture………………………………………………………………35 3. Conclusion…………………………………………………………………………..37 Chapitre IV : conception………………………………………………………………38 1.Conception du cas d’utilisation « s’authentifier » ………….……………………….39 2.Conception du cas d’utilisation « gérer le système »…… …………………………..41 3.Conception du cas d’utilisation « Créer une nouvelle demande de carte»…………..44 4.Conception du cas d’utilisation « Vérification»……………………………………..47 5.Conception du cas d’utilisation « Evaluation»………………………………………49 6. Conception cas d’utilisation général………………………………………………...52 7.Conception du diagramme de classe général…………………………………….......53 8.Conception du diagramme d’activité général………………………………………..54 9.Conclusion…………………………………………………………………….......…55 Chapitre IV : Réalisation………………………………………………………………56 1.Environnement de travail…………………………………………………………….57 2.Le Business Process Diagram……………………………………………………......61 3.Présentation de quelques interfaces………………………………………………….62 4.Evaluation…………….……………………………………………….......................73 5.Conclusion…………………………………………………………...........................73 Conclusion générale……………………………………………………………………74 Glossaire……………………………………………………………………………….75 Bibliographie et netographie…………………………………………………………...80 Annexe…………………………………………………………………………………82

Table des matières 5


Table des figures

Chapitre I :

Figure 1 : La Platforme Himilco Monétique …………………………………………..12

Figure 2 : service Conseil Monétique …………………………………………………13

Figure 3: schéma simplifié de l’application …………………………………………...14

Figure 4: La structure du processus …………………………………………………...16

Chapitre II :

Figure 5: L'architecture technologique du BPM ……………………………………....22

Chapitre III :

Figure 6: Modèle de cas d’utilisation initial …………………………………………..31

Figure 7: cas d'utilisation "s'authentifier" ……………………………………………..32

Figure 8: cas d'utilisation "créer une nouvelle demande" ……………………………..33

Figure 9: cas d’utilisation « vérifier les informations » ………………………………34

Figure 10: cas d’utilisation « gérer le système» ……………………………………….34

Figure 11: cas d’utilisation « évaluer la demande» …………………………………...35

Figure 12 : composant d’un BPMS type ………………………………………………36

Figure 13: Architecture Trois Tiers …………………………………………………...37

Chapitre IV:

Figure 14: cas d'utilisation "s'authentifier" détaillé …………………………………..40

Figure 15 : cas d’utilisation « gérer le système» détaillé………….…………………...42

Figure 16 : digramme de séquence « gérer système » ………………………………...43



Figure 17 : cas d'utilisation "créer une nouvelle demande" …………………………...45

Figure 18 : digramme de séquence du cas d'utilisation "créer une nouvelle demande...46

Figure 19 : cas d’utilisation « vérifier les données » …………………………………48

Figure 20 : cas d’utilisation « évaluer la demande» …………………………………..50

Figure 21 : diagramme de séquence du cas d’utilisation « évaluer la demande» ……..51

Figure 22 : cas d’utilisation général …………………………………………………...52

Figure 23 : diagramme de classe général ……………………………………………...53

Figure 24 : digramme d’activité général ………………………………………………54

Chapitre V :

Figure 25 : Digramme du processus de travail ...……………………………………...61

Figure 26 : Interface « authentification »………………………………………………62

Figure 27 : Interface « choix responsable service »……………………………………63

Figure 28 : Interface « Mise à jour des pondérations »………………………………..63

Figure 29 : Interface « Mise à jour des cartes »……………………………..…………64

Figure 30 : Interface « Mise à jour des utilisateurs »……………………..……………64

Figure 31 : Interface « choix du type de client »………………………………………64

Figure 32 : Interface « formulaire particulier » ……………………………………….65

Figure 33 : Interface « formulaire entreprise »………………………………………...66

Figure 34 : Interface « vérification entreprise »………………………………………..69

Figure 35 : Interface « vérification information particulier »………………………….71

Figure 36 : Interface « notation des informations »……………………………………72

Figure 57 : Interface « résultat de la demande »……………………………………….72



Un crédit est une créance pour un prêt ou plus généralement une

ressource financière pour l'entreprise. Le sens étymologique de crédit est la confiance

accordée à autrui. Il s'agit du participe passé latin de credere, croire.

L'accord de crédit est une activité qui repose sur la confiance que le prêteur

accorde à l'emprunteur de qui il attend le remboursement du prêt. De manière générale,

plus le prêteur aura confiance dans l'emprunteur, plus il lui prêtera une somme

importante avec un faible taux d'intérêt. Inversement, moins l'emprunteur aura de crédit

aux yeux du prêteur, plus celui-ci sera frileux, exigera des garanties importantes et

prêtera l'argent à un taux d'intérêt plus élevé.

Des méthodes automatisées d’évaluation des risques-clients (credit scoring en

anglais), consistant à attribuer une note chiffrée à la capacité de remboursement d'un

emprunteur à partir de diverses informations (revenus, chiffres d’affaires,

endettement...) sont utilisées pour faciliter l'analyse pour les opérations de crédit les

plus simples (crédit à la consommation, carte de crédit...).

Le nombre total de cartes en circulation ayant littéralement doublé de 2004 à

2008 pour passer de 900 348 à 1 870 125 cartes, les organismes financiers émetteurs

souhaitent mieux évaluer le risque inhérent à l’octroi du produit carte.

Pour cette raison l’objectif essentiel de notre travail consiste, après avoir

analyser les besoins liés à la résolution de ce type de problème, à exposer la solution

choisie pour l’octroi de cartes bancaire la plus proche du système scoring. Cette

dernière permet d’élaborer un score considéré comme un indicateur efficace spécifiant

la probabilité de solvabilité du demandeur de carte.

Chapitre introductif 8


Ainsi dans le cadre de ce projet, nous proposons une normalisation du processus

d’octroi de carte bancaire à travers un système de Crédit notation en répondant à la

problématique suivante :

Quelles sont les différentes étapes du processus ?

Quels sont les acteurs de ce système ?

Lorsque l’on ouvre un compte auprès d’une banque ou lorsque l’on demande un

prêt à un organisme de crédit ou en vue de l’obtention d’une carte bancaire, nous

devons fournir un certain nombre d’informations sur notre situation personnelle et

financière.

Ces informations sont enregistrées dans une base de données « clients ». La banque ou

l’organisme de crédit ne peut détenir sur nous que des données qui sont pertinentes

pour la gestion de nos comptes et de nos crédits.

Par exemple, ils ne peuvent détenir des informations sur nos opinions politiques, sur

notre appartenance syndicale ou sur notre religion.

Que comporte votre dossier client ?

- des données d’identification : nom, prénoms, date et lieu de naissance, nationalité,

adresse postale, numéro de client, coordonnées téléphoniques, adresse électronique ;

- des données liées à la gestion des produits et services souscrits ou demandés: situation

professionnelle, situation familiale, revenus, score calculé pour l’obtention d’une carte

bancaire ou d’un crédit, note de risque attribuée au client, segment de clientèle

(notamment pour nous adresser des offres commerciales adaptées), opérations

effectuées sur nos comptes (pour éditer les relevés de compte par exemple), litiges ou

difficultés passés ou en cours (inscription dans un fichier de la Banque Centrale, saisie

sur salaire, surendettement…)…

Chapitre introductif 9


Chapitre I:

Présentation générale

Au cours de ce chapitre, nous allons étudier le cadre général du projet. Cette

étude englobe une présentation de la société d’accueil ainsi qu’une spécification du

contexte du projet.

Chapitre I : Présentation 10


1 Présentation de la société HIMILCO MONETIQUE 1.1 Présentation stratégique

Himilco Monétique est une société de services informatiques spécialisée dans la

mise en place de solutions monétiques et de sécurisation des transactions et du

paiement (e-paiement).

Fondée par des spécialistes de la monétique et de la sécurité, Himilco Monétique

accompagne ses clients dans la mise en place de solutions monétiques et de sécurisation

du paiement (e-paiement).

1.2 Description générale de la société

Himilco est une société de monétique adressant les besoins de gestion de flux

monétique et propose des solutions de paiements électroniques sécurisés, selon des

études de marché, le marché monétique en Afrique est estimé à des centaines de

millions de dollars a présent inexploité par les acteurs actuels du marché.

Himilco est spécialisée dans la mise en place de solutions monétiques et de

sécurisation des transactions, Himilco propose ‘ an end to end secure payment system’

software et service, un portefeuille de solutions intégrées permettant le contrôle du

coût des transactions effectuées.

Fondée par des spécialistes de la monétique et de la sécurité, Himilco

accompagne ses clients dans la mise en place de solutions monétiques et l’optimisation

de flux monétiques existants.



Himilco propose des solutions Processus Oriente Client au lieu du processus oriente

compte classique.

Himilco Security

Himilco Kernel

Himilco POS

HimilcoDAC

Himilco Telco

Himilco Web

Himilco LINK

Himilco Mobile

Himilco Autorization

Figure 1 : La Platforme Himilco Monétique



Himilco intervient à tous les stades d’un projet monétique comme expliqué ci-

dessous, notre service Conseil en monétique couvre l'ensemble amont de la chaîne de

valeur de la Monétique et des Systèmes de Moyens de Paiement.

Figure 2 : service Conseil Monétique

Dans le but de satisfaire la demande de la société Himilco Monétique, nous

sommes amenés á concevoir une application informatique qui permet de s’intégrer au

reste des modules que comporte Himilco Platform et dont le rôle principal est de

normaliser le processus d’octroi de carte bancaire.

Cette application doit satisfaire un ensemble de besoins qui se résument dans

(Voir schéma - figure 3-) :

- Mise à jour de la base des règles et des critères des cartes bancaires par le

responsable service

- Le client commande une carte bancaire à partir du site web de la banque

- Réception de la commande par le responsable client pour vérification de la

conformité des données

- Evaluation de la demande par l’analyste



Figure 3: schéma simplifié de l’application

L´application doit satisfaire tous ces besoins ainsi que le besoin de

l´authentification de tout utilisateur du système, d’autant plus que l’application est

destinée aux banques.

L’intégration de ce module a pour principal objectif de permettre aux

organismes financiers émetteurs de mieux évaluer le risque inhérent à l’octroi d’un

produit carte par un système de collecte d’informations où toute donnée est gardée

précieusement, pour que la demande de carte bancaire soit jugée à sa juste valeur.

Pour se faire, un ensemble d’exigences doivent être assurées et qui consistent en :

La rapidité des échanges électroniques qui permet des gains de temps

considérable, pour le client mais aussi pour la banque.

L’amélioration de la qualité des traitements par la quasi élimination du risque

d’erreur de saisie.

Le gain économique qui se traduit par la diminution de l’utilisation du papier et

de l’encre.

L’enrichissement de la base de données de la banque.

La facilité et l’accélération de la commande de carte bancaire.



2 Démarche adoptée

Afin de réaliser les meilleures conceptions et de satisfaire la demande du client,

nous avons suivi un cheminement logique et précis et une démarche bien étudiée.

Cette démarche s’appuie principalement sur les quatre activités du Processus Unifié

Rationnel (la capture des besoins, l’analyse, la conception et la réalisation.) et utilise les

langages de modélisation unifié des données et des traitements UML (Unified

Modeling Language) et de modélisation du processus métiers en utilisant la notation

BPMN (Business Process Management Notation)

Le but de l’utilisation des standards comme UML et BPMN est d’accélérer la mise en

place du projet. La normalisation des échanges entre les différentes parties du processus

(Maîtrise d’ouvrage, maîtrise d’œuvre, et développement) permet d’obtenir le résultat

voulu plus rapidement.

C’est dans ce contexte que s’articule notre démarche qui a été divisée en quatre parties

tel que suit :

• Une première partie qui tourne autour de la capture des besoins fonctionnels et

non fonctionnels selon la méthodologie FURPS+, de l’identification des acteurs

du système et du raffinement des cas d’utilisation.

• Une deuxième partie qui s’articule sur l’analyse de chaque cas d’utilisation

d’une manière détaillée.

• Une troisième partie qui décrit la conception de chaque cas d’utilisation tout en

suivant une démarche bien déterminée qui se résume dans ce qui suit :

L’élaboration du cas d’utilisation détaillé

L’élaboration du diagramme de séquence de conception

Cette partie est clôturée par un diagramme de classe de conception final, d’un

des cas d’utilisation final et d’un diagramme d’activité final.

• Une quatrième partie qui présente les différentes étapes de la réalisation qui

sont :

L’environnement de travail

Le Business Process Diagram

Les interfaces utilisateurs du système

L’évaluation


http://fr.wikipedia.org/wiki/Traitement_de_l%27information


Figure 4: La structure du processus rationnel unifié

Conclusion

Ce chapitre nous a permis d’avoir une vision détaillée sur le contexte du projet

et par conséquent de passer à la spécification des besoins fonctionnels et non

fonctionnels qui seront présentés dans le chapitre suivant.



Chapitre II:

Présentation du Business

Process Management

Beaucoup d’attentions ont été mis sur les processus d’affaires dans les années récentes à cause des baisses dans l’économie globale, forçant les entreprises à améliorer leurs processus afin de maintenir leur rentabilité. Dans ce chapitre, nous allons essayer d’étudier et de définir les aspects généraux de la gestion des processus d’affaires

Chapitre II : Présentation du Business Process Management 17


1 Processus d’affaires :

Le processus d’affaires, appelée également procédure métier, processus

métier, procédure opérationnelle, procédure d’entreprise ou, en anglais, Business

Process désigne « un ensemble d'activités qui s'enchaînent de manière chronologique

pour atteindre un objectif, généralement délivrer un produit ou un service, dans le

contexte d'une organisation de travail (ex : une entreprise, administration, organismes

financiers...).

Les processus d’affaires sont des méthodes, étapes et activités que nous exécutons pour

accomplir nos fonctions. Par exemple, dans la plupart des entreprises, remplir une

commande du client implique plusieurs processus d’affaires, du traitement de la

commande à l’expédition du produit. Il y a des entreprises qui ont des cultures solides

de processus d’affaires; tandis que d’autres sont plus ou moins disciplinés dans les

processus d’affaires.

Une procédure d’entreprise est une procédure qui systématise l’organisation et la

politique d’une entreprise dans le but d’atteindre certains des objectifs de celle-ci

2 BPM (Business Process Management ou gestion des

processus métiers) :

Le BPM associe des méthodes de gestion de processus qui ont fait leur preuve

avec une nouvelle classe d'outils logiciels pour les entreprises. Il permet de gagner

considérablement en vitesse et en agilité pour améliorer les performances d'une

organisation.

2.1 Objectifs :

L’enjeu du BPM est d’unifier, sous un seul outil, toutes ces visions, pour fournir

à l’entreprise la possibilité de définir ses processus au niveau métier, et de faire

intervenir les utilisateurs et les applications de l’entreprise en tant que partie prenante à

ces processus. L’objectif est de permettre aux décideurs, analystes métiers, équipes

fonctionnelles et équipes techniques de collaborer pour la définition et l’évolutivité des

processus métiers via un seul outil agrégeant les différentes visions.



2.2 Les trois dimensions du BPM :

Un processus métier est modélisé en plusieurs niveaux, et plus généralement en

trois niveaux :

2.2.1 Le niveau métier :

Il définit les principales étapes du processus métier et son impact sur

l’organisation de l’entreprise. Ce niveau est défini par les décideurs, et les équipes-

méthodes de l’entreprise.

2.2.2 Le niveau fonctionnel

Formalisation des interactions entre les participants fonctionnels du processus,

où sont formalisées les règles métiers conditionnant son déroulement. Ce niveau est

modélisé par les équipes fonctionnelles.

2.2.3 Le niveau technique

Le niveau technique est le lien entre les activités / participants modélisés dans le

niveau fonctionnel, et les applications ou services du Système d’Information, ainsi que

les tâches utilisateurs (Workflow « flux de travail »). Ce niveau est réalisé par les

architectes et les équipes techniques de l’entreprise.

2.3 La gestion des processus d’affaires concerne:

- L’organisation des affaires autour des processus (se concentrant sur la

satisfaction du client).

- La clarification et la documentation des processus.

- La surveillance de la performance des processus et de la conformité.

- L’identification continuelle des opportunités pour leurs améliorations et pour

leurs implémentations.

Dépendant des priorités de l’entreprise, ces quatre aspects de la gestion des

processus d’affaires peuvent être implémentés individuellement soit pour des processus

particuliers soit pour tous les processus. Par contre, l’implémentation des quatre aspects

ensembles aura un impact plus significatif sur le volume d’affaires traité.



2.4 Avec le BPM :

- Les responsables fonctionnels peuvent plus facilement mesurer, gérer et

contrôler tous les aspects et les éléments de leurs processus opérationnels.

- Les responsables informatiques peuvent directement mettre leurs compétences

et leurs ressources au service du métier.

- Les employés d'une entreprise peuvent mieux coordonner leurs efforts et

améliorer leurs productivités et leurs performances personnelles.

- L'entreprise dans son ensemble peut répondre plus rapidement aux

transformations et aux défis de son marché pour continuer à atteindre ses

objectifs.

3 BPMN (Business Process Modeling Notation):

BPMN est une notation graphique (éléments graphiques et diagrammes), utilisée

pour représenter un Processus métier en séparant les informations métier des

informations techniques. Elle fournit une correspondance vers des langages

d'exécution. C'est l'équivalent d'UML appliqué à la gestion des processus. Une

modélisation basée sur BPMN peut ensuite être traduite en BPML ou en BPEL4WS

(plus communément appelée BPEL).

Cette notation représente plus de deux ans de travail pour BPMI (Business

Process Management Initiative). Ce consortium d’entreprises créé par Intalio a su

rassembler les leaders du marché du BPM. Il s’est affirmé en innovateur depuis

quelques années sur le BPM. Membre de l’OASIS, OMG, W3C et WfMC, son premier

objectif est d’établir une notation compréhensible par les utilisateurs : des analystes aux

développeurs en passant par les acteurs qui gèrent et mesurent les processus.

BPMN définit des diagrammes de processus appelés flowcharts, c'est-à-dire des

modèles graphiques où s’enchaînent des activités et des indicateurs.

Même si BPMN n’est pas encore utilisé par tous les éditeurs, la représentation des

objets se retrouve plus ou moins en standard dans la plupart des outils.



Le BPMN réconcilie modélisation des processus métier et besoin de l’informatique.

Cette notation a ses avantages mais on observe une faiblesse, les objets sont

élémentaires.

Quel est l’intérêt de modéliser avec la notation BPMN ? : Cette notation permettra une

interopérabilité entre différentes applications, de la modélisation à l’exécution des

processus.

Pour conclure la modélisation des processus, souvent sous-estimées dans des projets,

permet et facilite l’adhésion et la compréhension des acteurs des projets.

4 De BPMN à BPEL, de la modélisation à l’exécution… :

Dans le monde de l’exécution des processus, BPEL4WS est devenu le langage

phare. Plus communément appelé BPEL, BPEL4WS est un langage de programmation

qui permet de définir une activité par la combinaison de Services Web. Annoncé en

2003 par BEA, IBM et Microsoft, il est basé sur WSFL (Web Services Flow

Language). BPEL a été crée à l’initiative de BPMI et doit encore être approuvé par

l’OASIS.

En fait, les futures spécifications validées par l’OASIS ne changeront pas

fondamentalement BPEL. En effet, le groupe de travail d’OASIS n’a pas pris de

décision clé. Quand les éditeurs n’étaient pas d’accord avec certaines spécifications, il a

volontairement laissé des « trous » dans le standard pour que les éditeurs les

remplissent selon leurs propres spécifications. Pour compléter cette version standard,

les clients devront alors obtenir les extensions des éditeurs et il sera impossible de faire

le lien entre le BPEL d’un éditeur à l’autre.

Bien que la version de BPEL ne soit pas encore officielle, beaucoup d’outils

disent le supporter. En fait, chaque éditeur a mis en œuvre et complété son propre

langage BPEL – une sorte de BPEL propriétaire - à partir d’un support commun. On

peut cependant espérer que les spécifications finales seront rapidement validées par

l’OASIS et que les éditeurs modifieront en conséquence leur version pour y être

conforme.



5 BPMS :

Noterez souvent à la fin du sigle BPM. Le « S » de BPMS signifie « Suite ». Le BPMS est une suite logicielle d'outils BPM qui comprend des modules

fonctionnels, des fonctionnalités techniques et une architecture sous-jacente intégrés

dans un environnement unique qui met en œuvre tous les aspects de la technologie

BPM de façon homogène. Les suites BPM sont des packages complets.

Architecture d’un système complet de BPMS :

Figure 6: L'architecture technologique du BPM



Un outil de modélisation. C'est évidemment le cœur du système. C'est lui qui servira à

formaliser la description des fonctions exercées dans l'entreprise en processus, en

applications informatiques. Il permettra de définir également les données échangées, les

interfaces avec les autres modules.

Des outils de développement. Ils permettront de formaliser la logique qui régit les

processus de l'entreprise, à énoncer les règles de fonctionnement.

Un moteur d'exécution. Il supervisera le déroulement des processus ainsi que les

échanges de paramètres.

Un moteur de règles. Il évaluera l'état de tous les objets impliqués dans le déroulement

des processus et déterminera si les conditions sont remplies pour en lancer, poursuivre

ou arrêter l'exécution.

Un référentiel. Il mémorisera tous les objets manipulés, en particulier les définitions

des processus, les règles qui doivent déclencher leur exécution, les contraintes

d'intégrité, de sécurité ainsi que les mesures de référence relatives au métier de

l'entreprise.

Des outils d'administration. Ils permettront de régler les paramètres de l'ensemble du

système et d'obtenir des indicateurs de performance et des statistiques à partir des

données collectées lors de l'exécution des processus.

6 Conclusion :

Sur le plan pratique, une suite d’outils de gestion des processus (BPM) assiste

l’entreprise dans son fonctionnement et permet aux acteurs Direction Service

Informatique, et aux directeurs des unités organisationnelles ou directions d’assurer et

atteindre les objectifs stratégiques de leurs métiers.

Apres avoir vue en détail ce qu’est un BPM, nous passerons à la phase de

capture des besoins, pour spécifier la nature du projet.



Chapitre II :

Capture des besoins et

analyse

Cette étape de conception va nous permettre de préciser l’étude du contexte du futur

système en décrivant les façons qu’auront les acteurs de l’utiliser.

Ce chapitre a pour principal objectif la spécification des besoins fonctionnels et

non fonctionnels de l’application.

Chapitre III : Capture des besoins et analyse

24


1 Contexte du système

Nous avons cherché une solution pour permettre aux organismes financiers

émetteurs de mieux évaluer le risque inhérent à l’octroi d’un produit carte. Nous avons

donc cherché à définir des critères d’évaluation (relatif à chacun des produits carte) et

d’y associer un système de pondération ; et ce, dans l’objectif d’identifier et de mesurer

les facteurs de risque conduisant à l’acceptation ou le rejet de la demande.

L’éligibilité d’un client à un produit carte est en fonction de son score par rapport à la

classification des produits carte de l’institution.

Le système devrait avoir, pour les organismes financiers émetteurs, les opportunités et

les valeurs ajoutées suivantes :

- Maîtrise du risque

- Profitabilité accrue

- Réactivité et pertinence dans le traitement des demandes

Ainsi que les points forts et atouts suivants :

- Solution ouverte

- Multi-produit carte

- Paramétrable : choix des critères d’évaluation et du système de pondération

Quelles sont les contraintes ?

Deux critères importants doivent être pris en considération lors de la conception de la

solution :

- La flexibilité : les besoins des clients sont définis au fur et à mesure de

l’avancement du projet.

- Extensibilité : de nouveaux besoins peuvent être exprimés par les clients à tout

moment.


25


1.1 Identification des besoins fonctionnels :

Le système comporte quatre acteurs :

- Le client : un client de la banque demandant une carte bancaire.

- Le responsable client : l’administrateur du système.

- Le responsable service : l’agent de la banque.

- L’analyste : l’analyste financier de la banque.

Le système comporte cinq modules, à savoir :

Module d’authentification : ce module permet d’identifier les utilisateurs de

l’application.

Module création d’une nouvelle demande : ce module permet au client de

commander une carte bancaire en ligne.

Module vérification des données : ce module permet au responsable client de

vérifier les conformités des informations du client.

Module gérer le système : ce module permet au responsable service de gérer la

base des règles ainsi que les caractéristiques des cartes bancaires.

Module évaluation : permet à l’analyste d’évaluer les demandes afin de donner

un score à la demande.


26


1.2 Méthode d’indentification des besoins: Furps+

L'obligation est définie comme « une condition ou une capacité d'un système qui

doit être conforme».

Il existe de nombreux types d'exigences. Une façon de classer entre eux est décrit

comme le FURPS + modèle [GRA92], en utilisant l'acronyme FURPS de décrire les

grandes catégories de besoins avec des sous-catégories,

Comme indiqué ci-dessous :

- Functionality (Fonctionnalité)

- Usability (Facteur humain)

- Reliability (Fiabilité)

- Performance (Performance)

- Supportability (Possibilité de prise en charge)

Le "+" dans FURPS + rappelle à inclure de telles exigences comme:

- Contraintes de conception

- exigences de mise en œuvre

- exigences en matière d'interface

- conditions matérielles.


27


1.2.1 Fonctionnalités du système :

Identification du client

Le client saisie ses informations

Le client choisi une carte

Identification du responsable client

Le responsable client consulte les demandes de crédit en cours

Le responsable client reçoit la demande de carte du client avec la carte souhaitée

Le responsable client vérifie les informations du client

Le responsable client, si besoin, modifie, ajoute les informations du client

Identification de l’analyste

L’analyste note les informations du client sans voire les données personnelles du client

L’analyste lance le calcule du score

Identification du responsable système

Le responsable système gère la base de règles de pondération

Le responsable système gère les types des cartes dans l’établissement bancaire

Le responsable système gère les utilisateurs

1.2.2 Usage :

Les facteurs humains:

Utilisateurs expérimentés dans le domaine informatique

Formations des utilisateurs

Interface utilisateur :

Ergonomique

Eviter les couleurs liées au daltonisme

Les instructions doivent être compréhensibles

Guider le client avec des écrans.

Les menus, les icônes sur l’écran doivent être faciles à utiliser.


28


1.2.3 Fiabilité

L’efficacité : l’application doit fournir des réponses exactes et fiables.

La robustesse : l’application doit respecter des cohérences de traitement des

informations.

L’extensibilité : l’application doit être capable de faire face à des charges d'utilisation

variables. En effet, la consommation de ressources doit être la plus linéaire et la plus

prévisible possible.

L’évolutivité : l’application doit évoluer afin de satisfaire aux exigences de

performances croissantes

1.2.4 Performance

La rapidité et performance: Elle doit offrir un temps de réponse minimal pour le

téléchargement et l’affichage des pages.

L’écran doit guider les clients pour faciliter l’utilisation et diminuer le temps de

traitement de la demande.

Le temps de calcul du score doit être assez cours.

1.2.5 Possibilité de prise en charge

Installer et mettre à jour facilement l’application, la surveiller, localiser les problèmes,

Modifier sa configuration si nécessaire.

Installer sans avoir de problèmes.

Supporter l’augmentation de la charge.

Possibilité de modifier les fonctionnalités à des coûts raisonnables. (Extensibilité)

Possibilité de comprendre sans efforts excessifs l’organisation interne et le

fonctionnement du système et d’y apporter des modifications.


29

http://www.tout-savoir.net/lexique/definition/1299/capacite/

http://www.tout-savoir.net/lexique/definition/2364/donc/


1.2.6 Obligation de mise en œuvre

La stratégie de sécurité d'authentification ainsi que les politiques de l'intégrité de la

base de données seront adaptées à la stratégie de la banque. Cependant l’application

doit permettre l’identification des utilisateurs, la fiabilité, la confidentialité et

l’intégrité des données.

1.2.7 Exigence d’interface

La convivialité : l’application doit prévoir une facilité d’utilisation et d’accès aux

informations.

Interaction : l’application doit respecter et améliorer le dialogue entre Homme et

Machine et doit satisfaire les besoins du client.

1.3 Identification des acteurs et des cas d’utilisations

1.3.1 Les acteurs

• Le client

• Le responsable service

• Le responsable client

• L’analyste

1.3.2 Les cas d’utilisations

• S’authentifier

• Créer une nouvelle demande

• Vérifier les informations

• Evaluer la demande

• Gérer le système


30


1.4 Représentation du modèle de cas d’utilisation initial

Figure 6 : Modèle de cas d’utilisation initial


31


1.5 Raffinement des cas d’utilisations

1.5.1 Raffinement du cas d’utilisation « s’authentifier »

Ce raffinement présente le diagramme du module « Authentification »

Figure 7 : cas d'utilisation "s'authentifier"

Cas d’utilisation : « S’authentifier »

Acteurs Principal: Client, responsable client, responsable service, analyste

Pré conditions : pour le client : avoir un compte à la banque, pour les

autres : être un employé de la banque

Post-conditions : utilisateur authentifié

Description du scénario :

L’utilisateur s’identifie en saisissant son nom d’utilisateur et son mot de

Passe.

Le système vérifie leurs existences :

− Si le nom d’utilisateur et le mot de passe sont valides, l’utilisateur

sera connecté au système et dirigé vers la page qui lui est destinée

− Si le nom d’utilisateur et le mot de passe sont invalides, une

interdiction d’accès est signalée.


32


1.5.2 Raffinement du cas d’utilisation « créer une nouvelle demande »

Ce raffinement présente le diagramme du module « créer une nouvelle demande »

Figure 8 : cas d'utilisation "créer une nouvelle demande"

Cas d’utilisation : « Créer une nouvelle demande »

Acteurs Principal: Client.

Pré conditions : Client authentifié.

Post-conditions : Demande effectuée

Description du scénario : Le client rempli le formulaire puis choisi le carte

qu’il souhaite avoir.

1.5.3 Raffinement du cas d’utilisation « vérifier les informations »

Ce raffinement présente le diagramme du module « vérifier les informations »

responsable client vérifier les informations

Figure 9 : cas d’utilisation « vérifier les informations »


33


Cas d’utilisation : « Vérifier les informations »

Acteurs Principal: Responsable client.

Pré conditions : Responsable client authentifié, demande créée.

Post-conditions : vérification effectuée.

Description du scénario : Le responsable client vérifie la conformité des

données que le client a enregistrées.

1.5.4 Raffinement du cas d’utilisation « gérer le système»

Ce raffinement présente le diagramme du module « gérer le système »

gèrer la base de règle

gèrer les cartes

gèrer les utilisateurs

responsable service gèrer le système

<<extend>>

<<extend>>

<<extend>>

Figure 10 : cas d’utilisation « gérer le système»

Cas d’utilisation : « Gérer le système »

Acteurs Principal: Responsable service.

Pré conditions : Responsable authentifié.

Post-conditions : aucune.

Description du scénario : Le responsable service gère la base de règle et

les caractéristiques des cartes.


34


1.5.5 Raffinement du cas d’utilisation « évaluer la demande»

Ce raffinement présente le diagramme du module « évaluer la demande »

évaluer la demandeanalyste noter les informations

<<include>>

Figure 11 : cas d’utilisation « évaluer la demande»

Cas d’utilisation : « évaluer la demande »

Acteurs Principal: Analyste.

Pré conditions : analyste authentifié, informations vérifiées, base de règle

mise à jour.

Post-conditions : évaluation effectuée.

Description du scénario : L’analyste reçoit les informations pertinentes de

la demande à évaluer et note chaque information.

2 Etude de l’architecture : Après avoir exprimé les besoins fonctionnels et non fonctionnels, nous pouvons

maintenant procéder à la définition de l’architecture de notre système et à la réflexion

aux choix techniques correspondants.

2.1 Plateforme :

Une plateforme de gestion des processus d’affaires donne de la capacité de

définir collectivement les processus, de les déployer en tant qu’applications accessibles

sur le Web et qui sont intégrées aux logiciels et systèmes existants d’une organisation.

Elle permet de s’adapter et de s’arrimer aux systèmes des clients, partenaires et

fournisseurs.


35


Cette plateforme permet de s’intégrer avec les systèmes opérationnels existants

comme les progiciels de gestion de type ERP, CRM ou SCM et avec les bases de

données.

En effet, ce type d’architecture permet non seulement un développement

modulaire d’une application mais aussi garantie sont évolutivité.

2.2 Composants d’un BPMS type :

Figure 12 : composant d'un BPMS type

2.3 Architecture n-tiers :

Dans une plateforme de gestion de processus d’affaires, nous adaptons une

architecture de 3-tiers (architecture à trois niveaux).

L’architecture trois tiers est l'application du modèle le plus général qu'est le multi-tiers

et c’est également une extension du modèle client/serveur.

L'architecture logique du système est divisée en trois niveaux ou couches :

• Couche présentation

• Couche métier

• Couche accès aux données


36


Plus spécifiquement c’est une architecture partagée entre :

• Un client, c'est-à-dire l’ordinateur demandeur de ressources, équipée d'une

interface utilisateur chargée de la présentation ;

• Le serveur d'application (appelé également middleware), chargé de fournir la

ressource mais faisant appel à un autre serveur ;

• Le serveur de données, fournissant au serveur d'application les données dont il a

besoin.

Niveau1 Niveau2 Niveau3

Client

Envoi de Requêtes

Envoi de Réponses

Serveur d’application

Serveur de bases de données

Requête SQL

Figure 13 : Architecture Trois Tiers

3 Conclusion Ce chapitre nous a permis de mieux connaître et comprendre nos besoins

fonctionnels et non fonctionnels par l’étude et le raffinement des différents cas

d’utilisation. Ce qui nous donne la possibilité de passer à l’analyse de ces cas qui sera

traitée dans le prochain chapitre.


37


Chapitre IV:

Conception

Ce chapitre a pour principal objectif de structurer et comprendre

l’application et de modéliser le problème d’une façon orienté objet.

En effet, le modèle d’analyse détaille les cas d’utilisation et procède à une première

répartition du comportement du système entre divers objets.

Chapitre IV : Conception 38


1 Conception du cas d’utilisation « s’authentifier » 1.1 Description textuelle du cas d’utilisation « s’authentifier » Nom Authentification use case ID UC001 Acteurs principaux Employé : responsable client, responsable système, analyste Acteurs secondaires

Description

L’employé saisie le nom d’utilisateur et le mot de passe, il sera dirigé soit vers gérer les demandes s’il est responsable client, soit vers gérer le système s’il est responsable service soit vers l’évaluation de la demande

Pré-conditions Le système doit être ouvert et la connexion avec la base doit être effectué

Scénarios

1. L’employé saisi le nom d’utilisateur et le mot de passe 2. Le système vérifie s’ils sont corrects 2.1 Si les deux champs sont incorrects, un message d’erreur : veuillez vérifier le login et/ou le mot de passe 2.2 Si les deux champs sont corrects : 2.2.1 il sera dirigé vers « gérer les demandes » s’il est Responsable Client 2.2.2 il sera dirigé vers « gérer le système » s’il est Responsable Service 2.2.3 il sera dirigé vers « évaluation » s’il est analyste

Post-conditions

Le Responsable Client peut vérifier et modifier les informations du client Le Responsable Service peut gérer le système L’analyste peut évaluer les demandes

Priorité Haute

Scénario alternatif Le directeur peut ouvrir le système grâce à son login et mot de passe unique



1.2 Cas d’utilisation « s’authentifier » détaillé

Figure 14: Cas d'utilisation "s'authentifier"



2 Conception du cas d’utilisation « gérer le système » 2.1 Description textuelle du cas d’utilisation « gérer le système » Nom Gérer système use case ID UC002 Acteurs principaux Responsable service Acteurs secondaires

Description Le responsable service gère les utilisateurs, la base de règle et les cartes

Pré-conditions Le responsable service doit s’être authentifié

Scénarios

1. Le responsable service choisi de gérer soit les utilisateurs soit la base de règle soit les cartes

2. Le responsable service peut ajouter ou supprimer les utilisateurs ou leurs informations

3. Le responsable service choisie les informations à noter ainsi que leur pondérations

4. Le responsable service peut ajouter, supprimer ou modifier les cartes ainsi que leur score

Post-conditions Les informations des utilisateurs, les cartes et les bases de règles sont mises à jour

Priorité Haute

Scénario altérnatif Le directeur peut ouvrir le système grâce à son login et mot de passe unique



2.2 Cas d’utilisation « gérer système » détaillé

Figure 15 : cas d'utilisation "gérer système"



2.3 Diagramme de séquence du cas d’utilisation « gérer le système »

: Responsable service

: interface Authentification

: gérer cartes : gérer utilisateurs

: gérer base de régle

s'autentifier

réponse

mettre à jour

mettre à jour

mettre à jour

alt

Figure 16 : Digramme de séquence du cas d'utilisation " gérer système"



3 Conception du cas d’utilisation « Créer une nouvelle

demande de carte» 3.1 Description textuelle du cas d’utilisation « Créer une nouvelle

demande de carte» Nom Créer une nouvelle demande de carte use case ID UC003 Acteurs principaux Client Acteurs secondaires Description Le client s’authentifie, puis saisi ses informations

Pré-conditions Le client doit être un client de la banque Le client doit s’être authentifié

Scénarios 1. Le client choisi entre entreprise ou particulier 2. Le client rempli le formulaire 3. Le client choisi la carte souhaité

Post-conditions Le client a rempli le formulaire et le formulaire a été envoyé Priorité Haute

Scénario altérnatif Le responsable client peut remplir les informations que le client n’a pas fournies

Nombehavional Assomption Le client doit avoir un compte à la banque



3.2 Cas d’utilisation « Créer une nouvelle demande de carte » détaillé

Figure 17 : cas d'utilisation "créer nouvelle demande"



3.3 Diagramme de séquence du cas d’utilisation « Créer une nouvelle

demande de carte»

Figure 18 : diagramme de séquence du cas d’utilisation « créer nouvelle demande »



4 Conception du cas d’utilisation « Vérification» 4.1 Description textuelle du cas d’utilisation « Vérification» Nom Vérification use case ID UC004 Acteurs principaux Responsable client Acteurs secondaires Système d’échange bancaire, SI de la banque

Description Le responsable doit vérifier les informations de chaque demande, il compare le formulaire obtenu avec les informations du systeme d’echange bancaire et de la banque

Pré-conditions Notification de chaque donnée collectée La demande est prête à être évaluée

Scénarios

1. le système fait appel à une fonction 2. le système fait appel aux notes des données utiles 3. le système fait appel aux pondérations des données utiles 4. l’agent lance le calcul du CS 5. le système calcul le CS 6. Le système recommande 0, 1 ou plusieurs cartes aux client

suivant le score obtenu et les cartes existantes Post-conditions Priorité Haute

Scénario altérnatif Si la fonction choisie ne correspond pas aux données saisies, il y a retour à la page : « choisir fonction »

Nombehavional Seule l’administrateur peut gérer les fonctions et les pondérations Assomption Le client doit avoir un compte à la banque



4.2 Cas d’utilisation « Vérification» détaillé

Figure 19 : cas d’utilisation « vérifier les données »



5 Conception du cas d’utilisation « Evaluation» 5.1 Description textuelle du cas d’utilisation « Evaluation» Nom Evaluation use case ID UC005 Acteurs principaux Analyste Acteurs secondaires

Description L’analyste note les informations du client et lance le calcule du score

Pré-conditions Les informations du client sont collectées par l’agent La demande est prête à être évaluée

Scénarios

7. L’analyste reçoit les informations pertinentes du client 8. L’analyste donne une note à chaque information 9. L’analyste lance le calcul du score 10. Le système calcul le score 11. Le système recommande 0, 1 ou plusieurs cartes aux client suivant le score obtenu et les cartes existantes

Post-conditions Le score est calculé Priorité Haute Scénario alternatif Nombehavional Seule le responsable système peut gérer les informations à noter et

leur pondération



5.2 Cas d’utilisation « Evaluation» détaillé

Figure 20 : cas d'utilisation "évaluer la demande"



5.3 Diagramme de séquence du cas d’utilisation « Evaluation»

Figure 21 : Diagramme de séquence du cas d'utilisation " évaluer demande"



Chapitre IV : Conception

52

6 Conception cas d’utilisation général



53

7 Conception du diagramme de classe général


8 Conception du diagramme d’activité général


54


9 Conclusion Cette analyse des différents cas d’utilisation nous a permis d’effectuer une

spécification plus précise des besoins et nous a servi de base à une réflexion sur les

mécanismes internes du système.

Ceci constitue une entrée essentielle pour la réalisation du modèle conceptuel du

système que nous allons présenter dans le prochain chapitre.



Chapitre I :

Réalisation

Dans ce chapitre nous allons parler de la phase de réalisation de l’application nous allons parler en 1er lieu de notre choix de l’environnement du travail, ou on y spécifiera l’environnement matériel et l’environnement logiciel qu’on a utilisé pour réaliser notre application. Enfin nous allons exposer quelques interfaces de l’application.

Chapitre V : Réalisation 56


1. Environnement de travail :

1.1 Choix du BPMS : Intalio est aujourd’hui le premier système Open Source de gestion des processus

d’affaires (BPMS) et se distingue par son efficacité redoutable et sa prise en main

relativement facile par rapport à ses concurrents propriétaires. Intalio|BPMS permet de

couvrir le cycle complet d’un projet de BPM, de la modélisation jusqu’à l’amélioration,

en passant par le déploiement.

Intalio se distingue par son respect des standards dominants dans les BPMS

modernes: modélisation des processus en BPMN et génération automatique du code en

BPEL et des Web Services en respectant le protocole SOAP et REST. Intalio fut aussi

le premier à implémenter BPEL4People, un standard aujourd’hui qui permet de décrire

les patrons d’activités humaines.

1.2 Environnement Matériel Cette application a été développée sur 2 machines possédant les caractéristiques

suivantes :

PC Laptop numéro 1:

- Processeur : Intel(R) Pentium(R) Dual CPU T2310 @ 1.46GHz

- Mémoire Vive : 2048 MBytes (DDR2)

- Disque Dur : 160 GO

- Système d’exploitation : Microsoft XP Sweet 5.1

PC Laptop numéro 2:

- Processeur : Intel(R) Core ™ 2 duo CPU T5750 @ 2.00 GHz

- Mémoire Vive : 1.99 Go (DDR2)

- Disque Dur : 240 GO

- Système d’exploitation : Microsoft XP Sweet 5.1



1.3 Environnement logiciel : 1.3.1 Intalio|BPMS Community Edition:

Dans le cadre de notre projet nous avons choisit de travailler avec Intalio|BPMS

Community Edition: le premier BPMS complet entièrement gratuit.

Intalio|BPMS est aujourd’hui le premier système Open Source de gestion des

processus d’affaires (BPMS) et se distingue par son efficacité redoutable et sa prise en

main relativement facile par rapport à ses concurrents propriétaires. Intalio|BPMS

permet de couvrir le cycle complet d’un projet de BPM, de la modélisation jusqu’à

l’amélioration, en passant par le déploiement.

Intalio permet à l'entreprise de dynamiser l'ensemble de ses ressources en

accélérant la conception, la reconfiguration et l'exécution de ses processus métier.

Intalio libère l'adoption de solution Business Process Management en offrant

une suite d'applications pour gérer le cycle de vie de processus métiers complexes.

Intalio se distingue par son respect des standards dominants dans les BPMS

modernes: modélisation des processus en BPMN et génération automatique du code en

BPEL et des Web Services en respectant le protocole SOAP et REST. Intalio fut aussi

le premier à implémenter BPEL4People, un standard aujourd’hui qui permet de décrire

les patrons d’activités humaines.

D’un point de vue fonctionnel, Intalio se décompose en trois parties principales :

Intalio|Designer, Intalio|Server et Intalio|Workflow :

Le Designer permet de transcrire l’enchainement des étapes du processus

d’affaires sous la forme d’un graphique fonctionnel (en BPMN). Celui-ci est ensuite

transformé par l’outil, déployé en un seul clic et exécuté côté serveur.

Le serveur permet l’exécution des processus fabriqués dans le Designer.

Intalio|Workflow prend en charge les interactions du processus avec les utilisateurs

finaux, participant au processus. Avec un déploiement à chaud des processus et une

gestion des versions intégrée, vous obtenez un outil qui se démarque par son efficacité

rarement vue dans le monde de l’intégration.



En effet Intalio décline l'unique solution complète de Business Process

Management (BPM) qui réconcilie Maîtrise d'ouvrage et Maîtrise d'œuvre en trois

formats:

La définition technique de la solution:

Plate-forme de conception et d'exécution de processus tirant parti des standards

du marché (BPMN, BPEL 2.0, J2EE, Web Services).

Intalio|BPMS Server fédère l'ensemble des ressources (techniques et humaines)

impliquées dans un processus.

Avec Intalio|BPMS Server :

• Les processus sont nativement décrits dans sémantiques standard (BPEL 2.0)

• L'intégration avec les systèmes techniques repose sur des composants

middleware banalisés aptes à couvrir les systèmes existants

• L'interaction avec les collaborateurs s'appuie sur des interfaces de workflow

intégrables dans une infrastructure de portail.

Architecture Intalio :

La structuration de l'offre :

Intalio|BPMS Server

Plate-forme d'exécution des processus, Intalio|BPMS Server associe ces processus aux

ressources humaines et/ou techniques correspondantes.

Intalio|BPMS permet l'exécution de processus BPEL 2.0

Intalio|BPMS Designer

Capable de récupérer les travaux de modélisation déjà menés dans un outil tiers tel que

IDS-Scheer ARIS, Intalio|BPMS Designer rend exécutables les processus ainsi

importés.

C'est donc à travers Intalio|BPMS Designer que les processus sont associés aux

systèmes techniques et aux collaborateurs impliqués. Intalio|BPMS Designer est intégré

à Eclipse



Intalio|BPMS Workflow

Intalio|BPMS Workflow est une solution unique de Workflow basée sur le

standard BPEL4People développé par IBM et SAP compatible avec des portails JSR-

168.

Intalio|BPMS Workflow offre une implémentation AJAX basée sur XForms

permettant une interaction avec les différents "workflow patterns" orchestrés par

Intalio|BPMS Server.

1.3.2 EasyPHP :

EasyPHP est un package qui installe et configure automatiquement un

environnement de travail permettant de mettre en œuvre toute la puissance et la

souplesse qu’offre le langage dynamique PHP et son support efficace des bases de

données. Il regroupe un serveur Apache, un serveur de base de données MySQL, ainsi

que des outils facilitant le développement web et logiciel.

1.3.3 MYSQL :

MySQL est un système de gestion de base de données (SGDB). Selon le type

d'application, sa licence est libre ou propriétaire. Il fait partie des logiciels de gestion de

base de données les plus utilisés au monde, autant par le grand public (applications web

principalement) que par des professionnels, en concurrence avec Oracle ou Microsoft

SQL Server.

1.3.4 Rational Rose :

Rational Rose est un outil de référence pour la modélisation UML. Il est

devenu en quelques années l’outil le plus utilisé dans la conception logiciel. Il permet

une modélisation aisée et rapide grâce à son interface graphique facile.

Sa coopération étroite avec les environnements de développement majeurs est réalisée

par une intégration directe et native.



Chapitre V : Réalisation

61

2. Le Business Process Diagram :


1. Présentation de quelques interfaces :

3.1Interface authentification du système :

Figure 26: Interface "authentification"

L’utilisateur s’authentifie et il est redirigé automatiquement vers l’une des interfaces

du système dépendamment de son privilège (client, responsable client, responsable de

service, analyste).



3.2 Interface « choix du responsable service» :

Veuillez choisir :

Figure 27 : Interface "choix du responsables service"

3.2.1 Interface « Mises à jour des pondérations» :

Figure 28 : Interface de la Mise à jour des de la pondération



3.2.2 Interface « Mise à Jour des cartes » :

Figure 29 : Interface de la Mises à jour des cartes

3.2.3 Interface « Mises à jour des utilisateurs» :

Figure 30 : interface de la "mise à jour des utilisateurs"

3.3 Interface « choix du type de client »

Figure 31 : interface du "choix du type de client "



D’après son choix, le client est dirigé soit vers la page « particulier » soit vers la page « entreprise ».

3.3.1 Interface « particulier » :



Figure 32 : Interface du "formulaire du particulier"

3.2.2 Interface « entreprise » :



Figure 33 : Interface du "formulaire de l'entreprise"



3.3 Interface « vérification du responsable client» :

3.3.1 Interface « vérification entreprise» :



Figure 1: Interface "vérification des informations de l’entreprise



3.3.2 Interface « vérification particulier» :

Figure 35: Interface de "vérification des informations du particulier"



3.4 Interface « notation des informations » :

Figure 36 : Interface « notation des informations »

3.5 Interface « Résultat demande »

Figure 37 : interface de « résultat demande »



4 Evaluation :

Cette solution que nous avons conçue peut être considérée comme performante

puisqu’elle a permit de normaliser le processus d’affaire de répondre aux besoins réels

du métier tout en respectant les contraintes et les règles.

Cette application, pouvant être perçu comme étant un prototype (version 1.0),

sera soumise à une batterie de tests. Dans un premier lieu, les tests nous permettront de

vérifier si l’application conçue répond aux besoins spécifiques. En deuxièmement lieu,

ils permettront également de faire sortir les défauts et les corrigés. Enfin, dans un

troisième lieu, les tests permettront d’optimiser les performances de l’application.

Une fois les tests terminés l’application sera prête pour être intégrée au sein

d’Himilco Platform.

5 Conclusion : Dans ce dernier chapitre, nous avons pu présenter l’environnement et le

processus de développement. Nous avons exposé ainsi le résultat de développement à

l’aide des aperçus écran. Nous avons clôturé par une évaluation du travail réalisé.



Conclusion

Nous avons essayé de modéliser une application paramétrable permettant à un

client de commander une carte bancaire depuis son fauteuil, et que cette commande soit

jugée à sa juste valeur.

En effet, grâce au BPMS, nous avons pu créer un processus de travail répondant

aux besoins que nous avons décelés pendant toute cette période.

Notre projet de fin d’étude nous a été d’un grand apport sur plusieurs plans, tout

d’abord sur le plan de la communication, nous avons due collecter les informations de

part et d’autre, pour pouvoir ensuite analyser les besoins, d’autre part nous avons appris

à gérer et normaliser des processus d’affaires. Sur le plan logiciel nous pouvons dire

que nous avons appris à maîtriser Intalio|BPMS, qui est considéré comme un outil très

puissant et leader du marché.

Conclusion Générale 74


Glossaire

Scoring : le scoring est un outil utilisé par les organismes de financement afin de

qualifier votre éligibilité au financement. Construit sur l'historique du fichier client, il

analyse vos revenus, votre situation professionnelle, votre ancienneté dans votre

entreprise, votre situation matrimoniale, la présence d'enfants à charge, le taux

d'endettement, votre capacité d'épargne et votre âge.

Il vise à définir des profils type de personne pour lesquelles le prêt présentera un risque

important de non recouvrement des créances. Cela permet aux organismes de

financement de limiter les situations de surendettement de leurs clients.

Score : note globale attribuée lors d’une demande d’une carte bancaire ou d’un crédit.

Cette note est établie en fonction de critères disposant chacun d’une notation élaborée à

partir de données statistiques. A une certaine plage de montants de points, variable

selon les organismes, tel ou carte bancaire est accordée.

Glossaire 75


Processus Unifié : Le processus unifié est un processus de développement logiciel qui

regroupe les activités à mener pour transformer les besoins d’un utilisateur en système

logiciel. Mais c’est plus qu’un simple processus. C’est un framework de processus

générique pouvant être adapté à une large classe de systèmes logiciels, à différents

domaines d’application, à différents types d’entreprises, à différents niveaux de

compétence et à différentes tailles de projets.

Rational Unified Processus : Le Rational Unified Process affine, mettre à jour et

détaille le Processus Unifié plus général. Il précise également tous les artefacts, les

activités ainsi les rôles, fournit des lignes directrices et comprend des modèles pour la

plupart des artefacts …

Le produit RUP : Le produit RUP constitue une documentation cohérente et bien

conçue décrit le Rational Unified Process, présentée sous forme de pages HTML et

vendue par Rational (une division d’IBM).

BPM (la gestion des processus métier) :C’est un ensemble de méthodes, d'outils et de

technologies utilisés pour concevoir, mettre en œuvre et contrôler des processus métier

opérationnels. Le BPM est une approche centrée sur les processus pour améliorer les

performances, qui associe technologies de l'information et méthodologies de processus

et de gouvernance. Le BPM est le fruit d'une collaboration entre des professionnels du

métier (responsables fonctionnels et/ou opérationnels) et des informaticiens pour

favoriser la mise en place de processus métier efficaces, souples et transparents. Le

BPM englobe des personnes, des systèmes, des fonctions, des métiers, des clients, des

fournisseurs et des partenaires.

Processus métier :

Le terme de « processus métier » est souvent utilisé à tort et à travers pour désigner des

notions différentes : processus exécutable, processus abstrait, processus collaboratif,

etc.

Un processus métier est une chorégraphie d’activités incluant une interaction entre

participants sous la forme d’échange d’informations. Les participants peuvent être :

Des applications / services du SI

Glossaire 76


Des acteurs humains

D’autres processus métiers

Business Process Modeling Notation (BPMN). « Notation pour la modélisation des

processus métiers ». Une notation graphique standardisée pour dessiner des processus

métiers dans un workflow, faciliter la communication et la portabilité des modèles de

processus.

BPD (Business Process Diagram) : Un BPD représente un processus en séparant ou

découplant les informations métiers des informations techniques. Cette notation fournit

une correspondance vers un langage d’exécution, son utilité n’est plus à démontrer car

il est compris par tous (utilisateurs, analystes, développeurs qui gèrent et mesurent les

processus), et de la description du processus peut être interprété par un langage et

exécuter ce dernier.

Même si BPMN n’est pas encore utilisé par tous les éditeurs, la représentation des

objets se retrouve plus ou moins en standard dans la plupart des outils.

BPEL : (Business Process Execution Language) : Langage de programmation XML

pour la spécification des processus métiers exécutables, appliqué essentiellement à

l'orchestration de services Web.

BAM (Business Activity Monitoring)

Pilotage de la performance opérationnelle au travers du contrôle continu des processus

clés.

BPEL / BPEL4WS (Business Process Execution Language for Web Services)

Conçu par IBM, BEA et Microsoft et basé sur le BPML, c'est la représentation XML

d’un processus exécutable, qui peut être déployée sur n’importe quel moteur de

processus métier. L’élément premier d’un processus BPEL est une « activité », qui peut

être l’envoi d’un message, la réception d’un message, l’appel d’une opération (envoi

d’un message, attente d’une réponse), ou une transformation de données.

L'activité est définit par la combinaison de Services Web. BPEL utilise WSDL pour

décrire les actions d'un processus. Il est constitué à partir de deux standards : WSFL

Glossaire 77


d'origine IBM, XLANG d’origine Microsoft.

Il inclut WS-Coordination, qui assure la communication entre les services web

composant une tâche et WS-Transaction, qui gère le déroulement des tâches.

Langage concurrent: XPDL du WfMC

W3C (World Wide Web Consortium): Ce consortium est constitué par des

représentants d'entreprises privées, des acteurs de l'industrie informatique, et des

laboratoires de recherche internationaux. Le service rend compte de toutes les normes

du Web et de son histoire. Le W3C n'émet pas de normes, mais des recommandations.

Sa gestion est assurée conjointement par le Massachusetts Institute of Technology

(MIT) aux États-Unis, le European Research Consortium for Informatics and

Mathematics (ERCIM) en Europe (anciennement INRIA) et l'Université Keio au Japon.

WfMC(Workflow Management Coalition) : La coalition WfMC est une association

internationale regroupant éditeurs, utilisateurs et analystes, dont la mission est de

promouvoir et de développer l'utilisation de la gestion électronique de processus

(workflow), grâce à la définition de standards de logiciels, en termes de syntaxe,

d'interopérabilité et de connectivité.

Workflow (Automatisation/intégration) : Intégration de processus informatisés afin

d’en améliorer la performance globale.

WSDL (Web Services Description Language) : Langage de type XML, conçu par

Ariba, IBM et Microsoft, Il décrit les services référencés dans un annuaire UDDI.

WSDL expose, entre autres, les fonctions disponibles, les formats de messages et de

protocoles, et une adresse qui localise les services sur le réseau.

XML : Langage de description de données défini par le W3C. Evolution du langage

SGML, XML permet aux concepteurs de documents HTML de définir leurs propres

marqueurs, dans le but de personnaliser la structure des données qu'ils comptent

présenter. Alors qu'HTML précise comment les éléments d'une page seront présentés,

XML définit ce que contiendront ces éléments. Il permet de créer des pages Internet

sophistiquées (comprises par les navigateurs modernes). Mais aussi, il est utilisé pour

les échanges entre machines et/ou programmes, même étrangers entre eux (EDI,

Services Web…).

Glossaire 78


Services Web : Ensemble de protocoles permettant à des applications de dialoguer

indépendamment des plates-formes et des langages sur lesquelles elles reposent.

La communication entre ces applications est qualifiée d’interopérabilité et est réalisée

en utilisant des protocoles d’échanges basés sur XML comme SOAP, XML - RPC ou

XMLP. Des procédures de description et de recherche de ces services ont pour nom

ebXML, UDDI et WSDL.

SOAP : Protocole de liaison entre objets ou services, développé à l'origine par

Microsoft et quelques partenaires comme W3C, et utilisé pour les Services Web. Il

autorise l'interopérabilité avec différents environnements logiciels quelle que soit leur

plate-forme d'exécution. Le principal avantage de SOAP face à l'utilisation d'un

document purement XML est la possibilité offerte aux développeurs d'adjoindre leurs

propres détails aux messages.

Les appels SOAP traversent le firewall, à la différence de COM. Il est plus complet mai

plus compliqué que le protocole XML-RPC.

UDDI : Spécifications définissant la manière de publier et de retrouver des

informations concernant des Services Web. UDDI gère, comme un annuaire

téléphonique, 3 types d'informations : techniques, d'interfaces, de références, etc.; les

catégories et taxonomies ; et les adresses et données de contact.

Glossaire 79


Bibliographie

• Les bases du BPM POUR LES NULS Kiran Garimella, Michael Lees, Bruce

Williams

• BPMN, un véritable standard ? Guillaume Decalf

• BPMN Quels composants logiciels pour un système de BPMS?

• Business Process Management (De la modélisation à l’exécution Positionnement

par rapport aux Architectures Orientées Services), Tanguy Crusson

• Le processus unifié de développement logiciel RUP,Université Farhat Abbas de

Sétif – Algérie 15 juin 2007, Bassem DEBBABI et Mohammed Said BOUDJELDA

• Le processus unifié de développement logiciel RUP, Université Farhat Abbas de

Sétif – Algérie 15 juin 2007, Grady Booch et James Rumbaugh Ivar Jacobson.

• Le processus unifié de développement logiciel. Eyrolles, 2000.

• UML et les Design Patterns. CampusPress, 2002. Craig Larman.

• The Rational Unified Process An Introduction, Second Edition. Philippe Kruchten.

• Building J2EE Applications with the Rational Unified Process. Kelli Houston et

Wojtek Kozaczynski Peter Eeles.

• Modélisation UML avec Rational Rose 2000. Eyrolles, 2000. Terry Quatrani.

• Guide pratique du RUP. CampusPress, 2003. Philippe Kruchten et KROLL Per.

• Vivez Librement avec les TIC ! Société de Services en Logiciel Libre Le système

d’information est la colonne vertébrale d’une organisation.

• Processus de Développement Logiciel Cours M14 Université de Paris 13 _ IUT

Villetaneuse _ Formation Continue Licence Pro SIL - 2007/2008, Pierre Gérard

Bibliographie et netographie 80


Netographie

http://www.opermix.com/FR/solutions-durables/gestion-des-processus-avec-intalio/

http://ebusiness.info/guide.php3?societe=9561

www.wiley.com

www.BPMS.info www.intalio.com www.intalio.org www.développez.net www.wikipedia.com www.fr-mysql.com http://www.oxiasoft.com/developpement-offshore/credit-scoring.html www.bct.gov.tn www.ibm.com www.netalya.com www.bpmfundamentals.wordpress.com www.creditmutuel.fr www.clictopay.com.tn

Bibliographie et netographie 81

http://www.opermix.com/FR/solutions-durables/gestion-des-processus-avec-intalio/

http://ebusiness.info/guide.php3?societe=9561

http://www.wiley.com/

http://www.bpms.info/

http://www.intalio.com/

http://www.intalio.org/

http://www.d%C3%A9veloppez.net/

http://www.wikipedia.com/

http://www.fr-mysql.com/

http://www.oxiasoft.com/developpement-offshore/credit-scoring.html

http://www.bct.gov.tn/

http://www.ibm.com/

http://www.netalya.com/

http://www.bpmfundamentals.wordpress.com/

http://www.creditmutuel.fr/

http://www.clictopay.com.tn/


ANNEXES

Dictionnaire de données Table carte

Champ Type Null Défaut Commentaires id_carte int(30) Non Identifiant Carte

nom_carte varchar(20) Oui NULL

type_carte varchar(20) Oui NULL Débit ou Crédit

plafond_cash int(30) Non

plafond_achat int(30) Non

score_carte int(30) Non Score d’octroi de la carte

montant_decouvert int(30) Non

frais_carte int(30) Non Table Client

Champ Type Null Défaut Commentaires num_compte int(30) Non Numéro de compte bancaire

adresse varchar(30) Non Adresse

localite varchar(30) Non Localité

ville varchar(30) Non Ville

tel int(10) Non Téléphone

fax int(11) Non Fax

email varchar(20) Non Adresse Email

code_postal int(20) Non Code Postal Table Conjoint

Champ Type Null Défaut Commentaires num_piece_ident_c int(30) Non Numéro pièce

d’identité conjoint

num_compte_c int(30) Non N° de compte

Annexes 82


du conjoint

date_delivrance_piece_ident_c Date Non Date de délivrance carte identité conjoint

lieu_delivrance_piece_ident_c varchar(30) Non Lieu de délivrance carte identité conjoint

nom_c varchar(30) Non Nom conjoint

prenom_c varchar(30) Non Prénom conjoint

profession_c varchar(30) Non Profession conjoint

revenu_mesuel_c int(30) Non Revenu mensuel conjoint

primes_par_an_c int(30) Non Prime par an conjoint

Table Demande

Champ Type Null Défaut Commentaires id_demande int(30) Non Identifiant demande

num_compte int(30) Non Identifiant numéro de compte

score int(30) Non Score allouée lors de la demande

carte varchar(30) Non Carte allouée lors de la demande

Table Employé Champ Type Null Défaut Commentaires nom varchar(30) Non

prenom varchar(20) Non

poste varchar(20) Non

login varchar(20) Non

mdp varchar(20) Non

privilege varchar(20) Non (responsable client, analyste, responsable service)

Annexes 83


Table Entreprise Champ Type Null Défaut Commentaires

num_compte_entp int(30) Non N° compte bancaire entreprise

code_en_douane int(30) Non Code en douane de l’entreprise

raison_sociale Varchar(30) Non

forme_juridique Varchar(30) Non

secteur_activite Varchar(30) Non

mouvements Varchar(40) Non

nom_representant_legal Varchar(30) Non

chiffre_affaires int(20) Non

num_registre_commerce int(30) Non

num_cin_representant_legal int(20) Non Table Incidents de paiements chèques

Champ Type Null Défaut Commentaires num_compte_p_c int(30) Non Identifiant N°

de compte

id_incidents int(30) Non Identifiant incidents de paiements par chèques

personne_interdite int(11) Non

nbre_incidents_regularises int(11) Non Nombre d’incidents de paiements par chèques

nbre_incidents_non_regularises int(11) Non Nombre d’incidents de paiements par chèques

Table Note Champ Type Null Défaut Commentaires

num_compte int(11) Non Identifiant N° de compte bancaire

id_ponderation int(11) Non Identifiant pondération

note int(11) Non

Annexes 84


Table Particulier

Champ Type Null Défaut Commentaires num_compte_part int(30) Non N° de compte

bancaire particulier

num_piece_ident int(30) Non N° pièce d’identité particulier

nom_p Varchar(30) Non Nom particulier

prenom_p Varchar(30) Non Prénom particulier

date_naiss Date Non Date de naissance particulier

lieu_naiss Varchar(30) Non Lieu de naissance particulier

prenom_pere Varchar(30) Non Prénom du père du particulier

profession Varchar(30) Non Profession particulier

revenu_mensuel int(30) Non Revenu mensuel du particulier

primes int(25) Non Primes par an du particulier

date_titularisation Date Non Date de titularisation du particulier

employeur Varchar(30) Non Employeur du particulier

adresse_employeur Varchar(30) Non Adresse de l’employeur du particulier

etat_civil Varchar(25) Non Etat civil du particulier

sexe Varchar(10) Non Sexe du particulier

nombre_personne_a_charge int(11) Non Nombre de personne à charge par le

Annexes 85


particulier

situation_familiale varchar(20) Non Situation familiale du particulier

domiciliation varchar(30) Non Domiciliation du particulier

garanties_proposees varchar(30) Non Garanties proposées par le particulier

patrimoine_actuel varchar(30) Non Patrimoine actuel

Table Pondération par champ

Champ Type Null Défaut Commentaires id_ponderation int(30) Non Identifiant pondération

champ varchar(30) Non Libellé du champ à pondérer

ponderation int(11) Non Pondération du champ

type_client varchar(30) Non Type du client au quel s’associe la pondération (entreprise ou particulier)

Table Situation de crédits

Champ Type Null Défaut Commentaires num_compte_s_c int(30) Non N° compte

bancaire

id_situation_credits int(30) Non Identifiant situation de crédits

total_encourts int(20) Non Total des encourts

date_1ere_echeance date Non Date de 1ère échéance

date_derniere_echenace date Non Date de dernière échéance

charge_mesuelle int(30) Non Charge mensuelle

impayes varchar(30) Non Nbre d’impayés

Annexes 86


Table Situation financière Champ Type Null Défaut Commentaires

num_compte_s_f int(30) Non N° de compte client

id_situation_financiere int(30) Non Identifiant situation financière

taux_de_marge_commerciale

int(30) Non Taux de Marge Commerciale

marge_exploitation int(30) Non Taux de marge d’exploitation

marge_brute int(30) Non Taux de marge brute

marge_nette int(30) Non Taux de marge nette

rotation_actif int(30) Non Ratio de rotation de l’actif

levier_endettement int(30) Non Levier d’endettement

rendement_fonds_propres int(30) Non Ratio de rendement des fonds propres

rentabilite_globale int(30) Non Ratio de rentabilité globale

valeur_relative_bfr int(30) Non Valeur relative du besoin en fond de roulement

valeur_relative_fr int(30) Non Valeur relative du fond de roulement

rentabilite_financiere int(30) Non Ratio de rentabilité financière

excedent_brut_exploitation_total_actifs_economiques

int(30) Non Taux d’excédents brut d’exploitation/total des actifs économiques

excedent_brut_exploitation_valeur_ajoutee

int(30) Non Taux d’excèdent brut d’exploitation/ valeur ajoutée

resultat_net_charges_finan int(30) Non Résultat net des charges

Annexes 87


cieres_k_permanents financières/ capitaux permanents

marge_operationelle int(30) Non Taux de marge opérationnelle

part_richesse_restante_a_entreprise

int(30) Non Part de richesse restante à l’entreprise

part_attribuee_au_personnel

int(30) Non Part attribuée au personnel

production_chiffre_affaires int(30) Non Ratio production/chiffre d’affaires

charges_financieres_valeur_ajoutee

int(30) Non Charges financières/valeur ajoutée

taux_valeur_ajoutee int(30) Non Taux de valeur ajoutée

valeur_ajoutee_production int(30) Non Valeur ajoutée/production

poids_charges_financieres int(30) Non Poids des charges financières

cout_endettement int(30) Non Cout d’endettement

solvabilite int(30) Non solvabilité

actifs_immobilises_total_actifs_economiques

int(30) Non Actifs immobilisés /total des actifs économiques

dmlt_dettes_totales int(30) Non DMLT/dettes totales

resultat_exploitation_total_actifs_economiques

int(30) Non Résultat d’exploitation/total des actifs économique

valeur_liquidative int(30) Non Valeur liquidative

dct_dettes_totales int(30) Non DCT/ Dettes Totales

taux_endettement_global int(30) Non Taux d’endettement global

Annexes 88


equilibre_structurel int(30) Non Equilibre structurel

autonomie_financiere int(30) Non Autonomie financière

taux_endettement_a_terme

int(30) Non Taux d’endettement à terme

couverture_actif_fixe int(30) Non Couverture de l’actif fixe

ratio_dependance int(30) Non Ratio de dépendance

capacite_remboursement_dettes_structurelles

int(30) Non Capacité de remboursement /dettes structurelles

ratio_fond_roulement int(30) Non Ratio de fond de roulement

dmlt_k_propres int(30) Non DLMT/capitaux propres

credits_fournisseurs int(30) Non Crédits Fournisseurs

credits_clients int(30) Non Crédits clients

delai_moyen_stocks int(30) Non Délais moyen des stocks

Annexes 89


Script de la création de la base de données -- phpMyAdmin SQL Dump -- version 3.1.1 -- http://www.phpmyadmin.net -- -- Serveur: localhost -- Généré le : Lun 04 Février 2009 à 08:50 -- Version du serveur: 5.1.30 -- Version de PHP: 5.2.8 SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO"; -- -- Base de données: `credit_scoring` -- -- -------------------------------------------------------- -- -- Structure de la table `carte` -- CREATE TABLE IF NOT EXISTS `carte` ( ìd_carte` int(30) NOT NULL AUTO_INCREMENT, `nom_carte` varchar(20) DEFAULT NULL, `type_carte` varchar(20) DEFAULT NULL, `plafond_cash` int(30) NOT NULL, `plafond_achat` int(30) NOT NULL, `score_carte` int(30) NOT NULL, `montant_decouvert` int(30) NOT NULL, `frais_carte` int(30) NOT NULL, PRIMARY KEY (ìd_carte`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=2 ; -- -------------------------------------------------------- -- Structure de la table `client` -- CREATE TABLE IF NOT EXISTS `client` ( `num_compte` int(30) NOT NULL, àdresse` varchar(30) NOT NULL, `localite` varchar(30) NOT NULL, `ville` varchar(30) NOT NULL, `tel` int(10) NOT NULL, `fax` int(11) NOT NULL, èmail` varchar(20) NOT NULL,

Annexes 90


`code_postal` int(20) NOT NULL, PRIMARY KEY (`num_compte`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; -- -------------------------------------------------------- -- -- Structure de la table `conjoint` -- CREATE TABLE IF NOT EXISTS `conjoint` ( `num_piece_ident_c` int(30) NOT NULL, `num_compte_c` int(30) NOT NULL, `date_delivrance_piece_ident_c` date NOT NULL, `lieu_delivrance_piece_ident_c` varchar(30) NOT NULL, `nom_c` varchar(30) NOT NULL, `prenom_c` varchar(30) NOT NULL, `profession_c` varchar(30) NOT NULL, `revenu_mesuel_c` int(30) NOT NULL, `primes_par_an_c` int(30) NOT NULL, PRIMARY KEY (`num_compte_c`,`num_piece_ident_c`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; -- -------------------------------------------------------- -- -- Structure de la table `demande` -- CREATE TABLE IF NOT EXISTS `demande` ( ìd_demande` int(30) NOT NULL AUTO_INCREMENT, `num_compte` int(30) NOT NULL, `score` int(30) NOT NULL, `carte` varchar(30) NOT NULL, PRIMARY KEY (ìd_demande`,`num_compte`), KEY `num_compte` (`num_compte`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ; -- -------------------------------------------------------- -- -- Structure de la table èmployé` -- CREATE TABLE IF NOT EXISTS èmployé` ( `nom` varchar(30) NOT NULL,

Annexes 91


`prenom` varchar(20) NOT NULL, `poste` varchar(20) NOT NULL, `login` varchar(20) NOT NULL, `mdp` varchar(20) NOT NULL, `privilege` varchar(20) NOT NULL, PRIMARY KEY (`login`,`mdp`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=COMPACT; -- -------------------------------------------------------- -- -- Structure de la table èntreprise` -- CREATE TABLE IF NOT EXISTS èntreprise` ( `num_compte_entp` int(30) NOT NULL, `code_en_douane` int(30) NOT NULL, `raison_sociale` varchar(30) NOT NULL, `forme_juridique` varchar(30) NOT NULL, `secteur_activite` varchar(30) NOT NULL, `mouvements` varchar(40) NOT NULL, `nom_representant_legal` varchar(30) NOT NULL, `chiffre_affaires` int(20) NOT NULL, `num_registre_commerce` int(30) NOT NULL, `num_cin_representant_legal` int(20) NOT NULL, PRIMARY KEY (`num_compte_entp`,`num_registre_commerce`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; -- -------------------------------------------------------- -- -- Structure de la table ìncidents_de_paiements_cheques` -- CREATE TABLE IF NOT EXISTS ìncidents_de_paiements_cheques` ( `num_compte_p_c` int(30) NOT NULL, ìd_incidents` int(30) NOT NULL AUTO_INCREMENT, `personne_interdite` int(11) NOT NULL, `nbre_incidents_regularises` int(11) NOT NULL, `nbre_incidents_non_regularises` int(11) NOT NULL,

Annexes 92


PRIMARY KEY (ìd_incidents`,`num_compte_p_c`), KEY `num_compte_p_c` (`num_compte_p_c`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=COMPACT AUTO_INCREMENT=1 ; -- -------------------------------------------------------- -- -- Structure de la table `note` -- CREATE TABLE IF NOT EXISTS `note` ( `num_compte` int(11) NOT NULL, ìd_ponderation` int(11) NOT NULL, `note` int(11) NOT NULL, PRIMARY KEY (`num_compte`,ìd_ponderation`), KEY ìd_ponderation` (ìd_ponderation`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; -- -------------------------------------------------------- -- -- Structure de la table `particulier` -- CREATE TABLE IF NOT EXISTS `particulier` ( `num_compte_part` int(30) NOT NULL, `num_piece_ident` int(30) NOT NULL, `nom_p` varchar(30) NOT NULL, `prenom_p` varchar(30) NOT NULL, `date_naiss` date NOT NULL, `lieu_naiss` varchar(30) NOT NULL, `prenom_pere` varchar(30) NOT NULL, `profession` varchar(30) NOT NULL, `revenu_mensuel` int(30) NOT NULL, `primes` int(25) NOT NULL, `date_titularisation` date NOT NULL, èmployeur` varchar(30) NOT NULL, àdresse_employeur` varchar(30) NOT NULL, ètat_civil` varchar(25) NOT NULL, `sexe` varchar(10) NOT NULL, `nombre_personne_a_charge` int(11) NOT NULL, `situation_familiale` varchar(20) NOT NULL, `domiciliation` varchar(30) NOT NULL, `garanties_proposees` varchar(30) NOT NULL, `patrimoine_actuel` varchar(30) NOT NULL, PRIMARY KEY (`num_compte_part`,`num_piece_ident`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Annexes 93


-- -------------------------------------------------------- -- -- Structure de la table `ponderation_champ` -- CREATE TABLE IF NOT EXISTS `ponderation_champ` ( ìd_ponderation` int(30) NOT NULL AUTO_INCREMENT, `champ` varchar(30) NOT NULL, `ponderation` int(11) NOT NULL, `type_client` varchar(30) NOT NULL, PRIMARY KEY (ìd_ponderation`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ; -- -------------------------------------------------------- -- -- Structure de la table `situation_credits` -- CREATE TABLE IF NOT EXISTS `situation_credits` ( `num_compte_s_c` int(30) NOT NULL, ìd_situation_credits` int(30) NOT NULL AUTO_INCREMENT, `total_encourts` int(20) NOT NULL, `date_1ere_echeance` date NOT NULL, `date_derniere_echenace` date NOT NULL, `charge_mesuelle` int(30) NOT NULL, ìmpayes` varchar(30) NOT NULL, PRIMARY KEY (ìd_situation_credits`,`num_compte_s_c`), KEY `num_compte_s_c` (`num_compte_s_c`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ; -- -------------------------------------------------------- -- -- Structure de la table `situation_financiere` -- CREATE TABLE IF NOT EXISTS `situation_financiere` ( `num_compte_s_f` int(30) NOT NULL, ìd_situation_financiere` int(30) NOT NULL AUTO_INCREMENT, `taux_de_marge_commerciale` int(30) NOT NULL, `marge_exploitation` int(30) NOT NULL, `marge_brute` int(30) NOT NULL, `marge_nette` int(30) NOT NULL,

Annexes 94


`rotation_actif` int(30) NOT NULL, `levier_endettement` int(30) NOT NULL, `rendement_fonds_propres` int(30) NOT NULL, `rentabilite_globale` int(30) NOT NULL, `valeur_relative_bfr` int(30) NOT NULL, `valeur_relative_fr` int(30) NOT NULL, `rentabilite_financiere` int(30) NOT NULL, èxcedent_brut_exploitation_total_actifs_economiques` int(30) NOT NULL, èxcedent_brut_exploitation_valeur_ajoutee` int(30) NOT NULL, `resultat_net_charges_financieres_k_permanents` int(30) NOT NULL, `marge_operationelle` int(30) NOT NULL, `part_richesse_restante_a_entreprise` int(30) NOT NULL, `part_attribuee_au_personnel` int(30) NOT NULL, `production_chiffre_affaires` int(30) NOT NULL, `charges_financieres_valeur_ajoutee` int(30) NOT NULL, `taux_valeur_ajoutee` int(30) NOT NULL, `valeur_ajoutee_production` int(30) NOT NULL, `poids_charges_financieres` int(30) NOT NULL, `cout_endettement` int(30) NOT NULL, `solvabilite` int(30) NOT NULL, àctifs_immobilises_total_actifs_economiques` int(30) NOT NULL, `dmlt_dettes_totales` int(30) NOT NULL, `resultat_exploitation_total_actifs_economiques` int(30) NOT NULL, `valeur_liquidative` int(30) NOT NULL, `dct_dettes_totales` int(30) NOT NULL, `taux_endettement_global` int(30) NOT NULL, èquilibre_structurel` int(30) NOT NULL, àutonomie_financiere` int(30) NOT NULL, `taux_endettement_a_terme` int(30) NOT NULL, `couverture_actif_fixe` int(30) NOT NULL, `ratio_dependance` int(30) NOT NULL, `capacite_remboursement_dettes_structurelles` int(30) NOT NULL, `ratio_fond_roulement` int(30) NOT NULL, `dmlt_k_propres` int(30) NOT NULL, `credits_fournisseurs` int(30) NOT NULL, `credits_clients` int(30) NOT NULL, `delai_moyen_stocks` int(30) NOT NULL, PRIMARY KEY (ìd_situation_financiere`,`num_compte_s_f`), KEY `num_compte` (`num_compte_s_f`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ; -- -- Contraintes pour les tables exportées -- -- -- Contraintes pour la table `conjoint` -- ALTER TABLE `conjoint` ADD CONSTRAINT `conjoint_ibfk_1` FOREIGN KEY (`num_compte_c`) REFERENCES `client` (`num_compte`);

Annexes 95


-- -- Contraintes pour la table `demande` -- ALTER TABLE `demande` ADD CONSTRAINT `demande_ibfk_1` FOREIGN KEY (`num_compte`) REFERENCES `client` (`num_compte`); -- -- Contraintes pour la table èntreprise` -- ALTER TABLE èntreprise` ADD CONSTRAINT èntreprise_ibfk_1` FOREIGN KEY (`num_compte_entp`) REFERENCES `client` (`num_compte`); -- -- Contraintes pour la table ìncidents_de_paiements_cheques` -- ALTER TABLE ìncidents_de_paiements_cheques` ADD CONSTRAINT ìncidents_de_paiements_cheques_ibfk_1` FOREIGN KEY (`num_compte_p_c`) REFERENCES `client` (`num_compte`); -- -- Contraintes pour la table `note` -- ALTER TABLE `note` ADD CONSTRAINT `note_ibfk_1` FOREIGN KEY (`num_compte`) REFERENCES `client` (`num_compte`), ADD CONSTRAINT `note_ibfk_2` FOREIGN KEY (ìd_ponderation`) REFERENCES `ponderation_champ` (ìd_ponderation`); -- -- Contraintes pour la table `situation_credits` -- ALTER TABLE `situation_credits` ADD CONSTRAINT `situation_credits_ibfk_1` FOREIGN KEY (`num_compte_s_c`) REFERENCES `client` (`num_compte`);

Annexes 96


Les Procès verbaux des réunions avec l’encadreur société.

1er PV - 09 /02/2009 HIMILCO, Pôle des technologies de communications El Ghazela - Ariana

Présents à la réunion :

• Encadreur société : M. KOUKI Raed • Stagiaires : - M. TRABELSI Wissem

- M. ALLAGUY Marwen Credit Scoring (C.S): définit le taux d’intérêt et le montant d’un crédit que peut avoir un client d’une banque

• Définition du Use Case « Himilco scoring »

o Acteurs : - Agent bancaire o Cas d’utilisation : - Demande de carte

- Authentification - Calcul C.S - Collecte d’informations

o Acteurs externes : - Banque du client - Banque centrale - Autres banques - Organisations financières

• Normalisations des Processus Métiers Business analysis : Choix de carte bancaire Business Intelligence : ensemble d’indicateurs peu nombreux conçus pour permettre aux gestionnaires de prendre connaissance de l’état et de l’évolution des systèmes qu’ils pilotent

• Le module ‘scoring’ va être intégré au reste des modules intégrés dans Himilco

Server • On y intégrera aussi un module de Business Intelligence • Couches du système :

Présentation Métiers Base de données

Annexes 97


• Plan de Travail :

I- Analyse :

- Définition des besoins fonctionnels (Fonctional requirements) - Durée d’exécution à définir

II- Conception :

- Modélisation avec UML (Rational Rose, Agilo, Extreme Developper) - Outputs : uses cases, modèles fonctionnels…. - Durée d’exécution à définir

III- Développement :

- Génération d’un code qui tourne - Outils utilisés (Intalio Developper, Intalio Server) - Durée d’exécution à définir

IV- Tests :

- Tests de l’application et correction des erreurs

V- Production et rapport

ALLAGUY Marwen TRABELSI Wissem

Annexes 98


P.V. 2ème réunion 19/02/2009

HIMILCO, Pôle des technologies de communications El Ghazela - Ariana



- M. ALLAGUY Marwen Plan de Travail :

I- Analyse :

a. Définition des besoins fonctionnels (Fonctional requirements) b. 3 semaines (nous entamons la deuxième semaine)

II- Conception :

- Modélisation avec UML (Rational Rose, Agilo, Extrem Developper) - Outputs : uses cases, modèles fonctionnels…. - Durée d’exécution à définir


a. Génération d’un code qui tourne b. Outils utilisés (Intalio Developper, Intalio Server) c. Durée d’exécution à définir

IV- Tests :

a. Tests de l’application et correction des erreurs


Annexes 99


Travail rendu :

Les besoins fonctionnels : Définitions des fonctions attendues :

‐ Type de carte : crédit ou débit

‐ Montant maximum d’un retrait par unité de temps (plafond)

‐ Montant du découvert

‐ Frais de la carte

‐ Débit immédiat ou différé

‐ Internationale/Nationale

‐ Concours bancaires (ensemble de crédits ou de prêts accordés par une banque à court terme : facilité de caisse, découvert, et autres crédits et prêts à moins d'un an.)

‐ Carte pour retrait ou achat ou les 2

Définitions des informations manipulées : ‐ Etat civil du client (informations personnelles)

‐ Antécédents bancaires

‐ Antécédents judiciaires

‐ Informations fournis par d’autres organismes

Les cas d’utilisations : ‐ L’agent authentifie le client.

‐ L’agent demande une carte.

‐ Le système calcule le CS.

‐ Le calcul du CS fait appel à la BC, à l’OC, à la banque du client et aux autres banques

Annexes 100


Travail rendu après modification ponctuelle :

Les besoins fonctionnels : Définitions des fonctions attendues :

‐ Type de carte : crédit ou débit

‐ Montant maximum d’un retrait par unité de temps (plafond)

‐ Montant du découvert

‐ Frais de la carte

‐ Débit immédiat ou différé

‐ Internationale/Nationale

‐ Concours bancaires (ensemble de crédits ou de prêts accordés

par une banque à court terme : facilité de caisse, découvert,

Travail à affiner

et autres crédits et prêts à moins d'un an.)

‐ Carte pour retrait ou achat ou les 2

Définitions des informations manipulées :

‐ Etat civil du client (informations personnelles)

‐ Antécédents bancaires Continuer l’investigation ‐ Antécédents judiciaires

‐ Informations fournis par d’autres organismes

Les cas d’utilisations :

‐ L’agent reçoit la demande de carte

‐ L’agent fait l’acquisition des données

‐ L’agent demande la vérification des données

‐ L’agent valide l’opération

‐ Le système calcule le CS

Annexes 101


Travail à faire :

- Le package :

Analyse du package généré lors du déploiement de intalio designer vers intalio server

- Définition des besoins fonctionnels et non fonctionnels en fonction du document annexés ci dessus

Document reçu lors de la réunion

Concepts: Requirements A requirement is defined as "a condition or capability to which a system must conform". There are many different kinds of requirements. One way of categorizing them is described as the FURPS+ model [GRA92], using the acronym FURPS to describe the major categories of requirements with subcategories as shown below. Functionality Usability Reliability Performance Supportability The "+" in FURPS+ reminds you to include such requirements as: design constraints implementation requirements interface requirements physical requirements. (See also [IEEE Std 610.12.1990].) Functional requirements specify actions that a system must be able to perform, without taking physical constraints into consideration. These are often best described in a use-case model and in use cases. Functional requirements thus specify the input and output behavior of a system. Requirements that are not functional, such as the ones listed below, are sometimes called nonfunctional requirements. Many requirements are non-functional, and describe only attributes of the system or attributes of the system environment. Although some of these may be captured in use cases, those that cannot may be specified in Supplementary Specifications. Nonfunctional requirements are those that address issues such as those described below. A complete definition of the software requirements, use cases, and Supplementary Specifications may be packaged together to define a Software Requirements Specification (SRS) for a particular "feature" or other subsystem grouping. Functionality Functional requirements may include: feature sets capabilities security Usability Usability requirements may include such subcategories as: human factors (see Concepts: User-Centered Design) aesthetics consistency in the user interface online and context-sensitive help wizards and agents user documentation

Annexes 102


training materials Reliability Reliability requirements to be considered are: frequency and severity of failure recoverability predictability accuracy mean time between failure (MTBF) Performance A performance requirement imposes conditions on functional requirements. For example, for a given action, it may specify performance parameters for: speed efficiency availability accuracy throughput response time recovery time resource usage Supportability Supportability requirements may include: testability extensibility adaptability maintainability compatibility configurability serviceability installability localizability (internationalization) Design Requirement A design requirement, often called a design constraint, specifies or constrains the design of a system. Implementation Requirement An implementation requirement specifies or constrains the coding or construction of a system. Examples are: required standards implementation languages policies for database integrity resource limits operation environments Interface Requirement An interface requirement specifies: an external item with which a system must interact constraints on formats, timings, or other factors used by such an interaction Physical Requirement A physical requirement specifies a physical characteristic that a system must possess; for example, material shape size weight

Annexes 103


This type of requirement can be used to represent hardware requirements, such as the physical network configurations required. More Information More information on this topic can be found at: Concepts: Types of Requirements Concepts: User-Centered Design White Paper: Applying Requirements Management with Use Cases Copyright © 1987 - 2003 Rational Software Corporation Rational Unified Process

Rational Unified Process: Overview

TRABELSI Wissem ALLAGUY Marwen

Annexes 104


P.V. 3ème réunion 05/03/2009

HIMILCO, Pôle des technologies de communications El Ghazela - Ariana




I- Analyse :

a. Définition des besoins fonctionnels (Fonctional requirements) b. 3 semaines (nous entamons la deuxième semaine)

II- Conception :

- Modélisation avec UML (Rational Rose, Agilo, Extrem Developper) - Outputs : uses cases, modèles fonctionnels…. - Durée d’exécution à définir


a. Génération d’un code qui tourne b. Outils utilisés (Intalio Developper, Intalio Server) c. Durée d’exécution à définir

IV- Tests :



Annexes 105


- Travail rendu : Fonctionalités du système : Fonctionalités : Identification de l’agent ou de l’admin Saisie des informations client dans la demande de carte L’agent envoie ce formulaire de demande pour vérification L’agent consulte les demandes de crédit en cours L’agent modifie les demandes de carte Calcul du score pour chaque demande L’admin élabore le formulaire de demande L’admin élabore la base de règles de pondération et L’admin élabore le types des cartes dans l’établissement bancaire - Capacités : Sécurité : Provide services to protect access to certain resources or information USAGE les facteurs humains : expériences dans le domaine informatique de l’agent Formations de l’agent (Motivations Resistance au logiciel Peur d’être licencier) Esthétique : ergonomique Interface utilisateur simplifié Eviter les couleurs liées au daltonisme Les instructions doivent être compréhensibles Guider le client avec des écrans. Les menus, les icones sur l’écran doivent être faciles à utiliser. Faire une vidéo explicative FIABİLİTE Après une période d’inactivité le logiciel sera verrouillé automatiquement et l’agent doit s’authentifier pour ouvrir la session en cours Le résultat du score de chaque client doit être détaillé (note et pondération de chaque élément) L’agent doit avoir la possibilité de vérifier les informations avant de les envoyer pour vérification L’agent doit s’assurer que le formulaire a bien été reçu et vérifie par l’organisme de vérification (accusé de réception)

Annexes 106


L’agent doit pouvoir interrompre toute opération a n’importe quel moment donné Le logiciel doit comporter un système de sauvegarde automatique PERFORMANCE L’écran doit guider les clients pour faciliter l’utilisation et diminuer le temps de traitement de la demande Le temps de calcul du score doit être assez cours Facilité de support POSSİBİLİTE DE PRISE EN CHARGE Installer et mettre à jour facilement l’application, la surveiller, localiser les problèmes, modifier sa configuration si nécessaire. Installer sans avoir des problèmes. Supporter l’augmentation de la charge. Possibilité de modifier les fonctionnalités à des coûts raisonnables. (Extensibilité) Possibilité de comprendre sans efforts excessifs l’organisation interne et le fonctionnement du système et d’y apporter des modifications. - Vues du système : Nous avons exposé les différentes vues de notre système que chacun des administrateurs ou utilisateur (agent bancaire) peut voir ou manipuler dans notre système Vue formulaire de demande de carte : lister les champs se trouvant sur ce formulaire Pour cela il faut continuer la recherche auprès des banques et autres organisme - Fonction scoring : Trouver les fonctions liées au modèle social tunisien qui peuvent être utilisées dans notre système PS : On ne pourra pas faire notre réunion quotidienne cette semaine car nous n’avons pas pu définir les fonctions qu’on va utiliser dans notre système

TRABELSI WISSEM ALLAGUY MARWEN

Annexes 107


P.V. 4ème réunion

19/03/2009 HIMILCO, Pôle des technologies de communications El Ghazela - Ariana


• Encadreur société : M. KOUKI Raed • M. JARAYA Mehdi • Stagiaires : - M. TRABELSI Wissem


VI- Analyse :

a. Définition des besoins fonctionnels (Fonctional requirements) b. 1 mois

VII- Conception :

- Modélisation avec UML (Rational Rose) - Modélisation Merise - Outputs : use cases, modèles fonctionnels…. - 1 semaine

VIII- Développement :

a. Se familiariser avec Intalio Server et Designer b. Génération d’un code qui tourne c. Outils utilisés (Intalio Developper, Intalio Server) d. 2 semaines

IX- Tests :


X- Production et rapport a. Date : 30 avril

NB : Remise du projet le 15 avril Remise du rapport le 30 avril

Annexes 108


- Travail rendu : Fonctionnalités du système : Fonctionnalités : Identification de l’agent ou de l’admin Saisie des informations client dans la demande de carte L’agent envoie ce formulaire de demande pour vérification L’agent consulte les demandes de crédit en cours L’agent modifie les demandes de carte Calcul du score pour chaque demande L’admin élabore le formulaire de demande L’admin élabore la base de règles de pondération et L’admin élabore les types des cartes dans l’établissement bancaire Correction des Fonctionnalités du système Identification de l’agent ou de l’admin L’agent demande une carte L’agent collecte les données de l’entreprise ou du particulier

- Signalétique - Situation financière - Situation en matière d’incidents de paiement

L’agent vérifie les données collectées L’agent demande une notification de chaque donnée pertinente L’agent modifie la demande si besoin L’agent lance le calcul du CS L’agent recommande une carte L’admin gère le système L’admin gère les cartes L’admin gère les formulaires L’admin gère les utilisateurs L’admin gère les pondérations L’admin gère les fonctions Le système fait appel au SI de la banque lors de la vérification des données

Annexes 109


Use cases :

Fonction scoring : Nous avons décidé de laisser la liberté à l’admin de paramétrer la/les fonction(s) qui vont être utilisé lors du calcul du CS (entreprise ou particulier Aspect technique : Nous avons essayé de travailler sur Intalio Designer pour pouvoir faire tourné un exemple (Hello World et Pipa tutorial) et nous avons essayé de compiler des exemples sur Intalio Server (Hello World et absence request) PS : prière de contacter M. Sami MAHFOUDHI (encadreur IHEC Carthage, Numéro : ********, mail : [email protected]) pour avoir plus d’information sur le stage : date de dépôt, formalités…) Travail à faire : Terminer la conception

TRABELSI WISSEM ALLAGUY MARWEN

Annexes 110

mailto:[email protected]


Min PV du 31/03/2009


• Encadreur société : M. KOUKI Raed

• Stagiaires :

- M. TRABELSI Wissem

- M. ALLAGUY Marwen

Taches à faire :

A. Rédaction selon le model contextuel des use cases

1. ( submit ) de la Demande de carte

2. évaluation de la demande de carte

3. Authentification

B. Implémentation des 3 use cases ( intalio)

C. Conception et création des la BD ( mySQL)

Raed Kouki

Annexes 111

credit scoring, l'octroi des cartes bancaires

Economy & Finance