Vous êtes sur la page 1sur 28

Projet de Conception N1

Automatisation d'un processus de paiement

Livrable: Dossier d'expression des besoins

Enseignants : Y.AMGHAR, L.BRUNIE


Equipe projet : R.Jeatsa Kengni, X.Lucas, L.Martin, C.Molea (CdP)

PC1

Dossier d'expression des besoins

Avant Propos
Ce document a t rdig dans le but d'exprimer les rgles de gestion mettre en place
ainsi que les exigences fonctionnelles et non fonctionnelles dans le cadre du projet de conception
5IF Automatisation d'un processus de paiement .

PC1 Automatisation d'un processus de paiement

2/28

PC1

Dossier d'expression des besoins

Suivi du livrable
Responsable du livrable :

Loc MARTIN

Validation du livrable le :

14/10/2009

Date

Version

Auteur

Modifications

10/10/09

0.1

Loc MARTIN

Cration du document et dfinition de sa structure

14/10/09

1.0

Cosmin MOLEA

Version pour validation

16/10/09

1.1

Loc MARTIN

Corrections par rapport la revue

16/10/09

1.2

Xavier LUCAS

Corrections par rapport la revue

18/10/09

1.3

Cosmin MOLEA

Dfinition du plan d'urbanisation du SI

PC1 Automatisation d'un processus de paiement

3/28

PC1

Dossier d'expression des besoins

Table des matires


1. Objet du projet - Contexte................................................................................................................5
1.1. L'objet du projet........................................................................................................................5
1.2. Le contexte gnral du projet....................................................................................................5
1.3. Vocabulaire...............................................................................................................................6
2. Rgles de gestion..............................................................................................................................7
2.1 AVENTIX / Employeurs...........................................................................................................7
2.2 AVENTIX / Banque..................................................................................................................8
2.3 AVENTIX / Commerants........................................................................................................9
2.4 Autres services et avantages.....................................................................................................9
3. Exigences fonctionnelles................................................................................................................10
3.1 Mthode...................................................................................................................................10
3.2 Dfinition des acteurs..............................................................................................................10
3.2.1 Acteurs externes..............................................................................................................10
3.2.2 Acteurs internes...............................................................................................................11
3.3 Modle de donnes..................................................................................................................12
3.4 Cas d'utilisation........................................................................................................................13
3.4.1 Gestion comptable............................................................................................................13
3.4.2 Gestion des commandes...................................................................................................15
3.4.3 Gestion des transactions...................................................................................................17
3.4.4 Gestion B2B / B2C / Portail.............................................................................................19
3.5 Plan d'urbanisation du SI.........................................................................................................26
4. Exigences non-fonctionnelles.........................................................................................................27

PC1 Automatisation d'un processus de paiement

4/28

PC1

Dossier d'expression des besoins

1. Objet du projet - Contexte


1.1. L'objet du projet
L'entreprise AVENTIX se propose de concurrencer SODEXHO en initialisant un projet qui vise
remplacer les chques restaurant par une carte puce. Ainsi, le paiement auprs des commerants, dans le
cadre de diffrentes actions de consommation ne fera plus appel au traitement papier des chques, mais
laissera place un traitement informatique plus performant.
Ce projet a comme objectif de raliser une spcification d'un tel systme de paiement. Son
positionnement dans le cycle de vie d'un produit informatique le situe dans le cadre de l'tude prliminaire
et l'tude dtaille. Parmi les rsultats que la matrise d'uvre devra proposer au client se trouvent la
dfinition des processus sur le plan mtier et organisationnel, un plan d'urbanisation, une proposition
d'architecture applicative, une proposition d'architecture technique, une stratgie de dploiement, un
business plan.

1.2. Le contexte gnral du projet


Au jour d'aujourd'hui, la chane de traitement des chques restaurant fait intervenir cinq acteurs : une
socit qui met les chques restaurant, l'employeur qui achte les chques pour les cder aux employs en
prenant sa charge une partie de valeur indique, l'employ qui utilise le chque et enfin le commerant
affili auprs d'une centrale de rglement des titres (CRT). Le traitement des chques restaurant est semiautomatique car il ncessite l'envoi des chques par les commerants la centrale de rglement des titres. A
ce niveau, les chques sont traits de faon informatique afin de permettre aux commerants d'tre crdits.
Dans la figure ci-dessous on observe le fonctionnement existant avec SODEXHO:

PC1 Automatisation d'un processus de paiement

5/28

PC1

Dossier d'expression des besoins

Pour supprimer la partie manuelle dans la chane de traitement des chques restaurant au profit d'un
traitement entirement automatique, on souhaite remplacer le chque par une carte puce sans que cela
modifie, sur le plan de l'organisation, les procdures d'acquisition et de traitement dj utilises. On
nommera ce nouveau mode : carte restaurant. Ainsi, on envisage une simplification des protocoles
d'acquisition et d'utilisation.
Les employeurs reoivent un nombre de cartes correspondant au nombre d'employs auxquels elles
sont destines. Il communiquent la valeur de la participation et le numro d'employeur. L'employ se
prsente chez un commerant (muni d'un lecteur de cartes puce) et remet sa carte pour payer. Les
informations ncessaires sont envoyes par le lecteur au centre de compensation travers un rseau de
transfert d'informations numriques. Le centre de compensation effectuera des oprations spcifiques afin
de permettre aux commerants d'tre crdits.
Dans la figure ci-dessous on observe le fonctionnement souhait avec AVENTIX:

1.3. Vocabulaire
SI = Systme d'Information
UC = Use Case
EDI = Echange de Donnes Informatiques
CaP = Carte Puce
B2B = Business To Business
B2C = Business To Client

PC1 Automatisation d'un processus de paiement

6/28

PC1

Dossier d'expression des besoins

2. Rgles de gestion
ci doit tre prsente ou en trouvant les modes de rmunrations les plus avantageux.
Pour prsenter notre rsultat, nous allons nous intresser chaque acteur externe entrant en
jeu dans notre stratgie marketing.

2.1 AVENTIX / Employeurs


L'ide ici est de fournir gratuitement le service propos par AVENTIX aux entreprises, cela
afin de faire souscrire le plus rapidement possible un grand nombre d'employeurs.
Le fonctionnement global est donc le suivant : l'employeur commande pour chacun de ses
employs une carte qu'il distribuera dans son entreprise. Cette carte est facture 10 afin de payer
les frais de paiement de la carte auprs du fournisseur ainsi que la livraison de celle-ci
l'employeur. En cas de perte, de vol ou d'endommagement d'une carte, l'employeur peut faire une
nouvelle demande de carte pour un employ qui sera de nouveau facture 10 l'entreprise.
Une fois les cartes commandes, l'employeur peut alors crditer les cartes de chaque
employ. Pour se faire, l'employeur va pouvoir partir du portail dterminer le montant attribu
ses employs par repas ainsi que son taux de participation (l'employeur aura un pourcentage de
participation de l'ordre de 50 60% du montant du repas, le reste tant la charge de l'employ).
Le nombre de repas crdits pour un mois correspond au nombre de jours travaills par l'employ
durant le mois prcdent (la premire fois, ce nombre correspond au nombre estim de jours
travaills par l'employ durant le premier mois). L'employeur pourra donc galement, grce au
portail, saisir pour chaque employ le nombre de jours travaills durant le mois prcdent. Ses
donnes devront tre saisies avant le 25 de chaque mois pour le mois suivant. Pass cette date, les
donnes du mois prcdent seront automatiquement rutilises.
Une facture sera alors dite et transmise l'entreprise, puis celle-ci se verra dbiter de
l'ensemble du montant mensuel global (la somme des montants mensuels de chaque employ
correspondant au montant d'un repas multipli par le nombre de jours travaills) au premier du
mois (l'employeur se charge de prlever la participation de l'employ en interne). A partir de ce
moment la carte de chaque employ sera crdite de son montant mensuel.
Il est possible de cumuler le crdit prsent sur la carte d'un employ d'un mois sur l'autre,
avec tout de mme comme limite maximale un montant gal cinquante repas. Toute somme
crdite au del de cette limite sera perdue.
On en dgage les rgles de gestion suivantes:
R1.1 : Fournir gratuitement le service propos par AVENTIX aux entreprises.
R1.2 : L'employeur commande pour chacun de ses employs une carte qu'il distribuera
PC1 Automatisation d'un processus de paiement

7/28

PC1

Dossier d'expression des besoins

dans son entreprise.


R1.3 : Chaque carte est facture 10 l'employeur.
R1.4 : L'employeur peut alors crditer les cartes de chaque employ grce au portail.
R1.5 : L'employeur va pouvoir partir du portail dterminer le montant attribu ses
employs par repas ainsi que son taux de participation (l'employeur aura un
pourcentage de participation de l'ordre de 50 60% du montant du repas, le reste
tant la charge de l'employ)
R1.6 : Le nombre de repas crdits pour un mois correspond au nombre de jours travaills
par l'employ durant le mois prcdent (la premire fois, ce nombre correspond au
nombre estim de jours travaills par l'employ durant le premier mois).
R1.7 : Les donnes relatives au nombre de jours travaills de chaque employ devront tre
saisies avant le 25 de chaque mois pour le mois suivant. Pass cette date, les donnes
du mois prcdent seront automatiquement rutilises.
R1.8 : Une facture sera alors dite et transmise l'entreprise, puis celle-ci se verra dbiter
de l'ensemble du montant mensuel global (la somme des montants mensuels de
chaque employ correspondant au montant d'un repas multipli par le nombre de
jours travaills) au premier du mois. A partir de ce moment la carte de chaque
employ sera crdite de son montant mensuel.
R1.9 : Il est possible de cumuler le crdit prsent sur la carte d'un employ d'un mois sur
l'autre, avec tout de mme comme limite maximale un montant gal cinquante
repas. Toute somme crdit au del de cette limite sera perdue.

2.2 AVENTIX / Banque


C'est grce la banque que AVENTIX va obtenir la majeure partie de sa rmunration. Le
principe est de crer un accord avec une banque afin d'avoir un compte rmunr au taux le plus
lev possible en contre-partie duquel AVENTIX s'engage toujours disposer d'une somme
d'argent minimum sur le compte.
Pour notre tude, nous nous somme bas sur un compte rmunr 10% garantis sur lequel
AVENTIX s'engage laisser 250 000 minimum.
A chaque fois que AVENTIX dbite le montant global d'une entreprise, ce montant est plac
sur ce compte.
On en dgage les rgles de gestion suivantes:
R2.1 : Crer un accord avec une banque afin d'avoir un compte rmunr au taux le plus
lev possible en contre-partie duquel AVENTIX s'engage toujours disposer d'une
somme d'argent minimum sur le compte.
R2.2 : A chaque fois que AVENTIX dbite le montant global d'une entreprise, ce montant
est plac sur ce compte.

PC1 Automatisation d'un processus de paiement

8/28

PC1

Dossier d'expression des besoins

2.3 AVENTIX / Commerants


Une autre partie des rmunrations de AVENTIX va se faire grce aux transactions avec les
commerants.
En effet, une fois qu'un commerant aura fait une demande d'adhsion (demande pouvant se
faire gratuitement travers le portail), celui-ci pourra grce un simple lecteur de cartes puce
(celui actuellement utilis pour le paiement par carte bleue) encaisser un client en utilisant la carte
AVENTIX de celui-ci. Lors de ce paiement, le compte virtuel du commerant sera crdit de la
valeur du repas. A une certaine frquence (7j, 14j ou 21j) le commerant pourra ensuite se faire
verser cet argent sur son compte bancaire. A chacun de ses versement, le commerant devra payer
des frais (un pourcentage du montant vers dpendant de la frquence des versements et de la
valeur de ceux-ci, pouvant dans certains cas tre gal zro).
Voici un tableau rcapitulatif des frais de transactions (en pourcentage du montant crdit):
Montant des frais

Taux 7 jours

Taux 14 jours

Taux 21 jours

en euros

De 0 1999,99
De 2000 3999,99
De 4000 5999,99
De 6000 7999,99
De 8000 9999,99
Plus de 10000

2,99%
2,69%
2,39%
2,09%
1,79%
1,49%

1,99%
1,79%
1,59%
1,39%
1,19%
0,99%

0,99%
0,79%
0,59%
0,39%
0,19%
0,00%

On en dgage les rgles de gestion suivantes:


R3.1 : Une fois qu'un commerant aura fait une demande d'adhsion, celui-ci pourra grce
un simple lecteur de cartes puce encaisser un client en utilisant la carte AVENTIX
de celui-ci.
R3.2 : Lors de ce paiement, le compte virtuel du commerant sera crdit de la valeur
du repas.
R3.3 : A une certaine frquence (7j, 14j ou 21j) le commerant pourra ensuite se faire verser
cet argent sur son compte bancaire.
R3.4 : A chacun de ses versement, le commerant devra payer des frais de transaction.

2.4 Autres services et avantages


En se basant sur cette solution de dmatrialisation de tickets restaurant propose par AVENTIX, il
est galement possible d'tendre le champ d'action d'autres ides.
On peut classer ces ides en deux catgories :
Des services toujours orients sur le ticket restaurant mais apportant une plus-value l'offre

PC1 Automatisation d'un processus de paiement

9/28

PC1

Dossier d'expression des besoins

actuelle. On peut pas exemple imaginer la mise en place sur le portail d'une section Avantages et
Rductions sur laquelle les commerants pourront y prsenter leurs offres exclusives proposes au
porteurs de Carte AVENTIX (formule spciale, rduction sur les menus, etc).
Des services rutilisant la technologie mise en place mais diversifiant l'activit. Il serait par
exemple possible d'tendre l'offre aux services proposs par les comits d'entreprises (CE).
L'employ pourrait ainsi acheter des places de cinma, karting, laser game, etc un tarif rduit qui
seraient ensuite crdites sur sa carte. L'employ n'aurait alors qu' utiliser sa carte AVENTIX une
fois sur place pour payer.

3. Exigences fonctionnelles
3.1 Mthode
Afin de dfinir prcisment les exigences fonctionnelles imposes par ce systme de cartes
puces, nous allons procder de la sorte :
identification des acteurs
description des Uses Cases par domaine fonctionnel
description de Use Case par diagramme d'activit
Pour identifier les Uses Cases par domaine fonctionnel, nous allons rflchir pour chaque
acteur, la liste des services qu'il serait susceptible d'utiliser. Nous allons ensuite regrouper ces
services dans des sous-domaines fonctionnels afin de dcrire le mtier de chaque acteur.
Bien entendu, nous ne pourrons tre exhaustifs quant la description des Uses Cases et de
chaque Use Case. Aussi, nous nous attacherons dcrire globalement les Uses Cases les plus
importants et les plus spcifiques chaque domaine fonctionnel. Puis, nous ne dcririons par un
diagramme d'activit que les Use Case les plus complexes mettre en uvre et les plus intressants
pour une future exploitation de ce document.

3.2 Dfinition des acteurs


Le systme concevoir interagit avec un ensemble d'acteurs externes et internes pour la
bonne marche de son fonctionnement; on distingue:
3.2.1 Acteurs externes
Employeur
Cet acteur reprsente les employeurs ou entreprises qui adhrent la carte puce restaurant.
PC1 Automatisation d'un processus de paiement

10/28

Il

PC1

Dossier d'expression des besoins

interagit avec AVENTIX en commandant des cartes puces pour leurs employs, et aussi
dans le rglement des factures.
Commerant
Cet acteur reprsente les prestataires de service, parmi lesquels commerants; restaurateurs;
ayant adhr au paiement par carte puce.

etc..

Lecteur carte puce


Cet acteur modlise un lecteur de cartes puce install chez un commerant partenaire afin
de permettre la transmission des donnes relatives une transaction commerciale avec la
socit AVENTIX.
Employ
Cet acteur tant un employ d'une des entreprises partenaire de la socit AVENTIX,
avec le systme via un portail pour accder son compte.

interagit

Banque
Cet acteur reprsente la banque partenaire de la socit AVENTIX, elle interagit avec le systme
pour les transactions et la gestion financires.
Fournisseur de cartes puce
Cet acteur reprsente le fournisseur de cartes puce la socit AVENTIX pour livraison aux
employeurs respectifs, il interagit avec le systme suite une commande de cartes puce.
Carte puce
Cet acteur contient les informations sur l'entreprise partenaire la socit AVENTIX et sur
l'employ propritaire de la carte
3.2.2 Acteurs internes
Service commande
Cet acteur s'occupe du traitement des commandes des employeurs et des devis.
Service facturation
Cet acteur correspond au poste de travail qui traite les factures et s'occupe galement des
expditions de cartes puce destination des entreprises.
Service traitement
Cet acteur correspond au service charg de surveiller le traitement des transactions entre le
commerant et le systme, et de mettre jour les donnes suite aux sollicitations des
employeurs
ou des employs.
PC1 Automatisation d'un processus de paiement

11/28

PC1

Dossier d'expression des besoins

Service client
Cet acteur correspond au service de gestion du portail, il permet aux employeurs, employs,
commerants et fournisseurs de cartes puce d'accder au systme pour d'ventuels besoins.

3.3 Modle de donnes

PC1 Automatisation d'un processus de paiement

12/28

PC1

Dossier d'expression des besoins

3.4 Cas d'utilisation


Nous avons class les cas d'utilisation identifis selon quatre domaines fonctionnels:

GESTION DES COMMANDES

GESTION DES TRANSACTIONS

GESTION B2B/B2C/PORTAIL

GESTION COMPTABLE

3.4.1 Gestion comptable

UC1 : facturer la commande de carte puces


Acteurs : service facturation, base de donnes
Description : une fois AVENTIX prvenu de la rception de la commande par le prestataire charg
de l'acheminement, le service facturation dresse la facture correspondante et l'expdie l'employeur.
UC2 : traiter facturation litigieuse
Acteurs : service facturation, base de donnes
Description : lors de la communication d'un litige par le service client, le service facturation
rcupre les informations de la commande concerne et value la solution possible avec l'entreprise
en communiquant les possibilits au service client. En consquence, elle ralise un avoir ou un
remboursement, en notifiant cette action l'employeur via la base de donnes ou le service client.

PC1 Automatisation d'un processus de paiement

13/28

PC1

Dossier d'expression des besoins

PC1 Automatisation d'un processus de paiement

14/28

PC1

Dossier d'expression des besoins

3.4.2 Gestion des commandes

UC1 : envoyer un bon de commande l'employeur


Acteurs : service commandes, base de donnes
Description : le service commande consulte dans la base de donnes du portail les demandes
d'envoi de bon de commande puis il imprime un bon de commande et l'affranchi pour envoi
l'adresse indique dans les coordonnes laissees par l'employeur.
UC2 : saisir une commande
Acteurs : service commandes, base de donnes
Description : une fois le bon de commande reu, le service commande saisie les informations de la
commande pour l'insrer dans la base de donnes interne. Grce ce procd, le stock est
valu et une demande d'approvisionnement en carte puce peut tre lance la fin d'une
priode prdfinie (tous les jours par exemple) en fonction de la demande. Puis il ajoute la
notification faire parvenir l'employeur dans la base de donnes du portail.
UC3 : annuler une commande
Acteurs : service commande, service client, base de donnes
Description : le service client contacte le service commande pour informer l'annulation d'une
commande. Le service commandes rcupre alors les informations de la commande et value la
lgalit ou non de la demande d'annulation. Il agit en consquence et ajoute dans la base de donnes
du portail la confirmation envoyer l'employeur.
UC4 : envoyer une commande de carte puces
Acteurs : service facturation, carte puce, base de donnes
Description : lorsque les cartes puces ont t reues (soit directement du stock soit aprs livraison
du partenaire cartes puces), le service facturation rcupre les donnes inscrire sur chaque carte
et lance la procdure de mise jour des cartes. Puis, il effectue l'emballage et l'expdition de la
commande tout en notifiant l'employeur de l'envoi de la commande par l'intermdiaire de la base de
donnes du portail.

PC1 Automatisation d'un processus de paiement

15/28

PC1

Dossier d'expression des besoins

PC1 Automatisation d'un processus de paiement

16/28

PC1

Dossier d'expression des besoins

3.4.3 Gestion des transactions


Traitement des oprations carte puce
Le service traitement effectue des vrifications sur le numro et la validit de la carte et
aussi que le montant total transmis n'excde pas le solde de la carte du client et enfin l'ajournement
de la carte en diminuant du solde le montant de la transaction, l'ajournement du compte commerant
chez AVENTIX.

UC1 : traitement des oprations CaP


Acteurs : service traitement, commerant.
Description : traitement qui consiste mettre jour la base de donne en fonction des donnes
transmises par les commerants. Ces informations portent sur la valeur de la prestation. Les
donnes sont transmises par un rseau de tlcommunication partir d'un lecteur de cartes
puce vers le service de traitement et vice-versa.
Exception : lecteur cartes puce dfectueux, ligne tlphonique en panne.

PC1 Automatisation d'un processus de paiement

17/28

PC1

Dossier d'expression des besoins

PC1 Automatisation d'un processus de paiement

18/28

PC1

Dossier d'expression des besoins

3.4.4 Gestion B2B / B2C / Portail

PC1 Automatisation d'un processus de paiement

19/28

PC1

Dossier d'expression des besoins

Systme de gestion employ


UC1 : consulter le solde de l'employ
Acteurs : employ, base de donnes
Description : l'employ peut tout moment consulter le solde prsent sur son compte. Pour cela il
doit accder au portail sur internet.
UC2 : consulter les diffrentes transactions de l'employ
Acteurs : employ, base de donnes
Description : il est galement possible pour l'employ, toujours grce au portail, de consulter
son historique des transactions. Aprs chaque transaction, celle-ci est sauvegarde en basse de
donnes.

PC1 Automatisation d'un processus de paiement

20/28

PC1

Dossier d'expression des besoins

Systme de gestion employeur


UC1 : saisir une commande
Acteurs : employeur, base de donnes
Description : lorsqu'un employeur dsire commander de nouvelles cartes il peut, travers le
portail, raliser une commande. Cette commande est enregistre en base de donnes afin d'tre
traite ensuite par le service commande.
UC2 : consulter les comptes de l'entreprise
Acteurs : employeur, base de donnes
Description : un employeur peut consulter la liste des comptes dont il dispose grce au portail.
Parmi les informations disponibles, on retrouve pour chaque compte l'identifiant et le nom de
l'employ qui est assign le compte ainsi que le nombre de jours travaills par l'employ.
UC3 : supprimer des comptes employs
Acteurs : employeur, base de donnes
Description : L'employeur a la possibilit de supprimer les comptes lis son entreprise. Pour cela,
il slectionne les comptes supprimer puis doit valider la suppression. Aprs suppression d'un
compte, celui-ci reste encore actif mais il n'est plus possible de le crditer.
UC4 : modifier les informations de l'entreprise
Acteurs : employeur, base de donnes
Description : il est possible que l'employeur fasse des modifications sur les informations relatives
l'entreprise. Il peut ainsi modifier diffrents lments tels que l'adresse de livraison des cartes, le
montant unitaire d'un repas, le taux de participation, etc mais aussi des informations relatives
chaque compte telles que le nom de l'employ rattach au compte ou le nombre de jours travaills
par celui-ci.

Systme de gestion commerant


UC1 : faire une demande d'adhsion
Acteurs : commerant, base de donnes
Description : un commerant peut faire gratuitement une demande d'adhsion en ligne. Aprs avoir
saisi un certain nombre d'informations, le commerant valide sa demande. Celle-ci elle sauvegarde
en base de donnes en attendant d'tre traite par le service client.
UC2 : consulter les informations du commerant
Acteurs : commerant, base de donnes
Description : le commerant a la possibilit de consulter ses informations sur le portail afin de
vrifier leur validit et s'assurer que celles-ci soient jour.
PC1 Automatisation d'un processus de paiement

21/28

PC1

Dossier d'expression des besoins

UC3 : modifier les informations du commerant


Acteurs : commerant, base de donnes
Description : le commerant peut tout moment modifier ses informations partir du portail.
Parmi ses informations nous pouvons par exemple retrouver le nom de son commerce, son nom, ses
coordonnes postales et bancaires, sa frquence de paiement, etc.
UC4 : consulter le solde du commerant
Acteurs : commerant, base de donnes
Description : un commerant peut, grce au portail, consulter le solde disponible sur son compte
AVENTIX.

Systme de gestion fournisseur


UC1 : consultation des commandes de cartes puces
Acteurs : fournisseur, base de donnes
Description : le fournisseur de cartes puces peut, grce au portail, consulter les commandes de
cartes puces en cours.

Oprations de compensation
Le systme de compensation permet de crditer d'un cte AVENTIX et de l'autre les
commerants, et aussi de dbiter les entreprises. Ces oprations seront effectues l'aide d'un
systme d'change de Donnes Informatises (EDI) ou, dans le cas o on n'utilise pas un tel
systme, l'aide des bordereaux de virement bancaires.
UC1 : compensation
Acteurs : le service traitement, la base de donnes, la banque
Description : selon le mode d'change avec les banques:
diter des bordereaux contenant les donnes bancaires ncessaires pour faire les transactions
changer les donnes informatiques ncessaires pour effectuer la compensation

PC1 Automatisation d'un processus de paiement

22/28

PC1

Dossier d'expression des besoins

PC1 Automatisation d'un processus de paiement

23/28

PC1

Dossier d'expression des besoins

PC1 Automatisation d'un processus de paiement

24/28

PC1

Dossier d'expression des besoins

PC1 Automatisation d'un processus de paiement

25/28

PC1

Dossier d'expression des besoins

3.5 Plan d'urbanisation du SI


Aprs avoir tudi les diffrents domaines fonctionnels de AVENTIX, nous sommes en
mesure de proposer un plan d'urbanisation de son systme d'information (voir la figure cidessous). Nous allons dfinir plus en dtail ce plan d'urbanisation dans le dossier d'architecture
applicative.

PC1 Automatisation d'un processus de paiement

26/28

PC1

Dossier d'expression des besoins

4. Exigences non-fonctionnelles
Rappel des statistiques :
500 000 transactions / jour
300 000 entreprises
6 000 000 cartes
15s de dlai maximum pour effectuer une transaction
Tolrance panne : 0. Scurit : totale

tant donn le contexte particulier dans lequel nous nous trouvons, il est videmment ncessaire de
confronter le futur systme un certain nombre de besoins non fonctionnels. Un tel systme
demande en effet un certain investissement dans son laboration et sa ralisation pour rpondre avec
satisfaction son utilisation.
Tout d'abord, il est vident que, compte tenu du nombre de transactions par jour, le systme devra
rpondre une exigence de disponibilit, de robustesse et de performance extrmement
importantes. En effet, en tenant compte de la charge susceptible d'tre impose et du temps de
rponse maximum acceptable pour une transaction, il sera ncessaire de veiller concevoir une
architecture suffisamment importante et ventuellement des moyens de secours permettant de palier
un incident. Le systme devra ainsi tre capable de supporter au minimum 1,5 fois la charge
annonce afin d'approcher au maximum de la disponibilit 100%. Des choix importants en
matire de rseaux et de rpartition des charges sur serveurs sont faire.
Pour poursuivre dans cette ide de disponibilit du systme, il faudra bien videmment rpondre
un besoin de scurit extrmement important. Il sera en effet vital d'assurer une confidentialit des
donnes au cours des diffrents traitements. De plus, une tude et une mise en uvre plus
rigoureuses devront tre effectues en identifiant avec prcision la totalit des sources d'ventuels
problmes de scurit et apporter les parades ncessaires avant la mise en service du systme. Pour
aider l'identification des failles de scurit, il faudra probablement envisager la consultation par
une socit experte dans ce domaine et une phase de test rigoureuse.
Le systme devra galement offrir une fiabilit totale. Il n'est en effet pas question dans ce domaine
des changes de flux financiers que le systme produise des dysfonctionnements. Il en rsulterait
une situation ingrable matriellement et lgalement.
Au-del des ces aspects, il faudra galement tre capable de mettre en place ce systme tout en
respectant l'exigence d'intgration avec les diffrents service de AVENTIX et l'ensemble des
acteurs externe actuels.
Afin de corriger un ventuel incident mineur, le systme doit aussi respecter l'exigence de
maintenabilit afin d'viter une perturbation consquente. Dans ce style d'ides, il faudra que le
PC1 Automatisation d'un processus de paiement

27/28

PC1

Dossier d'expression des besoins

systme respecte talement les critres de portabilit et rutilisabilit. Ceci non pas seulement de
rduire le dlai de maintenance (changement de serveur par exemple), mais aussi pour tre capable
de supporter une volution ventuelle de l'utilisation des cartes puces (nouveaux services).
Enfin, le portail B2B devra rpondre l'exigence globale d'ergonomie afin de justifier sa mise en
place et de promouvoir l'utilisation en ligne scurise.
non de l'ensemble de ces besoins non fonctionnels dcidera de la russite du projet.

PC1 Automatisation d'un processus de paiement

28/28