Etude pour la mise en place d'un système de paiement électronique dans une institution financière.

REPUBLIQUE DEMOCRATIQUE DU CONGO

MINISTERE DE L'ENSEIGNEMENT SUPERIEUR ET UNIVERSITAIRE

INSTITUT SUPERIEUR DE COMMERCE LE LA GOMBE

I.S.C

B.P. 16596

SECTION : INFORMATIQUE DE GESTION

CYCLE DE LICENCE

 

 

« ETUDE POUR LA MISE EN PLACE D'UN

SYSTEME DE PAIEMENT ELECTRONIQUE DANS UNE INSTITUTION FINANCIERE »

 

Cas de la BCDC

Par

KIMWESA PASIMAN'U PATIENCE,

 

Analyste Programmeur

Mémoire présenté et défendu en vue de l'obtention du titre de Licencié en Informatique de Gestion

Option : Réseaux

Directeur : Professeur MIS Alphonse-Christian

IVINZA LEPAPA

 

Année Académique 2011 - 2012

 



DEDICACE

A toi Jéhovah, Dieu le Père, Créateur de toutes choses visibles et invisibles, pour Ton amour infini, pour la sagesse et l'intelligence dont tu m'as dotée depuis l'enfance à ce jour.

A toi Jésus-Christ, mon Seigneur et Sauveur, tu m'as donné l'intelligence de connaître Le Père et c'est grâce à ton obéissance que je suis aujourd'hui comme toi, fils de Dieu et citoyen céleste.

A toi mon amour à vie Christina, ma chère épouse, tu n'as cessé de m'apporter tout ton soutien en tout temps, surtout durant la réalisation de ce mémoire. Je me souviens que même jusque très tard la nuit, t'étais toujours à mes côtés, m'encourageant à tenir jusqu'au bout de cette compétition.

A toi Winny Kimwesa, la première à avoir fait de moi un papa, je sais que t'es encore si petite, à peine sept mois pour comprendre combien t'es précieuse pour moi

A ma mère Marie Colette, mes frères Fulgence, Firmin, Blanchard, Emmanuel, ma soeur Agnès et l'ensemble de la famille Kimwesa pour vos conseils et encouragement.

A mes collègues de lutte Sylvain KASONGA, Eric Shabani, Jean-Jacques MATA, Mme Jeanne UMADJELA, Georges BUSHIRI, Papy NSHASHA, Alpha BALUME, Nancy LUEMBA et les autres qui peut être ne trouveront pas leurs noms sur cette page ; pour la cohésion et le désir de toujours apprendre plus,

A Monsieur Taso, Mr Basile Mpadi, Becky Kilutu et tous les collègues de service, pour vos conseils et encouragements

Je dédie ce travail.

Patience KIMWESA PASIMANU

« Celui qui acquiert du sens aime son âme; Celui qui garde l'intelligence trouve le bonheur. »

Proverbe 19 : 8

AVANT PROPOS

Cet oeuvre a été réalisé dans but d'adhérer à la règle selon laquelle tout étudiant finaliste en cycle de licence doit rédiger un mémoire de fin d'étude dans son domaine de formation et ce conformément aux normes académiques en vigueur en République Démocratique du Congo en général et à l'Institut Supérieur de Commerce de la Gombe en particulier.

Nous sommes très reconnaissants et exprimons notre pleine gratitude à Jéhovah, Seul Vrai Dieu, Créateur de toutes choses, notre Père et à notre Seigneur Jésus - Christ c'est vrai qu'Ils méritent plus que notre reconnaissance pour tout ce que nous sommes devenu.

Notre gratitude va aussi droit à la personne du Professeur MIS Alphonse Christian IVINZA LEPAPA, qui non seulement en dépit de ses multiples occupations, a accepté d'assurer la direction de ce travail scientifique mais aussi, a été pour nous un vrai guide tout au long de notre formation en licence. Son encadrement, ses conseils, sa volonté et son amour nous ont poussés à l'excellence. Ainsi, il restera à jamais gravé dans nos souvenirs.

Nous exprimons aussi notre pleine gratitude au P.O M'VIBUDULU KALUYIT, au P.O Emmanuel KANGA, aux Professeurs J.P MBIKAYI, J.P BOOTO, KOLA, MAKINDU, MAPHANA, aux Chefs de Travaux J.R DISONAMA, Emmanuel MAYAMONA et Alex NKUSU, à l'assistant Dodi MBUTA, à Mr Willy BARUTI. Nous attestons qu'ils ont constitué le socle même de notre formation académique en Licence.

Nous remercions aussi l'ensemble du corps professoral et administratif de l'I.S.C. pour leur coeur disposé à continuer de travailler pour la formation de la jeunesse Congolaise malgré les moments difficiles.

Nous remercions aussi les autorités de la BCDC qui nous ont acceptées pour effectuer nos recherches pour réaliser ce travail. Qu'elles trouvent ici, l'expression de notre gratitude.

Que toute personne qui nous a apporté de près ou de loin son soutien de quelque forme que ce soit, trouve ici l'expression de notre reconnaissance.

INTRODUCTION GENERALE

0.1. Problématiques

Malgré la vitesse de l'évolution des Nouvelles Technologies de l'Information et de la Communication (NTIC), il est indispensable de noter que le paiement électronique a des particularités qui lui sont propres.

Du fait de ses caractéristiques, la question du mode de paiement, de coût du matériel et de la sécurité des parties est capitale. Pour assurer la sécurité par exemple, des mesures d'élimination de tous les risques d'interceptions des informations lors des transactions, encore accrues par le caractère ouvert et international du réseau et, en cas d'interception, pouvoir rendre les informations inutilisables par le fraudeur. C'est dans cet ordre d'idée que nous voulons étudier pour mettre en place un système de paiement électronique à la BCDC dans le but d'augmenter les services que la banque offre et accroître ses résultats .

0.2. Enjeux, objectifs et Hypothèse du travail

Les enjeux et objectifs du nouveau système sont premièrement d'ordre sécuritaire, les instruments de paiement également sont une autre préoccupation pour le paiement électronique. Néanmoins, le haut degré de technicité qui y est lié constitue une formidable opportunité pour l'apparition de systèmes de paiement totalement innovants.

Ainsi un système de paiement électronique, pour être sûre et performant, doit répondre aux premières nécessités suivantes :

ü Authentification et intégrité des messages;

ü Confidentialité;

ü Divisibilité;

ü Disponibilité;

ü Non répudiation.

0.2.1. L'enjeu de la sécurisation du paiement

La banque doit :

ü Favoriser le développement des affaires dans un climat de confiance et de sécurité;

ü Mettre à disposition les outils de paiement adaptés aux modèles de distribution des commerçants;

ü Equilibrer les responsabilités entre les différents acteurs commerçants, banquiers et consommateurs,

ü Adapter l'importance des dispositifs de sécurité au risque;

ü Intégrer le cadre juridique: légal et contractuel;

ü Assurer un niveau de protection conforme aux standards actuels en matière .de sécurité des données et des échanges ;

ü Consolider la confiance du consommateur.

0.2.2. Les objectifs à atteindre par le nouveau système :

ü Rapprocher les acteurs du commerce (banque, client, commerçant) par l'utilisation d'un réseau ouvert et sécurisé;

ü Permettre aux commerçants l'enregistrement et l'administration d'un compte à distance;

ü Mettre à la disposition du client la carte bancaire comme outil de paiement sécurisé ;

ü Enregistrer des informations sur les transactions effectuées;

ü Rendre l'information accessible à tous et à tout moment;

ü Offrir le plus grand nombre de services;

ü de convivialiser la gestion des transactions.

Avantage :

ü Fidélisation de la clientèle ;

ü Réduction des coûts;

ü Augmentation des revenus;

ü Conquête de nouveaux marchés et de clients.

0.3. Choix et intérêt du sujet

A la fin de notre formation en deuxième Licence, l'obligation nous incombe de rédiger un mémoire conciliant toutes les notions acquises pour mettre en place un système d'information en réseau à un cas concret qui sera par la suite défendu en vue d'obtention du titre de licencié en Informatique de Gestion, option Réseaux, remplissant ainsi notre devoir académique. « ETUDE POUR LA MISE EN PLACE D'UN SYSTEME DE PAIEMENT ELECTRONIQUE DANS UNE INSTITUTION FINANCIERE cas de la, BCDC » est pour nous un sujet à propos car il nous a permis non seulement d'avoir une vue globalisante de Réseaux informatiques mais aussi nous a familiarisé avec cette technologie émergeante et en perpétuelle évolution à travers la planète.

0.4. Délimitation du sujet

Il est évident que tout travail de recherche scientifique soit limité dans le temps et dans l'espace pour faciliter sa compréhension et son exploitation. Ainsi, c'est au sein de la direction informatique et monétique de la banque Commerciale Du Congo (BCDC) que nous avons effectué nos recherches pour la période allant de l'année 2010 à 2011

0.5. Méthodes et techniques utilisées

Dans le cadre de ce travail, nous avons utilisé la méthode UML qui n'impose pas une démarche particulière pour l'analyse d'un système d'informations. Et dans le souci de maîtriser les risques, nous avons souhaité faire usage d'une démarche itérative et incrémentale fondée sur les besoins des utilisateurs et centrée sur l'architecture logicielle. Nous avons fait usage à la méthode Rapid Application Development (RAD) avec sa démarche d'analyse en sept phases.

Quant aux techniques, nous nous sommes servi de :

ü L'interview : qui nous a permis d'avoir des réponses aux différentes questions posées aux principaux acteurs du système ;

ü L'observation : chaque fois que nous allions dans le service concerné, notre attention était fixée sur tout ce qui se faisait.

ü La documentation : nous avons consulté beaucoup de documents existant au sein du service concerné et même depuis le site internet de la Banque.

0.6. Subdivision du travail

Hormis l'introduction et la conclusion, notre travail comporte deux grandes parties. La première, Approches théoriques avec deux chapitres à savoir : Généralités sur les réseaux informatiques et Systèmes de paiement électronique et Institutions Financières. Et La deuxième, Conception du nouveau système d'information avec ses cinq chapitres dont : présentation de la BCDC, étude de l'existant, étude des scenarii, étude détaillée du système futur et étude technique de la solution retenue.

1ère Partie :

APPROCHES THEORIQUESChapitre 1er : GENERALITES SUR LES RESEAUX INFORMATIQUES

1.1 Définition

Dans le domaine de l'informatique, un réseau de communication est un ensemble de moyens matériels et logiciels permettant de faire communiquer entre eux différents systèmes informatiques^1(*).

Par extension, la notion de réseau englobe souvent non seulement le réseau, en tant que moyen de communication, mais aussi les systèmes qu'il interconnecte.

La notion de réseau recouvre trois aspects:

ü Un aspect matériel, qui concerne les infrastructures d'interconnexion.

ü Un aspect logique, qui concerne les fonctions de contrôle et de commande des échanges d'informations.

ü Un aspect utilisateur, qui concerne les services que ces utilisateurs peuvent attendre du réseau.

1.2 Historique2(*)

La communication entre ordinateurs ne peut pas être distinguée de celle des hommes. Si au départ, l'ordinateur n'est qu'un gros jouet aux mains de scientifiques, celui-ci a créé une véritable révolution technologique qui devient le support de base de la communication entre les humains. L'informatique est entrée partout, dans le téléphone, dans les disques compacts, la voiture, l'avion. Partout l'ordinateur a remplacé la machine à écrire.

Evolution des capacités de communication des ordinateurs

L'ordinateur au début n'a que des capacités de calcul. Communiquer avec lui est l'affaire de spécialistes très pointus. Puis, petit à petit, la technique s'améliore. On utilise des bandes perforées puis des cartes perforées. Les sorties sont faites sur des imprimantes. Les Télétypes sont utilisés pour communiquer avec l'ordinateur. Ce sont des terminaux qui font de la saisie sur un clavier et de l'affichage sur du papier.

Les terminaux vidéo se généralisent ensuite. L'affichage se fait sur écran. Ces écrans deviennent de plus en plus sophistiqués, avec de la couleur, du graphisme. Un terminal est assez « bête », il ne fait que de la saisie et de l'affichage, il envoie les caractères tapés au clavier et reçoit des ordres d'affichage.

Le prix des processeurs diminuant, la technologie devenant à la portée de plus petites équipes, le microordinateur arrive à la fin des années 70 (INTEL). Depuis, la façon de concevoir les réseaux et les applications a considérablement changé.

Chaque constructeur durant les années 60-90 a développé son propre réseau informatique avec son langage propriétaire. Ceci permet de garder une clientèle captive, l'utilisateur n'ayant que peu de possibilités d'aller voir un autre constructeur. Certes à cette époque IBM® se fait copier ses machines par deux ou trois constructeurs mais c'est très limité. La société IBM à la fin des années 70 détenait 80 à 90% des ventes d'ordinateurs.

Cependant les clients évoluent, ils rachètent d'autres entreprises qui n'ont pas forcément les mêmes ordinateurs.

Comment faire pour communiquer entre deux systèmes complètement différents?

On voit alors apparaître des machines de réseau qui sont des traducteurs, d'un côté, ils vont parler le SNA d'IBM, de l'autre le DSA de BULL. On voit ainsi que pour connecter n constructeurs, il faut créer, à condition que les traducteurs soient réversibles, n (n+1)/2 traducteurs. Travail gigantesque et difficile à mettre à jour car les langages réseaux évoluent très vite.

Il a donc fallu se réunir entre constructeurs pour définir un langage commun qui permette d'interconnecter les systèmes. Il en est résulté le protocole OSI (Open System Interconnection) de l'ISO (International Standards Organization). Ce langage devait résoudre le problème des communications hétérogènes. En fait ces développements n'ont jamais été publics (pas de sources), le marché restreint. Peu de constructeurs se sont dits : « J'abandonne mon langage pour l'OSI ». Du coup un petit langage né du Département de la Défense Américain (DOD) et promu par des Universités (Berkeley) est devenu ce langage d'interconnexion. Il s'appelle Internet Protocole (IP) Pour donner un ordre d'idée : pour une petite machine IBM des années 1988. OSI valait 100 KF et TCP/IP 5 KF. De plus avec TCP/IP on pouvait se relier à un vaste réseau existant. Le choix est vite fait!

1.3 La normalisation

La normalisation est l'action qui consiste à faire qu'un système respecte une ou plusieurs normes. En effet, le monde informatique semble être le milieu ayant produit dans sa courte histoire le plus des normes dans le monde. L'évolution rapide et continuelle dans le domaine, ainsi que la volonté d'interconnecter des systèmes en est l'une des causes. Dans des nombreux cas, des normes sont émises pour pallier uniquement aux insuffisances techniques qui, dans leurs évolutions, rendent cette norme caduque.

Selon l'approche anglo-américaine et européenne, aux états unis, la standardisation commerciale et financière consiste à définir des communautés d'intérêt pour déduire le standard industriel puis les services d'entreprise correspondant. Cette démarche appuyée par un ensemble d'organismes souvent privés (W3C,...) permet aux états unis d'Amérique d'acquérir une certaine domination industrielle et commerciale. Les états unis opposent le standard de facto au standard de jure (documents établit à la suite de procédures d'enquête pour avis). Les européens font la distinction entre le standard et la norme, émanation d'un organisme de normalisation.

1.4 Le standard 

Un standard s'impose sur le marché en termes de la qualité technique, de la position dominante,... et tous les équipementiers doivent les proposer commercialement. Ainsi, un standard peut être revendiqué en termes de la propriété intellectuelle. Retenons tout de même qu'un standard n'est pas une norme mais peut le devenir.

1.5 La norme

Une norme est le résultat d'une longue négociation collective entre les acteurs concernés au sein d'une organisation de normalisation. La convergence d'un projet de norme vers une norme s'effectue par consensus successifs et peut durer plusieurs années jusqu'au vote final de la norme, alors valide pour une durée limitée (quelques années).

Une entité est conforme à une norme internationale si ses spécifications techniques respectent les fonctionnalités décrites dans les normes des organismes correspondantes.

C'est le respect de la norme qui permet le remplacement d'un produit par un autre équivalent pour ainsi garantir l'interopérabilité des systèmes et produits industriels construits par différents constructeurs entre eux. Une norme n'est pas obligatoire étant donné que son utilisation résulte d'un choix du fabricant ou des exigences d'un client.^3(*)

1.6 Le modèle OSI

Dans les années 1980, des commissions de normalisation, ont défini comment écrire un nouveau réseau, propre à interconnecter les machines de différents constructeurs. Il en est resté un succès qui s'appelle X25 pour la troisième couche, mais le réseau mondial OSI n'existe toujours pas. Cependant ce modèle a clarifié les choses en matière de réseau.

Ce modèle a abouti à une représentation en couches qui reste une référence pour tout le monde, même si les réalisations différent quelque peu.

Le modèle OSI (Open System Interconnect) est une norme dans les réseaux. Modèle en couches fournissant un cadre conceptuel et normatif aux échanges entre systèmes hétérogènes^4(*).

1.6.1 Objectifs

ü La constitution des réseaux formés des systèmes informatique hétérogènes

ü La conception des applications indépendantes du réseau de transmission et des postes de travail.

ü La définition des règles de communication universelle indépendante des moyens de transfert.

ü L'adaptation du réseau à tous les types d'architectures existantes.

ü La gestion de l'asynchronisme des demandes d'où la création et la gestion des files d'attente avec définition de la stratégie de réponses aux requêtes.

ü La prévention, la gestion des blocages mutuels et des congestions.

Ainsi, pour faire circuler l'information sur un réseau on peut utiliser principalement deux stratégies :

· La première stratégie consiste en ce que l'information soit envoyée de façon complète.

· La seconde stratégie consiste à ce que l'information soit fragmentée en petits morceaux (paquets), chaque paquet est envoyé séparément sur le réseau, les paquets sont par la suite réassemblés au niveau de la machine destinataire. On parle de réseau à commutations de paquets.

Avec le modèle OSI, chaque couche effectue une tâche définie et dépend des services de la couche inférieure. Chaque couche donc fournit ses propres services à la couche supérieure.

Couche	Fonctionnalité
7	Application
6	Présentation
5	Session
4	Transport
3	Réseau
2	Liaison
1	Matériel

1.7 Le modèle TCP/IP

TCP/IP est né de la réflexion de chercheurs américains suite à un problème posé par l'armée américaine. L'armée américaine disposait (et dispose encore) de plusieurs bases sur le territoire mondial. Chacune de ces bases dispose de sa propre logistique informatique. Les machines des différents centres pouvaient être de types différents et reliées entre elles à l'intérieur de ces centres par des réseaux locaux différents. Cependant ces centres informatiques doivent échanger des informations. Les bases sont reliées les unes aux autres par des câbles. La question était de trouver un moyen pour que l'information puisse circuler entre ces bases même si certains des chemins empruntables étaient détruits. Il a fallu donc trouver un système permettant de retrouver des chemins (routes) qui se reconfigureraient automatiquement en cas de coupures des liaisons. De cette recherche est née IP (Internet Protocol ou Interconnected Network Protocol). IP comme nous le verrons, est un protocole qui permet d'envoyer des informations élémentaires de machine à machine. Cependant l'information ne part pas d'une machine mais d'une application fonctionnant sur une machine pour aboutir à une application fonctionnant sur une autre machine. Pour résoudre ce problème les chercheurs ont développé un autre protocole du nom de TCP (Transport Control Protocol). Le nom de TCP/IP a donc été choisi en référence à ces deux principaux protocoles qui le caractérisent.

Aujourd'hui TCP/IP intègre beaucoup d'autres protocoles (ICMP, IGP, FTP, SMTP, HTTP, ...). TCP/IP est un protocole qui nécessite une coopération des OS des machines dans pratiquement toutes les couches. Dans un réseau qui suit le modèle OSI, le OS (Operating System : système d'exploitation) de la machine n'intervient que dans les couches 4 et supérieures. TCP/IP est très répandu, car sa robustesse a été prouvée (quelques millions de machines interconnectées dans le monde).

Il est également très répandu, car dès son origine il a été implémenté sur des systèmes Unix. Beaucoup de chercheurs ayant contribué à l'évolution de TCP/IP à son origine sont issus de l'université de Berkeley qui a très largement diffusé son système Unix avec l'interface des sockets pour manipuler des connexions TCP/IP.

couches

Application

Transport

Interconnexion

Interface avec le réseau

Matériel

1.7.1 Vue en couches du modèle TCP/IP

Les couches 5 à 7 du modèle OSI sont des couches dites d'application. Elles sont orientées application, et fournissent une interface entre une application et le réseau.

Les couches 1 à 4 sont des couches dites de liaison. Ce sont elles qui se chargent et qui se chargeront du routage, afin d'acheminer correctement les paquets d'un point à un autre.

Le modèle TCP/IP ne suit pas tout à fait l'architecture en couche du modèle OSI. Après expérimentation, on s'est aperçu qu'une carte réseau devait regrouper les couches 1 et 2 pour obtenir des performances correctes.

Toutefois, il existe quelques cas où les couches 1 et 2 sont différenciées dans le modèle TCP/IP. C'est le cas par exemple d'une connexion par modem, qui comporte une couche de liaison de données (PPP : Point to Point Protocol). On peut aussi trouver parfois une couche de niveau présentation (6), c'est par exemple le cas du SSL (Secure Socket Layer).

Remarque : dans le modèle TCP/IP, la couche de transport utilise soit TCP (Transmission Control Protocol), soit U.D.P (User Datagram Protocol). Par contre, il n'existe qu'un seul protocole de niveau Réseau : I.P (Internet Protocol).

La couche Matérielle correspond aux couches 1 et 2 du modèle OSI. Les couches matérielles et Interface avec le réseau correspondent à la couche 3 du modèle OSI. La couche Transport correspond aux couches 4 et 5 du modèle OSI. Cette comparaison au modèle OSI n'est que relative, car chaque couche du modèle OSI doit vérifier que la couche équivalente sur la machine destinataire va recevoir toutes les données émises sans erreur. Le protocole des couches Interface avec le réseau et Interconnexion ne garantit pas ceci. Ces protocoles sont de type Best Effort. Le problème de traitement des erreurs est remonté dans les couches supérieures (Couche transport en utilisant TCP ou couche application en utilisant UDP)^5(*).

1.7.2 Identification des machines

Sur un réseau utilisant TCP/IP chaque machine est identifiée par une adresse IP. Chaque identifiant IP appelé numéro ou adresse IP doit être unique sur l'ensemble du réseau. Chaque machine ne dispose que d'une adresse IP par réseau sur lequel elle est connectée. Les machines (routeurs, passerelles) qui sont multi-domiciliées c'est-à-dire qui possèdent plusieurs adresses IP sont des cas spéciaux.

1.7.3 Format d'une adresse IP

Signalons d'abord qu'à nos jours, il existe deux types d'adresse IP, V4 et V6. Une adresse IP V4 est un nombre codé sur 4 octets. Par habitude, cette adresse est représentée sous la forme décimale pointée A.B.C.D où A, B, C et D sont quatre chiffres décimaux allant de 0 à 255.

1.7.4 Attribution des adresses IP.

Les adresses Internet (32 bits en Ipv4) identifient de manière unique une machine sur la toile du réseau. Elles sont délivrées par des organismes chargés de gérer le bon déploiement de ces adresses.

Une adresse IP est composée de deux champs : l'adresse réseau et l'adresse machine. L'adresse réseau est placée sur les bits de poids forts, alors que l'adresse de machine est calculée sur les bits de poids faible. Toutefois, dans les communications entre machines, un autre type d'adresse est parfois utilisé, il s'agit de l'adresse M.A.C (Media Access Control), en accord avec le protocole A.R.P (Address Resolution Protocol).

Il existe plusieurs classes d'adresses. On parle des classes A, B, C, D et E. Elles sont différenciées par les bits de poids forts qui les compose.

Classe	Présentation des bits	Rôle dans le réseau	Rôle pour les machines
A	0000	Identifiant du réseau	Identifiant machine
B	1000	Identifiant du réseau	Identifiant machine
C	1100	Identifiant du réseau	Identifiant machine
D	1110	Identifiant du réseau	Identifiant machine
E	1111	Non utilisée	Non utilisée

Une adresse IP V4 est toujours de la forme a.b.c.d ; dans le cas d'une classe A, on peut librement fixez les valeurs b, c et d. On pourra donc adresser théoriquement 16 777 214 machines. Une classe B fixe librement les valeurs de c et d. On pourra alors adresser 65 534 machines. Une classe C fixe uniquement la valeur de d. On pourra donc adresser 254 machines. La classe D est une classe quelque peu différente, puisqu'elle est réservée à une utilisation particulière : le multicast. La classe E est quant à elle une classe non utilisée jusqu'à ce jour. On dispose donc en théorie des plages d'adresses suivantes^6(*) :

Classe	Plage
A	0.0.0.0	127.255.255.255
B	1.0.0.0	191.255.255.255
C	1.1.0.0	223.255.255.255
D	1.1.1.0	239.255.255.255
E	1.1.1.1	247.255.255.255

Il existe quelques adresses dites non routables. Ces adresses sont réservées à un usage interne, ou dans le cas de réseaux privés. Elles ne sont en théorie jamais routées sur l'Internet. Il existe 3 classes d'adresses IP :

Classe A : 10.0.0.0

Classe B : 172.16.0.0 à 172.31.0.0

Classe C : 192.168.0.0 à 192.168.255.0

127.0.0.0 est aussi une classe A particulière, puisqu'elle ne sera jamais non plus routée sur un réseau. Elle est réservée pour un usage interne d'adresses IP. On l'appelle aussi interface loopback (interface de bouclage).

1.7.5 Passage des adresses IP aux adresses physiques.

Dans un réseau TCP/IP, chaque machine est identifiée par une adresse IP. Cette adresse est logique, elle ne dépend pas du matériel utilisé pour relier les machines ensemble. Ces adresses IP peuvent être modifiées relativement rapidement par les administrateurs pour diverses raisons.

Au niveau de la couche 2 du modèle OSI, chaque machine dispose d'une adresse physique distincte. Cette adresse physique dépend du matériel réseau utilisé (Carte réseau). Il faut trouver un système qui permette de convertir l'adresse logique IP en une adresse physique de la machine. Pour ce faire plusieurs méthodes sont utilisables.

1.7.6 La table de routage

On peut imaginer que sur chaque machine travaillant avec TCP/IP on dispose d'une table qui fait la conversion entre une adresse logique IP et une adresse matérielle (adresse physique mac). Cette méthode, quoi que très efficace, devient lourde à gérer. A chaque ajout, suppression ou modification d'une adresse IP pour une machine, il faut remettre à jour la table de correspondance sur toutes les machines.

1.7.7 Le routage et les protocoles de routage

1.7.7.1 Le Routage

Le routage est une méthode d'acheminement des informations à la bonne destination à travers un réseau^7(*). Le but d'un protocole de routage est très simple : fournir l'information nécessaire pour effectuer un routage, c'est-à-dire la détermination d'un chemin à travers le réseau entre une machine émettrice et une machines réceptrices, toutes deux identifiées par leur adresse. Les protocoles de routages établissent des règles d'échange des messages d'état entre routeurs pour mettre à jours leurs tables selon des critères de coût comme, par exemple, la distance, l'état de la liaison, le débit, et ainsi améliorer l'efficacité du routage.

Le réseau Internet est organisé comme une collection de « systèmes autonomes», chacun d'entre eux étant en général administré par une seule entité. Un système autonome, ou SA, est constitué d'un ensemble de réseaux interconnectés partageant la même stratégie de routage, plus précisément tous routeurs internes à ce système obéissent à un même protocole de routage, régi par une autorité administrative (un département responsable spécifique comme un fournisseur d'accès ou toute autre organisation). Le protocole de routage utilisé à l'intérieur d'un système autonome est référencé en tant que protocole interne à des passerelles, ou IGP. Un protocole séparé, appelé EGP (protocole externe à des passerelles, est utilisé pour transférer des informations de routage entre les différents systèmes autonomes.

1.7.7.2 Les protocoles de routage

o RIP (Routing Information Protocol) a été conçu pour fonctionner en tant qu'IGP dans des systèmes autonomes de taille modérée. RIP utilise un algorithme d'une classe connue sous le nom « d'algorithmes à vecteurs de distance», il recherche le plus court chemin au sens d'un critère de coût où seul le nombre de routeurs traversés intervient, un coût unitaire étant associé à la traversée de chaque réseau. Le protocole est limité aux réseaux dont le plus long chemin (le diamètre du réseau) implique 15 routeurs maximum. Il est mal adapté au traitement de boucles dans les chemins et utilise des « métriques » fixes pour comparer les routes alternatives. Cela n'est pas toujours approprié pour les situations où les routes doivent être choisies en fonction de paramètres temps réel comme un délai, une fiabilité ou une charge mesurés.

o OSPF : Basé sur un algorithme conçu par le chercheur en informatique néerlandais Dijkstra, l'algorithme SPF (Shortest Path First) calcule le plus court chemin vers toutes les destinations de la zone ou du SA en partant du routeur où s'effectue le calcul (à partir de sa base de données topologiques) au sens d'un critère de coût où entrent de multiples paramètres. Ce calcul est effectué de manière indépendante par tous les routeurs « OSPF » internes au SA. C'est par l'intermédiaire de cet algorithme que s'effectue la mise à jour de la table de routage: Ayant trouvé les plus courts chemins d'un point à un autre, en terme de coût, le routeur est apte à connaître le prochain routeur à qui il doit transmettre le message, pour que ce dernier arrive de manière optimum à son destinataire (ce routeur étant évidement un routeur adjacent au routeur qui effectue le calcul sur le chemin le plus court et se trouvant sur ce réseau). Chaque mise à jour de la base de données entraîne la mise à jour de la table de routage. C'est ici qu'intervient la communication entre les routeurs, communication régie par le protocole OSPF. Elle définit des règles et des formats de messages que doivent respectés les routeurs « OSPF » internes à un système autonome. OSPF a la particularité de s'appuyer directement sur IP et non sur UDP comme le protocole RIP.

On distingue 5 types de messages : « Hello », « Description de base de données », « Requête d'état de liaison », « Mise à jour d'état de liaison », « Acquittement d'état de liaison ». Qui permettent aux différents routeurs de s'échanger des informations sur l'état des liaisons et déterminer ainsi une fonction de coût plus réaliste que dans RIP.

1.7.8 Protocoles TCP/IP et UDP

Pour les échanges qui ont besoin d'une grande fiabilité, le protocole de Transport TCP/IP Signet non défini. (Transport Control Protocol) est utilisé dans les stations d'extrémité. Pour les échanges qui ne nécessitent pas une telle fiabilité, un protocole de Transport plus simple UDP (User Datagram Protocol) fournit les services de bout en bout en mode sans connexion. Le protocole UDP ne possède pas de fonction de contrôle de flux, il essaye toujours de transmettre les données quel que soit l'état de congestion du réseau.

Le protocole TCP est implanté au-dessus du protocole IP pour assurer un transfert fiable en mode connecté : il fournit le même service que le protocole de transport, dit de classe 4, défini dans le modèle.

1.7.9 La fragmentation.

Le but d'IP est de trouver un chemin pour envoyer un datagramme. Ce datagramme va circuler de passerelles en passerelles. Ces passerelles sont connectées sur un support physique qui peut avoir des MTU (Maximum Transfert Unit) différent (c'est-à-dire qui échange des trames de longueurs différentes).



Le réseau1 dispose d'un MTU M1, il est connecté au réseau 2, via G1, qui dispose d'un MTU M2, qui ... via Gn-1, qui dispose d'un MTU Mn. Supposons qu'une machine du réseau 1 envoie un datagramme IP de longueur L à destination d'une machine sur le réseau N, alors 5 cas de figures peuvent se présenter:

1°) La longueur L est inférieur au min (M1, M2,...Mn), Alors, le datagramme est émis de passerelles en passerelles jusqu'à ce qu'il atteigne sa destination sur le réseau N.

2°) La longueur L est supérieure au min (M1, M2,...Mn), alors si le datagramme ne doit pas être fragmenté, un message ICMP d'erreur est émis vers la machine source et le datagramme est détruit par la passerelle qui ne peut pas le faire transiter sur l'autre réseau.

3°) La longueur L est supérieure au min (M1, M2, Mn), alors si le datagramme peut être fragmenté, la passerelle qui ne peut émettre directement ce datagramme va le couper en autant de petits datagrammes que nécessaire et émettre tous les fragments sur l'autre réseau. Lorsque les fragments arrivent sur la passerelle suivante, cette dernière ignore que ce sont des fragments, et les traites comme des datagrammes normaux.

4°) Le datagramme arrive sur une passerelle qui ne peut le traiter faute de ressources suffisantes, alors ce dernier est détruit sans autre forme de procès.

5°) Le datagramme arrive sur la passerelle qui ne dispose pas d'information pour router ce datagramme, alors elle le détruit et émet un message ICMP qui signale une erreur de routage. IP envoie des datagrammes de machines à machines. IP garantie qu'il fera tout son possible pour envoyer le datagramme (Best effort). IP peut détruire un datagramme.

IP ne garantit pas qu'un datagramme émis arrive à l'identique sur l'autre machine. Il peut fragmenter le datagramme et émettre ces fragments sur différents chemins en fonction des tables de routages. IP n'est pas un protocole fixe, mais est en perpétuel évolution. IP ne fixe pas seul les routes, il utilise d'autres protocoles (GGP, RIP, ...).

1.8 L'architecture Client / Serveur

De nombreuses applications fonctionnent selon l'environnement client/serveur, cela signifie que des machines clientes (des machines faisant partie du réseau) contactent un serveur, une machine généralement très puissante en termes de capacités d'entrée-sortie, qui leur fournit des services. Ces services sont des programmes fournissant des données telles que l'heure, des fichiers, une connexion, ...

Les services sont exploités par des programmes, appelés programmes clients, s'exécutant sur les machines clientes. On parle ainsi de client FTP, client de messagerie, ..., lorsque l'on désigne un programme, tournant sur une machine cliente, capable de traiter des informations qu'il récupère auprès du serveur (dans le cas du client FTP il s'agit de fichiers, tandis que pour le client messagerie il s'agit de courrier électronique).

Pour que deux ou plusieurs noeuds arrivent à se communiquer il est impératif de mettre en place un ou plusieurs modèles de communications. Ainsi, nous allons effectuer un passage en revue de ces dits modèles.

1.9 La sécurité du système d'Information (SI)

La mise en place de la sécurité su SI nécessite la connaissance complète de l'ennemi, et de ses méthodes. Puisque sécurité complète est illusoire, il est nécessaire de connaitre les risques pesants sur le SI afin d'imaginer les différents scénarios qui peuvent mener à la mise en danger du SI^8(*). Il conviendra donc à partir des risques d'appliquer les bonnes méthodes afin d'obtenir un niveau de sécurité en accord avec les besoins.

1.9.1 Définitions

La sécurité informatique se rapporte aux données du SI et aux transactions qui y sont effectuées.

La sécurité des systèmes informatiques couvre généralement les critères de base et fonctions associées^9(*) suivantes :

ü L'intégrité des ressources physiques et logiques (équipements, données, traitements, transactions, service) est relatif au fait qu'elles n'ont pas été détruites (altération totale) ou modifiées (altération partielle) à l'insu de leurs propriétaires tant de manière intentionnelle qu'accidentelle.

ü La confidentialité c'est la protection des données contre une divulgation non autorisée. Autrement dit, la confidentialité consiste à assurer l'accès aux ressources uniquement aux personnes autorisées.

ü La disponibilité d'une ressource est relative à la période de temps pendant laquelle le service offert est opérationnelle. Le système et les données sont accessibles et utilisables à la demande par une entité autorisée ;

ü L'identification et authentification peuvent être mises en oeuvre pour contribuer à réaliser des procédures de contrôle d'accès et des mesures de sécurité assurant la confidentialité et l'intégrité des données, la non-répudiation et l'imputabilité. L'identification et authentification des ressources et des utilisateurs permettent d'imputer la responsabilité de la réalisation d'une action à une entité.

ü La non-répudiation est le fait de ne pouvoir nier ou rejeter qu'un événement (action, transaction) a eu lieu. A ce critère de sécurité peuvent être associées les notions d'imputabilité ou encore d'auditabilité.

1.9.2 Approche globale de la sécurité informatique^10(*)

Il faut traiter la sécurité d'un système informatique en sa totalité, car il est inutile d'avoir une porte blindée dans sa maison et en même temps avoir les fenêtres ouvertes sur le monde extérieur^11(*).

Partant de cette idée, on doit donc aborder la sécurité dans son contexte global c'est-à-dire, on doit assurer les différents aspects de sécurité suivants :

1.9.2.1 La Sécurité Organisationnelle

ü Définir les rôles des différents acteurs : Qui fait quoi ?

ü Sensibiliser les utilisateurs aux problèmes de la sécurité

ü Intégrer le facteur sécurité dans tout projet informatique dès sa conception jusqu'à sa réalisation

ü Arrêter les procédures d'organisation et de mise en oeuvre de la sécurité

1.9.2.2 La sécurité physique et environnementale

ü Règles de sécurité des locaux qui abritent les serveurs sensibles et les équipements d'interconnexion : équiper ces locaux par des détecteurs d'incendie et par un système d'extinction automatique.

ü Verrouillage des locaux contre le vol du matériel.

ü Issue de secours dans les locaux

ü Accès permis seulement aux personnes autorisées (utiliser des clés spéciales ou une carte à puce pour contrôler les accès à la salle informatique)

1.9.2.3 La sécurité des accès

ü Sécurité des accès aux postes de travail et aux serveurs pour les utilisateurs et les administrateurs. L'accès doit être assuré par :

§ Nom utilisateur et mot de passe

§ Carte à puce : l'authentification par carte à puce est destinée à garantir l'identité d'une personne à assurer son identification via un code PIN et à protéger l'accès aux postes de travail par le biais d'un mot de passe dynamique (c'est-à-dire qu'il faut changer de temps en temps)

ü Classification des données selon leur confidentialité et leur appartenance,

ü Gestion des droits d'accès aux données et aux fonctionnalités des logiciels en fonction des profils des utilisateurs

1.9.2.4 La sécurité des réseaux

ü Assurer la sécurité des topologies LAN et WAN pour garantir la continuité de transmission des données à l'intérieur et à l'extérieur de l'entreprise,

ü Contrôler le flux des données entre le système d'information et le monde extérieur (c'est-à-dire l'Internet ou le WAN) pour éviter tout risque d'attaque (alors il faut installer serveur proxy avec un firewall)

ü Détecter les intrusions qui viennent de l'extérieur et les éviter au préalable,

ü Assurer la sécurité de transmission de données sur l'Internet en implantant des protocoles sécurisés (SSL (Secure Sockets Layer), IPsec, etc...) et en faisant le cryptage des messages.

1.9.2.5 La sécurité des serveurs

ü Classification des serveurs de l'entreprise (le serveur proxy doit être assez performant pour bien protéger le serveur de base de données),

ü Audit sécurité des configurations des serveurs sensibles,

ü Sécuriser les procédures d'exploitation et d'administration (avec des mots de passe et arrêter qui fait quoi)

1.9.2.6 La sécurité des données

ü Assurer une sauvegarde quotidienne et hebdomadaire des données,

ü Faire la sauvegarde sur des supports multiples,

ü Protéger les supports de sauvegarde, contre les incendies, dans une armoire ignifuge.

1.9.2.7 La sécurité énergétique

La sécurité énergétique est très importante quant au fonctionnement des équipements formant la plateforme technique. Il est recommandé d'équiper les armoires abritant les différents éléments par des onduleurs performants pour remédier aux petites coupures du courant ou aux chutes de la tension électrique. En revanche, pour les coupures de longue durée, il faut prévoir l'installation d'un groupe électrogène qui va assurer la continuité du courant nécessaire pour le bon fonctionnement.

1.9.2.8 La sécurité antivirale (c'est la sécurité contre les virus informatiques)

Un virus est un programme informatique qui peut infecter d'autres programmes dans le but de les modifier pour y ajouter une copie de lui-même, de gêner leur fonctionnement et voire même les supprimer ou nuire à certaines composantes de l'ordinateur. Les virus vont de la simple balle de ping-pong qui traverse l'écran au virus destructeur de données et au plus méchant qui formate le disque dur.

Les virus ne sont pas classés selon leurs dégâts mais selon leur mode de propagation et d'infection, d'où, outre les virus classiques, on distingue principalement quatre types de virus :

ü Les Vers ce sont des virus capables de se propager à travers un réseau d'entreprise.

ü Les Chevaux de Troie (les troyens) sont des virus qui permettent de créer une faille dans un système, généralement, c'est pour permettre à leur programmeur de s'introduire dans le système infecté et de l'administrer à distance et faire tout ce qu'il veut.

ü Les bombes logiques sont des virus capables de se déclencher suite à un évènement particulier (suite à une date système programmée, exemple : le virus de CHERNOBYLE)

ü Les Canulars sont des annonces publicitaires (les spams) qui arrivent à travers le courrier électronique et qui peuvent contenir des virus ou des fausses alertes ou des fausses informations.

L'Antivirus

C'est un utilitaire qui détecte les virus sur l'ordinateur par l'analyse (opération de scan) des fichiers sur tout support de données : Disque Dur, disquette,

CD et même ceux qui sont encore en Mémoire centrale ou sur le secteur d'amorçage

Quelques antivirus :

ü Symantec Norton Antivirus

ü Mcafee Virusscan

ü F-secure, etc.

Vu le nombre de virus existants et augmentant et vu leur nuisance, leur menace et leur rapidité de propagation accrue grâce au réseau Internet, la nécessité de se disposer d'un antivirus n'est plus à démontrer.

Mais vu la création et l'injection journalière, de nouveaux virus sur l'Internet, la possession d'un antivirus n'est plus suffisante pour s'assurer et dire qu'aucun virus ne passerait inaperçu car l'antivirus, lors de son analyse, fait référence à une liste de signatures numériques des différents virus établie lors de son développement; alors il ne peut donc reconnaître la signature de ceux qui sont créés après sa commercialisation.

Reconnaître de façon automatique les nouveaux virus ; Non !

Mais, Oui, avec l'acquisition d'une nouvelle version d'antivirus ou par le téléchargement à partir de l'Internet de la liste de nouvelles définitions des virus de façon périodique et fréquente pour que l'antivirus puisse détecter les virus récemment créés et éventuellement désinfecter les fichiers touchés et ainsi éviter les risques de nouvelles infections.

1.9.3 Architecture de sécurité

Cette architecture reflète l'ensemble des dimensions organisationnelles, juridiques, humaines et technologiques de la sécurité informatique à prendre en considération pour une appréhension complète de la sécurité d'une organisation.

1.9.3.1 Dimension humaine

ü Gestion des ressources humaines

ü Dissuasion

ü Surveillance

ü Ethique

ü Formation

ü Compétence

ü Etc.

1.9.3.2 Dimension technique et opérationnelle

ü Sécurité matérielle

ü Sécurité environnementale

ü Sécurité des télécoms

ü Sécurités des personnes

ü Sécurité logique

ü Sécurité applicative

ü Sécurité de l'exploitation

ü Sécurité physique

1.9.3.3 Dimension juridique et réglementaire

ü Norme

ü Procédures

ü Conformité

ü Législation

ü Contrats

ü Etc.

1.9.3.4 Dimension politique organisationnelle et économique

ü Stratégie

ü Gouvernance

ü Responsabilité

ü Organisation

ü Evaluation

ü Contrôle

ü Optimisation

ü Maîtrise des coûts

ü Assurance

ü Etc.

1.9.4 Stratégie de sécurité

Une bonne stratégie de sécurité ne permet pas de gagner de l'argent. Par contre, si elle est bien préparée et exploitée comme il le faut, elle nous évite d'en perdre.

Une bonne stratégie opérationnelle, doit passer par les trois étapes suivantes :

a) Une bonne Préparation

ü Une charte de sécurité

ü Un cahier des charges

ü Les moyens nécessaires à la mise en place de la sécurité

b) Une bonne application

ü Planification de la mise en place

ü Mise en place des procédures de différents aspects de la sécurité

ü Veiller à la disponibilité et au bon état du tout le système de sécurité

c) Un bon suivi

ü Contrôle et vérification périodique de l'efficacité du système sécurité (Audit de la sécurité),

ü Formation et recyclage du personnel de la sécurité,

ü Renouvellement des moyens de sécurité obsolètes (dépassés),

ü Mise à jour périodique de l'antivirus,

ü Mise à jour périodique des systèmes d'exploitation pour remédier à leur bug et à leur faille de vulnérabilités aux intrusions qui viennent de l'extérieur et en particulier de l'Internet.

En résumé, obtenir un niveau de sécurité informatique suffisant pour prévenir les risques technologique et informationnel est primordial tant pour les individus que pour les organisations ou les Etats qui utilisent ou fournissent des services via les technologies numériques. Il est important de pouvoir identifier les valeurs à protéger et les risques correctement afin de déterminer les exigences de sécurité et les moyens de les satisfaire. Ceci implique une approche globale, pluridisciplinaire et systémique de la sécurité. La sécurité informatique doit permettre de répondre aux besoins de disponibilité, d'intégrité et de confidentialité de certaines ressources. Aux aspects purement techniques de la sécurité, il faut associer la mise en oeuvre efficace de procédures d'exploitation et de gestion. Par ailleurs, le personnel de l'organisation doit être formé aux mesures de sécurité et doit s'engager à les respecter. Ainsi, la sécurité informatique fait également appel à l'intégrité des personnes qui conçoivent, gèrent, utilisent les infrastructures informatiques et à une gestion appropriée des ressources humaines^12(*).

Chapitre 2ème : INSTITUTIONS FINANCIERES ET SYSTEME DE PAIEMENT

ELECTRONIQUE

2.1 Institutions Financières

2.1.1 Définitions

Les institutions financières regroupent les institutions qui ont le pouvoir de créer de la monnaie^13(*).

Autrement, ce sont des entreprises qui produisent et vendent des services financiers.

Il s'agit notamment des banques, des établissements de crédit non bancaires, des entreprises d'investissement et des entreprises d'assurance.

On peut distinguer :

ü Les institutions financières monétaires (ayant pouvoir de créer la monnaie entre autres les banques centrales, les banques commerciales),

ü Les institutions financières spécialisées (établissements de crédit auxquels l'Etat confie une mission d'intérêt) ;

ü Les institutions financières nationales

ü Le Institutions financières internationales (FMI, Banque Mondiale, Réserve Fédérale).

2.1.2 Rôles

Le rôle principal des institutions financières est de servir d'intermédiaire financier entre les entreprises et les ménages.

Les institutions financières interviennent sur deux grandes variables économiques à savoir l'investissement et l'épargne.

Les entreprises peuvent :

ü Autofinancer leurs investissements (amortissement plus bénéfice non distribué),

ü Recourir au crédit (dans ce cas l'entreprise devra verser des intérêts aux banques) ou au marché financier (émissions de titres : actions, obligations).

Les ménages quant à eux, ont la possibilité de financer leurs investissements immobiliers par le moyen d'emprunt. Du moins, grâce à l'épargne, les ménages peuvent se procurer des :

· actifs monétaires (billets, pièces, dépôts à terme),

· actifs financiers (titres émis sur le marché financier par les entreprises)

· actifs réels (or, argent, immeubles,...)

L'épargne des ménages est généralement rémunérée sous forme d'intérêts par les banques.

2.1.3 Les Banques

Par définition, une banque est une entreprise qui effectue pour le compte d'autrui paiements et recettes, fait l'escompte, achète et revend des valeurs boursières, accorde des prêts, etc.^14(*).

Les banques sont les intermédiaires financiers qui ont pour fonction de recevoir des dépôts et d'accorder des prêts^15(*)

2.1.3.1 La banque électronique

2.1.3.1.1. La banque par ordinateur

a. Equipement nécessaire pour le client :

ü Un ordinateur.

ü Connexion entre son ordinateur et la banque,

ü Un modem et une ligne de téléphone.

ü Le programme adéquat fournit par la banque

ü Un système permettant de protéger les opérations effectuées par ordinateur.

b. Procédure

Actuellement, presque toutes les banques offrent désormais ce service. Il y a possibilité de signer une demande pour ce service dans pratiquement toutes les agences. Les opérations effectuées par ordinateur sont initiées par le client. Après avoir rempli toutes les formalités, le client pourrait rentrer avec un programme ainsi qu'un système de protection des opérations. Beaucoup de banques utilisent Digipass, qui est un petit appareil permettant à l'utilisateur de calculer, à l'aide d'un code secret et moyennant quelques manipulations simples, un code qui tient lieu de protection électronique.

Avec ce matériel, l'utilisateur pourra installer le programme dans son ordinateur, établir sa connexion, puis commencer à effectuer ses opérations depuis sa maison.

Les opérations possibles sont :

ü Consultation et impression des extraits,

ü Effectuer ses virements,

ü Vérification des portefeuilles d'actions,

ü Consultation des cours des actions,

ü Contrôle des dépenses effectuées à l'aide de ses cartes de crédit, etc.

2.1.3.1.2. La banque par téléphone

a. Equipement nécessaire

ü Une ligne de téléphone et

ü Un téléphone.

b. Procédure

La banque n'aura besoin que de la signature du client pour prendre la responsabilité des opérations qui seront effectuées par téléphone. La banque octroiera au client un code secret qu'il pourrait à tout moment modifier et s'en servira pour effectuer ses opérations. Un ordinateur vocal le guidera à travers les différentes étapes. La plupart du temps, il est possible, par téléphone, de contrôler le solde du compte du moment, d'avoir un aperçu des dernières opérations et d'effectuer des virements. Certaines banques offrent également la possibilité à leurs clients de s'adresser à un call center où des employés bien réels peuvent leur prêter assistance en cas de problèmes.

2.1.3.2 La banque par internet

a. Equipement nécessaire

Pareil à la banque par ordinateur, le client devrait disposer d'un ordinateur, d'un modem (et d'un abonnement internet) et d'une ligne de téléphone. Certaines banques offrent à leurs clients la possibilité d'accéder à leur site internet sans que ceux-ci doivent prendre un abonnement internet. Dans ce système, le client n'installe aucun programme spécifique sur l'ordinateur mais surfe directement sur le site internet de la banque, où il pourrait introduire sa signature électronique et effectuer ses opérations en ligne.

b. Procédure

Ici, une signature suffit à nouveau pour accepter la responsabilité des opérations effectuées via internet. Le client reçoit ensuite un système destiné à l'identifier et à sécuriser ses opérations (comme pour la banque par ordinateur) et la banque lui donne accès au site "transactionnel". En pratique, il peut dès lors entrer sur le site de la banque à partir de n'importe quel endroit au monde et y effectuer ses opérations. Outre les possibilités traditionnelles comme le visionnage et l'impression des extraits, l'exécution des virements, etc., ce système permet également d'acheter et de vendre des actions, de demander des informations sur des emprunts ou des assurances, de prendre rendez-vous avec l'agence. Les banques n'offrent pas toutes les mêmes services et le système peut connaître des limites d'ordre technique. Il est cependant très pratique car les banques peuvent adapter et enrichir en permanence leur site internet sans que cela pose le moindre problème pour l'utilisateur. Celui-ci n'a en effet plus besoin d'installer un logiciel sur le disque dur de son ordinateur.

2.1.3.3 La banque en self-service

Ici, aucun équipement particulier n'est nécessaire. Seuls la carte bancaire et le code secret allant de pair suffisent pour accéder aux guichets automatisés. Les opérations les plus courantes sont même effectuées en banque en dehors des heures ouvrables des agences.

Cette solution est idéale pour des personnes ne disposant pas d'un ordinateur, d'un téléphone ou d'un modem, si elles préfèrent effectuer leurs opérations seules ou qu'elles ne peuvent se rendre à l'agence durant les heures ouvrables. Aussi, les opérations électroniques coûtent moins cher : depuis peu, des frais sont en effet souvent imputés aux clients qui réalisent de petites opérations au guichet alors qu'il est possible de les effectuer en self-banking.

2.1.4 La Monnaie

La monnaie est un moyen de paiement accepté par tous, au sein d'un espace géographique donné, directement utilisable pour effectuer les règlements sur les marchés des biens et services ou pour régler définitivement toutes les dettes au sein d'un espace monétaire donné^16(*).

Dans les économies monétaires contemporaines, la monnaie peut être définie comme une créance sur un institut d'émission inscrite soit sur du papier (monnaie fiduciaire) soit sur des livres (monnaie scripturale)^17(*)

2.1.4.1 Historique

Dès lors que les êtres humains ont éprouvé le besoin de négocier des marchandises et des services, il leur a fallu un instrument d'échange. Le troc n'était pas pratique et n'offrait en outre que des possibilités limitées. Le recours à un instrument d'échange tel que l'argent a permis de scinder la transaction en deux : la personne A donne à la personne B une certaine somme d'argent en échange d'un certain bien; avec cette somme, la personne B achète un autre bien. L'argent fait donc office d'"intermédiaire" et devient aussi, par la force des choses, un instrument de mesure (la quantité de monnaie nécessaire pour exécuter une transaction est représentative de la valeur de cet échange ou de cette transaction).

Dans ses premières formes, l'argent consistait en marchandises qui avaient une valeur intrinsèque généralement acceptée, comme les briques de sel ou le thé. Mais il devait aussi avoir d'autres propriétés : il devait être difficilement falsifiable, être résistant, relativement rare et facilement divisible et utilisable.

Toutes ces qualités, l'or et l'argent les réunissaient. Mais, par la suite, la valeur intrinsèque de la monnaie va devenir progressivement une donnée de moins en moins importante, le public étant de plus en plus confiant dans le fait que des instruments d'échange lui permettent d'acheter d'autres marchandises. La monnaie fiduciaire, c'est-à-dire les billets de banque et les pièces de monnaie frappées dans des métaux non précieux comme le nickel, va alors tout doucement se substituer aux pièces en or et en argent.

On évoluera ensuite vers la monnaie scripturale. En fait de l'information consignée, c'est-à-dire de la monnaie qui circule par des jeux d'écritures entre débiteurs et créditeurs. Aujourd'hui, les opérations scripturales, prenant la forme d'ordres papier (tels que des virements et des chèques), sont de plus en plus souvent remplacées par des opérations électroniques (cartes magnétiques, cartes à puce, banque par téléphone, en self-service, à domicile, par ordinateur, etc.). Cette évolution tient principalement au fait que ce mode de paiement coûte moins cher et offre une meilleure sécurité.

2.1.4.2 Fonctions de la monnaie

On distingue habituellement trois fonctions de la monnaie :

· Intermédiaire des échanges^18(*)

· Réserve des valeurs

· Unité de mesure des valeurs (unité de compte)

2.1.4.3 Formes de la monnaie

Dans la littérature économique le terme « formes de la monnaie » désigne la variété d'instruments de circulation de la monnaie.

On distingue ainsi :

2.1.4.3.1 La monnaie métallique

Elle fait partie de la catégorie plus vaste de la monnaie marchandise. L'instrument de paiement est ainsi un objet tangible. Ces objets ont été divers selon les sociétés (bétail, sel, coquillages, morue....) mais la monnaie marchandise la plus connue est la monnaie métallique. Si les métaux tels que le cuivre, le fer, le bronze ont constituées les premières monnaies, ce sont les métaux précieux (or et argent), en raison de leurs qualités particulières, qui se sont progressivement imposés comme instruments monétaires.

2.1.4.3.2 La monnaie de papier ou les billets

La monnaie papier est acceptée en vertu de la confiance de son émetteur (d'où sa dénomination de monnaie fiduciaire). On dit également que c'est un instrument monétaire qui a une faible valeur intrinsèque en comparaison de sa valeur faciale.

La mise au point de cet instrument monétaire s'est révélée relativement longue. Trois grandes étapes ont marqué l'évolution du billet de banque :

· Dans l'Antiquité, puis au Moyen Age, les particuliers déposent de l'or et de l'argent auprès de banquiers et reçoivent en contrepartie des billets représentatifs de ces dépôts.

· Au XVIIème siècle : création du billet de banque par le banquier suédois Palmstruck.

2.1.4.3.3 La monnaie scripturale ou la monnaie de banque

On appelle ainsi la forme de la monnaie consistant en une écriture dans les livres d'une banque sous la forme de l'ouverture d'un compte à un client donnant naissance à un dépôt qui est une reconnaissance de dette de la banque envers son titulaire, et qui circule, sert à payer ses créanciers, est transférée sur le compte d'un autre agent par l'intermédiaire d'instruments tels que les chèques, les ordres de virement et les cartes bancaires.

Il s'agit de pratiques très anciennes. Ainsi les Grecs et les Romains connaissaient les virements de même que les arabes qui les utilisaient au IXe et Xe siècles. Cependant leur véritable développement date du XIIe siècle grâce aux marchands italiens et flamands.

2.1.4.3.4 La monnaie électronique ou la monétique

Par définition, la monnaie électronique est l'ensemble des techniques informatiques, magnétiques et télématiques assurant le transfert de sommes d'un compte vers un autre sans recourir à un support papier^19(*).

C'est une valeur monétaire représentant une créance sur l'émetteur, qui est stockée sur un support électronique, émise contre la remise de fonds d'un montant dont la valeur n'est pas inférieure à la valeur monétaire émise, acceptée comme moyen de paiement par des entreprises autres que l'émetteur^20(*).

La monnaie électronique est considérée « comme un substitut électronique des pièces et des billets de banque qui est stocké sur un support électronique tel qu'une carte à puce ou une mémoire d'ordinateur et qui est généralement destiné à effectuer des paiements électroniques de montants limités ».

Elle est non seulement une nouvelle évolution dans le cadre des paiements mais aussi une forme récente et particulière de la monnaie scripturale.

La monnaie électronique est véhiculée à travers deux nouveaux instruments de paiement :

· Le porte-monnaie électronique et

· Le porte-monnaie virtuel.

Le porte-monnaie électronique a pour objet l'automatisation des paiements de petits montants dans le commerce de proximité par le biais d'une carte à microprocesseur chargée de valeurs électroniques réelles qui peuvent être transférées directement entre les agents économiques^21(*).

Les applications directes de ce nouvel instrument de paiement concernent les distributeurs automatiques, les horodateurs, les péages, les publiphones, etc.

Le principe du porte-monnaie virtuel est sensiblement le même que le porte-monnaie électronique à la différence près que des unités électroniques sont chargées sur un logiciel porte-monnaie virtuel stocké sur le disque dur de l'ordinateur.

Le porte-monnaie virtuel a alors pour objet le paiement de petits montants à distance sur internet. Ces valeurs électroniques sont alors transmises sur le réseau pour le règlement des obligations financières entre les internautes et les e-marchands.

2.1.5 Les moyens de paiement

La monnaie scripturale représente de nos jours, une part très importante des moyens de règlement. La lettre de change et le billet à ordre sont cependant de moins en moins utilisés au profit d'autres instruments :

2.1.5.1 Le chèque

Le chèque est un ordre de paiement écrit adressé à sa banque (le tiré) que le payeur (le tireur) remet au bénéficiaire. Celui-ci peut se faire payer auprès de la banque du tiré directement ou le remettre à sa propre banque pour créditer son compte. Ainsi un dépôt bancaire (une dette du tiré) sera transféré du compte du payeur vers le compte du bénéficiaire.

2.1.5.2 Le virement

Le virement est un ordre du payeur adressé directement à sa banque afin que celle-ci effectue un transfert de fonds sur le compte d'un bénéficiaire par débit ou crédit. Celui-ci peut être un ordre automatique (permanent) donné à la banque afin que cette dernière vire à date fixe un montant déterminé à un tiers désigné à l'avance par le payeur. Le virement et le chèque sont rédigés sur du papier mais sont traités par l'informatique.

2.1.5.3 La domiciliation

Une domiciliation est une convention entre une personne qui effectue un paiement (débiteur), un bénéficiaire (le créancier) et une banque, en vertu de laquelle le débiteur autorise la banque à débiter automatiquement son compte du montant de chaque facture qu'il est tenu de régler au bénéficiaire. L'opération est entièrement automatique.

L'ordre permanent est basé sur un principe analogue à celui de la domiciliation : le compte du donneur d'ordre est automatiquement débité à une date donnée d'un montant fixe. Les données du bénéficiaire et du donneur d'ordre restent les mêmes. L'ordre permanent présente pour principaux avantages de permettre un gain de temps et d'être facile à utiliser.

2.1.5.4 L'avis de prélèvement automatique

C'est à l'initiative du créancier qui opère un prélèvement dans le cadre d'une autorisation donnée par le titulaire du compte. Cet instrument est généralement utilisé pour le paiement des impôts et des factures (téléphone, électricité...).

La somme est automatiquement et régulièrement prélevée sur le compte du débiteur.

2.1.5.5 Le titre interbancaire de paiement

Le débiteur donne son accord pour le paiement de chaque opération, mais le titre fait ultérieurement l'objet d'un traitement informatique.

2.1.5.6 La carte bancaire

C'est l'instrument le plus dématérialisé. Lors du paiement, les coordonnées bancaires du payeur sont saisies par lecture d'une piste magnétique de sa carte.

Elles permettront de pouvoir automatiquement débiter son compte et créditer le bénéficiaire de façon immédiate ou différée selon le type de contrat qui lie la banque et le détenteur de la carte. Il existe des formes élaborées qui permettent des opérations encore plus rapides, plus sûres et plus anonymes. Ainsi un code secret peut être joint à la carte qui est composé par le payeur rendant le débit immédiat. Les cartes à puces sont des cartes bancaires possédant un ordinateur miniaturisé permettant de stocker des informations sur un compte bancaire et de le débiter très rapidement. On parle également de monnaie électronique.

2.2. Système de paiement électronique (SPE)

2.2.1. Définition

Un système de paiement électronique est un ensemble des moyens et des modes de transmission sécurisés des dettes financières sur les réseaux ouverts^22(*)

2.2.2. Typologie

Des centaines de SPE ont été recensé sur internet^23(*), du moins malgré cette variété, on distingue trois classes génériques :

· Les SPE articulés autour d'un compte bancaire,

· Les SPE articulés autour d'un compte non bancaire,

· La monnaie électronique.

2.2.2.1. Les SPE articulés autour d'un compte bancaire

Caractérisée essentiellement par la proposition des outils de sécurisation des données d'origine bancaire. Cette catégorie des SPE concerne la sécurisation en ligne des ordres de paiement réalisés à partir de la carte bancaire.

La sécurisation des ordres de paiement est assurée par des institutions bancaires ou non.

Ainsi, on différencie dans cette classe deux types de systèmes à savoir :

· Les protocoles sécurisés de communication : gèrent la transmission sécurisée des types différents de données sur le réseau (mail, paiement). On peut citer ici le protocole SSL^24(*)

· Les protocoles de paiement permettent de gérer uniquement la transmission sécurisée des paiements sur les réseaux ouverts. Le protocole SET^25(*) a recours à la cryptographie asymétrique pour répondre aux impératifs de confidentialité et d'intégrité du paiement.

Bien que ces technologies permettant l'authentification des parties, la garantie de la confidentialité et de l'intégrité des données transmises se confirment vraiment être sécuritaires, ils présentent néanmoins des coûts importants de transaction.

2.2.2.2. Les SPE articulés autour d'un compte non bancaire

Dans ces systèmes, les ordres de paiement sont transmis avec sécurité depuis des comptes non bancaires. Pour accéder à son compte, l'utilisateur doit utiliser un support logiciel ou physique garantissant son authentification. Ici, la carte bancaire est utilisée pour avoir accès et être authentifié au compte bancaire.

Les deux modèles dans cette classe sont :

· Le système notarié : permettant à un intermédiaire ou notaire la compensation et règlement d'écriture entre comptes marchands et utilisateurs du SPE.

Ainsi, ce notaire peut :

ü Certifier les termes des transactions,

ü Authentifier les parties contractantes

ü Réaliser les compensations et

ü Procéder aux règlements définitifs des paiements

Dans ce système, le client est censé ouvrir et créditer un compte pour lequel l'accès est conditionné par un secret transféré pour authentifier l'utilisateur distant.

· Le système de fidélisation : l'intermédiaire propose à ses clients de maximiser des points (remboursables en monnaie fiduciaire) constituant un réel pouvoir d'achat.

2.2.2.3. La monnaie électronique

Voir le point 2.1.4.3.3.

2.2.2.4. Autres types de systèmes de paiement électronique^26(*)

2.2.2.3.1 Le portefeuille numérique :

§ Garde en mémoire, de façon sécurisée, les données sur une carte de crédit et son propriétaire :

ü le nom du client

ü son numéro de carte de crédit

ü l'adresse d'expédition

§ Fournit automatiquement ces informations lors d'un achat

2.2.2.3.2 Le système numérique de paiement à solde cumulé :

§ Est utilisé pour des micro-paiements (10 $ ou moins)

§ Permet d'accumuler le solde de micro-paiements et d'achats sur le Web sur son compte de carte de crédit ou de téléphone

2.2.2.3.3 Le système de paiement en ligne à valeur enregistrée.

§ Permet de faire des paiements instantanés en ligne selon une valeur enregistrée dans un compte électronique

§ Peut s'agir d'une plateforme commerciale (Valista) ou d'un système de paiement de poste à poste (PayPal)

2.2.2.3.4 Le chèque électronique.

Étend les fonctionnalités des comptes chèques existants en permettant leur utilisation pour le paiement d'achats en ligne.

2.2.2.3.5 Le système électronique de présentation de facture et de paiement.

Affiche le compte en ligne et permet de le régler par virement électronique depuis un compte bancaire ou de carte de crédit

2.2.2.3.6 Les systèmes de paiement électronique pour le commerce mobile

Au Japon par exemple, il existe trois types de systèmes de paiement électronique mobiles par téléphone cellulaire :

- les systèmes de paiement à valeur enregistrée permettant le paiement depuis un compte bancaire ou un compte de carte de crédit

- les cartes de débit mobile (associée à un compte bancaire)

- les cartes de crédit mobile

Autres concepts :

ü Bénéficiaire : une personne désignée dans un ordre de paiement pour recevoir des fonds ;

ü Carte de paiement : une carte émise par les organismes permettant à son titulaire de retirer ou de virer des fonds ;

ü Carte de retrait : une carte émise par les organismes permettant exclusivement à son titulaire de retirer des fonds ;

ü Certificat électronique : un document sous forme électronique attestant du lien entre les données de vérification de signature électronique et un signataire ;

ü Destinataire : une personne censée recevoir le message de données ainsi que le paiement qui doit y faire suite ;

ü Dispositif de création de signature électronique : un matériel ou un logiciel destiné à mettre en application les données de création de signature électronique ;

ü Dispositif de vérification de signature électronique : un matériel ou logiciel destiné à mettre en application les données de vérification de signature électronique ;

ü Données de création de signature électronique : les éléments propres au signataire, tels que des clés cryptographiques publiques, utilisés pour créer la signature électronique ;

ü Données de vérification de signature électronique : les éléments, tels que des clés cryptographiques publiques, utilisés pour vérifier la signature électronique ;

ü Ecrit : toutes les formes d'expression dotées d'une signification lisible ;

ü Expéditeur : une personne qui émet l'ordre de paiement et au nom de qui le virement est opéré. Le terme peut aussi désigner la banque expéditrice qui reçoit l'ordre de paiement ;

ü Intermédiaire : une personne qui, au nom et pour le compte d'une autre, envoie, reçoit ou conserve des messages de données. L'intermédiaire est astreint aux mêmes obligations que son mandataire ;

ü Message de données : l'information créée, envoyée ou reçue par des procédés ou moyens électroniques ou optiques ou des procédés ou moyens analogues, notamment, l'échange de données informatisées, la messagerie électronique, le télégraphe, le télex, la télécopie et l'image chèque;

ü Monnaie électronique : une valeur monétaire représentant une créance sur l'émetteur qui est stockée sur un support électronique ou sur un support de même nature, émise contre la remise de fonds d'un montant dont la valeur n'est pas inférieure à la valeur monétaire émise et acceptée comme moyen de paiement par des entreprises autres que l'émetteur. Comme moyen de stockage électronique de valeur monétaire reposant sur un support technique la monnaie électronique peut être utilisée pour effectuer des paiements à des entreprises autres que l'émetteur sans faire intervenir nécessairement des comptes bancaires dans la transaction. La monnaie électronique peut reposer sur un support matériel comme la carte à puce ou sur tout autre moyen similaire. Elle peut aussi reposer sur un logiciel intégré dans un ordinateur personnel ;

ü Ordre de paiement : une instruction inconditionnelle, sous forme de message de données, donnée par un expéditeur à une banque réceptrice de mettre à la disposition d'un bénéficiaire une somme d'argent déterminée ou déterminable. Le paiement effectué sur demande du bénéficiaire, quel qu'en soit le moyen utilisé, ne constitue pas un ordre de paiement ;

ü Porte-monnaie électronique : une carte de paiement prépayée, c'est-à-dire sur laquelle une certaine somme d'argent a été chargée, permettant d'effectuer des paiements électroniques de montants limités ;

ü Prestataire de services de certification électronique : toute personne qui délivre des certificats électroniques ou fournit d'autres services en matière de signature électronique ;

ü Qualification des prestataires de services de certification électronique : l'acte par lequel un tiers, dit organisme de qualification, atteste qu'un prestataire de services de certification électronique fournit des prestations conformes à des exigences particulières de qualité ;

ü Signataire : toute personne qui met en oeuvre un dispositif de création de signature électronique ;

ü Signature électronique sécurisée : une signature électronique qui satisfait, en outre, aux exigences suivantes :

· être propre au signataire ;

· être créée par des moyens que le signataire peut garder sous son

· contrôle exclusif ;

· garantir avec l'acte auquel elle s'attache un lien tel que toute modification ultérieure de l'acte soit détectable ;

ü Télépaiement : un procédé technique qui permet de transférer un ordre de paiement à distance par l'utilisation d'instruments ou de mécanismes d'émission d'ordre sans contact physique entre les différents intervenants (participants) ;

ü Virement électronique : une série d'opérations commençant par l'ordre de paiement du donneur d'ordre effectué par des moyens ou procédés électroniques de paiement dans le but de mettre des fonds à la disposition d'un bénéficiaire. Il peut notamment être effectué au moyen d'une carte bancaire, d'un porte-monnaie électronique ou par le procédé du télépaiement ou de tout autre mode électronique de paiement.

2ème Partie :

CONCEPTION DU NOUVEAU SYSTEME D'INFORMATIONChapitre 3ème : PRESENTATION DE LA BCDC

3.0. Introduction

Ce premier chapitre nous permettra de :

§ Nous familiariser avec l'organisation de la banque, plus précisément celle de la Direction Informatique et Monétique.

§ Mieux cerner le thème du projet

§ Définir la démarche d'analyse que nous allons adopter pour mener à bien notre projet.

3.1. Présentation

3.1.1. Historique

§ 1909 : Naissance de la Banque. Société anonyme, elle exerce la majeure partie de ses activités en Afrique centrale. En 1911, elle obtient pour le Congo belge le privilège d'émission qu'elle conservera plus de 40 ans.

§ 1960 : Le Congo devient un état souverain. La Banque fait apport de ses activités européennes à la Banque Belgo-Congolaise constituée le 14 avril à Bruxelles. Cette dernière est connue depuis 1965 sous la dénomination de Banque Belgolaise, actionnaire, aux côtés de l'Etat congolais et de partenaires privés, de la banque congolaise.

§ 1997-2003 : L'effondrement de l'économie du pays et la longue guerre civile ont imposé à la banque de réduire sa taille à un niveau compatible avec ses activités.

§ 2004... : Profitant de l'amélioration du climat sociopolitique et de l'embellie économique consécutive, la banque redéploie son réseau sur l'ensemble du territoire et adapte son organisation commerciale aux nouveaux besoins de sa clientèle de particuliers, de PME/PMI, de grandes entreprises et d'institutionnels.

Elle est aujourd'hui la banque de référence en RDC, active sur l'ensemble du territoire du pays.

3.1.2. Profil et quelques données chiffrées de la Banque

La Banque a l'intelligence du marché. Elle connaît, comprend et mesure les besoins de financement des principaux opérateurs économiques et met à leur disposition des compétences éprouvées au niveau international, reconnues et appréciées par sa clientèle. Elle en fait la démonstration en s'affirmant comme un des contributeurs les plus actifs au financement de l'économie. Ce faisant, elle développe progressivement son offre de produits pour répondre de manière adaptée aux nouveaux besoins d'une économie émergente.

·  La Banque est le banquier de référence en République Démocratique du Congo depuis l'année de sa création, avec un total de bilan au 31/12/2010 équivalent à USD 359,8 millions et une contribution au financement de l'économie à hauteur d'USD 125,1 millions.

·  La Banque est le banquier et le conseiller financier des grandes entreprises congolaises et internationales, des institutionnels, des PME/PMI performantes et des particuliers.

·  Pour répondre avec efficience aux besoins du marché, la Banque est organisée en directions commerciales spécifiquement dédiées à ses cibles de clientèle.

· Fin 2010 :

o la banque emploie 472 collaborateurs, en augmentation de 124 unités au cours des 5 dernières années,

o elle entretient et développe un réseau performant de 16 agences réparties sur le territoire de la RDC,

o partenaire de Western Union pour le métier du transfert d'argent, la Banque déploie 28 guichets sur le territoire national.

·  La Banque pratique une gouvernance d'entreprise stricte et rigoureuse afin d'assurer l'équilibre entre l'esprit d'entreprise et la maîtrise des risques et du contrôle.

· La Banque soutient une démarche éthique qui recouvre un ensemble de valeurs essentielles : Intégrité - Loyauté - Objectivité - Confidentialité - Franchise - Honnêteté - Transparence.

3.1.3. Mission

La Banque hérite d'une longue tradition d'éthique des affaires et est à ce jour, la banque de référence oeuvrant dans le secteur bancaire congolais depuis un siècle.

Forte d'une expérience remontant à l'année de sa création, la Banque se concentre sur des métiers spécialisés qui s'adressent à une clientèle sélectionnée d'entreprises, d'institutionnels, de banques et de particuliers.

La Banque vise à répondre à leurs besoins de conseils et de produits financiers à haute valeur ajoutée à partir de son siège de Kinshasa, de sa succursale de Lubumbashi, de son réseau d'agences actif dans l'ensemble du pays, de ses relations internationales privilégiées et de ses canaux e-business.

La Banque s'emploie à mettre en oeuvre les principes de bonne gouvernance qui visent à garantir sa réputation comme partenaire commercial et opérateur financier fiable et fidèle à ses valeurs essentielles.

La Banque veut être une banque jeune, dynamique, créative, tournée vers l'avenir, capable de jouer son rôle d'opérateur économique et financier de premier plan, de satisfaire ses actionnaires et de permettre à son personnel de s'épanouir avec fierté au sein de son entreprise.

3.1.4. Organigramme de la Banque



3.2. Présentation de la Direction de l'Informatique et de la Monétique

La direction de l'Informatique et de la Monétique (DIM) de la Banque est animée par un directeur et 12 (douze) agents.

Elle est structurée en 3 (trois) services qui sont :

§ Service Système et Production ;

§ Service Assistance aux Utilisateurs;

§ Service Monétique et Télématique.

3.2.1. Organisation de la DIM

3.2.1.1. La direction de la DIM

Elle est dirigée par un directeur qui donne les grandes orientations et supervise l'ensemble des activités des différents services.

3.2.1.2. Le secrétariat

S'occupe de la circulation de l'information entre les autres directions d'une part et la DIM d'autre part au sein même de la dite direction .Les dossiers administratifs sont d'abord enregistrés au secrétariat, puis transmis chez le directeur qui après traitement les réoriente au secrétariat. A cette étape, le secrétariat transmet les dossiers aux services concernés pour exécution. La secrétaire s'occupe également des travaux de secrétariat public.

3.2.1.3. Service Système et Production

Objectifs :

Permettre à la banque de disposer d'une plateforme informatique fiable et opérationnelle :

· L'administration des systèmes, du réseau,

· La gestion de la sécurité physique et logique,

· La gestion du matériel et du consommable informatique,

· La supervision des travaux confiés aux agents afin qu'ils soient bien faits,

· L'optimisation des dispositions de production,

· La mise en place et le suivi des indicateurs de production,

· Le suivi et faire respecter le calendrier de production.

3.2.1.4. Service Assistance aux utilisateurs

Ce service est en contact direct avec les utilisateurs (agents de la banque).

Objectifs :

· Installer les différentes applications de la société,

· Former les utilisateurs à l'utilisation des logiciels,

· Administrer les bases de données,

· Assister les utilisateurs dans leurs tâches quotidiennes d'exploitation,

· Veille sur le bon fonctionnement et la mise à jour des différentes applications.

· Gérer les aspects informatiques de la Télécompensation par chèques bancaires, les systèmes de transfert d'argent.

· Ecouter les préoccupations des utilisateurs pour mieux répondre à leurs besoins.

3.2.1.5. Service Monétique et Télématique

Ce service :

· Gère les guichets automatiques de billets (G.A.B). Grâce à ses cartes, l'argent des clients est disponible à tout moment dans les guichets automatiques,

· Donne la possibilité aux clients de disposer en outre de cartes secondaires pour son entourage, tout en contrôlant le plafond de retrait de chacune.

· Effectue la vérification des opérations quotidiennes,

· Veille à l'établissement d'un état, à la gestion et aux suivis des G.A.B,

· Veille à la gestion de réclamations porteuses, au dressage des statistiques mensuelles sur les opérations et les commissions,

· Veille à l'approvisionnement et à l'assistance des G.A.B par les consommables des guichets comme les journaux.

3.2.2. Organigramme de la DIM



Chapitre 4ème : ETUDE DE L'EXISTANT

4.0. Introduction

Dans le processus de conception d'un système d'information, la méthode RAD préconise l'étude du système existant. Ainsi, pour notre étude, il sera question de récolter les informations auprès des utilisateurs s'imprégner du domaine d'étude, nous chercherons à comprendre exactement le processus de circulation des informations. Cette tâche sera facilitée par l'élaboration des différents diagrammes UML, entre autre, le diagramme :

ü De collaboration,

ü De classes,

ü De cas d'utilisations

ü Et de séquences.

C'est à partir de cette démarche que nous finirons par ce qui nous permettra de ressortir les points forts et les points faibles du système actuel.

4.1. L'analyse en UML (Unified Modeling Language)

· Le but^27(*) de l'analyse est de traduire dans un langage proche de celui des informaticiens les modèles exprimés dans l'expression des besoins.

· Cependant pour rester compréhensible par les clients ou utilisateurs, il n'intervient que des entités du domaine (métier) considéré.

· Elle sert d'interface, avec l'expression des besoins, aux dialogues et aux contrats avec les clients et les utilisateurs.

· L'analyse doit servir de support pour la conception, l'implémentation et la maintenance.

UML regroupe différents concepts provenant de méthodes objets de référence à savoir, OOSE4, BOOCH3 et OMT2.

4.2. La méthode Rapid Application Development (RAD)

La complexité de concevoir un système d'information nécessite de suivre une méthode. La structure de la méthode RAD propose cinq étapes :

§ L'initialisation :

ü Définition du périmètre général du projet,

ü Structuration par thème le travail,

ü Sélection des acteurs pertinents et

ü Amorcer dynamique du projet ;

§ Le cadrage : concerne l'expression des besoins des utilisateurs,

§ Le design : Etape de conception ou de reconfiguration et de la modélisation du futur système;

§ La construction : Etape de réalisation du futur système par prototypage

§ La finalisation : se charge de l'officialisation de la livraison globale et le transfert du système en exploitation et en maintenance.

4.2.1. Description des phases de RAD

1^ère phase : Repérage du domaine

L'objet principal est la détermination de la finalité du projet, son périmètre, ainsi que les acteurs concernés;

2^ème phase : Découverte des informations

Permet de connaître et comprendre tous les aspects du système d'information et aussi repérer les grands concepts d'informations gérés dans le domaine;

3^ème phase : Modélisation du workflow

A ce niveau s'effectue l'identification des rôles des différents acteurs et leur façon de collaborer au sein du domaine.

4^ème phase : Diagnostic

Le diagnostic permet d'apprécier la gestion des informations et les processus;

5^ème phase : Reconfiguration du système d'information

C'est à ce stade que les nouveaux principes portant sur la gestion des informations ainsi que la configuration des processus sont fixés;

6^ème phase : Modélisation du futur système d'information

Concerne la modélisation des différents aspects du système d'information futur en s'appuyant sur les règles arrêtées lors de la phase précédente;

7^ème phase : Rédaction du cahier des charges

Cette phase concerne la mise en forme du cahier de charges du futur système d'information.

4.3. Objectifs de l'étude de l'existant

· Comprendre l'actuel fonctionnement du système par une description détaillée des ressources humaines et matérielles de la banque,

· Répertorier les contraintes à prendre en compte en identifiant les points positifs et les points de dysfonctionnement,

· Evaluer et critiquer la situation actuelle de la monétique en termes de système d'information, d'organisation et de méthodes de travail.

· Eliminer les méthodes de gestion et d'organisation jugées défaillantes,

· Considérer les souhaits des utilisateurs pour des propositions des solutions plus adéquates,

4.4. Ressources disponibles

4.4.1. Ressources Humaines

Sous la responsabilité du directeur, la direction de l'Informatique et de la Monétique de la banque comprend les agents suivants répartis selon leurs services :

ü Un directeur;

ü Une secrétaire;

ü Quatre agents dans le service Système et Production;

ü Trois agents dans le service Assistance aux Utilisateurs ;

ü Trois agents dans le service Monétique.

4.4.2. Ressources Matériel

Le parc informatique de la banque au niveau de la direction générale comprend :

ü Plus de 250 micro-ordinateurs de bureau et des ordinateurs portables de marque, DeJI et HP,

ü 1 nouveau système d'information fonctionnant sous Windows,

ü 1 onduleur de 40kva,

ü 2 onduleurs de 15kva,

ü 2 onduleurs de 6kva,

ü 4 hubs pour le réseau

ü 1 serveur central contrôleur principal de domaine Windows 2003

ü 1 serveur de messagerie Microsoft Exchange,

ü 1 serveur Unix Aix qui intègre le système DELTA-BANK et

ü 1serveur vocal.

ü Plus de 110 imprimantes de marques différentes soit HP (1200), HP (1100), HP5L, HP (1150), Canon LBP 800, Lexmark E321 et des imprimantes matricielles de marque Epson (FX, LX, LQ).

Certaines imprimantes sont configurées sur machine d'utilisateur et d'autres partagées en réseau.

4.4.3. Le système informatique existant

Le système informatique de la banque s'occupe de :

ü La gestion du parc informatique,

ü La gestion des logiciels installés,

ü La maintenance du réseau informatique.

ü L'administration de la base de données, le paramétrage, l'assistance technique aux utilisateurs et le traitement de fin de journée (Batch).

4.4.4. Les Logiciels

A la banque on trouve les logiciels de base et les logiciels d'application.

4.4.4.1. Les logiciels de base

Dans cette catégorie nous avons d'une part des systèmes d'exploitation :

ü Windows XP

ü Unix,

ü MS DOS : systèmes d'exploitation de microordinateurs

Et d'autre part, des systèmes de gestion de base de données :

ü Oracle 9i

ü Informix,

ü SQL Base,

ü Access 2003

ü SQL Serveur,

Des langages de programmation :

ü Visual Basic,

ü Easy PHP,

ü Programmation Shell sous linux, avec les scripts.

4.4.4.2. Les logiciels d'application

Certains de ces logiciels ont été acquis par la Direction Informatique à travers les partenaires et d'autres ont été développée par les informaticiens de la banque. Ce sont:

ü DELTA BANK, version 8 : logiciel bancaire ;

ü DELTA PAIE : Gestionnaire de la paie du personnel;

ü DELTA lMMO : Gestionnaire des Immobilisations ;

ü DELTA SWIFT, MONEY EXPRESS, WESTERN UNION : pour le transfert d'argent,

ü IMAGE CHEQUE : Gestionnaire de la Télé compensation;

ü CORITEL & CORINET : Gestionnaire de la Télématique;

ü D.A.B : Gestionnaire du distributeur automatique de billets;

ü Une application qui gère les frais de mission ;

ü Une application qui gère les courriers ;

ü Une application qui gère les demandes de chéquiers ;

ü Multi X pack: gestionnaire des cartes bancaires.

4.4.5. Le Réseau

4.4.5.1. Le réseau global

L'avènement de nouvelle forme d'organisation et le rôle stratégique que jouent les télécommunications dans le développement d'une entreprise, ont conduit la banque à opter pour une liaison spécialisée avec ses agences. En effet, toutes les agences de la banque utilisent le réseau VSAT^28(*) et la technologie WIFI^29(*) par des antennes BLR^30(*)s qui relient les sites abritant les GAB^31(*).

4.4.5.2. Le Réseau local

La liaison entre différentes ressources du réseau local de la banque est assurée par des câbles Ethernet. Ainsi, des prises ont été prévues dans chaque bureau pour assurer la liaison entre postes de travail du réseau local. Cette liaison passe aussi par le commutateur de palier. Un autre câble relie les commutateurs des étages à ceux de la salle informatique. La topologie du réseau ETHERNET 100 BASE-T répond à la disposition géographique des postes de travail et au nombre d'ordinateurs qui composent ce réseau.

4.4.5.3. L'offre monétique

La banque offre une gamme variée de cartes bancaires pour répondre à la satisfaction de ses clients. On y trouve par exemple : CASH ADVANCE, MALAKITE, IVOIRE, AKSANTI, permettant aux clients de la banque de retirer de l'argent 24h/24 dans les distributeurs des agences et de payer directement chez les commerçants partenaires. Les cartes internationales VISA et MASTER CARD sont aussi disponibles, permettant aux clients de la banque d'effectuer des retraits à travers le monde entier.

4.4.5.4. Les Services

4.4.5.4.1. Retrait d'espèces

Le retrait d'argent peut s'effectuer à tout moment par les clients.

4.4.5.4.2. La consultation de solde

Le dernier solde du client peut être directement édité.

4.4.5.4.3. L'édition de relevés de compte

Il est possible de relever les 10 derniers mouvements effectués sur le compte.

Plusieurs autres services sont disponibles par la banque.

4.4.5.4.4. La Banque en Ligne E-BANKING

Les clients de la banque peuvent directement grâce à une connexion internet, accéder à leur compte depuis un poste de travail et avoir toutes les informations et effectuer des opérations possibles comme s'ils étaient dans une agence de la banque :

ü Consulter un compte;

ü Commander un chéquier ou une carte bancaire;

ü Editer un relevé de compte;

ü Donner des ordres de virement ;

ü Consulter le cours de change des principales devises.

ü Etc.

4.5. PREMIERE PHASE : REPERAGE DU DOMAINE D'ETUDE

Cette phase consiste à la prise de connaissance du projet et trouve ses fondements sur des interviews de direction avec différents membres de l'entreprise ayant une vue globalisante du domaine et pouvant fixer des grandes orientations.

4.5.1. Objectif

Le principal objectif est la détermination des finalités du projet, ses limites ainsi que l'ensemble d'acteurs y intervenant.

Cette phase est illustrée par le diagramme de flux ci-dessous.

4.5.2. Déroulement du repérage du domaine d'étude (phase 1)

Cette phase a été effectuée par de nombreuses rencontres que nous avons eues avec les différents intervenants (responsables de service, agents comptables, agents techniques) dans le processus d'élaboration du système de paiement électronique.

4.5.3. Délimitation du domaine d'étude

C'est grâce au diagramme de collaboration que les limites du projet sont représentées. Parce qu'il s'agit des opérations d'achat et de vente entre le client et son fournisseur, l'intervention de la banque ne pourrait avoir lieu qu'au cas où un client désire retirer son argent par chèque ou par carte bancaire ou encore lorsqu' un fournisseur dépose un chèque pour virement.

4.5.3.1. Diagramme de Collaboration

Ce diagramme facilite la mise en évidence des interactions entre objets du système et aussi entre objets et les messages qu'ils s'échangent. Lorsque le diagramme met en évidence des paquetages on parlera de diagramme de flux,

4.5.3.1.1. Notion de paquetage

Le paquetage regroupe les éléments de modélisation du système à savoir : les classes, les associations, les objets, les cas d'utilisations etc. Et dans le cadre de notre travail, nous nous en servirons pour représenter les domaines identifiés lors de la phase 1.

Formalisme de représentation d'un paquetage du diagramme de flux



4.5.3.1.2. Notion de message

Les paquetages communiquent entre eux moyennant le message.

Formalisme de représentation d'un message du diagramme de flux :



4.5.3.2. Représentation du diagramme de flux existant



1. Lancer commande

2. Envoyer facture

3. Livrer commande

4. Payer commande

5. Déposer chèque

6. Débiter compte

7. Régler fournisseur

4.6. DEUXIEME PHASE : LA DECOUVERTE DES INFORMATIONS

4.6.1. Objectif de la découverte des informations

Maîtriser les différentes façades du système d'information existant c'est-à-dire, comprendre les concepts importants d'informations que gère le domaine.

Cette phase, c'est-à-dire la découverte des informations se fait simultanément avec le repérage du domaine et la modélisation du Workflow.

4.6.2. Déroulement de la découverte des informations

Nous avons profité des interviews faits avec les principaux acteurs du système lors de la phase précédente, à savoir le repérage du domaine pour découvrir les informations nous permettant de mieux circonscrire l'architecture du système en place.

4.6.2.1. Résultat de la deuxième phase

4.6.2.1.1. Compte rendu des interviews

a. Avec le Directeur de la DIM

Nom de l'organisme : Domaine : D.I.M^32(*)
Compte rendu de l'interview	Poste: Directeur Interviewé : - Date: 15/07/12
Missions du Directeur : § suggérer la définition de la politique de développement des activités informatiques et monétiques et en assurer la mise en oeuvre; § garantir l'intégrité du système d'information (administration, sécurité, protection du système) ; § assurer l'intégration de nouvelles technologies de l'information dans la gestion de la banque; § élaborer le programme prévisionnel annuel des activités de la direction et en assurer l'exécution; § suivre l'exécution budgétaire sur la base des données fournies par le contrôle de gestion; § assurer la mise en oeuvre des programmes et actions de la direction inscrits dans le plan d'affaires ; § participer à la révision des conditions de banques; § élaborer et mettre à jour les procédures et instructions relatives aux activités confiées à la direction ; § assurer l'exécution des diligences demandées par les autorités Monétaires et de contrôle relatives au domaine d'activités de la direction ; § assurer l'établissement de certaines données nécessaires au contrôle de gestion et en assuré l'exploitation ; § rédiger le rapport d'activité de la direction; § participer aux actions de formation.

b. Avec le Chef de service de la Monétique

Nom de l'organisme : Banque ... Domaine : SM^33(*)
Compte rendu de l'interview	Poste: Chef de service Interviewé : - Date: 16/07/12
Mission principale du Service de la Monétique : § Gérer la monétique entre autre les cartes bancaires et les GAB^34(*). La banque est membre du GIM^35(*) qui met à la disposition des clients certaines cartes propres au groupe leur permettant d'effectuer des opérations sur les GAB des banques de la zone du groupement. Les serveurs monétique des banques affiliés au GlM convergent tous vers le CTMI^36(*).

c. Avec le chef de service de la Monétique

Nom de l'organisme : Banque ... Domaine : SM^37(*)
Compte rendu de l'interview	Poste: Chef de service Interviewé : - Date: 17/07/12
Mission principale du Service de la Monétique : § Gérer la monétique entre autre les cartes bancaires et les GAB^38(*). Le serveur monétique centralise et enregistre tous les traitements effectués par les GAB. L'agent comptable s'occupe aussi de : § La mise à jour des informations du serveur monétique vers les serveurs de comptabilité de la banque, § La maintenance, de la surveillance et de la réparation des GAB ; Le GAB peut connaître un certain nombre de panne le rendant ainsi indisponible à la clientèle. Ces pannes peuvent être de nature : ü Mécanique: lecteur de cartes défectueux, clavier brisé et disque dur corrompu ü Logiciel: système d'exploitation en faute et pilote de périphérique dépassé communication: réseau en panne de façon intermittente.

d. Chef de service assistance aux utilisateurs

Nom de l'organisme : Banque ... Domaine : Service Assistance aux Utilisateurs
Compte rendu de l'interview	Poste: Chef de service Interviewé : - Date: 18/07/12
Résultats attendus pour cette application: ü Doter un nouveau moyen de paiement, la carte bancaire à la clientèle, ü Le client peut facilement acheter en ligne en mode sécurisé à tout moment et en tout lieu; ü Permettre au client de faire opposition de sa carte bancaire; ü Offrir une nouvelle plateforme aux commerçants pour vendre leurs produits et contrôler leurs différentes transactions ü Etc.

a. Service de l'administration système

Nom de l'organisme : Banque ... Domaine : Service de l'administration des systèmes
Compte rendu de l'interview	Poste: Chef de service Production et Exploitation Interviewé : - Date: 19/07/12
Le Service Production et Exploitation a pour rôles de : ü Veiller à la sécurité et au bon fonctionnement de différents logiciels, serveurs, accessoires et autres matériels du site central; ü Suivre les contrats de maintenance et prendre les dispositions utiles pour assurer leur exécution ; ü Prendre part aux inventaires périodiques du parc des équipements informatiques, logiciels et applicatifs en service; ü Organiser des formations des utilisateurs depuis l'initiation à l'utilisation correcte des applicatifs à la petite maintenance (nettoyage) sur site ; ü assurer le développement et la maintenance logiciel et matériel du dispositif de communication Intranet ainsi que des liaisons inter-sites, qu'ils soient sous contrat de maintenance ou non; ü Assurer le bon fonctionnement des outils de communication externe (accès à Internet) ; ü Mettre en oeuvre une assistance auprès des utilisateurs de micro-ordinateur pour le bon fonctionnement des appareils mis à leur disposition; ü Entretenir les relations techniques avec les fournisseurs de matériels et de prestations bureautique; ü Assurer le développement de l'archivage électronique ; ü Participer à la formation des agents de la banque et des stagiaires sur le plan informatique.

4.7. Diagramme de classes

4.7.1. Notion de classe

4.7.1.1. Définition d'une classe

Une classe est un ensemble de données et de fonctions regroupées dans une même entité. Une classe est une description abstraite d'un objet. Les fonctions qui opèrent sur les données sont appelées des méthodes. Instancier une classe consiste à créer un objet sur son modèle. Entre classe et objet il y a, en quelque sorte, le même rapport qu'entre type et variable^39(*).

4.7.1.2. Représentation d'une classe

Ce rectangle à trois compartiments est la représentation d'une classe :

ü nom de la classe;

ü les attributs;

ü les méthodes.



Dans la notation UML, les attributs et méthodes publics sont précédés du signe plus tandis que les attributs et méthodes privés (encapsulés) sont précédés du signe moins.

4.7.1.3. Notion d'attribut

Il s'agit des données caractérisant l'objet. Ce sont des variables stockant des informations sur l'état de l'objet^40(*).

Il est possible d'identifier une classe à partir d'un attribut. Il est typé (Integer, Real, String ...).

4.7.1.4. Notion de méthodes

Les méthodes d'un objet caractérisent son comportement, c'est-à-dire l'ensemble des actions (appelées opérations) que l'objet est à même de réaliser. Ces opérations permettent de faire réagir l'objet aux sollicitations extérieures (ou d'agir sur les autres objets). De plus, les opérations sont étroitement liées aux attributs, car leurs actions peuvent dépendre des valeurs des attributs, ou bien les modifier.

4.7.1.5. Notion de multiplicité

La multiplicité définit le nombre d'instances de l'association pour une instance de la classe^41(*).

La multiplicité est définie par un nombre entier ou un intervalle de valeurs, elle est aussi la traduction d'une règle de gestion.

De façon pratique, on utilise des valeurs:

1	Un et un seul
0..1	Zéro ou un
N ou *	N (entier naturel)
M..N	De M à N (entiers naturels)
0..*	De zéros à plusieurs
1..*	De 1 à plusieurs

4.7.1.6. L'association

L'association est la relation la plus courante et la plus riche du point de vue sémantique^42(*).

Une association est une relation statique n-aire (le plus souvent : elle est binaire) : c'est-à-dire qu'elle relie plusieurs classes entre elles. L'association existe entre les classes et non entre les instances : elle est introduite pour montrer une structure et non pour montrer des échanges de données.

4.7.1.6.1. Les classes-association

Les attributs d'une classe dépendent fonctionnellement de l'identifiant de la classe. Parfois, un attribut dépend fonctionnellement de 2 identifiants, appartenant à 2 classes différentes. Une classe association est une association porteuse d'attribut(s).

4.7.1.7. Généralisation /Spécialisation^43(*)

Le principe de généralisation / spécialisation permet d'identifier parmi les objets d'une classe (générique) des sous-ensembles d'objets (des classes spécialisées) ayant des définitions spécifiques. La classe plus spécifique (appelée aussi classe fille, classe dérivée, classe spécialisée, classe descendante ...) est cohérente avec la classe plus générale (appelée aussi classe mère, classe générale ...), c'est-à-dire qu'elle contient par héritage tous les attributs, les membres, les relations de la classe générale, et peut contenir d'autres.

Les relations de généralisation peuvent être découvertes de 2 manières :

ü la généralisation : il s'agit de prendre des classes existantes déjà mises en évidences) et de créer de nouvelles classes qui regroupent leurs parties communes ; il faut aller du plus spécifique au plus général.

ü La spécialisation : il s'agit de sélectionner des classes existantes (déjà identifiées) et d'en dériver des nouvelles classes plus spécialisées, en spécifiant simplement les différences.

Ces 2 démarches, même si elles sont fondamentalement différentes, mènent au même résultat, à savoir la constitution d'une hiérarchie de classes reliées par des relations de généralisation.

La relation de généralisation est très puissante car elle permet de construire simplement de nouvelles classes à partir de classes existantes. Cependant, elle est très contraignante dans le sens où elle définit une relation très forte entre les classes. Ainsi, l'évolution d'une classe de base entraîne une évolution de toutes les classes qui en dérivent. Cet effet boule de neige peut avoir des conséquences aussi bien positives (quand c'est l'effet recherché) que négatives.



4.7.1.8. Agrégation

Dans UML, l'agrégation n'est pas un type de relation mais une variante de l'association. Elle représente une association non symétrique dans laquelle une des extrémités joue un rôle prédominant par rapport à l'autre extrémité. L'agrégation ne peut concerner qu'un seul rôle d'une association.

L'agrégation :

ü se représente toujours avec un petit losange du côté de l'agrégat.

ü est un type d'association qui exprime un couplage plus fort entre les classes.

ü permet de modéliser des relations de type maître et esclaves.

ü permet de modéliser une contrainte d'intégrité et de désigner l'agrégat comme contrainte.

Formalisme :



4.7.1.9. Règles de gestion

Les Règles de Gestions (RG) retenues sont :

RG1 : Un client a au moins un compte dans au moins une banque.

RG2 : Un compte appartient à un et un seul client.

RG3 : Un fournisseur a au moins un compte dans au moins une banque.

RG4 : Une banque est en relation avec au moins une autre banque.

RG5 : Un client possède au moins un chéquier.

RG6 : Un chéquier contient des chèques.

RG7: Un client édite un ou plusieurs chèques.

RG8 : Un chèque dépend d'un compte.

RG9 : Un compte appartient à une et une seule banque.

RG10 : Un chèque règle au moins une facture.

RG11: Un fournisseur délivre au moins une facture.

RGI2 : Une facture s'applique à une livraison.

RG13 : Une facture est générée par au moins une commande.

RG14 : Une livraison se compose d'au moins un produit.

RG15 : Une commande contient au moins un produit.

RG16 : Une commande provoque au moins une livraison.

RG17 : Un client peut passer plusieurs commandes.

RG18 : Un fournisseur livre des produits.

RG19 : Au moins une opération est faite sur un compte.

RG20: Un fournisseur peut effectuer au moins une opération.

RG21 : Un client peut effectuer plusieurs opérations.

RG22 : Une carte bancaire peut être utilisée pour faire au moins un retrait.

RG23 : Un client possède au moins une carte bancaire.

4.7.2. Représentation du diagramme des classes actuel

Après avoir analysé les informations recueillies lors des interviews auprès des différents acteurs du système nous avons représenté le diagramme de classe suivant :



Nous avons réalisé le diagramme de classes suivant avec Photoshop Cs4.

Pour une question de lisibilité, les types des attributs n'ont pas été mentionnés dans le diagramme de classes mais dans la description des classes.

4.7.3. Description des classes du diagramme

Classe Client : regroupe les personnes affiliées à la banque
Attribut	Nom	Description	Type
	N°CIBClient	Numéro de la CIB du client	Numérique
	NomClient	Nom du client	Texte
	PrenomClient	Prénom du client	Texte
	AdresseCIient	Adresse du client	Texte
	NumTélClient	Numéro Téléphone du client	Texte
	MailClient	Mail du client	Texte
Méthodes	Nom	Description
	CréerClient	Permet la création d'un nouveau client
	AfficherClient	Permet d' afficher la liste des clients
	ModifierClient	Permet de modifier des informations sur un client
	SupprimerClient	Permet de supprimer un client de la 1iste

Classe Compte : regroupe les différents comptes des clients

Attribut

Nom

Description

Type

N°Compte

Numéro du compte

Numérique

TypeCompte

Type du compte

Texte

Méthodes

Nom

Description

CréerCompte

Permet la création d'un nouveau compte

ConsulterCompte

Permet de consulter un compte

ModifierCompte

Permet de modifier des informations sur un compte

SupprimerCompte

Permet de supprimer un compte de la liste

Classe Fournisseur : contient l'ensemble des commerçants

Attribut

Nom

Description

Type

IDFournisseur

Identifiant du fournisseur

Texte

NomFounisseur

Nom du fournisseur

Texte

AdresseFournisseur

Adresse du fournisseur

Texte

MailFournisseur

Mail du fournisseur

Texte

Méthodes

Nom

Description

CréerFournisseur

Permet la création d'un nouveau fournisseur

AfficherFournisseur

Permet d'afficher la liste des fournisseurs

ModifierFournisseur

Permet de modifier des informations sur un fournisseur

SupprimerFournisseur

Permet de supprimer un fournisseur de la liste

Classe Chéquier : regroupe la liste des chéquiers

Attribut

Nom

Description

Type

N°Chéquier

Numéro du chéquier

Numérique

NombreChèque

Nombre de chèques

Numérique

Méthodes

Nom

Description

CréerChéquier

Permet la création d'un nouveau chéquier

AfficherChéquier

Permet d'afficher la liste des chéquiers

ModifierChéquier

Permet de modifier des informations sur un chéquier

SupprimerChéquier

Permet de supprimer un chéquier de la liste

Classe Chèque: regroupe l'ensemble des chèques

Attribut

Nom

Description

Type

N°Chèque

Numéro du chèque

Numérique

LibelléChèque

Libellé du chèque

Texte

Méthodes

Nom

Description

Créer Chèque

Permet la création d'un nouveau Chèque

Afficher Chèque

Permet d'afficher la liste des Chèques

Modifier Chèque

Permet de modifier des informations sur un Chèque

Supprimer

Chèque Permet de supprimer un Chèque de la liste

Classe carte Bancaire : regroupe la liste des cartes bancaires

Attribut

Nom

Description

Type

N°Carte

Numéro de la carte bancaire

Texte

DateValidité

Date de validité de la carte bancaire

Date

CodeVérification

Code de vérification de la carte bancaire

Numérique

Méthodes

Nom

Description

CréerCarte

Permet la création d'une carte bancaire

AfficherCarte

Permet d'afficher la liste des cartes bancaires

ModifierCarte

Permet de modifier des informations sur une carte bancaire

SuspendreCarte

Permet de suspendre une carte bancaire

Classe Opération : regroupe l'ensemble des opérations effectuées

Attribut

Nom

Description

Type

CodeOpération

Code de J'opération

Texte

Nature

Nature de l'opération

Texte

Montant

Montant de l'opération

Numérique

Méthodes

Nom

Description

CréerOpération

Permet la création d'une nouvelle opération

ConsulterOpération

Permet d'afficher la liste des opérations

ModifierOpération

Permet de modifier des informations sur une opération

SupprimerOpération

Permet de supprimer une opération de la liste

Classe Retrait: regroupe la liste des retraits

Attribut

Nom

Description

Type

IDRetrait

Identifiant du retrait

Texte

NatureRetrait

Nature du retrait

Texte

MontantRetrait

Montant du retrait

Numérique

Méthodes

Nom

Description

CréerRetrait

Permet la création d'un nouveau retrait

ConsulterRetrait

Permet d'afficher la liste des opérations de retraits

Classe Dépôt: regroupe la liste des dépôts

Attribut

Nom

Description

Type

IdDépôt

Identifiant du dépôt

Texte

NatureDépôt

Nature du dépôt

Date

MontantDépôt

Montant du dépôt

Numérique

Méthodes

Nom

Description

CréerDépôt

Permet la création d'un nouveau dépôt

ConsulterDépôt

Permet d'afficher la liste des opérations de dépôt

Classe Commande: regroupe la liste des commandes

Attribut

Nom

Description

Type

N°Commande

Numéro de la commande

Numérique

ObjetCommande

Objet de la commande

Texte

QuantitéCommande

Quantité de la commande

Numérique

DateCommande

Date de la commande

Date

Méthodes

Nom

Description

CréerCommande

Permet la création d'une nouvelle Commande

ConsulterCommande

Permet de consulter la liste des Commandes

ModitierCommande

Permet de modifier des informations sur une Commande

SupprimerCommande

Permet de supprimer une Commande de la liste

Classe Facture: regroupe la liste des factures

Attribut

Nom

Description

Type

N°Facture

Numéro de la facture

Numérique

TypeFacture

Date d'acquisition de la facture

Texte

DateFacture

Montant d'acquisition de la facture

Date

Méthodes

Nom

Description

CréerFacture

Permet la création d'une nouvelle Facture

ConsulterFacture

Permet de consulter la Jiste des Factures

ModifierFacture

Permet de modifier des informations sur une Facture

SupprimerFacture

Permet de supprimer une Facture de la liste

Classe livraison: regroupe la liste des livraisons effectuées

Attribut

Nom

Description

Type

N°Livraison

Numéro de la livraison

Numérique

DateLivraison

Date d'acquisition de la livraison

Date

Méthodes

Nom

Description

CréerLivraison

Permet la création d'une nouvelle livraison

ConsulterLivraison

Permet de consulter la liste des livraisons

ModifierLivraison

Permet de modifier des informations sur une livraison

SupprimerLivraison

Permet de supprimer une livraison de la liste

Classe Produit: regroupe J'ensemble des produits

Attribut

Nom

Description

Type

IdProduit

Identifiant du produit

Texte

NomProduit

Nom du produit

Texte

TypeProduit

Type du produit

Texte

Méthodes

Nom

Description

CréerProduit

Permet la création d'un nouveau produit

ConsulterProduit

Permet de consulter la liste des produits

ModifierProduit

Permet de modifier des informations sur un produit

SupprimerProduit

Permet de supprimer un produit de la liste

Classe Banque : contient la liste des banques

Attribut

Nom

Description

Type

IDBanque

Identifiant de la banque

Texte

NomBanque

Nom de la banque

Texte

AdresseBanque

Adresse de la banque

Texte

MailBanque

Adresse électronique de la banque

Texte

Méthodes

Nom

Description

CéerBanque

Permet la création d'une nouvelle banque dans la liste

AfficherBanque

Permet d'afficher des informations sur une banque

ModifierBanque

Permet de modifier les informations sur une banque

SupprimerBanque

Permet de supprimer une banque de la liste

4.8. TROISIEME PHASE : MODELISATION DU WORKFLOW (Flux de travail)

4.8.1. Objectif

Après avoir identifié acteurs et entités, nous allons décrire les flux d'évènements et les activités des processus faisant usage des objets créées. Ce flux d'évènements est appelé « Workflow » (flux de travail).

La description du workflow est utile :

· pour la présentation de délai des interactions entre différents acteurs ;

· pour identification des protocoles, des acteurs ou des entités ;

· lorsque les fractions d'un processus ne sont pas claires ou complexes.

· lorsque la conformité de la séquence d'activités est importante;

· lorsqu'il y'a moins d'acteur, beaucoup d'entités utilisées et plusieurs activités à effectuer.

Beaucoup de diagrammes peuvent découler de la description du workflow. Dans ce travail, nous ne nous intéresserons qu'aux diagrammes des cas d'utilisation et de séquence.

4.8.2. Déroulement de la troisième phase

La modélisation du workflow, troisième phase a été rendue effective non seulement lors des différents entretiens et réunion avec les principaux acteurs du domaine d'étude, mais aussi partant des diagrammes obtenus dans les deux précédentes phases.

4.8.3. Résultats de la troisième phase

4.8.3.1. Diagramme de cas d'utilisation

4.8.3.1.1. Acteurs

Un acteur représente une entité appartenant à l'environnement de l'application qui interagit avec l'application ou encore, il définit un ensemble harmonieux de rôles qu'un utilisateur ou une entité externe peut jouer en interagissant avec le système.

Ainsi, il peut consulter et/ou modifier directement l'état du système en échangeant des messages pouvant transporter certaines données.

Les principaux acteurs du système actuel sont :

Le Comité de Pilotage

C'est pour l'arbitrage et le contrôle des décisions à prendre que ce comité est mis en place. Ses principales missions sont :

ü La définition de l'organisation et la mise en place des procédures ;

ü La validation du plan d'action, des grands choix techniques et fonctionnels;

ü Le contrôle du plan d'avancement des travaux.

Le Groupe de Projet

Le groupe de projet :

ü Gère le déroulement du projet;

ü Elabore les rapports sur l'activité ;

ü Veille sur l'évolution du projet auprès du comité de pilotage;

ü Etablit des documents en destination du comité de pilotage;

ü Evalue les besoins et les solutions aux problèmes relevant de sa compétence.

Le Groupe des utilisateurs

Le groupe des utilisateurs a pour rôle :

ü D'être consulté directement sous forme d'interview;

ü De valider les procédures et les éléments de l'étude relevant de son domaine de compétence;

ü De réaliser les tests et la validation des maquettes;

ü d'être une ressource pour le projet.

4.8.3.1.2. Cas d'utilisation^44(*)

Les cas d'utilisation décrivent sous la forme d'actions et de réactions, le comportement du système étudié du point de vue des utilisateurs. Ils définissent les limites du système et ses relations avec son environnement^45(*).

Plusieurs types de relations peuvent intervenir dans des cas d'utilisation :

ü Relation d'inclusion (Include)

La relation d'inclusion sert à enrichir un cas d'utilisation par un autre cas d'utilisation. Cet enrichissement est réalisé par une inclusion impérative, il est donc systématique. L'inclusion sert à partager une fonctionnalité commune entre plusieurs cas d'utilisation. Elle peut également être employée pour structurer un cas d'utilisation en décrivant ses sous fonctions. Dans le diagramme des cas d'utilisation, cette relation est représentée par une flèche pointillée munie du stéréotype «include».

ü Relation d'extension (Extend)

Comme la relation d'inclusion, la relation d'extension enrichit un cas d'utilisation par un cas d'utilisation de sous fonction.

Cet enrichissement est analogue à celui de la relation d'inclusion mais il est optionnel. Comme pour l'inclusion, l'extension sert à structurer un cas d'utilisation ou à partager un cas d'utilisation de sous fonction. Dans le diagramme des cas d'utilisation, cette relation est représentée par une flèche pointillée munie du stéréotype «extend».

4.8.3.1.3. Identification des cas d'utilisation du système actuel

Dans le système existant, les Cas d'Utilisations (CU) sont :

1. CU1-Commander Produit

2. CU2- Livrer Produit

3. CU3-Faire Facture

4. CU4-Retirer CB

5. CUS- Retirer Chèque

6. CU6-Regler Espèce

7. CU7-Regler Chèque

8. CU8- Faire Virement



4.8.3.1.4. Représentation du diagramme des cas d'utilisation du système actuel

4.8.3.1.5. Formalisme adopté pour la description textuelle des cas d'utilisation

Scénarii nominal	N° du tableau concernant le CU
N°CU- i: «Nom du CU_1 »
Résumé du CU_1	N° de la Version	Date de réalisation
Acteurs du CU_1
DESCRIPTION DU SCENARIO NOMINAL <DEBUT> Corps de la description du scénario nominal (en soulignant éventuellement les alternatives et les exceptions). <FIN>
Scénario altérnatif	N° du tableau concernant le CU
N°CU- i: «Nom du CU_1 »
Résumé du CU_1	N° de la Version	Date de réalisation
Acteurs du CU_1
DESCRIPTION DES SCENARII ALTERNATIFS Corps de la description des différents scénarii alternatifs (en relevant éventuellement les alternatives et les exceptions).
Scénarii d'exceptions	N° du tableau concernant le CU
N°CU- 1 : «Nom du CU_1 »
Résumé du CU_1	N° de la Version	Date de réalisation
Acteurs du CU_1
DESCRIPTION DES SCENARII D'EXCEPTION Corps de la description des scénarii d'exception.

4.8.3.1.6. Description textuelle d'un cas d'utilisation

Un cas d'utilisation contient potentiellement plusieurs scénarios^45(*)

ü Un scénario correspond à l'exécution d'un ou plusieurs enchaînements joignant le début du cas d'utilisation à une fin normale ou non.

ü Les enchaînements parcourus lors d'un scénario sont sélectionnés par :

? Les messages envoyés par les acteurs

? L'état et les actions du système.

Un scénario est une instance d'un cas d'utilisation. Dans la description des cas d'utilisation on distinguera trois (3) types de scénario:

ü Le scénario nominal qui montre un déroulement normal;

ü Le scénario alternatif qui est une variante du scénario nominal;

ü Le scénario d'exception qui illustre un déroulement anormal du cas d'utilisation.

Cas d'utilisation 1 : CommanderProduit

Scénario nominal		Folio 1/3
CU1: CommanderProduit
Résumé: le client procède à la commande d'un produit auprès d'un Fournisseur		Version: 1.0		Date: 04/09/12
Acteurs: client et fournisseur
DESCRIPTION DU SCENARIO NOMINAL <DEBUT> 01 : le client contacte le fournisseur pour faire cas de ses besoins 02 : le fournisseur vérifie si le produit concerné existe dans sa boutique (E1) 03 : le fournisseur établi une facture proformat 04 : le fournisseur envoie la facture proformat au client 05 : le client analyse la facture pro format 06 : le client donne son avis (A1, E2) 07 : le client transmet son bon de commande au fournisseur <FIN>
Scénario alternatif		Folio 2/3
CUI: CommanderProduit
Résumé: le client procède à la commande d'un produit auprès d'un Fournisseur		Version: 1.0		Date: 04/09/12
Acteurs: client et fournisseur
DESCRIPTION DES SCENARIO ALTERNATIFS A1 : Montant facture proformat non satisfaisant A1.1 : Le client demande une révision du montant des produits A1.2 : Le scénario reprend au niveau du point 03 du scénario nominal
Scénario d'exception	Folio 3/3
CU1: CommanderProduit
Résumé: le client procède à la commande d'un produit auprès d'un Fournisseur	Version: 1.0		Date: 04/09/12
Acteurs: client et fournisseur
DESCRIPTION DU SCENARIO D'EXCEPTION E1 : Produit inexistant E1.1 : le fournisseur informe le client de l'inexistence du produit E1.2 : Fin de scénario. E2 : avis non favorable E2.1 : le client refuse la proposition du fournisseur E2.2 : Fin de scénario.

Cas d'utilisation 2 : LivrerProduit

Scénario nominal			Folio 1/3
CU2: LivrerProduit
Résumé: le fournisseur procède à la livraison du produit	Version: 1.0		Date: 04/09/12
Acteurs: client et fournisseur
DESCRIPTION DU SCENARIO NOMINAL <DEBUT> 01 : le fournisseur procède à la livraison du produit 02 : le client procède à la vérification du produit (A1, E1) 03 : le client valide et réceptionne le produit <FIN>
Scénario altérnatif				Folio 2/3
CU2: LivrerProduit
Résumé: le fournisseur procède à la livraison du produit		Version: 1.0		Date: 04/09/12
Acteurs: client et fournisseur
DESCRIPTION DES SCENARII ALTERNATIFS A1 : Nature des produits non satisfaisante A1.1 : le client renvoie le produit au fournisseur A1.2 : On repart au niveau du point 01 du scénario nominal
Scénario d'exception				Folio 3/3
CU2: LivrerProduit
Résumé: le fournisseur procède à la livraison du produit		Version: 1.0		Date: 04/09/12
Acteurs: client et fournisseur
DESCRIPTION DU SCENARIO D'EXCEPTION E1 : Produit de mauvaise qualité E1.1 : le client rejette le produit livré par le fournisseur E1.2 : Le scénario prend fin.

Cas d'utilisation 3 : FaireFacture

Scénario nominal		Folio 1/3
CU3: FaireFacture
Résumé : le fournisseur procède à l'édition de la facture conformément à la commande du client	Version: 1.0	Date: 04/09/12
Acteurs: Fournisseur et client
DESCRIPTION DU SCENARIO NOMINAL <DEBUT> 01 : le fournisseur réceptionne le bon de commande du client 02 : le fournisseur vérifie le bon de commande du client (A1) 03 : le fournisseur établi une facture conformément au bon de commande 04 : le fournisseur envoie la facture au client <FIN>
Scénario alternatif		Folio 2/3
CU3: FaireFacture
Résumé : le fournisseur procède à l'édition de la facture conformément à la commande du client	Version: 1.0	Date: 04/09/12
Acteurs: Fournisseur et client
DESCRIPTION DES SCENARII ALTERNATIFS A1 : bon de commande non conforme A1.1 : le fournisseur renvoie le bon de commande A1.2 : on repart au niveau du point 01 du scénario nominal

Cas d'utilisation 4 : RetirerCB

Scénario nominal		Folio 1/3
CU4: RetirerCB
Résumé : le client procède à un retrait de numéraire au conformément à la commande du client niveau du Guichet Automatique de Billet (GAB) par Carte Bancaire (CB)	Version: 1.0	Date: 05/09/12
Acteurs: Client et GAB
DESCRIPTION DU SCENARIO NOMINAL <DEBUT> 01 : le client introduit sa carte dans le lecteur de carte du GAB 02 : le lecteur de carte du GAB vérifie que la carte introduite est valide (Al) 03 : le GAB demande au client de saisir son code d'identification 04 : le client saisit son code d'identification 05 : le GAS compare le code d'identification avec celui qui est codé sur la puce de la carte (A2, E1) 06 : le GAS demande une autorisation au système d'autorisation Groupement Inter bancaire Monétique (GIM) 07 : le système d'autorisation du GIM donne son accord et indique le solde hebdomadaire 08 : le GAB demande au porteur de CB de saisir le montant désiré du retrait 09 : le client saisit le montant désiré du retrait 10 : le GAB contrôle le montant demandé par rapport au solde hebdomadaire (A3) 11 : le GAB demande au client s'il veut un ticket 12 : le client demande un ticket 13 : le GAB rend sa carte au client 14 : le client reprend sa carte 15 : le GAB délivre les billets et un ticket 16 : le client prend les billets et le ticket <FIN>
Scénario alternatif		Folio 2/3
CU4: RetirerCB
Résumé : le client procède à un retrait de numéraire au conformément à la commande du client niveau du Guichet Automatique de Billet (GAB) par Carte Bancaire (CB)	Version: 1.0	Date: 05/09/12
Acteurs: Client et GAB
DESCRIPTION DES SCENARII ALTERNATIFS A1 : carte non valide A1.1 : le GAB informe le client sur l'invalidité de la carte A1.2 : on repart au niveau du point 01 du scénario nominal A2 : code d'identification erroné pour la première ou deuxième fois A2.1 : le système informe le client que les informations saisies sont erronées A2.2 : le GAB enregistre l'échec sur la carte A2.3 : on repart au niveau du point 03 du scénario nominal A3 : montant demandé supérieur au solde hebdomadaire A3.1 : le système informe le client que le montant est élevé A3.1 : on repart au niveau du point 09 du scénario nominal Scénario
Scénario d'exception		Folio 2/3
CU4: RetirerCB
Résumé : le client procède à un retrait de numéraire au conformément à la commande du client niveau du Guichet Automatique de Billet (GAB) par Carte Bancaire (CB)	Version: 1.0	Date: 05/09/12
Acteurs: Client et GAB
DESCRIPTION DU SCENARIO D'EXCEPTION E1 : Utilisateur inconnue après trois tentatives E1.1 : le système informe l'utilisateur que la procédure de connexion a échoué E1.2: le GAB avale la carte El.3 : le système s'arrête

Cas d'utilisation 5 : RetirerChèque

Scénario nominal		Folio 1/3
CU5: RetirerChèque
Résumé : le client procède à un retrait de numéraire par chèque à la banque	Version: 1.0	Date: 05/09/12
Acteurs: Client et caissier
DESCRIPTION DU SCENARIO NOMINAL <DEBUT> 01 : le client contacte le caissier pour un retrait d'espèce 02 : le caissier réceptionne le chèque du client 03 : le caissier vérifie la validité des informations du chèque (A1) 04 : le caissier effectue une demande d'autorisation auprès de la banque du client 05 : la banque vérifie l'état du compte du client (E1) 06 : la banque informe le caissier sur l'état du compte 06 : le caissier débite le compte du client 07 : le caissier règle le client en espèce <FIN>
Scénario alternatif		Folio 2/3
CU5: RetirerChèque
Résumé : le client procède à un retrait de numéraire par chèque à la banque	Version: 1.0	Date: 05/09/12
Acteurs: Client et caissier
DESCRIPTION DES SCENARII ALTERNATIFS A1 : chèque non valide A1.1 : le caissier informe le fournisseur sur le motif de l'invalidité du chèque A1.2 : on repart au niveau du point 02 du scénario nominal
Scénario d'exception		Folio 2/3
CU5: RetirerChèque
Résumé : le client procède à un retrait de numéraire par chèque à la banque	Version: 1.0	Date: 05/09/12
Acteurs: Client et caissier
DESCRIPTION DU SCENARIO D'EXCEPTION E1 : le solde du compte est créditeur E1.1 : le caissier informe le client de l'état du solde E1.2 : Le scénario prend fin

Cas d'utilisation 6 : ReglerEspèce

Scénario nominal		Folio 1/3
CU6: ReglerEspèce
Résumé : le client procède au règlement de sa facture en Espèce	Version: 1.0	Date: 05/09/12
Acteurs: Client et Fournisseur
DESCRIPTION DU SCENARIO NOMINAL <DEBUT> 01 : le fournisseur en voie la facture au client 02 : le client vérifie la facture (A1) 03 : le client contacte le fournisseur pour régler sa facture en espèce 04 : le fournisseur informe le client de sa disponibilité 05 : le client envoie le montant correspondant en espèce au fournisseur 06 : le fournisseur vérifie le montant en espèce par rapport à la facture (A2) 07 : le fournisseur accuse la réception du montant <FIN>
Scénario alternatif		Folio 2/3
CU6: ReglerEspèce
Résumé : le client procède au règlement de sa facture en Espèce	Version: 1.0	Date: 05/09/12
Acteurs: Client et Fournisseur
DESCRIPTION DES SCENARII ALTERNATIFS A1 : Facture non conforme A1.1 : le client renvoie la facture A1.2 : on repart au niveau du point 01 du scénario nominal A2 : Montant insuffisant A2.1 : Le fournisseur informe le client et demande une révision du montant

Cas d'utilisation 7 : ReglerChèque

Scénario nominal		Folio 1/3
CU7: ReglerChèque
Résumé : le client procède au règlement de sa facture par chèque	Version: 1.0	Date: 05/09/12
Acteurs: Client et Fournisseur
DESCRIPTION DU SCENARIO NOMINAL <DEBUT> 01 : le fournisseur envoie la facture au client 02 : le client vérifie la facture (A1) 03 : le client contacte le fournisseur pour régler sa facture par chèque 04 : le fournisseur informe le client de sa disponibilité OS : le client édite un chèque correspondant au montant de la facture 06 : le client envoie le chèque au fournisseur 07 : le fournisseur vérifie le montant du chèque par rapport à la facture (A2) 08 : le fournisseur accuse la réception du montant <FIN>
Scénario alternatif		Folio 2/3
CU7: ReglerChèque
Résumé : le client procède au règlement de sa facture par chèque	Version: 1.0	Date: 05/09/12
Acteurs: Client et Fournisseur
DESCRIPTION DES SCENARII ALTERNATIFS A1 : Facture non conforme A1.1 : le client renvoie la facture A1.2 : on repart au niveau du point 01 du scénario nominal A2 : Montant du chèque insuffisant A2.1 : Le fournisseur informe le client et demande une révision du montant A2.2 : on repart au niveau du point 05 du scénario nominal

Cas d'utilisation 8 : FaireVirement

Scénario nominal		Folio 1/3
CU8: FaireVirement
Résumé : le caissier procède à un virement du compte du Client vers le compte du fournisseur	Version: 1.0	Date: 05/09/12
Acteurs: Caissier et Fournisseur
DESCRIPTION DU SCENARIO NOMINAL <DEBUT> 01 : le caissier réceptionne le chèque du fournisseur 02 : le caissier vérifie la validité des informations du chèque (A1) 03 : le caissier effectue une demande d'autorisation auprès de la banque du client 04 : la banque vérifie l'état du compte du client (E1) 05 : la banque informe le caissier 06 : le caissier débite le compte du client 07 : le caissier règle le fournisseur <FIN>
Scénario alternatif		Folio 2/3
CU8: FaireVirement
Résumé : le caissier procède à un virement du compte du Client vers le compte du fournisseur	Version: 1.0	Date: 05/09/12
Acteurs: Caissier et Fournisseur
DESCRIPTION DES SCENARII ALTERNATIFS A1: le chèque n'est pas conforme A1.I: le caissier retourne le chèque A2.1 : on repart au niveau du point 01 du scénario nominal
Scénario d'exception		Folio 3/3
CU8: FaireVirement
Résumé : le caissier procède à un virement du compte du Client vers le compte du fournisseur	Version: 1.0	Date: 05/09/12
Acteurs: Caissier et Fournisseur
DESCRIPTION DU SCENARIO D'EXCEPTION E1 : le solde du compte est insuffisant E1.1 : le caissier informe au fournisseur de l'état du solde E1.2 : Le scénario prend fin

4.8.4. Présentation des diagrammes de séquence

Suite aux descriptions textuelles, le scénario peut être représenté en utilisant un diagramme de séquences^46(*) qui permet :

ü de visualiser l'aspect temporel des interactions

ü de connaître le sens des interactions (acteur vers système ou contraire).

Ainsi, les diagrammes de séquences suivants illustrent chacun le scénario nominal des différents cas d'utilisation du système existant.

Diagramme de séquence 1 : CU CommanderProduit



Diagramme de séquence 2 : CU LivrerProduit



Diagramme de séquence 3 : CU LivrerProduit



Diagramme de séquence 4 : CU RetirerCB



Diagramme de séquence 5 : CU RetirerChèque



Diagramme de séquence 6 : CU ReglerEspèce



Diagramme de séquence 7 : CU ReglerChèque



Diagramme de séquence 8 : CU faireVirement



4.9. QUATRIEME PHASE : DIAGNOSTIC

4.9.1. Objectif du diagnostic

L'objectif de la phase de diagnostic est de porter un jugement sur le système existant. Elle nous permettra donc, grâce à l'analyse faite dans les phases précédentes de déceler les forces et faiblesses du système actuel.

4.9.2. Déroulement de la quatrième phase

Comme nous avons eu à faire un bilan des informations et des flux échangés (workflow) au cours des phases 2 (découverte des informations) et 3 (modélisation du workt1ow), il nous restera d'en faire une synthèse afin de pouvoir proposer des solutions.

4.9.3. Résultat de la quatrième phase

4.9.3.1. Forces

La Direction de l'informatique et de la monétique permet à la banque d'offrir à sa clientèle une diversité de produit et de service. Comme produit et service nous pouvons citer :

ü Les cartes bancaires : Elles permettent au client d'effectuer des retraits sur les GAB (Guichets Automatiques de Billet).

ü Les chéquiers ; Grâce au chèque, les clients peuvent faire des achats dans certains points de vente et des retraits d'espèce au niveau des guichets ou tout autre banque du Groupement Inter bancaire Monétique.

ü Les GAB existent dans différents endroits dans la capitale et dans quelques succursales à travers le pays, fonctionnant à tout moment. Au niveau du GAB, le client peut effectuer des retraits d'espèces, obtenir un reçu et consulter son solde.

ü Le e-banking : C'est un processus par lequel le client peut gérer ses transactions bancaires électroniquement à partir d'un poste connecté à Internet, sans qu'il ne soit obligé de se rendre dans une succursale physique. Grâce à ce service, le client peut consulter son solde, donner des ordres de virements, commander une carte bancaire ou un chéquier, bloquer une carte bancaire ou un chéquier, consulter le cours de change des principales devises, imprimer un Relevé D'identité Bancaire (RIB).

ü Le serveur vocal (Coritel) ; C'est un processus par lequel le client peut gérer à partir d'un poste téléphonique ses transactions bancaires. A partir de ce service le client de la banque peut consulter son solde, le cours de change des principales devises et ouvrir un compte.

Tous ces produits et services permettent au client de rentrer en possession de son argent dans les meilleurs délais, d'effectuer des achats et d'avoir l'état de son compte à tout moment. Cependant il existe des points de faiblesses. En effet avec l'évolution fulgurante des Nouvelles Technologies d'Information et de communication (NTIC) (de plus en plus de boutique en ligne), l'accroissement des utilisateurs d'institution bancaire, les désagréments liés à l'aspect manuel des chèques et l'indisponibilité des GAB à certains moment, le domaine de prestation devient peu performant.

4.9.3.2. Faiblesses

Le rôle que joue chaque produit et service est d'une grande importance pour la Banque, mais dans l'objectif d'être encore plus proche du client, nous pensons que cela n'est pas suffisant.

En effet certains problèmes dans le fonctionnement peuvent être relevés:

ü la non-conformité des chèques;

ü le retard dans le règlement des chèques;

ü le manque de confidentialité;

ü le non aboutissement d'un virement dû à l'insuffisance d'argent constaté dans le compte source;

ü l'indisponibilité des GAB dû à une panne :

§ mécanique: lecteur de cartes défectueux, clavier brisé et disque dur corrompu;

§ logiciel: système d'exploitation en faute et pilote de périphérique dépassé;

§ communication: réseau en panne de façon intermittente;

§ humaine: mauvaise saisie.

ü l'engorgement des guichets et les longues files d'attente due à la lenteur des traitements.

4.10. Conclusion de l'étude de l'existant

L'étude de l'existant nous a permis de comprendre le fonctionnement du système actuel. En effet elle nous a permis de souligner les points forts, les points faibles et les disfonctionnements du système dans sa globalité. Ces éléments constitueront non seulement la base des propositions du système futur pour pallier aux difficultés et insuffisances actuelles, mais aussi nous permettront d'avoir une vision plus approfondie de l'architecture du système à mettre en place.

Chapitre 5EME : ETUDE DES SCENARII

5.0. INTRODUCTION

Le présent chapitre nous amènera à établir les scénarii possibles pour la mise en place du futur système futur et les évaluations possibles en termes de coût matériel, logiciel et des besoins en ressources humaines.

Pour ce faire, une estimation des gains et des risques sera établie en vue de permettre aux utilisateurs du système futur d'opérer un choix sur la base de ces éléments comparatifs. Tout en rappelant les objectifs du futur système à mettre en place, nous allons, au cours de cette phase d'étude, proposer des solutions possibles, satisfaisant les objectifs et contraintes du domaine.

5.1. GENERALITES

5.1.1. OBJECTIFS DU SYSTEME FUTUR

Les objectifs poursuivis par ce système sont:

ü permettre aux commerçants d'accéder à la monétique à moindre coût;

ü apporter des services nouveaux à la clientèle des commerçants;

ü améliorer le service de la clientèle de la Banque

ü moderniser les moyens de paiement;

ü décongestionner les guichets bancaires et commerciaux;

ü utiliser les cartes comme support de consolidation de la clientèle;

ü y apporter une valeur ajoutée à la banque grâce au gain sur les transactions;

ü permettre le traitement automatique des transactions financières;

ü faciliter les transferts de fonds des clients et des commerçants;

ü alléger les charges financières par la diminution des GAB

5.2. DESCRIPTION DES SCENARII

5.2.1. Symboles utilisés pour la description de la structure réseau

Symbole	Signification
	Ordinateur de bureau
	Ordinateur portable
	Imprimante
	Switch
	Routeur
	Modem
	Onduleur
	Serveur bancaire
	Serveur de base de données
	Serveur proxy
	Serveur d'applications
	Liaison commutée
	Firewall
	Bâtiment

5.2.2. Description du premier scénario

Il sera question dans ce scénario de mettre en place une application web fonctionnant en environnement 3-tiers où les couches de présentation, traitement et d'accès aux données seront séparées et on devra donc respecter le modèle Vue Contrôleur (MVC). Les traitements, la gestion de la persistance (base de données) et des vues seront effectuées côté serveur, un serveur installé dans un cadre (local) sécurisé à la banque.

Les tâches effectuées par les différents acteurs à savoir le fournisseur ou le commerçant, le client et l'Administrateur du système seront possibles en fonction des rôles et des droits qui leurs seront attribués par ce dernier.

Les acteurs cités plus haut, à partir de leur poste de travail munit d'un client léger (navigateur web), pourront avoir accès en mode sécurisé à l'application hébergée sur le serveur (distant) et effectueront les tâches qui leur incombent.

Le fournisseur pourra effectuer toutes les opérations d'administration de gestion des produits et des transactions en interagissant directement avec l'application et éditer des états.

Le client, une fois sa commande établie sur le site du fournisseur, est redirigé de manière transparente et automatique sur la page de l'application où il pourra faire le paiement en toute sécurité.

Pour une raison de sécurité, la connexion entre les différentes banques se fera grâce à un VPN (Virtual Private Network) avec lPSEC (Internet Protocol Security) est un protocole (couche 1 du modèle OSI) permettant le transport de données sécurisées sur un réseau IP) comme protocole de cryptage.

Pour cette première solution (comme dans les autres solutions), nous préconisons entièrement des outils logiciels Open Source pour le serveur (le système d'exploitation, le SGBD, le serveur d'application, etc.) et aussi pour les clients (le client léger: navigateur

5.2.3. PRISE EN COMPTE DES CONTRAINTES

Le système à mettre en place doit tenir compte de la configuration du réseau intranet existant pour l'utilisation du matériel.

5.2.4. CALCUL DU COUT DE DEVELOPPEMENT PAR LA METHODE COCOMO

COCOMO (COnstructive COst Model) II est un modèle qui permet d'estimer le coût, l'effort et le temps nécessaire au développement d'un logiciel^47(*).

Le modèle original de COCOMO a été édité la première fois par le Dr. Barry Boehm en 1981 et a reflété les pratiques en matière de développement de logiciel de cette époque. Durant les 15 années suivantes les techniques de développement de logiciel ont changé.

COCOMO est le modèle le mieux documenté dont les paramètres sont adaptables à l'environnement. A l'origine, il a été construit sur une étude de 63 projets logiciels de 2000 à 100.000 lignes de code dans l'entreprise TRW Inc. (Société Américaine spécialisée dans l'Automobile et le Transport). Ce modèle existe en trois versions: simple, intermédiaire et détaillé.

Nous allons présenter les grandes lignes du modèle simple car c'est ce dernier qui est utilisé pour notre cas précis, afin d'introduire la modélisation comme outil d'estimation des coûts et d'illustrer ses avantages en matière de gestion de projet.

Le modèle COCOMO simple est destiné à donner des estimations approximatives de coûts. Il s'appuie uniquement sur la taille estimée du logiciel et sur le type de logiciel à développer.

Trois types de projets peuvent donc être distingués :

ü Projets de mode organique : concerne des petites équipes travaillant dans un environnement qui leur est familier et un domaine d'application bien connu. Ceci étant, le coût de communication est négligeable, bonne maîtrise du travail par chaque membre de l'équipe, rapidité d'exécution du travail.

ü Projets de mode semi-détaché : C'est le pont entre le mode organique et le mode embarqué décrit ci-dessous. Dans cette catégorie, l'équipe de projet peut être composée de programmeurs de divers niveaux d'expérience. Les membres de l'équipe ont une expérience limitée dans ce type de système. Ils peuvent être totalement inexpérimentés en ce qui concerne quelques-uns des aspects du système à développer, mais pas tous.

ü Projets de mode embarqué : dans cette catégorie, Le système à développer est une partie d'un système complexe et fortement connecté de matériels et de logiciels, de normes et de procédures opérationnelles. Sa principale caractéristique c'est que le système doit fonctionner sous des contraintes particulièrement fortes.

Les formules permettant de calculer le coût, ou plus exactement l'effort requis pour le développement du logiciel sont les suivantes :

ü Mode organique : HM^48(*) = 2.4 (KLSL^49(*)) ^1.05

ü Mode semi détaché : HM = 3 (KLSL) ^1.12

ü Mode embarqué : HM = 3.6 (KLSL) ^1.20

Le modèle COCOMO simple permet également d'estimer le temps de développement nécessaire au projet (TDEV). Le temps de développement est le temps requis pour terminer le projet, en supposant que les ressources de personnel requises sont disponibles. Les équations pour les différents modes de projets sont les suivantes:

ü Mode organique TDEV = 2.5 (HM)^0.38

ü Mode semi détaché TDEV = 2.5 (HM) ^0.35

ü Mode embarqué TDEV = 2.5 (HM) ^0.32

Le nombre de personnes requises pour réaliser le projet dans cet intervalle de temps est donc : N = HM/TDEV.

Le coût total de réalisation dans notre cas sera estimé à HM * ValeurHM.

Où ValeurHM représente le salaire moyen d'un informaticien en République Démocratique du Congo. Nous estimons ce salaire à mille dollars américains (1000$).

5.2.4.1. Présentation de l'architecture réseau



5.2.4.2. Liste des matériels requis

Les matériels suivants sont indispensables pour la mise en place de ce scénario :

ü trois (03) serveurs;

ü cinq (05) micro-ordinateurs;

ü quatre (04) imprimantes;

ü un (01) ondu1eur ;

ü un (01) switch ;

ü un (0 1) routeur ;

ü un (01) modem;

ü un (01) Firewall.

5.2.4.3. Liste des logiciels requis

Pour les systèmes d'exploitation :

ü Windows 7 pour les micro-ordinateurs ;

ü Ubuntu 12.04 Server 64 bits pour les serveurs.

ü Pour les logiciels de développement WinDev 15

ü Pour le logiciel antivirus Kaspersky 2011

5.2.4.4. L'évaluation des coûts

5.2.4.4.1. Coût du matériel et logiciel

Désignation	Caractéristiques	Qté	PU en $	Montant en $
Serveur	Serveur HP ProLiant ML310G2 Processeur Intel® Pentium® 4 à 3,20 GHz (3,20 GHz), Disque dur SCSI Ultra320 72 Go, enfichable à chaud, la 000 tr/min, format 1", 3 Go de RAM, en standard Lecteur/graveur DVD et RW HP 16X max demi-hauteur	03	-	Existants
Ordinateur (Desktop + Laptop)	ü Intel® Pentium® Dual-Core E5400 Processor (2.70 GHz) ü 2 GB RAM / 500 GB Hard Disk Drive ü SATA SuperMulti LightScribe DVD Writer Drive ü Integrated Intel® Graphics Media Accelerator X 4500 HD ü Windows 7 Professional ü Carte réseau: 100/1000 Mbps ð Wireless ü Carte graphique : 128Mb ü Ecran : LCD 21'', 24'' ü Clavier + souris optique USB ü Lecteur DVD#177;RW, 24x	05	-	Existant
Imprimante	HP LaserJet 1200	04	-	Existant
Onduleur	APC Back-UPS RS - 40KVA	01	-	Existant
Switch	O-Link DES-I 0080 - Switch 16 Ports, 10/1 00 Ethernet	01	200,21$	200,21$
Firewall	NetGear ProSafe VPN Firewall 8FVSI14	01	112.50$	112.50$
Antivirus	Kaspersky 2011	-	150$	150$
Système d'exploitation serveur	Ubuntu 12.04 Server 64 bits pour les serveurs	-	-	Gratuit
Système d'exploitation des micro-ordinateurs	Microsoft Windows 7	-	-	-
SGBDR	MySQL 5.0	-	-	-
Logiciel de développement	WinDev 15	-	-	-
Serveur d'application	Jakarta Tomcat 5.0.28 incluant le serveur web Apache	-	-	-
Total				462,71$

5.2.4.4.2. Calcul du coût de développement

Étant donné que le groupe de développement est assez restreint et est familier avec le cadre d'étude, nous avons choisi la première famille de projet décrite dans le modèle COCOMO, c'est-à-dire un projet en mode organique.

Pour déterminer le nombre de ligne de code source de l'application, nous estimons à dix-sept (17) le nombre de processus automatisables et à cinq cent (500) lignes la taille du code source de chacun de ces processus.

ValeurHM = 1000$en RDC.

Par application nous obtenons:

L'effort à consentir :

ü HM = 2.4 (500* 17/1000)^1.05

ü HM = 22.70

Le temps de développement :

ü Tdev = 2.5*(21.3)^0.38

ü Tdev = 7.99 mois

Nombre de personnes nécessaires pour accomplir le travail dans le délai :

ü HM/Tdev = 21.3/7.99

ü HM/Tdev = 2.66 Soit environ 3 personnes.

Coût financier de l'application (CF):

ü CF = HM*ValeurHM

ü CF = 21.3*1000$

ü CF = 21300$

Intitulé	valeur
Effort de développement (HM)	22.70
Temps de développement (Tdev)	7.99
Valeur de l'homme/mois (ValeurHM)	1000$
Nombre de développeurs	3
Coût de réalisation	22700$

5.2.4.4.3. Coût de formation des utilisateurs

Les utilisateurs de l'application (un administrateur, un agent du Service Système Production et Exploitation et un agent du Service Monétique) devront être formés.

Prix de l'horaire (USD)	Nombre d'heures par utilisateur	Nombre d'utilisateurs	Montant (USD)
25,75$	10	3	772,5$

5.2.4.4.4. Coût de mise place du VPN

Désignation	Prix (USD)
Installation et configuration des Firewall	574,46$
Mise en place du VPN	402,12$
Total :	976,58$

5.2.4.4.5. Coût total de mise en oeuvre

Désignation	Prix (USD)
Coût matériel et logiciel à acquérir	462,71$
Coût de développement	22.700$
Coût de formation	772,5$
Coût de mise en place du VPN	976,58$
Coût total	24911,79$

5.2.5. Description du deuxième scénario

Comme dans le scénario précédent, il sera également question ici de la mise en place d'une application web fonctionnant en environnement 3-tiers. Les procédures de connexion des différents acteurs à l'application restent inchangées toujours avec une sécurité dans l'échange des données. Du moins dans ce scénario, sera mis en place un CTMI (Centre de Traitement Monétique Interbancaire, centre où convergent toutes les banques partenaires).

Nous proposerons une connexion VPN (avec IPSEC comme protocole de cryptage) au CTMI afin de s'appuyer sur ce réseau pour se connecter aux autres banques. Cette architecture respecte les contraintes mais nécessite le développement d'un module supplémentaire pour interagir à partir de l'interface de l'application avec les serveurs du CTMI.

5.2.5.1. Présentation de l'architecture réseau



5.2.5.2. Liste du matériel requis

Désignation	Caractéristiques	Qté	PU en $	Montant en $
Serveur	Serveur HP ProLiant ML310G2 Processeur Intel® Pentium® 4 à 3,20 GHz (3,20 GHz), Disque dur SCSI Ultra320 72 Go, enfichable à chaud, la 000 tr/min, format 1", 3 Go de RAM, en standard Lecteur/graveur DVD et RW HP 16X max demi-hauteur	03	-	Existants
Ordinateur (Desktop + Laptop) Pentium IV.	ü Intel® Pentium® Dual-Core E5400 Processor (2.70 GHz) ü 2 GB RAM / 500 GB Hard Disk Drive ü SATA SuperMulti LightScribe DVD Writer Drive ü Integrated Intel® Graphics Media Accelerator X 4500 HD ü Windows 7 Professional ü Carte réseau: 100/1000 Mbps ð Wireless ü Carte graphique : 128Mb ü Ecran : LCD 21'', 24'' ü Clavier + souris optique USB ü Lecteur DVD#177;RW, 24x	05	-	Existant
Imprimante	HP LaserJet 1200	04	-	Existant
Onduleur	APC Back-UPS RS - 40KVA	01	-	Existant
Switch	O-Link DES-I 0080 - Switch 16 Ports, 10/1 00 Ethernet	01	200,21$	200,21$
Firewall	NetGear ProSafe VPN Firewall 8FVSI14	01	112.50$	112.50$
Antivirus	Kaspersky 2011	-	150$	150$
Système d'exploitation serveur	Ubuntu 12.04 Server 64 bits pour les serveurs	-	-	Gratuit
Système d'exploitation des micro-ordinateurs	Microsoft Windows 7	-	-	-
SGBDR	MySQL 5.0	01	Gratuit	Gratuit
Logiciel de développement	WinDev 15	01	-	-
	PHP 5	01	Gratuit	Gratuit
	Dreamweaver 8	01	Gratuit	Gratuit
	Fireworks 8	01	Gratuit	Gratuit
Serveur d'application	Jakarta Tomcat 5.0.28 incluant le serveur web Apache	01	-	-
Total				462,71$

5.2.5.3. Coût de développement

Dans ce deuxième scénario, nous avons les mêmes conditions de développement que celles décrites au scénario précédent.

Il s'agit donc du cas d'un projet en mode organique. Et pour déterminer le nombre de ligne de code source de l'application, nous estimons à dix-sept (17) le nombre de processus automatisables et à cinq cent (500) lignes la taille du code source de chacun de ces processus.

ValeurHM = 1000$ en RDC.

Le tableau ci-dessous contient les résultats obtenus par l'application de la méthode COCOMO.

Intitulé	valeur
Effort de développement (HM)	22.70
Temps de développement (Tdev)	7.99
Valeur de l'homme/mois (ValeurHM)	1000$
Nombre de développeurs	3
Coût de réalisation	22700$

5.2.5.4. Coût de formation des utilisateurs

Prix de l'horaire (USD)	Nombre d'heures par utilisateur	Nombre d'utilisateurs	Montant (USD)
25,75$	10	3	772,5$

Comme dans le scénario précédent, les utilisateurs de l'application (un administrateur, un agent du Service Système Production et Exploitation et un agent du Service Monétique) devront être formés.

5.2.5.5. Coût de mise place du VPN Banque-CTMI

Désignation	Prix (USD)
Installation et configuration des Firewall	574,46$
Mise en place du VPN	402,12$
Total :	976,58$

5.2.5.6. Coût total de mise en oeuvre

Désignation	Prix (USD)
Coût matériel et logiciel à acquérir	462,71$
Coût de développement	22.700$
Coût de formation	772,5$
Coût de mise en place du VPN	976,58$
Coût total	24911,79$

5.2.6. Description du troisième scénario

A la différence des deux scénarios vus précédemment, ce troisième scénario que nous allons présenter sera assez complexe dans son architecture réseau, par contre facile à mettre en oeuvre. Il est comparable à l'actuel système d'information comprenant les évolutions devant satisfaire les contraintes.

En effet l'architecture permettant le fonctionnement des GAB est comparable à ce scénario. Mais comparable aux scénarii cités précédemment, les échanges d'informations entre les acteurs se feront de manière sécurisée.

Nous avons mis en place une Ligne Spécialisée (LS) pour la connexion de manière sécurisée, la Banque à l'une des banques partenaires (BP) que nous avons reliée au CTMI par une connexion VSAT.

5.2.6.1. Présentation de l'architecture réseau

.



NB : concernant la liste du matériel requis, nous signalons que seule la gamme des matériels accompagnants l'antenne VSAT s'ajoute aux équipements énumérés dans les deux précédents scénarios. Liste des logiciels requis est la même que pour les deux précédents scénarios, par rapport à l'évaluation des coûts, le coût matériel bouge avec l'ajout du matériel VSAT ; le coût logiciel ainsi que celui de formation des utilisateurs restent les mêmes, ainsi, le coût total de mise en oeuvre sera un peu plus élevé que pour les précédents scénarios.

5.2.7. Etude comparative des scénarii

5.2.7.1. Premier scénario

Avantage :

ü échange sécurisé des informations entre la Banque, la banque du client et la banque du fournisseur à travers le VPN IPSEC ;

ü utilisation importante des outils logiciels Open Source;

ü gain en temps de traitement;

ü niveau de sécurité très élevée.

Inconvénients:

ü difficultés liées à la mise en oeuvre;

ü difficultés liées à l'exploitation;

ü nécessité de faire une bonne répartition des charges;

ü coût de réalisation élevé.

5.2.7.2. Deuxième scénario

Avantage :

ü échange sécurisé des informations entre la Banque et le CTMI à travers le VPN IPSEC;

ü utilisation importante des outils logiciels Open Source;

ü rapidité de traitement;

ü niveau de sécurité élevée;

ü répartition optimale des tâches métiers;

ü facilité d'exploitation.

Inconvénients:

ü mise en oeuvre difficile ;

ü coût de réalisation élevé;

ü mise en place de la politique de sécurité difficile.

5.2.7.3. Troisième scénario

Avantage:

ü Automatisation des opérations (sans intervention manuelle);

ü gain optimal en temps d'exécution des tâches métiers;

ü échange sécurisé des informations entre la Banque, la Banque partenaire intermédiaire par cryptage des données à travers la Liaison Spécialisée;

ü utilisation importante des outils logiciels Open Source ;

ü répartition optimale des tâches métiers;

ü facilité de maintenance;

ü coût de réalisation acceptable.

Inconvénients :

ü encombrement lié à l'augmentation du trafic;

ü difficulté de mettre en place une politique de sécurité.

5.2.7.4. Tableau comparatif des différents scenarii

Scénario

Critères

	Efficacité de traitement	Intégrité des données	Coûts	Sécurité	Mise en oeuvre
Scénario 1	Elevé	Très Elevé	Moyen	Très Elevé	Très difficile
Scénario 2	Elevé	Très Elevé	Moyen	Très Elevé	Difficile
Scénario 3	Elevé	Elevé	faible	Elevé	acceptable

5.2.7.5. Scénario retenu

Avec le scénario retenu on devra mettre en place un logiciel devant répondre à un certain nombre d'objectifs entre autre :

ü Permettre le client d'effectuer le paiement de sa commande d'une manière sécurisée;

ü Faciliter le commerçant de toucher son argent dans les meilleurs délais lorsqu'il effectue une vente;

ü renforcer la confidentialité et la sécurité des données;

ü permettre aux utilisateurs l'établissement d'états statistiques;

ü améliorer la rapidité de traitement des données bancaires;

ü assurer l'intégrité des données;

Le choix du comité de pilotage s'est porté sur le troisième scénario qui sera mis en oeuvre. Ce choix se justifie par:

ü la prise en compte de tous les objectifs et les contraintes exprimés par les utilisateurs;

ü le coût de développement plus abordable;

ü fiabilité et rapidité dans les traitements;

ü facilité de sa mise en oeuvre.

5.2.7.6. Le scénario de mise en oeuvre

La mise en oeuvre de la solution proposée se fera comme suit:

ü le développement de l'application;

ü l'installation de l'application

ü la formation des utilisateurs;

ü le test du nouveau produit;

ü la mise en exploitation de l'application,

5.2.7.7. Conclusion

Il a été question dans ce chapitre de présenter les solutions envisagées pour améliorer les insuffisances du système en place tenant compte des contraintes.

Le coût, avantages et inconvénients des différentes solutions que nous considérons comme éléments de décision présentés nous ont permis de choisir le troisième scénario pour la mise en oeuvre. Cette solution choisie fera l'objet de la rédaction du cahier des charges utilisateur à la prochaine étape de notre analyse.

Chapitre 6ème : ETUDE DETAILLEE DU SYSTEME FUTUR

6.0. INTRODUCTION

Dans le chapitre précédent ayant trait à l'étude de l'existant, le diagnostic a montré quelques insuffisances et dysfonctionnements du système en place, mais aussi des forces. Nous abordons dans la logique de la méthode RAD la cinquième phase, reconfiguration du système d'information et la sixième phase, modélisation du futur système d'information.

L'étude détaillée du système futur renferme des solutions conceptuelles, organisationnelles et techniques pouvant satisfaire sans précédent aux objectifs et contraintes du domaine.

Dans la cinquième phase par où nous allons d'ailleurs commencer, il sera question de modifier le système actuel pour améliorer son fonctionnement, puis viendra la sixième phase, la modélisation du système futur.

6.1. GENERALITES

6.1.1. Objectif de l'étude de la reconfiguration et modélisation du système

L'objectif de cette étude est de permettre au groupe de projet de :

ü centraliser les informations par la mise en place d'une base de données;

ü proposer une reconfiguration du système d'information;

ü modéliser le scénario de mise en oeuvre que nous avons retenu.

6.1.2. La démarche suivie

Dans cette étude nous réaliserons la cinquième phase (reconfiguration du système d'information) et la sixième phase (modélisation du système d'information) de la méthode RAD.

Nous ferons recours aux diagrammes UML suivants pour illustrer les deux phases :

ü le diagramme de flux;

ü le diagramme des cas d'utilisations;

ü le diagramme de séquences;

ü le diagramme de classe;

6.2. Cinquième PHASE : RECONFIGURATION DU SYSTEME

6.2.1. Objectif de la cinquième phase

Le but poursuivi dans cette phase de reconfiguration du système est d'utiliser le diagnostic produit à la phase précédente (Diagnostic) pour arrêter de nouveaux principes qui portent sur la gestion des informations et sur la reconfiguration des processus. Principes qui serviront de références pour les choix de modélisation que nous ferons apparaître dans la phase suivante.

6.2.2. Déroulement de la cinquième phase

La reconfiguration du système d'information a été le travail du groupe de projet. Sa réelle concrétisation a connu le concours des utilisateurs qui vérifiaient à chaque fois la concordance entre leurs besoins et la réalisation du groupe de projet.

6.2.3. Contenu et résultat de la cinquième phase

Du fait que la phase du diagnostic de l'existant nous a permis de détecter les problèmes de l'existant, nous envisagerons les propositions pour les nouvelles orientations du futur système à mettre en place.

La reconfiguration du système permettra de :

ü améliorer les échanges d'informations;

ü régénérer les processus ;

ü renforcer la confidentialité des données ;

ü tenir compte des contraintes des utilisateurs.

6.2.3.1. Amélioration des échanges d'informations :

ü les utilisateurs directs du système sont l'administrateur et le fournisseur ;

ü les opérations vont concerner les achats et les ventes en ligne;

ü un fournisseur pourra effectuer des opérations de vente ;

ü les différents acteurs (clients, fournisseurs et banque) communiquent entre eux par des courriels ;

ü chaque utilisateur possède un compte système à partir duquel il opère;

ü les comptes systèmes sont sécurisés, de ce faite une authentification est demandée lors de la connexion ;

ü le client sera détenteur d'un nouveau moyen de paiement qui est la carte bancaire, en lieu et place du chéquier;

ü le client pourra remplir et régler son panier d'achat en ligne;

ü pour une question de sécurité, le client doit obligatoirement s'identifier pour effectuer un paiement;

ü le client pourra faire opposition de sa carte bancaire auprès de sa banque.

6.2.3.2. Introduction de nouveaux processus

ü L'application sera protégée en accès.

Pour cela un processus « Authentification » s'avère nécessaire.

ü Un administrateur sera défini. Il aura pour tâche la maintenance de l'application et l'administration de la base de données. Ceci entraîne la création de nouveaux processus « CréerCompteAdmin »,

« ModifierCompteAdmin », « SupCompteAdmin », « Validation ».

ü Le fournisseur pourra remplir un formulaire d'inscription en ligne pour obtenir un compte fournisseur qui sera validé et créé par l'administrateur. Ce qui engendre la création du processus « CréerCompteFournis ».

ü Le fournisseur pourra également assurer la maintenance de son compte par la modification ou la suppression de ce dernier. D'où l'introduction des processus « ModifCompteFournis », « SupCompteFournis ».

ü De plus, le fournisseur aura une tache d'administration de second niveau où il pourra créer, modifier ou supprimer des produits. Ceci donnera naissance aux processus « CréerProduit », « ModifierProduit » et « SupProduit ».

ü Le client d'un fournisseur enregistré pourra effectuer un paiement sur l'application. D'où la nécessité du processus « PayerCommande »

ü Lors d'une opération de paiement le client doit obligatoirement s'identifier sur l'interface de l'application. Ce qui explique le processus « Identification ».

ü Tous les fournisseurs pourront suivre l'état des transactions bancaires,

ü consulter et/ou éditer les différentes informations sur les opérations les concernant. D'où les

ü processus « SuivreTransaction », « Consulterlnfos » et « EditerEtat ».

6.2.3.3. Prise en compte des contraintes

ü Le système à mettre en place doit tenir compte de la configuration du réseau intranet

ü Existant pour l'utilisation du matériel.

Les utilisateurs distants, s'ils sont habilités, doivent pouvoir interagir avec le système sans l'intermédiaire d'une application autre que les navigateurs courants.

6.3. Sixième PHASE : MODELISATION DU SYSTEME FUTUR

6.3.1. Objectif de la sixième phase

Le but de cette phase est de modéliser les différentes facettes du système d'information, en tenant compte des principes et des règles que nous avons arrêtés à la phase précédente (reconfiguration du système d'information).

6.3.2. Déroulement de la sixième phase

A partir des ébauches des diagrammes réalisés à la deuxième phase (découverte des informations), à la troisième phase (modélisation du workflow) et des résultats de la cinquième phase (reconfiguration du système d'information), nous allons établir les modèles du futur système d'information.

Les diagrammes présentés aux utilisateurs et aux décideurs ont été approuvés.

6.3.3. Contenu et résultat de la sixième phase

6.3.3.1. Représentation du diagramme de flux

Pour des raisons de lisibilité, nous avons remplacé sur le diagramme les messages par des numéros.

a. Lance la commande

b. Transmet le contexte

c. Rempli le formulaire de paiement

d. Demande une autorisation

e. Répond à la demande d'autorisation

f. Confirme la transaction

g. Fait le virement



6.3.3.2. Diagramme de cas d'utilisation du nouveau système

Pour rappel, le diagramme de cas d'utilisation montre l'ensemble des fonctionnalités du domaine d'étude. Chaque fonctionnalité est traduite par un processus qui sera modélisé au moyen d'un diagramme de séquence et/ou d'un diagramme d'activité.

6.3.3.2.1. Les cas d'utilisation (CU)

Ceci est la liste des cas d'utilisation du système futur :

1. CU1-Authentification;

2. CU2-CréerCompteAdmin ;

3. CU3-CréerCompteFournis ;

4. CU4-Validation;

5. CU5-ModifCompteAdmin ;

6. CU6-ModifCompteFournis;

7. CU7-SupCompteAdmin ;

8. CU8-SupCompteFournis ;

9. CU9-CréerProduit;

10. CU10-ModifierProduit;

11. CU11-SupProduit;

12. CU12-ConsulterInfo ;

13. CU13-EditerEtat ;

14. CU14-SuivreTransaction ;

15. CU15-Identification ;

16. CU16-PayerCommande,

6.3.3.2.2. Représentation du diagramme de Cas d'Utilisation



6.3.3.3. Description des acteurs

Les acteurs qui utiliseront le système nouveau d'information sont les suivants:

ü L'administrateur : il est chargé de l'administration et de la maintenance de l'application;

ü Le fournisseur : il a un rôle d'administration secondaire; il peut en outre créer, modifier ou supprimer des produits de la base de données. Le système lui offre également le pouvoir d'effectuer manuellement une opération de vente;

ü Le client : lorsqu'il est habilité par le fournisseur, le client a la possibilité d'effectuer un paiement sécurisé sur le système tout en s'identifiant par les informations de sa carte bancaire. Il peut également consulter l'interface, ainsi que les offres que le système lui propose.

6.3.3.4. Les besoins des cas d'utilisation

Ces besoins concernent les cas d'utilisations automatisables :

ü Interface Homme Machine

Le dispositif d'entrée sortie comprend :

§ un clavier alpha numérique et une souris;

§ un écran pour l'affichage des messages;

§ une imprimante.

ü Pré condition générale

On considère que tous les éléments du système fonctionnent normalement et que la connexion au réseau local est permanente.

6.3.3.5. Description textuelle des cas d 'utilisation

Nous rappelons qu'un scénario est une instance d'un cas d'utilisation. Comme vu précédemment, nous verrons les trois (3) types de scénario pour décrire chaque cas d'utilisation :

ü Le scénario nominal qui montre un déroulement normal;

ü Le scénario alternatif qui est une variante du scénario nominal;

ü Le scénario d'exception qui illustre un déroulement anormal du cas d'utilisation.

Cas d'utilisation 1 : Authentification

Scénario nominal		Folio 1/2
CU1: Authentification
Résumé: permet à l'acteur de s'authentifier une fois connecté au système	Version: 1.0	Date: 01/10/12
Acteurs: fournisseur et administrateur
DESCRIPTION DU SCENARIO NOMINAL <DEBUT> 01 : l'acteur demande à se connecter 02 : le système demande de s'identifier par un nom d'utilisateur et un mot de passe 03 : l'acteur saisi les informations requises 04 : le système vérifie Jes informations fournies par l'acteur (Al) OS : le système étabJit la connexion correspondant au profiJ <FIN>
Scénario Alternatif		Folio 2/2
CU1: Authentification
Résumé: permet à l'acteur de s'authentifier une fois connecté au système	Version: 1.0	Date: 01/10/12
Acteurs: fournisseur et administrateur
DESCRIPTION DES SCENARII ALTERNATIFS A1 : Jes informations saisies sont incorrectes A1.1 : Le système informe l'acteur que les données saisies sont erronées A1.2 : Le scénario reprend au niveau du point 02 du scénario nominal

Cas d'utilisation 2 : CreerCompteAdmin

Scénario nominal		Folio 1/2
CU2: CreerCompteAdmin
Résumé: permet à l'administrateur de créer un compte d'administration de l'application pour pouvoir effectuer des opérations	Version: 1.0		Date: 01/10/12
Acteurs : Administrateur
DESCRIPTION DU SCENARIO NOMINAL <DEBUT> 01 : inclusion du cas d'utilisation Authentification 02 : le système affiche la page d'accueil 03 : l'administrateur choisit l'option créer compte 04 : le système affiche le menu de création de compte 05 : l'administrateur choisit le type de compte à créer 06 : le système affiche la fenêtre de création de compte 07 : l'administrateur rempli les champs et valide 08 : le système vérifie la validité des informations (A1) 09 : le système crée le compte 10 : le système informe l'administrateur <FIN>
Scénario alternatif		Folio 2/2
CU2: CreerCompteAdmin
Résumé: permet à l'administrateur de créer un compte d'administration de l'application pour pouvoir effectuer des opérations	Version: 1.0		Date: 01/10/12
Acteurs : Administrateur
DESCRIPTION DES SCENARII ALTERNATIFS A1 : les informations saisies sont incorrectes A1.1 : Le système informe l'administrateur que les informations saisies sont erronées A1.2 : Le scénario reprend au niveau du point 06 du scénario nominal

Cas d'utilisation 3 : CreerCompteFournis

Scénario nominal		Folio 1/2
CU3: CreerCompteFournis
Résumé: permet au fournisseur de remplir un formulaire de création d'un compte	Version: 1.0		Date: 01/10/12
Acteurs : fournisseur et administrateur
DESCRIPTION DU SCENARIO NOMINAL <DEBUT> 01 : le fournisseur accède au système 02 : le système affiche la page d'accueil 03 : le fournisseur choisit de créer un compte 04 : le système affiche le formulaire de création de nouveau compte fournisseur O5 : le fournisseur rempli le formulaire et valide 06 : le système vérifie et enregistre le formulaire (A1) 07 : le système informe le fournisseur 08 : le système envoie une alerte de création de compte fournisseur en attente à l'administrateur <FIN>
Scénario alternatif		Folio 1/2
CU3: CreerCompteFournis
Résumé: permet au fournisseur de remplir un formulaire de création d'un compte	Version: 1.0		Date: 01/10/12
Acteurs : fournisseur et administrateur
DESCRIPTION DES SCENARII ALTERNATIFS A1 : les informations saisies sont incorrectes A1.1 : Le système informe le fournisseur gue les informations saisies sont erronées A1.2 : Le scénario reprend au niveau du point 04 du scénario nominal

Cas d'utilisation 4 : Validation

Scénario nominal		Folio 1/2
CU4 : validation
Résumé: permet à l'administrateur de valider la création de compte fournisseur à partir du formulaire que ce dernier rempli	Version: 1.0		Date: 01/10/12
Acteurs : fournisseur et administrateur
DESCRIPTION DU SCENARIO NOMINAL <DEBUT> 01 : inclusion du cas d'utilisation « Authentification» 02 : le système affiche la page d'accueil 03 : affichage de l'alerte de création de compte fournisseur en attente 04 : l'administrateur choisi l'option « créer compte fournisseur» 05 : le système affiche la liste des comptes en attente de création 06 : l'administrateur sélectionne le compte à créer 07 : le système affiche les informations sur le compte 08 : l'administrateur vérifie les informations de création de compte (El) 09 : l'administrateur valide les informations 10 : le système crée le compte 11 : un mail de confirmation de création de compte est envoyé au fournisseur <FIN>
Scénario alternatif		Folio 1/2
CU4 : validation
Résumé: permet à l'administrateur de valider la création de compte fournisseur à partir du formulaire que ce dernier rempli	Version: 1.0		Date: 01/10/12
Acteurs : fournisseur et administrateur
DESCRIPTION DES SCENARII D'EXCEPTION E1 : les informations saisies sur le formulaire ne sont pas valides E1.1 : l'administrateur contacte le fournisseur par mail pour une nouvelle inscription E1.2 : le scénario prend fin

Cas d'utilisation 5 : ModifCompteAdmin

Scénario nominal			Folio 1/2
CU5 : ModifCompteAdmin
Résumé: permet à l'administrateur de modifier des comptes	Version: 1.0			Date: 01/10/12
Acteurs : Administrateur
DESCRIPTION DU SCENARIO NOMINAL <DEBUT> 01 : inclusion du cas d'utilisation « Authentification » 02 : le système affiche la page d'accueil correspondant au profil 03 : l'administrateur accède à la rubrique « modifier compte » 04 : le système affiche la liste des comptes OS : l'administrateur choisit le compte à modifier 06 : le système affiche les informations sur le compte ainsi que les champs modifiables 07 : l'administrateur modifie les champs de son choix 08 : l'administrateur valide la modification 09 : le système vérifie la validité des informations (A1) 10 : le système modifie le compte 11 : le système informe l'administrateur <FIN>
Scénario alternatif			Folio 2/2
CU5 : ModifCompteAdmin
Résumé : permet à l'administrateur de modifier des comptes		Version: 1.0		Date: 01/10/12
Acteurs : Administrateur
DESCRIPTION DES SCENARll ALTERNATIFS A1 : les informations saisies sont incorrectes A1.1 : Le système informe l'administrateur que les données saisies sont erronées A1.2 : Le scénario reprend au niveau du point 06 du scénario nominal

Cas d'utilisation 6 : ModifCompteFournis

Scénario nominal		Folio 1/2
CU6 : ModifCompteFournis
Résumé : permet au fournisseur de modifier son compte	Version: 1.0		Date: 01/10/12
Acteurs : fournisseur
DESCRIPTION DU SCENARIO NOMINAL <DEBUT> 01 : inclusion du cas d'utilisation « Authentification» 02 : le système affiche la page d'accueil de son compte 03 : le fournisseur accède à la rubrique « modifier compte » 04 : le système affiche les informations sur son compte ainsi que les champs modifiables 05 : le fournisseur modifie les champs de son choix 06 : le fournisseur valide la modification 07 : le système vérifie la validité des informations (A1) 08 : le système modifie le compte <FIN>
Scénario alternatif		Folio 2/2
CU6 : ModifCompteFournis
Résumé : permet au fournisseur de modifier son compte	Version: 1.0		Date: 01/10/12
Acteurs : fournisseur
DESCRIPTION DES SCENARII ALTERNATIFS A1 : les informations saisies sont incorrectes A1.1 : Le système informe le fournisseur que les données saisies sont erronées A1.2 : Le scénario reprend au niveau du point 04 du scénario nominal

Cas d'utilisation 7 : SupCompteAdmin

Scénario nominal		Folio 1/2
CU7 : SupCompteAdmin
Résumé : permet à l'administrateur de supprimer un compte système	Version: 1.0		Date: 01/10/12
Acteurs : administrateur
DESCRIPTION DU SCENARIO NOMINAL <DEBUT> 01 : inclusion du cas d'utilisation « Authentification » 02 : le système affiche la page d'administration 03 : l'administrateur accède à la rubrique « supprimer compte» 04 : le système affiche la liste des comptes disponibles 05 : l'administrateur sélectionne le compte à supprimer et valide 06 : le système demande une identification 07 : l'administrateur fourni les informations 08 : le système vérifie les informations fournies (A1) 09 : le système demande confirmation 10 : l'administrateur confirme la suppression 11 : le système supprime le compte 12 : le système informe l'administrateur <FIN>
Scénario alternatif		Folio 2/2
CU7 : SupCompteAdmin
Résumé : permet à l'administrateur de supprimer un compte système	Version: 1.0		Date: 01/10/12
Acteurs : administrateur
DESCRIPTION DES SCENARII ALTERNATIFS A1 : les informations saisies sont incorrectes A1.1 : Le système informe l'administrateur que les données saisies sont erronées A1.2: Le scénario reprend au niveau du point 04 du scénario nominal

Cas d'utilisation 8 : SupCompteFournis

Scénario nominal		Folio 1/2
CU8: SupCompteFournis
Résumé : permet au fournisseur de supprimer son compte	Version: 1.0		Date: 01/10/12
Acteurs : Fournisseur
DESCRIPTION DU SCENARIO NOMINAL <DEBUT> 01 : inclusion du cas d'utilisation « Authentification» 02 : le système affiche la page d'accueil correspondant au profil 03 : le fournisseur accède à la rubrique « supprimer compte» 04 : le système demande une identification OS : le fournisseur fourni les informations d'identification 06 : le système vérifie les informations (A1) 07: le système demande une confirmation de suppression 08 : le fournisseur confirme la suppression 09 : le système supprime le compte 10 : le système informe le fournisseur <FIN>
Scénario alternatif		Folio 2/2
CU8: SupCompteFournis
Résumé : permet au fournisseur de supprimer son compte	Version: 1.0		Date: 01/10/12
Acteurs : Fournisseur
DESCRIPTION DES SCENARII ALTERNATIFS A1 : les informations saisies sont incorrectes A1.1 : le système informe le fournisseur A1.2 : le scénario reprend au niveau du point 04 du scénario nominal

Cas d'utilisation 9 : CréerProduit

Scénario nominal		Folio 1/2
CU9: CréerProduit
Résumé : permet à l'administrateur du site marchand (fournisseur) d'ajouter un produit en back office	Version: 1.0		Date: 01/10/12
Acteurs : Fournisseur
DESCRIPTION DU SCENARIO NOMINAL <DEBUT> 01 : inclusion du cas d'utilisation « Authentification» 02 : le système affiche la page d'accueil correspondant au profil 03 : le fournisseur accède à la rubrique « créer produit » 04 : le système affiche le formulaire de création de produit 05 : le fournisseur remplie le formulaire et valide 06 : le système vérifie la validité des informations (A1) 07 : le système crée le produit <FIN>
Scénario alternatif		Folio 1/2
CU9: CréerProduit
Résumé : permet à l'administrateur du site marchand (fournisseur) d'ajouter un produit en back office	Version: 1.0		Date: 01/10/12
Acteurs : Fournisseur
DESCRIPTION DES SCENARII ALTERNATIFS A1 : les informations saisies sont incorrectes A1.1 : Le système informe l'acteur que les données saisies sont erronées A1.2 : Le scénario reprend au niveau du point 04 du scénario nominal

Cas d'utilisation 10 : ModifierProduit

Scénario nominal		Folio 1/2
CU10: ModifierProduit
Résumé : permet à l'administrateur du site marchand (fournisseur) de modifier un produit en back office	Version: 1.0		Date: 01/10/12
Acteurs : Fournisseur
DESCRIPTION DU SCENARIO NOMINAL <DEBUT> 01 : inclusion du cas d'utilisation « Authentification» 02 : le système affiche la page d'accueil correspondant au profil 03 : le fournisseur accède à la rubrique « modifier produit» 04 : le système affiche la liste des produits en vente 05 : le fournisseur sélectionne le produit à modifier et valide 06 : le système affiche le formulaire de modification de produit 07 : le fournisseur saisie les informations requises 08 : le système vérifie la validité des informations (A1) 09 : le système modifie le produit <FIN>
Scénario alternatif		Folio 2/2
CU10: ModifierProduit
Résumé : permet à l'administrateur du site marchand (fournisseur) de modifier un produit en back office	Version: 1.0		Date: 01/10/12
Acteurs : Fournisseur
DESCRIPTION DES SCENARII ALTERNATIFS A1 : les informations saisies sont incorrectes A1.1 : Le système informe le fournisseur que les données saisies sont erronées A1.2 : Le scénario reprend au niveau du point 04 du scénario nominal

Cas d'utilisation 11 : SupProduit

Scénario nominal		Folio 1/1
CU11 : SupProduit
Résumé : permet à l'administrateur du site marchand (fournisseur) de supprimer un produit en back office	Version: 1.0		Date: 01/10/12
Acteurs : Fournisseur
DESCRIPTION DU SCENARIO NOMINAL <DEBUT> 01 : inclusion du cas d'utilisation « Authentification» 02 : le système affiche la page d'administration 03 : le fournisseur accède à la rubrique « supprimer produit» 04 : le système affiche la liste des produits en vente 05 : le fournisseur sélectionne le produit à supprimer et valide 06 : le système demande confirmation 07 : le fournisseur confirme la suppression 08 : le système supprime le produit <FIN>

Cas d'utilisation 12 : ConsulterInfo

Scénario nominal		Folio 1/1
CU12 : ConsulterInfo
Résumé : permet au fournisseur de consulter les informations sur les produits	Version: 1.0		Date: 01/10/12
Acteurs : Fournisseur
DESCRIPTION DU SCENARIO NOMINAL <DEBUT> 01 : inclusion du cas d'utilisation « Authentification» 02 : le système affiche la page d'accueil correspondant au profil 03 : le fournisseur accède à la rubrique de « consultation» 04 : le système affiche le menu de consultation 05 : le fournisseur fait son choix et valide 06 : le système recherche les informations 07 : le système lui affiche les informations demandées <FIN>

Cas d'utilisation 13 : EditerEtats

Scénario nominal		Folio 1/1
CU13: EditerEtats
Résumé : permet au fournisseur d'imprimer des états sur les produits	Version: 1.0		Date: 01/10/12
Acteurs : Fournisseur
DESCRIPTION DU SCENARIO NOMINAL <DEBUT> 01 : inclusion du cas d'utilisation ConsulterInfo 02 : le fournisseur demande l'impression d'un état 03 : le système imprime les états <FIN>

Cas d'utilisation 14 : SuivreTransaction

Scénario nominal		Folio 1/1
CU14: SuivreTransaction
Résumé : permet au fournisseur de visualiser l'état des transactions informations sur les produits	Version: 1.0		Date: 01/10/12
Acteurs : Fournisseur
DESCRlPTION DU SCENARIO NOMINAL <DEBUT> 01 : inclusion du cas d'utilisation Authentification 02 : le système affiche la page d'accueil correspondant au profil 03 : le fournisseur accède à la rubrique « suivre transactions » 04 : le système affiche un menu 05 : le fournisseur fait son choix 06 : le système recherche les informations 07 : le système lui affiche les informations demandées <FIN>

Cas d'utilisation 15 : Identification

Scénario nominal		Folio 1/3
CU15 : Identification
Résumé : permet au client de s'authentifier lors d'une opération de paiement	Version: 1.0		Date: 01/10/12
Acteurs : client et banque
DESCRIPTION DU SCENARIO NOMINAL <DEBUT> 01 : le système affiche l'interface d'identification 02 : le client remplie les champs de la fenêtre et valide 03 : le système vérifie les informations fournies par le client (A1, E1) 04: le système demande une autorisation auprès du Centre de Traitement Monétique Interbancaire (CTMI) 05: les serveurs bancaires du CTMI vérifient les informations (validité de la carte, solvabilité du compte) (E2, E3) 06 : les serveurs bancaires du CTMI envoient confirmation au système 07 : le système informe le client du succès d'identification <FIN>
Scénario alternatif		Folio 2/3
CU15 : Identification
Résumé : permet au client de s'authentifier lors d'une opération de paiement	Version: 1.0		Date: 01/10/12
Acteurs : client et banque
DESCRIPTION DES SCENARII ALTERNATIFS A1 : les informations saisies sont incorrectes A1.1 : Le système informe le fournisseur que les données saisies sont erronées A1.2 : Le scénario reprend au niveau du point 01 du scénario nominal
Scénario d'exception		Folio 3/3
CU15 : Identification
Résumé : permet au client de s'authentifier lors d'une opération de paiement	Version: 1.0		Date: 01/10/12
Acteurs : client et banque
DESCRIPTION DU SCENARIO D'EXCEPTION E1 : le client a entré des informations incorrectes plus de 05 (cinq) fois E1.1 : le système s'arrête E2 : la carte n'est pas valide E2.1 : Le Centre de Traitement Monétique Interbancaire (CTMI) informe le système E2.2 : Le système informe le client E2.3 : le système s'arrête E3 : le compte n'est pas solvable E3.1 : Le CTMI informe le système E3.2 : Le système informe le client E3.3 : le système s'arrête.

Cas d'utilisation 16 : PayerCommande

Scénario d'exception		Folio 1/1
CU16: PayerCommande
Résumé : permet au client de procéder au paiement par carte bancaire	Version: 1.0		Date: 01/10/12
Acteurs : client, fournisseur et banque
DESCRIPTION DU SCENARIO NOMINAL <DEBUT> 01 : le client choisit l'option « payer commande » sur le site du fournisseur 02 : le site du fournisseur envoie les références de la transaction au système (Code fournisseur, montant et devise de la transaction) 03 : le client est routé sur le système en mode sécurisée (cryptage SSL 256bits) 04 : inclusion du cas d'utilisation « Identification» 05 : le système demande une confirmation d'achat au client 06 : le client confirme son achat 07 : Le système envoie les références de la transaction au CTMI en mode sécurisé 08 : les serveurs bancaires du CTMI effectuent la transaction 09 : les serveurs bancaires du CTMI envoient confirmation au système la : le système informe le client du succès de l'achat par l'envoie un ticket électronique en mode sécurisé 11 : le système envoie une alerte de vente réussie au fournisseur en mode sécurisé par mail <FIN>

6.3.3.6. Diagramme de séquence

Le diagramme de séquence est une variante du diagramme de collaboration. Il permet de mieux visualiser la séquence des messages en mettant l'accent sur les aspects temporels; l'axe vertical représente le temps, l'axe horizontal représente les objets qui collaborent. Une ligne verticale en pointillé est attachée à chaque objet et représente sa ligne de vie. L'utilisation du diagramme de séquence dans l'analyse a pour but de faciliter la représentation d'un processus en se basant sur le workf1ow et les échanges entre acteurs. Nous pourrons donc l'utiliser pour représenter un processus existant, sans entrer dans le détail des activités, soit pour modéliser des variantes de processus à partir d'un processus de référence.

6.3.3.6.1. Représentation des diagrammes de séquence

Les diagrammes de séquences suivants illustrent chacun le scénario nominal (déroulement normal) des processus concernés.



Diagramme de séquence 1 : CU Authentification

Diagramme de séquence 2 : CU CréerCompteAdmin



Diagramme de séquence 3 : CU CréerCompteFournis



Diagramme de séquence 4 : CU Validation



Diagramme de séquence 5 : CU ModifCompteAdmin



Diagramme de séquence 6 : CU ModifCompteFournis





Diagramme de séquence 7 : CU SupCompteAdmin

Diagramme de séquence 8 : CU SupCompteFournis



Diagramme de séquence 9 : CU CréerProduit



Diagramme de séquence 10 : CU ModitierProduit



Diagramme de séquence 11 : CU SupProduit



Diagramme de séquence 12 : CU Consulterlnfo



Diagramme de séquence 13 : CU EditerEtat



Diagramme de séquence 14 : CU SuivreTransaction



Diagramme de séquence 15 CU Identification



Diagramme de séquence 16 CU FairePaiement



6.3.3.7. Diagramme de classe

Pour rappel, un diagramme de classes est une collection d'éléments de modélisation statiques (classes, paquetages...), qui montre la structure d'un modèle. Le diagramme de classes fait abstraction des aspects dynamiques et temporels. Il permet de représenter l'ensemble des informations formalisées, ayant fait l'objet d'une définition sur le fond et sur la forme, qui sont gérées dans le domaine.

6.3.3.7.1. Règles de gestion (RG)

RG1 : Un client possède au moins une carte bancaire;

RG2 : Un client possède au moins un compte bancaire;

RG3 : Une carte bancaire peut faire l'objet d'une opposition;

RG4 : Un client peut faire des commandes;

RG5 : Un client effectue des achats;

RG6 : Un compte existe dans une banque;

RG7 : Une carte bancaire fait référence à un compte bancaire;

RG8 : Un fournisseur possède un compte bancaire;

RG9 : Un fournisseur vend des produits;

RG10 : Un fournisseur effectue des opérations de vente;

RG11 : Un fournisseur édite des factures ;

RG12 : Un fournisseur possède un compte système;

RG13 : Un administrateur gère au moins un compte système;

RG14: Un administrateur gère des opérations;

RG15: Une opération concerne des produits;

RG16: Une opération est soit une vente ou un achat;

RG17: Une opération est facturée;

RG18: Une commande peut contenir des produits;

RG19: Une banque envoie des mails;

RG20: Un fournisseur reçoit au moins un mail;

RG21 : Un client reçoit au moins un mail;

RG22 : Un utilisateur a accès à au moins un compte système;

RG23 : Un utilisateur est un fournisseur ou un administrateur.

6.3.3.7.2. Représentation du diagramme de classe futur



6.3.3.7.3. Description des classes

Classe : Opposition

Attributs

NOM

DESCRIPTION

TYPE

IDOpposition

Identifiant de l'opposition

Texte

RaisonOpposition

Motif de l'opposition

Texte

Méthodes

NOM

DESCRIPTION

CréerOpposition

Permet la création d'une nouvelle opposition

AfficherOpposition

Permet d'afficher des informations sur une Opposition

ModifierOpposition

Permet de modifier les informations sur une Opposition

SupprimerOpposition

Permet de supprimer une Opposition

Classe : Cartebancaire

Attributs

NOM

DESCRIPTION

TYPE

N°Carte

Numéro de la carte bancaire

Texte

CodeCarte

Code de vérification de la carte bancaire

Texte

DateValidité

Date de validité de la carte bancaire

Date

NOM

DESCRIPTION

Méthodes

CréerCarte

Permet la création d'une nouvelle carte bancaire

AfficherCarte

Permet d'afficher la liste des cartes bancaires

ModifierCarte

Permet de modifier des informations sur une carte

SupprimerCarte

Permet de supprimer une carte bancaire de la liste

Classe: CompteBancaire

Attributs

NOM

DESCRIPTION

TYPE

N°CompteBancaire

Numéro du compte bancaire

Numérique

TypeCompteBancaire

Type du compte bancaire

Texte

SoldeCompte

Solde du compte bancaire

Numérique

Méthodes

NOM

DESCRIPTION

CréerCompteBancaire

Permet la création d'un nouveau compte bancaire

AfficherCompteBancaire

Permet d'afficher la liste des comptes bancaires

ModifierCompteBancaire

Permet de modifier des informations sur un compte bancaire

SupprimerCompteBancaire

Permet de supprimer un compte bancaire de la liste

DebiterCompteBancaire

Permet de débiter un compte bancaire

CrediterCompteBancaire

Permet de créditer un compte bancaire

Classe : Identification

Attributs

NOM

DESCRIPTION

TYPE

Identifiant

Identifiant du client

Texte

N°CarteBancaire

Numéro de la carte bancaire du client

Texte

MotDePasse

Mot de passe du client

Texte

CodeDeVérification

Code de vérification de la carte du client

Texte

Classe : Client

Attributs

NOM

DESCRIPTION

TYPE

N°CIBClient

Numéro de la CIB du client

Numérique

NomClient

Nom du client

Texte

PrenomClient

Prénom du client

Texte

AdresseClient

Adresse du client

Texte

MailClient

Mail du client

Texte

Méthodes

NOM

DESCRIPTION

CréerClient

Permet la création d'un nouveau client

AfficherClient

Permet d'afficher la liste des clients

ModifierC1ient

Permet de modifier des informations sur un client

SupprimerClient

Permet de supprimer un client de la liste

Classe : Banque

Attributs

NOM

DESCRIPTION

TYPE

IDBanque

Identifiant de la banque

Texte

NomBanque

Nom de la banque

Texte

AdresseBanque

Adresse de la banque

Texte

MailBanque

Adresse électronique de la banque

Texte

Méthodes

NOM

DESCRIPTION

CréerBanque

Permet la création d'une nouvelle banque dans la liste

AfficherBanque

Permet d'afficher des informations sur une banque

ModifierBanque

Permet de modifier les informations sur une banque

SupprimerBanque

Permet de supprimer une banque de la liste

Classe : Produit

Attributs

NOM

DESCRIPTION

TYPE

IDProduit

Identifiant du produit

Texte

NomProduit

Nom du produit

Texte

TypeProduit

Type du produit

Texte

Méthodes

NOM

DESCRIPTION

CréerProduit

Permet la création d'un nouveau produit

ConsulterProduit

Permet d'afficher la liste des produits

ModifierProduit

Permet de modifier des informations sur un produit

SupprimerProduit

Permet de supprimer un produit de la liste

Classe : Commande

Attributs

NOM

DESCRIPTION

TYPE

IDCommande

Identifiant de la commande

Texte

NatureCommande

Nature de la commande

Texte

Montant

Montant de la commande

Numérique

Devise

Devise du montant

Numérique

Méthodes

NOM

DESCRIPTION

CéerCommande

Permet la création d'un nouveau panier

ConsulterCommande

Permet de consulter les informations sur un panier

ModifierCommande

Permet de modifier les informations sur un panier

SupprimerCommande

Permet de supprimer panier

Classe : Mail

Attributs

NOM

DESCRIPTION

TYPE

IDMail

Identifiant de l'adresse électronique

Texte

MotDePasse

Mot de passe de l'adresse électronique

Texte

EtatMail

Etat de l'adresse électronique

Texte

Méthodes

NOM

DESCRIPTION

CréerMail

Permet la création d'une nouvelle adresse électronique

AfficherMail

Permet d'afficher des informations sur une adresse électronique

ModifierMail

Permet de modifier les informations sur une adresse

SupprimerMail

Permet de supprimer une adresse électronique de la liste

ActiverMail

Permet d'activer une adresse électronique

SuspendreMail

Permet de suspendre une adresse électronique

Classe : Facture

Attributs

NOM

DESCRIPTION

TYPE

N°Facture

Numéro de la facture

Numérique

TypeFacture

Type Facture

Texte

DateFacture

Date d'acquisition de la facture

Date

Méthodes

NOM

DESCRIPTION

CréerFacture

Permet la création d'une nouvelle facture

ConsulterFacture

Permet d'afficher la liste des factures

ModifierFacture

Permet de modifier des informations sur une facture

SupprimerFacture

Permet de supprimer une facture de la liste

Classe : Fournisseur

Attributs

NOM

DESCRIPTION

TYPE

IDFournisseur

Identifiant du fournisseur

Texte

NomFounisseur

Nom du fournisseur

Texte

AdresseFournisseur

Adresse du fournisseur

Texte

MailFournisseur

Mail du fournisseur

Texte

Méthodes

NOM

DESCRIPTION

CréerFournisseur

Permet la création d'un nouveau fournisseur

Afficherfournisseur

Permet d'afficher la liste des fournisseurs

ModifierFournisseur

Permet de modifier des informations sur un fournisseur

SupprimerFournisseur

Permet de supprimer un fournisseur de la liste

Classe : CompteSystèmc

Attributs

NOM

DESCRIPTION

TYPE

IDCompte

Identifiant du compte électronique

Texte

TypeCompte

Type du compte électronique

Texte

Méthodes

NOM

DESCRIPTION

CéerCompte

Permet la création d'un nouveau compte

AfticherCompte

Permet d'afficher des informations sur un compte électronique

ModifierCompte

Permet de modifier les informations sur un compte

SupprimerCompte

Permet de supprimer un compte électronique

Classe : Opération

Attributs

NOM

DESCRIPTION

TYPE

IDOpération

Code de l'opération

Texte

LibelléOpération

Nature de l'opération

Texte

MontantOpération

Montant de l'opération

Texte

Méthodes

NOM

DESCRIPTION

CréerOpération

Permet la création d'une nouvelle opération

ConsulterOpération

Permet d'afficher la liste des opérations

ModifierOpération

Permet de modifier des informations sur une opération

SupprimerOpération

Permet de supprimer une opération de la liste

Classe : Authentification

Attributs

NOM

DESCRIPTION

TYPE

NomConnexion

Nom de la connexion

Texte

MotDePasse

Mot de passe

Texte

Classe : Achat

Attributs

NOM

DESCRIPTION

TYPE

IDAchat

Identifiant de l'achat

Texte

LibelléAchat

Libellé de l'achat

Texte

Montant

Montant de l'achat

Numérique

Méthodes

NOM

DESCRIPTION

CréerAchat

Permet la création d'un nouvel achat

ConsulterAchat

Permet de consulter les informations sur un achat

ModifierAchat

Permet de modifier les informations sur un achat

SupprimerAchat

Permet de supprimer un achat

Classe : Vente

Attributs

NOM

DESCRIPTION

TYPE

IDVente

Identifiant de la vente

Texte

LibelléVente

Libellé de la vente

Texte

Méthodes

NOM

DESCRIPTION

CréerVente

Permet la création d'une nouvelle vente

ConsulterVente

Permet de consulter les informations sur une vente

ModifierVente

Permet de modifier les informations sur une vente

SupprimerVente

Permet de supprimer une vente

Classe : Utilisateur

Attributs

NOM

DESCRIPTION

TYPE

NomUtilisateur

Nom de l'utilisateur

Texte

MotDePasse

Mot de passe de l'utilisateur

Texte

Privilège

Statut de l'utilisateur

Texte

Méthodes

NOM

DESCRIPTION

CréerUtilisateur

Permet de créer un utilisateur

ModifierUtilisateur

Permet de modifier les informations sur un utilisateur

SupprimerUtilisateur

Permet de supprimer un utilisateur de la liste

Classe : Administrateur

Attributs

NOM

DESCRIPTION

TYPE

IDAdministrateur

Identifiant de la banque

Texte

NomAdministrateur

Nom de l'adrninistrateur

Texte

PrénomAdministrateur

Prenom de l'administrateur

Texte

AdresseAdministrateur

Adresse de l'administrateur

Texte

FonctionAdministrateur

Fonction de l'administrateur

Texte

Méthodes

NOM

DESCRIPTION

CréerAdministrateur

Permet d'afficher des informations sur un administrateur

AfficherAdministrateur

Permet d'afficher des informations sur un administrateur

ModifierAdministrateur

Permet de modifier les informations sur un administrateur

SupprimerAdministrateur

Permet de supprimer un administrateur de la liste

Chapitre 7ème : ETUDE TECHNIQUE DE LA SOLUTION RETENUE

7.1. Présentation et fonctionnalités du langage de programmation retenu : WEBDEV

WEBDEV est un AGL (Atelier de Génie Logiciel) orienté développement de sites Intranet et Internet. WEBDEV permet de développer tout type de sites dynamiques incluant l'accès à des bases de données. Il permet aussi de développer des sites semi-dynamiques et statiques ou PHP^50(*).

7.1.1. Présentation de WEBDEV

WEBDEV est composé de différents éditeurs :

ü Un éditeur de projet permettant de visualiser et d'agir sur le graphe du projet.

ü Un éditeur de pages.

ü Un éditeur d'analyses permettant l'accès à tout type de base de données (HyperFileSQL, HyperFileSQL Client/Serveur, MySQL, xBase, AS/400*, Oracle*, SQL Server*, Access**, OLE DB, etc.).

ü Un éditeur de code évolué (avec assistants, vérification du code saisi, coloration syntaxique, aide contextuelle ...) incluant un puissant débogueur.

ü Un éditeur de styles incluant police, couleur, position, etc.

ü Un éditeur de requêtes pour les sélections d'enregistrements dans les fichiers.

ü Un éditeur d'états.

ü Un éditeur de dossier technique reprenant intégralement toutes les informations techniques de votre projet.

ü Un éditeur d'installation. * accès natif optionnel, ** accès natif inclus

L'éditeur d'installation assure la mise en place des sites créés, ainsi que leur maintenance. Cet outil permet de réaliser une installation sur le serveur via FTP ou par média physique (CD, Zip, etc.).

Des outils facilitant le développement sont également fournis (WDMAP, WDOUTIL,

WDSQL, etc.) ainsi que de nombreux exemples et assistants réutilisables.

Les principaux éditeurs sont utilisés, depuis la définition d'une analyse jusqu'à l'installation, en passant par toutes les phases du développement (création de pages, traitements, sauvegardes.

7.1.1.1. Les différents services de l'Internet

Le terme Internet regroupe plusieurs services d'utilisation différente :

ü FTP (File Transfer Protocol) est un service d'un ordinateur vers un autre à travers Internet.

ü SMTP (Simple Mail Transfer Protocol) permet d'envoyer des messages ou mails à un utilisateur défini. Chaque utilisateur doit disposer d'une adresse Email qui lui sert de boîte aux lettres.

ü http (HyperText Transfer Protocol) : http est un protocole de niveau application qui est utilisé pour le transfert de pages sur Internet.

Chacun de ces services nécessite un gestionnaire de services installé sur un serveur

Le gestionnaire de services FTP gère l'hébergement des fichiers, les droits d'utilisation des fichiers et la réponse aux demandes en provenance des autres postes

Le gestionnaire de service SMTP prend en charge les demandes d'envoi de messages et le routage vers les serveurs POP (réception des messages) concernés.

Le gestionnaire Web (www) permet l'hébergement des pages et répond aux demandes de consultation de la part des postes client.

7.1.1.2. Le Web en détail

Les pages Web sont visualisées sur un poste par l'intermédiaire d'un navigateur Web (Internet Explorer, FireFox, Opera, etc.). Le navigateur interprète le contenu des fichiers au format HTML décrivant les pages. On parle de pages HTML.

WEBDEV génère automatiquement le code HTML et JavaScript.

Il est possible d'afficher directement une page dans un navigateur en tapant son URL^51(*) dans la zone adresse du navigateur.

Si l'URL ne correspond pas à une adresse valide, une erreur de connexion est retournée dans l'écran du navigateur.

Si l'URL est valide, la page demandée s'affiche dans le navigateur. L'utilisateur peut alors déclencher une action en cliquant sur un lien ou un bouton. La requête correspondante est alors envoyée au serveur qui l'analyse.

Le lien permet de lancer le chargement d'une autre page ou bien de lancer une application Web.

7.1.1.3. Site statique, semi-dynamique ou dynamique ?

ü Le site statique est composé de pages conçues à l'avance de manière définitive.

Dans ce cas, le contenu des pages n'évoluera pas dynamiquement en fonction d'un choix de l'utilisateur.

ü Un site semi-dynamique est un site statique composé de pages conçues à l'avance mais enrichies par une base de données. Dans ce cas, le contenu des pages n'évoluera pas dynamiquement en fonction d'un choix de l'utilisateur. L'un des meilleurs exemples est un catalogue de pièces détachées.

ü Un site dynamique est constitué de pages enrichies de données provenant d'une base de données. Il est nécessaire d'exécuter des traitements d'accès aux données sur le serveur permettant de constituer la page.

WEBDEV permet de développer des sites dynamiques composés de pages, de traitements serveur (accès aux bases de données, calculs, etc.) et de traitements exécutés par le navigateur (contrôles, traitements répétitifs, etc.).

WEBDEV permet aussi de développer des sites statiques et semi-dynamiques.

7.1.2. Fonctionnement d'une application WEBDEV

Une application WEBDEV hébergée sur un serveur peut être exécutée en appelant une URL particulière depuis un navigateur. Par exemple : http://www.monserveur.com/wd150awp/wd150awp.exe/CONNECT/monappli

Le lanceur de WEBDEV « wd150awp.exe » permet d'exécuter l'application sur le serveur grâce au serveur d'application wd150session.exe.

Le serveur d'application construit dynamiquement la première page de l'application et l'envoie au navigateur par l'intermédiaire du serveur Web.

7.1.3. Principe de programmation WEBDEV

Le débit entre le serveur Internet et le poste client est plus lent qu'avec un réseau local classique. Les échanges de données entre le poste client et le serveur doivent donc être réduits pour que l'application puisse s'exécuter sans ralentissement. WEBDEV permet de différencier les traitements exécutés sur le serveur et les traitements exécutés sur le poste client.

7.1.3.1. Les traitements sur le serveur

Les traitements exécutés sur le serveur sont les traitements principaux de l'application. Ils concernent la gestion de la base de données (HyperFileSQL et HyperFileSQL Client/Serveur, xBase, AS/400, Oracle, SQL Server, Access, OLE DB, etc.), les traitements de calcul.

Ces traitements sont écrits en WLangage.

7.1.3.2. Les traitements sur le poste client

Les traitements exécutés sur le poste client sont de vérification qui ne nécessite pas d'accéder au serveur. Ces traitements utilisent uniquement les informations contenues dans la page. Ces traitements peuvent être écrits en JavaScript ou WLangage. Dans ce dernier cas, WEBDEV se charge de convertir automatiquement le code WLangage en JavaScript pour qu'il puisse être exécuté par le navigateur.

7.1.3.3. Administrateur WEBDEV

L'administrateur WEBDEV est un exécutable installé sur le serveur.

L'administrateur permet de configurer le nombre de connexions autorisées en même temps pour le serveur, par site, par utilisateur. Il permet aussi de fixer le temps maximum d'exécution d'une requête et le temps limite pour la déconnexion des utilisateurs inactifs.

L'administrateur peut à tout moment afficher la liste des utilisateurs connectés au site.

7.1.4. Evaluation des avantages du futur système

ü Ouverture du domaine de prestations de la banque

Le nouveau mode de paiement qu'offre le futur système, donnera non seulement une grande satisfaction à l'ensemble de la clientèle de la BCDC mais aussi une plus grande ouverture de la banque vers l'extérieur.

ü Rapidité de traitement

Dans ce nouveau système de paiement, tous les acteurs (client, fournisseur, banque) travailleront plus vite minimisant ainsi le temps et gagneront en argent par la réduction des déplacements et l'automatisation du processus achat/vente.

ü Fiabilité des transactions

Pour réduire les risques d'erreurs, les valeurs numéraires ne seront pas saisies manuellement lors d'une opération de paiement par l'application. Aussi, tous les acteurs sont authentifiés. Les données échangées entre les acteurs sont illisibles pour les tiers ne faisant pas partir du domaine parce qu'elles sont cryptées par le SSL-256 bits.

ü Sécurité des données

L'utilisation de certificat SSL et d'un système d'exploitation linux Debian permet d'avoir un niveau de sécurité très élevé.

ü Facilité d'établissement de bilans

Les utilisateurs du nouveau système pourront établir facilement des bilans parce que ce système constituera toute une mémoire.

7.1.5. Evaluation des risques du futur système

Le système futur bien que présentant de nombreux avantages n'est tout de même pas à l'abri d'un certain nombre de risques inhérents à tout système informatique. Parmi ces risques on peut citer :

L'infection par les virus pouvant endommager le système;

La panne d'un micro-ordinateur ou du serveur;

La non disponibilité du système lié aux pannes d'électricité de longue durée dépassant l'autonomie des onduleurs ;

Les accès malveillants et les intrusions.

7.2. PROCEDURE DE SECOURS

Ce sont des procédures à appliquer en cas de défaillance du système. Plusieurs cas de figure peuvent se présenter.

7.2.1. Pannes d'électricité

En cas de panne d'électricité, les onduleurs assureront l'alimentation électrique pendant la durée de leur autonomie. Les groupes électrogènes appuieront les onduleurs. Cela permettra d'éviter les pertes d'information au niveau de la base de données.

7.2.2. Panne d'un poste de travail ou d'un serveur

En cas de panne d'un poste, l'utilisateur devra utiliser un autre poste pour effectuer les traitements en attendant la réparation de son poste ou son remplacement. Le serveur dispose de deux disques durs; cela permet d'implémenter la technologie RAID afin de pouvoir rebâtir les données en cas de panne de l'un des disques, l'autre disque sera utilisé pour reconstruire les données du disque défectueux en attendant que le disque défaillant soit remplacé. En cas de panne de serveur, il est conseillé de déplacer un de ses disques durs sur un autre poste de travail qui sera configuré en serveur temporaire. En cas de défaillance de ses deux disques durs, les sauvegardes sur supports

(DVD-ROM, bande, disque amovible) permettront de restaurer les données.

7.2.3. Plantage du logiciel

En cas de plantage du logiciel, il est recommandé de réinitialiser le programme. Au cas où la panne persisterait malgré l'intervention de l'administrateur système, il faudrait contacter les développeurs pour une maintenance.

7.3. PROCEDURE DE SECURITE

7.3.1. Protection contre les catastrophes

Les catastrophes susceptibles d'endommager les installations sont l'incendie, la foudre, l'orage et l'inondation. Pour éviter ces catastrophes, le local où seront installées les machines doit être aménagé et équipé d'extincteurs et de paratonnerres. Pour ne pas totalement perdre les informations en cas de détérioration des disques durs, les données seront sauvegardées sur des bandes, CD-ROM ou du papier listing. Ces supports de sauvegarde seront conservés hors du local abritant les machines pour éviter leur destruction en cas de catastrophes.

7.3.2. Protection contre les virus informatiques

Les virus sont des programmes informatiques capables de provoquer la destruction des données et/ou du matériel et de porter atteinte à la fiabilité des résultats produits par le système. Ces virus peuvent provenir des CD-ROM, des disquettes contaminés ou tout autre support (disque dur) ou réseau (local, internet).

Pour protéger les postes de travail contre les attaques virales nous proposons :

· d'acquérir des antivirus récents et régulièrement mis à jour pour qu'ils puissent surveiller permanemment les ordinateurs et désinfecter le plus rapidement possible une éventuelle attaque virale;

· de vérifier la source de tout programme à installer (avec le système d'exploitation).

7.3.3. La politique de sauvegarde

La procédure de sauvegarde que nous proposons consiste à faire :

· des sauvegardes journalières qui ont une durée d'une semaine;

· des sauvegardes hebdomadaires qui ont une durée d'un mois ;

· des sauvegardes mensuelles qui ont une durée de six mois;

· des sauvegardes annuelles qui seront conservées indéfiniment.

Par ailleurs, il est conseillé que chacune des sauvegardes soit en double et que leur conservation se fasse dans un lieu totalement sécurisé (l'une sur le site et l'autre en dehors).

7.3.4. Protection contre les accès malveillants

La sécurisation passe par un contrôle rigoureux de l'identité des personnes qui accèdent au local technique où sont installés les différents serveurs. Il n'y a pas de solution simple et immédiate pour sécuriser un site web. Nous proposons des mesures de sécurité technique à tous les niveaux :

· protection au niveau du serveur web ;

· protection au niveau du réseau ;

· protection au niveau de l'application.

7.3.5. Protection au niveau du serveur web

Le paramétrage du système d'exploitation du serveur est très important. En effet la protection du serveur est impossible tant que le système d'exploitation sous-jacent n'est pas sécurisé. Pour cela, il faut des mesures de sécurité spécifiques concernant la gestion des utilisateurs, des processus, des systèmes de fichiers, etc.

7.3.6. Protection au niveau du réseau

Un équipement de filtrage (de type firewall) sera utilisé pour limiter les flux réseaux ouverts depuis l'extérieur. Le firewall permet d'assurer le filtrage par service des accès entrants et limite ainsi les risques auquel est soumis le serveur web.

7.3.7. Protection au niveau de l'application

La protection de l'application passe par :

· l'authentification des utilisateurs ;

La confidentialité des données sera assurée par la définition d'un profil utilisateur à travers l'utilisation de mot de passe et de nom de connexion. Pour plus de sécurité les mots de passe seront régulièrement modifiés. L'accès aux informations sera ainsi protégé. Chaque utilisateur n'accèdera qu'aux données dont il a droit et n'effectuera que les traitements qui lui sont autorisés.

· L'utilisation de fonctions de chiffrement;

Les échanges nécessitant un certain niveau de confidentialité doivent utiliser les options de transfert sécurisé basé sur le chiffrement (SSL, HTTPS^52(*))

7.4. PROCEDURE DE MISE EN OEUVRE

7.7.1. Procédure de vérification

Le système futur devra être soumis a une série de test afin de s'assurer de son adéquation avec les besoins et exigences exprimés par les utilisateurs. Les éventuelles défaillances décelées au cours de ces tests seront progressivement corrigées jusqu'à l'obtention d'une application correcte et conforme aux besoins.

7.7.2. Formations des utilisateurs

Il est prévu de former des utilisateurs du système. Cela leur permettra non seulement de se familiariser avec le logiciel, mais aussi de constater à l'usage les cas d'erreurs et les insuffisances du logiciel. Elle permettra donc la révision et la correction des imperfections par les développeurs.

7.7.3. Planning de réalisation

Etape	Durée
Conception	Deux (02) semaines
Implémentation	Huit (08) mois
Mise en oeuvre	Trois (03) mois

7.8. Conclusion

Le présent chapitre a permis d'étudier les aspects techniques de façon détaillée de la solution retenue. Il présente les procédures de secours, les procédures transitoires ainsi que la politique de sécurité. Il met fin à la phase d'analyse et sa validation devrait servir de fondement à l'étape de l'implémentation que nous n'avons pas abordé au cours dans ce travail.

CONCLUSION GENERALE

Dans le cadre de notre travail de fin de cycle de licence, nous avons choisi d'étudier de mettre en place un système de paiement électronique à la BCDC. Ce système est nouveau au sein de la banque ce qui augmente la complexité et la délicatesse de la tâche. Tout en nous basant sur les moyens de paiement manuel qu'offre la structure avec leurs atouts et leurs faiblesses, nous avons proposés des solutions pour pallier à ces insuffisances afin d'atteindre les objectifs visés de son informatisation. Un scénario fut retenu et modélisé dans le dernier chapitre de ce travail après concertation avec le groupe d'utilisateur. En somme dans ce document, nous avons défini le futur système d'information et les procédures de secours et de sécurité adéquates à son utilisation. Nous aimerions que le travail que nous avons entrepris à la BCDC connaisse son achèvement pour permettre de voir nos efforts couronnés par la mise en place d'un système de paiement électronique.

BIBLIOGRAPHIE

PHILIPP Jacques, Architecture et normalisation des systèmes distribués, Ed. Ellipse, 2003, Page20

David TILLOY, Introduction aux réseaux TCP/IP. Support de cours, Ed. 1998/99, Page 5.

Dhafrallah MHIR : « La sécurité des systèmes informatiques » édité en janv-2003 (pages 25 à 29)

GHERNAOUTI-Hélie S.,  « sécurité informatique et Réseaux », Dunod, Paris, pages 1 à 5

Gérer l'entreprise numérique », ERPI 2010, pages 29-31

L.DEBRAUWER & F.V. DER HEYDE : « UML 2, Initiation, exemples et exercices corrigés » 2^ème éd. Page 29

B.GIACOMONI - Ass. A.T.L.A.N.T.I.C : « RESEAUX INFORMATIQUES » septembre 2009, page4.

Dominique LALOT : « RESEAUX INFORMATIQUES, notes de cours », page4

Roland Trique, Jargon informatique, JO 1998

Graig HUNT, TCP/IP Network administration, O'Reilly, 2005, Page 17.

Julien Levrard : « La sécurité du Système d'Information : De nouveaux défis pour la DSI »

MAKKES Mounir et HADHRI Mohamed Ali : « Gestion d'un Centre Informatique » page 29.

Mr DIEMER : « Cours d'ECONOMIE GENERALE » page 73

38 Dictionnaires et recueils de correspondance

Dr. Babacar Sène : «  Cours de monnaie (Economie monétaire et financière) 2010 - 2011 » page30

David Bounie : « Quelques incidences Bancaires et monétaires des systèmes de paiement électronique »

Jacques Saint-Amant «  Le cadre juridique des paiements électroniques »(Nov. 2002), page 416

D.Bounie & S. Soriano «La monnaie électronique, Principes, fonctionnement et organisation» page 84

(Pierre-Paul LEMYRE : « Le guide juridique du commerçant électronique » page 168).

O. Caya, J. Lavallée et D. Perras (Université de Sherbrooke), « Ies systèmes d'information de Gestion,

Robert Ogor : « Modélisation avec UML » page39

Jean Michel DOUDOUX : « Développons en Java 9.0 », page4

Laurent AUDIBERT : « UML2 »

STEFFE - ENITA de Bordeaux : « COURS UML13.doc », Mars 2005, page 3

A. AIT ADDI, « Analyse et conception orientées objets », Cours UML 2009-2010, page 58.

R.DELCAMBRE, « COCOMO », Mars 2003, page 2

TDF TECH 2010- www.pcsoft.fr, pages 14, 15

TABLE DE MATIERES

DEDICACE i

AVANT-PROPOS iii

INTRODUCTION GENERALE 4

0.1 Problématiques 4

0.2 Enjeux, objectifs et Hypothèse du travail 4

0.3 Choix et intérêt du sujet 6

0.4 Délimitation du sujet 6

0.5 Méthodes et techniques utilisées 6

0.6 Subdivision du travail 7

1^ère Partie : CONCEPTS THEORIQUES 8

Chapitre 1^er : GENERALITES SUR LES RESEAUX INFORMATIQUES 9

1.1 Définition 9

1.2 Historique 9

1.3 La normalisation 11

1.4 Le standard 11 1.5. La norme 11

1.6 Le modèle OSI 12 1.7 Le modèle TCP/IP 13

1.7.1. Vue encouche du modèle TCP/IP 14

1.7.2. Identification des machines 16 1.7.3. Format d'une adresse IP 16

1.7.4. Attribution des adresses IP 16 1.7.5. Passage des adresses IP aux adresses physiques 18

1.7.6. La table de routage 18 1.7.7. Le routage et les protocoles de routage 18 1.7.8. Protocoles TCP/IP et UDP 20

1.7.9. La fragmentation 20 1.8. L'architecture Client / Serveur 22

1.9. La sécurité du système d'Information (SI) 22

1.9.1. Définitions 23 1.9.2. Approche globale de la sécurité informatique 23

1.9.2.1. La Sécurité Organisationnelle 24

1.9.2. La sécurité physique et environnementale 24

1.9.2.3. La sécurité des accès 24

1.9.2.4. La sécurité des réseaux 25

1.9.2.5. La sécurité des serveurs 25

1.9.2.6. La sécurité des données 25

1.9.2.7. La sécurité énergétique 26

1.9.2.8. La sécurité antivirale 26

1.9.3. Architecture de sécurité 27

1.9.4. Stratégie de sécurité 29

Chapitre 2^{ème :} INSTITUTIONS FINANCIERES ET SYSTEME DE PAIEMENT

ELECTRONIQUE 31

2.1. Institutions Financières 31

2.1.1. Définition 31

2.1.2. Rôles 31

2.1.3. Les Banques 32

2.1.3.1. La banque électronique 32

2.1.3.1.1. La banque par ordinateur 32

2.1.3.1.2. La banque par téléphone 33

2.1.3.2. La banque par internet 34

2.1.3.3. La banque en self-service 35

2.1.4. La monnaie 35

2.1.4.1. Historique 35

2.1.4.2. Fonctions de la monnaie 36

2.1.4.3. Formes de la monnaie 36

2.1.4.3.1. La monnaie métallique 37

2.1.4.3.2. La monnaie de papier ou les billets 37

2.1.4.3.3. La monnaie scripturale ou la monnaie de banque 37

2.1.4.3.4. La monnaie électronique ou la monétique 38

2.1.5. Les moyens de paiement 39

2.1.5.1. Le Chèque 39

2.1.5.2. Le Virement 39

2.1.5.3. La Domiciliation 40

2.1.5.4. L'avis de prélèvement automatique 40

2.1.5.5. Le titre interbancaire de paiement 40

2.1.5.6. La carte bancaire 40

2.2. Système de paiement électronique (SPE) 41

2.2.1. Définition 41

2.2.2. Typologie 41

2.2.2.1. Les SPE articulés autour d'un compte bancaire 42

2.2.2.2. Les SPE articulés autour d'un compte non bancaire 42

2.2.2.3. La monnaie électronique 42

2.2.2.4. Autres types de systèmes de paiement électronique 43

2.2.2.3.1. Le portefeuille numérique 43

2.2.2.3.2. Le système numérique de paiement à solde cumulé 43

2.2.2.3.3. Le système de paiement en ligne à valeur enregistrée 43

2.2.2.3.4. Le chèque électronique 44

2.2.2.3.5. Le SPE de présentation de facture et de paiement 44

2.2.2.3.6. Les SPE pour le commerce mobile 44

2^ème Partie : CONCEPTION DU NOUVEAU SYSTÈME D'INFORMATION 47

Chapitre 3^ème : PRESENTATION DE LA BCDC 47

3.0. Introduction 47

3.1. Présentation

3.1.1. Historique 47

3.1.2. Profil et quelques données chiffrées de la Banque 49

3.1.3. Mission 50

3.1.4. Organigramme de la Banque 51

3.2. Présentation de la DIM 52

3.2.1. Organisation de la DIM 52

3.2.2. Organigramme de la DIM 54

Chapitre 4^ème : ETUDE DE L'EXISTANT 55

4.0. Introduction 55

4.1. L'analyse en UML 55

4.2. La méthode RAD 56

4.2.1. Description des phases de RAD 56

4.3. Objectifs de l'étude de l'existant 57

4.4. Ressources disponibles 58

4.4.1. Ressources Humaines 58

4.4.2. Ressources Matérielles 58

4.4.3. Le système informatique existant 59

4.4.4. Les logiciels 59

4.4.5. Le Réseau 60

4.4.5.1. Le Réseau global 60

4.4.5.2. Le Réseau local 60

4.4.5.3. L'offre monétique 60

4.4.5.4. Les services 61

4.5. Première phase : repérage du domaine 62

4.5.1. Objectif 62

4.5.2. Déroulement de la 1^ère phase 62

4.5.3. Délimitation du domaine d'étude 62

4.5.3.1. Diagramme de collaboration 62

4.5.3.2. Représentation du diagramme de flux existant 64

4.6. Deuxième phase : Découverte des informations 64

4.6.1. Objectif de la phase 64

4.6.2. Déroulement de la 2^ème phase 65

4.7. Diagramme de classe 69

4.7.1. Notion de classe 69

4.7.2. Représentation de diagramme des classes actuel 74

4.7.3. Description des classes du diagramme 76

4.8. Troisième phase : Modélisation du Workflow 83

4.8.1. Objectif 83

4.8.2. Déroulement de la 3^ème phase 83

4.8.3. Résultat de la 3^ème phase

4.8.3.1. Diagramme de cas d'utilisation 83

4.8.3.1.1. Acteurs 83

4.8.3.1.2. Cas d'utilisation (CU) 85

4.8.3.1.3. Identification de cas d'utilisation du système actuel 85

4.8.3.1.4. Représentation des CU du système actuel 86

4.8.3.1.5. Formalisme adopté pour la description des CU 87

4.8.3.1.6. Description textuelle d'un CU 88

4.8.4. Présentation des diagrammes de séquence 98

4.9. Quatrième phase : Diagnostic 106

4.9.1. Objectif de la 4^ème phase 106

4.9.2. Déroulement de la 4^ème phase 106

4.9.3. Résultat de la 4^ème phase 106

4.10. Conclusion de l'étude de l'existant 107

Chapitre 5^EME : ETUDE DES SCENARII 108

5.0. Introduction 108

5.1. Généralités 108

5.1.1. Objectifs du système futur 108

5.2. Description des scenarii 109

5.2.1. Symboles utilisés pour la de la structure réseau 109

5.2.2. Description du premier scénario 110

5.2.3. Prise en compte des contraintes 111

5.2.4. Calcul du cout de développement par la méthode COCOMO 111

5.2.4.1. Présentation de l'architecture réseau 114

5.2.4.2. Liste des matériels requis 115

5.2.4.3. Liste des logiciels requis 115

5.2.4.4. L'évaluation des coûts 115

5.2.4.4.1. Coût du matériel et logiciel 115

5.2.4.4.2. Calcul du coût de développement 118

5.2.4.4.3. Coût de formation des utilisateurs 118

5.2.4.4.4. Coût de mise en place du VPN 119

5.2.4.4.5. Coût total de mise en oeuvre 119

5.2.5. Description du 2^ème scénario 120

5.2.5.1. Présentation de l'architecture réseau 120

5.2.5.2. Liste des matériels requis 121

5.2.5.3. Coût de développement 123

5.2.5.4. Coût de formation des utilisateurs 124

5.2.5.5. Coût de mise en place du VPN banque-CTMI 124

5.2.5.6. Coût total de mise en oeuvre 124

5.2.6. Description du 3^ème scénario 125

5.2.6.1. Présentation de l'architecture réseau 125

5.2.7. Etude comparative des scénarii 126

5.2.7.1. Premier sccénario (avantage et inconvénient) 126

5.2.7.2. Deuxième scénrio (avantage et inconvénient) 126

5.2.7.3. Troisième scénario (avantage et inconvénient) 127

5.2.7.4. Tableau comparatif des différents scénarii 127

5.2.7.5. Scénario retenu 127

5.2.7.6. Le scénario de mise en oeuvre 128

5.2.7.7. Conclusion 128

Chapitre 6^ème : ETUDE DETAILLEE DU SYSTEME FUTUR 129

6.0. Introduction 129

6.1. Généralités 129

6.1.1. Objectif de l'étude de la reconfiguration et modélisation du système

6.1.2. La démarche suivie 129

6.2. Cinquième phase : Reconfiguration du système 130

6.2.1. Objectifs de la 5^ème phase 130

6.2.2. Déroulement de la 5^ème phase 130

6.2.3. Contenu et résultat de la 5^ème phase 130

6.2.3.1. Amélioration des échanges d'informations 130

6.2.3.2. Introduction de nouveaux processus 131

6.2.3.3. Prise en compte des contraintes 132

6.3. Sixième phase : Modélisation du système futur 132

6.3.1. Objectif de la 6^ème phase 132

6.3.2. Déroulement de la 6^ème phase 132

6.3.3. Contenu et résultat de la sixième phase 132

6.3.3.1. Représentation du diagramme de flux 132

6.3.3.2. Diagramme de CU du nouveau système 133

6.3.3.2.1. Les cas d'utilisation 133

6.3.3.2.2. Représentation du diagramme de Cas d'Utilisation 135

6.3.3.3. Description des acteurs 136

6.3.3.4. Les besoins des cas d'utilisation 136

6.3.3.5. Description textuelle des cas d'utilisation 136

6.3.3.6. Diagramme de séquence 152

6.3.3.6.1. Représentation du diagramme de séquence 152

6.3.3.7. Diagramme de classe 168

6.3.3.7.1. Règles de gestion 168

6.3.3.7.2. Représentation du diagramme de classe futur 169

6.3.3.7.3. Description des classes 170

Chapitre 7^ème : ETUDE TECHNIQUE DE LA SOLUTION RETENUE 180

7.1. Présentation et fonctionnalités du langage de programmation retenu :

WEBDEV 180

7.1.1. Présentation de WEBDEV 180

7.1.1.1. Les différents services de l'internet 181

7.1.1.2. Le Web en détail 181

7.1.1.3. Site statique, semi-dynamique ou dynamique ? 182

7.1.2. Fonctionnement d'une application WebDev 183

7.1.3. Principe de programmation WebDev 183

7.1.3.1. Les traitements sur le serveur 183

7.1.3.2. Les traitement sur le poste client 184

7.1.3.3. Administrateur WebDev 184

7.1.4. Evaluation des avantages du futur système 184

7.1.5. Evaluation des risques du futur système 185

7.2. Procédure de secours 185

7.2.1. Panne d'électricité 185

7.2.2. Panne d'un poste de travail ou d'un serveur 186

7.2.3. Plantage du logiciel 186

7.3. Procédure de sécurité 186

7.3.1. Protection contre les catastrophes 186

7.3.2. Protection contre les virus informatiques 186

7.3.3. La politique de sauvegarde 187

7.3.4. Protection contre les accès malveillants 187

7.3.5. Protection au niveau du serveur web 188

7.3.6. Protection au niveau du réseau 188

7.3.7. Protection au niveau de l'application 188

7.4. Procédure de mise en oeuvre 189

7.7.1. Procédure de vérification 189

7.7.2. Formation des utilisateurs 189

7.7.3. Planning de réalisation 189

7.8. Conclusion 189

CONCLUSION GENERALE 190

Bibliographie 191 Table des matières 192

* ¹ B.GIACOMONI - Ass. A.T.L.A.N.T.I.C : « RESEAUX INFORMATIQUES » septembre 2009, page4.

* ² Dominique LALOT : « RESEAUX INFORMATIQUES, notes de cours », page4

* ³ PHILIPP Jacques, Architecture et normalisation des systèmes distribués, Ed. Ellipse, 2003, Page20

* ⁴ Roland Trique, Jargon informatique, JO 1998

* ⁵ Graig HUNT, TCP/IP Network administration, O'Reilly, 2005, Page 17.

* ⁶ David TILLOY, Introduction aux réseaux TCP/IP. Support de cours, Ed. 1998/99, Page 5.

* ⁷ Roland Trique, Op.cit.

* ⁸ Julien Levrard : « La sécurité du Système d'Information : De nouveaux défis pour la DSI »

* ⁹ GHERNAOUTI-Hélie S.,  « sécurité informatique et Réseaux », Dunod, Paris, pages 1 à 5

* ¹⁰ MAKKES Mounir et HADHRI Mohamed Ali : « Gestion d'un Centre Informatique » page 29.

* ¹¹ Dhafrallah MHIR : « La sécurité des systèmes informatiques » édité en janv-2003 ( pages 25 à 29)

* ¹² GHERNAOUTI-Hélie S., Opcit, p15.

* ¹³Mr DIEMER : « Cours d'ECONOMIE GENERALE » page 73

* ¹⁴ 38 Dictionnaires et recueils de correspondance

* ¹⁵ Dr. Babacar Sène : «  Cours de monnaie (Economie monétaire et financière) 2010 - 2011 » page30

* ¹⁶ DIEMER : « ECONOMIE GENERALE », cours p410

* ¹⁷ David Bounie : « Quelques incidences Bancaires et monétaires des systèmes de paiement électronique »

* ¹⁸ Dans les sociétés primitives, les échanges se réalisaient sous la forme d'un troc, (échange d'un bien contre un autre)

* ¹⁹ Jacques Saint-Amant «  Le cadre juridique des paiements électroniques »(Nov. 2002), page 416

* ²⁰ D.Bounie & S. Soriano «La monnaie électronique, Principes, fonctionnement et organisation» page 84

* ²¹ D.Bounie & S. Soriano Opcit, page 1,2

* ²² idem

* ²³ Bounie, tricot et Picory 2000

* ²⁴ SSL : Secure Socket Layer, ce protocole est le système de paiement le plus utilisé sur internet bien qu'il soit d'origine non bancaire, grâce à lui, l'utilisateur sécurise son numéro de carte bancaire en ligne. Le SSL utilise un système cryptographique à clé publique.

* ²⁵ SET : Secure Electronic Transaction, permet d'authentifier les parties concernées dans un acte de paiement moyennant une certification et la mise en place d'une cryptographie asymétrique.

SET va toutefois beaucoup plus loin que SSL car il utilise des certificats et des signatures

électroniques afin de garantir l'identité des parties (Pierre-Paul LEMYRE : « Le guide juridique du commerçant électronique » page 168).

* ²⁶ O. Caya, J. Lavallée et D. Perras (Université de Sherbrooke), « Ies systèmes d'information de Gestion, Gérer l'entreprise numérique », ERPI 2010, pages 29-31

* ²⁷ Robert Ogor : « Modélisation avec UML » page39

* ²⁸ VSAT : Very Small Aperture Terminal

* ²⁹ WIFI : Wireless Fidelity

* ³⁰ BLR : Boucle Locale Radio

* ³¹ GAB : Guichet Automatiques de Billets

* ³² DIM : Direction de l'Informatique et de la Monétique

* ³³ SM : Service Monétique

* ³⁴ GAB : Guichet Automatique de Billet

* ³⁵ GIM : Groupement Interbancaire Monétique

* ³⁶ CTMI : Centre de Traitement Monétique Interbancaire

* ³⁷ SM : Service Monétique

* ³⁸ GAB : Guichet Automatique de Billet

* ³⁹ Jean Michel DOUDOUX : « Développons en Java 9.0 », page42

* ⁴⁰ Laurent AUDIBERT : « UML2 »

* ⁴¹ J.STEFFE - ENITA de Bordeaux : « COURS UML13.doc », Mars 2005, page 34

* ⁴² Idem, p34

* ⁴³ Idem, p37

* ⁴⁴ L.DEBRAUWER & F.V. DER HEYDE : « UML 2, Initiation, exemples et exercices corrigés » 2^ème éd. Page 29

* ⁴⁵ A. AIT ADDI, « Analyse et conception orientées objets », Cours UML 2009-2010, page 58.

* ⁴⁶ R.Ogor « Modélisation avec UML », mai-2006 ; p26

* ⁴⁷ R.DELCAMBRE, « COCOMO », Mars 2003, page 2

* ⁴⁸ HM : nombre d'Homme/Mois nécessaire à la réalisation du projet,

* ⁴⁹ KLSL : nombre de kilo-lignes livrées.

* ⁵⁰ TDF TECH 2010- www.pcsoft.fr, pages 14, 15

* ⁵¹ URL (Uniform Resource Locator) correspond au chemin d'accès de la page sur le serveur qui l'héberge, par exemple : http://www.monserveur.com/page3.htm

* ⁵² HTTPS : Hyper Text Transfer Protocol Secure