See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/346097190

Développement d’une API Java de paiement en ligne sur les sites e-commerce

Thesis · July 2017

DOI: 10.13140/RG.2.2.29031.06564

CITATIONS READS
0 1,751

1 author:

Tossou Osias Noël Nicodème Finagnon

African Institute for Mathematical Sciences Senegal
6 PUBLICATIONS   0 CITATIONS   

SEE PROFILE

All content following this page was uploaded by Tossou Osias Noël Nicodème Finagnon on 23 November 2020.

The user has requested enhancement of the downloaded file.

 RÉPUBLIQUE DU BÉNIN
MINISTÈRE DE L’ENSEIGNEMENT SUPÉRIEUR
ET DE LA RECHERCHE SCIENTIFIQUE

UNIVERSITÉ D’ABOMEY-CALAVI

INSTITUT DE FORMATION ET DE
RECHERCHE EN INFORMATIQUE
BP 526 Cotonou Tel : +229 21 14 19 88
http://www.ifri-uac.net Courriel : contact@ifri.uac.bj

MÉMOIRE
pour l’obtention du

Diplôme de Licence en Génie Logiciel

Présenté par :
Osias Noël Nicodème Finagnon TOSSOU
—
Soutenu le 22 Juillet 2017 devant le jury composé de :
Prof. YAYA K. Abdoulaï (Président du Jury)
Doctorant METONGNON Lionel
Ing. AIKPE Roland

Développement d’une API Java de

paiement en ligne sur les sites e-commerce

Sous la supervision :

Prof. Eugène C. EZIN Ing. Jean-Pierre KOUKPAKI

Directeur de mémoire Directeur de stage

Année Académique : 2016-2017

Dédicace

Mon père Appolinaire TOSSOU

Ma mère Florence GBONSOU

Mes frères et sœurs

i
Remerciements
Remerciements

Je tiens à remercier tous ceux qui ont participé à l’élaboration de ce travail particulièrement :

• tout le personnel administratif de l’Institut de Formation et de Recherche en Informatique

(IFRI),

• monsieur Jean-Pierre KOUKPAKI et Eugène C. EZIN, pour avoir accepté de superviser ce

travail et pour leur conseils et apports à la réalisation du présent document,

• tout le personnel de JTEK-Solutions pour leur esprit d’accueil et leur sens de partage,

• tous mes amis pour leur assistances.

ii
Table des matières

Dédicace i

Remerciements ii

Résumé/Abstract 2

Introduction 4

1 Revue de littérature 6
1.1 Etat de l’art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1.1 Présentation des solutions existantes . . . . . . . . . . . . . . . . . . . . . . 6
1.1.2 Intérêt du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2 Quelques notions utiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.1 e-commerce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.2 e-paiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.3 API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Matériels et méthodes 11
2.1 Matériels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.1 La technologie utilisée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.2 Présentation du SGBD Postgres . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.3 Outils de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Méthodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.1 Présentation de la méthode Scrum . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.2 Présentation du modèle UML . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.3 Présentation des différentes diagrammes . . . . . . . . . . . . . . . . . . . 16

3 Résultats 20
3.1 Architecture générale de l’API eb-pay . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 Sécurité de l’API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.1 Sécurité côté marchand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.2 Sécurité côté client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3 Principales interfaces graphiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

iii
TABLE DES MATIÈRES TABLE DES MATIÈRES

3.3.1 Interface d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.3.2 Formulaire de demande de l’API eb-pay . . . . . . . . . . . . . . . . . . . . 23
3.3.3 Interface de connexion du marchand . . . . . . . . . . . . . . . . . . . . . . 23
3.3.4 Interfaces visualisant les paramètres du marchand . . . . . . . . . . . . . . 23
3.3.5 Interfaces de paiement du client . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3.6 Interfaces de l’administrateur de eb-pay . . . . . . . . . . . . . . . . . . . . 25

Conclusion 27

Bibliographie 28

iv
Table des figures

2.1 Interaction entre Modèle Vue et Contrôleur . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4 Diagramme de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1 Architecture générale de l’API eb-pay . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 Description du processus de génération de la clé du marchand . . . . . . . . . . . 22
3.3 Interface d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4 Formulaire de demande de l’API eb-pay . . . . . . . . . . . . . . . . . . . . . . . . 23
3.5 Interface de connexion du marchand . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.6 Interfaces visualisant les parametres du marchand . . . . . . . . . . . . . . . . . . 24
3.7 Interface de paiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.8 Interface de paiement selon le type de paiement . . . . . . . . . . . . . . . . . . . 25
3.9 connexion de l’administrateur l’API eb-pay . . . . . . . . . . . . . . . . . . . . . . 25
3.10 Interface présentant la liste des demandes de l’API eb-pay . . . . . . . . . . . . . 26

1
 Résumé
Après avoir révolutionné les moyens de transmettre l’information, Internet vient révolution-
ner les pratiques commerciales avec le commerce électronique, en offrant la possibilité de trans-
mettre de l’argent (e-paiement). En effet, le e-paiement (paiement électronique) est un moyen
permettant d’effectuer des transactions commerciales pour l’échange de biens ou de services
sur Internet. Actuellement, il est très bien implanté et utilisé par la majorité des personnes et
entreprises ayant un commerce sur internet.

Cependant, plusieurs moyens de paiement en ligne existent, mais très peu sont adapté au
contexte africain plus particulièrement Béninois. Le présent mémoire vise à mettre en place
un moyen de paiement fiable et sécurisé en Afrique à travers la production d’une API Java
déportée du nom de « eb-pay » destiné au site e-commerce. Cette API utilisera les moyens de
paiement bancaire existants (les cartes bancaires : VISA, MasterCard....).

eb-pay permettra donc de vendre et d’acheter des produits et services dans le monde par
internet. Il garde le choix de l’établissement bancaire du marchand et du client ainsi que les
moyens de paiement acceptés.

Mots clés : eb-pay, e-paiement, e-commerce, API, Java.

2
 Abstract
Having revolutionized the ways to pass on the information, Internet comes to revolutionize
the commercial practices with the e-commerce, by offering the possibility of passing on some
money (e-payment). Indeed, the e-payment (electronic payment) is a way allowing to make
commercial transactions for the exchange of the properties or the services on the Internet. At
present, he is implanted very well and used by the majority of the people and companies having
a trade on the Internet.

However, several on-line means of payment exist, but little are adapted to the African context
more particularly Beninese. The present report aims at setting up a means of payment reliable
and reassured(secured) in Africa through the production of API popular waltz deported by the
name of " eb-pay " intended for the e-commerce site. This API will use the existing banking
means of payment (bank cards: VISA, MasterCard).

eb-pay will thus allow to sell and to buy products and services(departments) in the world
by internet. He(it) keeps(guards) the choice of the banking institution of the trader and the
customer as well as the accepted means of payment.

Key words: eb-pay, e-paiement, e-commerce, API, Java.

Introduction
Le monde connait une avancée technologique dans tous les secteurs d’activités grâce aux
Technologies de l’Information et de la Communications. Cette avancée a atteint le secteur du
commerce. Ce qui nous amène au commerce en ligne (e-commerce) ; qui se définit par l’échange
de biens et services à travers les réseaux informatiques. Cette activité a besoin d’un moyen de
paiement fiable et sécurisé pour se développer. Cependant, en Afrique plus particulièrement
au Bénin, il n’existe presque pas de moyens de paiement en ligne. Le thème de notre mémoire «
Développement d’une API Java de paiement en ligne sur les sites e-commerce », s’inscrit dans
cette dynamique, il s’agira de mettre en place une interface de programmation, en vue d’aider
les promoteurs de site e-commerce d’Afrique, plus particulièrement du Bénin à intégrer un
moyen de paiement sécurisé sur leur site e-commerce.

Problématique
Ce sujet s’intéresse à la difficulté qu’ont les développeurs des applications e-commerce en
Afrique à intégrer un système de paiement fiable à leurs applications. Ce faisant, il met l’accent
sur les contraintes que représente le niveau du paiement électronique pour l’accroissement des
applications e-commerce. Pour ce fait, il propose une API basée sur les moyens de paiement
existant comme les cartes bancaires et paypal. Au regard des difficultés qu’ont les développeurs
dans les moyens de paiement électronique, on peut bien rechercher les avantages liés à la mise
en place d’une telle API.

Objectifs
Réaliser une API pouvant aider les commerçants à intégrer les moyens de paiement en ligne
sur leurs plateformes e-commerce.

Objectifs spécifiques

• Mise en place d’une plateforme web sécurisée

• Gestion comptes marchands (partie marchand /administrateur) :

Ce module central concerne la gestion des marchands par les administrateurs. Il gé-
rera tout ce qui est de l’ordre de la création des comptes marchands, l’enregistrement des
informations du marchand, l’authentification sur le panel d’administration,. . .

Pour avoir un compte, le marchand doit envoyer un mail de demande à l’administra-

teur, qui se chargera de valider ou non la demande.

• Gérer les différentes historiques des transations d’un marchand :

4
 Ce module permettra au marchand de consulter les différentes translations qu’il a eues.

• Paiements par carte bancaire ou transactions bancaires :

Lors du processus d’un achat sur le site du marchand, le client est redirigé vers la plate-
forme eb-pay pour faire le paiement. Il saisit les informations bancaire de sa carte, qui sont
ensuite envoyées à sa banque qui se chargera de débiter son compte. Après la transaction,
nous informons le marchand.

Le présent mémoire fait le point de nos travaux et comporte trois (3) chapitres.
Le premier chapitre intitulé « Revue de littérature » synthétise l’état actuel de la recherche en lien avec
la problématique du sujet afin de montrer à la fin en quoi notre recherche est intéressante et innovante.
Le deuxième chapitre de ce travail intitulé « Matériels et méthodes » est constitué de l’analyse des be-
soins, de la conception du système, des outils de développement et matériels utilisés en vue de la concep-
tion et de la réalisation de la solution proposée
Ce travail s’achève par le dernier chapitre intitulé « Résultats », qui présente les résultats obtenus et plus
précisément les commentaires des captures d’écran et des simulations de l’application ainsi conçue.
Chapitre 1
Revue de littérature

L’objectif d’une revue de la littérature est de résumer l’état de l’art ou de la connaissance dans un
domaine et pour une période ou un territoire.

1.1 Etat de l’art

Pour notre travail avons eu à faire l’etat de l’art :

1.1.1 Présentation des solutions existantes

6
Chapitre 1. Revue de littérature 1.1. Etat de l’art

Il existe une panoplie de solutions de paiement en ligne au nombre desquelles nous pouvons citer :

1.1.1.1 PayPal

PayPal est un service de paiement en ligne qui permet de payer des achats, de recevoir
des paiements, ou d’envoyer et de recevoir de l’argent. Pour bénéficier de ces services, une
personne doit créer un compte puis transmettre diverses coordonnées bancaires à PayPal,
telles que le numéro de carte de paiement. Par la suite, les transactions sont effectuées sans
avoir à re-communiquer ces coordonnées bancaires, une adresse de courrier électronique
et un mot de passe étant suffisants.

1.1.1.2 S-money

S-money est un service permettant, à partir d’un compte de monnaie électronique,

de payer, recevoir et transférer de l’argent instantanément avec son Smartphone. Ce
service de paiement mobile est immédiat, gratuit et sécurisé. C’est aussi une plate-
forme de paiement qui s’adapte à l’activité des professionnels. Son API S-money Pro,
permet la collecte de fonds et l’encaissement pour compte de tiers pour un paiement à distance ou un
paiement de proximité, et s’intègre facilement (cagnotte, crowdfunding, marketplace, m-commerce, . . .).

1.1.1.3 Bluepaid (Europe)

Bluepaid (Europe) est spécialisée dans l’encaissement de compte de

tiers sur Internet Il propose aux e-commerçants, auto-entrepreneurs, ar-
tisans... des outils tels que des pages et des liens de paiement leur per-
mettant d’encaisser en toute sécurité leurs paiements par Internet, de
manière simple. Les cartes encaissées sont les cartes Visa et Mastercard.
Bluepaid permet également d’encaisser des paiements par abonnements.

1.1.1.4 Payzen

Payzen est une solution de paiement en ligne. Elle propose dans sa solution un
nombre important de moyens de paiement (cartes, Prélèvement, Banque en ligne,
financement, wallet..), afin de donner le maximum de choix à vos clients. Vous pou-
vez notamment, intégrer à votre forfait des moyens de paiement privatifs ou des
cartes cadeaux.

1.1.1.5 UniPay

La passerelle UniPay est une solution de paiement en ligne universelle, très robuste et open
source pour le traitement des paiements. C’est aussi un moteur d’orchestration de circula-
tion des paiements ; il est conçu non seulement comme le système de paiement en ligne ou
de la facturation récurrente, mais aussi comme la plate-forme de gestion des relations et

7
Chapitre 1. Revue de littérature 1.1. Etat de l’art

des marchands. UniPay est conçu pour accommoder les besoins des petits marchands dé-
tenant un compte marchand, aussi bien que les gros marchands ayant plusieurs comptes et
les entreprises multimarchand avec un grand nombre des clients, revendeurs et de comptes marchands
associés. C’est aussi une solution préférée de nombreuses organisations de ventes indépendantes (OVIs)
et les fournisseurs de services de paiement (PSP).

8
Chapitre 1. Revue de littérature 1.2. Quelques notions utiles

1.1.2 Intérêt du projet

Ces différentes API de paiement en ligne ne sont pas bien adaptées au contexte africain et ne sont
pas non plus open-source. Le coût de leur acquisition est élevé. Nous nous proposons donc de mettre
à disposition des africains particulièrement les béninois une solution alternative qui évitera le stockage
des informations bancaires des clients. Elle sera développée avec les thechnologies étudiées au cours de
notre formation, notament le Java EE. Voilà ce qui justifie le choix de ce thème.

1.2 Quelques notions utiles

1.2.1 e-commerce
Le e-commerce ou le commerce électronique, un sous ensemble de l’e-business, est l’achat, la vente et
l’échange de biens et de services sur les réseaux informatiques (comme internet) par le biais duquel les
opérations ou les conditions de vente sont exercées par voie électroniques. Contrairement à la croyance
populaire, le commerce électronique n’est pas seulement sur le web. En fait, le commerce électronique est
bien vivant dans les transactions entre entreprise avant le web dans les années 70 par l’intermédiaire de
l’EDI (Electronic Data Interchange) a travers des VAN (Value-Added Networks). E-commerce peuvent
être répartis en quatre catégories principales : B2B1 , B2C2 , C2B3 et C2C4 .

1.2.2 e-paiement
Le e-paiement (paiement en ligne) est un échange d’argent par système électronique. Il s’agit des
paiements que l’on réalise sur Internet ou via des réseaux de télécommunications, générés à partir soit
d’un ordinateur, soit d’un téléphone mobile

1.2.3 API
Une API (Application Programming Interface) est une Interface Applicative de Programmation qui
permet d’établir des connexions entre plusieurs logiciels pour échanger des données. C’est un ensemble
1
B2B : Business-to-Business ,Ceux sont les entreprises qui font affaire avec d’autres, comme les fabricants qui
vendent a des distributeurs et grossistes, qui a leur tour vendent aux détaillants. La tarification est basée sur la
quantité de l’ordre et est souvent négociable
2
B2C : Business-to-consumer , Ceux sont les entreprises vendant au grand public en général grâce a des cata-
logues en utilisant des logiciels panier. En volume en dollars, B2B a la palme, cependant B2C est vraiment ce que
l’utilisateur, a en tête en ce qui concerne le commerce électronique, dans son ensemble.
3
C2B : Consumer-to-Business , Le consumer to business (C2B) est un modèle d’entreprise (business model)
dans lequel les consommateurs (les particuliers) sont au service de l’entreprise en apportant un produit ou une
prestation, et non le contraire comme c’est le cas traditionnellement.
4
C2C : Consumer-to-Consumer , Il existe de nombreux sites offrants de petites annonces gratuites, enchères, et
des forums ou les particuliers peuvent acheter et vendre en ligne grâce au système de paiements tels que PayPal
[2], ou les gens peuvent envoyer et recevoir de l’argent en ligne en toute simplicité. Le service d’enchère d’eBay
est un bon exemple de commerce de personne, des transactions ont lieu tous les jours depuis 1995.

9
Chapitre 1. Revue de littérature 1.2. Quelques notions utiles

normalisé de classes, de méthodes ou de fonctions qui sert de façade par laquelle un logiciel offre des
services à d’autres logiciels.

10
Chapitre 2
Matériels et méthodes

2.1 Matériels

2.1.1 La technologie utilisée

Nous avons eu à utiliser la technologie J2EE1 pour notre dévéloppement avec plusieurs API comme :
Servlet, JSP2 , JavaMail, JPA3

2.1.1.1 Présentation de la technologie J2EE

Le langage Java, développé par Sun, est un langage orienté objet. En effet il possède
un mécanisme qui permet de décrire les caractéristiques d’un objet de façon unique
et de pouvoir lui faire subir des opérations. Le langage Java n’est pas interprété mais
les fichiers java, appelés portant l’extension .java, sont compilés en byte code, fichier
.class, puis lus par ce que l’on appelle une machine virtuelle Java (JVM). Le lan-
gage est donc indépendant de chaque machine, on parle de langage portable. Pour
programmer en Java, il suffit d’installer un JRE(Java Runtime Environement) ou un JDK(Java Develop-
pement Kit) qui comprend un JRE et d’autre outils, une JVM et un simple éditeur de texte. Le langage
JEE, qui peut être considéré comme une extension de Java, est un ensemble de spécifications destinées
aux applications d’entreprises. Ce langage permet la création d’applications performantes et robustes.
JEE s’appuie sur le modèle Modèle Vue Contrôleur (MVC). Le figure ci-après représente l’interaction en
le modèle, la vue et le contrôleur.

1
J2EE : Java Entreprise Edition Version 2
2
JavaServer Pages
3
Java Persistence API

11
Chapitre 2. Matériels et méthodes 2.1. Matériels

F IGURE 2.1 – Interaction entre Modèle Vue et Contrôleur

La couche Vue représente ce que l’utilisateur a sous les yeux. Le modèle peut être divers et varié. C’est
là que se trouvent les données. Il s’agit en général d’un ou plusieurs objets Java. Ces objets s’apparentent
généralement à ce qu’on appelle souvent « la couche métier » de l’application et effectuent des traite-
ments absolument transparents pour l’utilisateur. Par exemple, on peut citer des objets dont le rôle est
de gérer une ou plusieurs tables d’une base de données. La dernière couche permet de faire le lien entre
la vue et le modèle lorsqu’une action utilisateur est intervenue sur la vue.
Cette architecture permet aux développeurs de se concentrer sur la couche métier et au designer de
s’occuper de la vue.

2.1.1.2 Présentation de Servlet

Une servlet est une classe Java qui permet de créer dynamiquement des données
au sein d’un serveur HTTP. Ces données sont le plus généralement présentées au
format HTML, mais elles peuvent également l’être au format XML ou tout autre
format destiné aux navigateurs web. Les servlets utilisent l’API Java Servlet.
Une servlet s’exécute dynamiquement sur le serveur web et permet l’extension
des fonctions de ce dernier, Par exemple : l’accès à.des bases de données, transactions
d’e-commerce, etc. Une servlet peut être chargée automatiquement lors du démarrage du serveur web
ou lors de la première requête du client. Une fois chargées, les servlets restent actives dans l’attente
d’autres requêtes du client.
L’utilisation de servlets se fait par le biais d’un conteneur de servlets (framework) côté serveur. Celui-
ci constitue l’environnement d’exécution de la servlet et lui permet de persister entre les requêtes des
clients. L’API définit les relations entre le conteneur et la servlet. Le conteneur reçoit la requête du client,
et sélectionne la servlet qui aura à la traiter. Le conteneur fournit également tout un ensemble de services

12
Chapitre 2. Matériels et méthodes 2.1. Matériels

standards pour simplifier la gestion des requêtes et des sessions. La version actuelle des spécifications
servlet est la 3.1.

2.1.1.3 Présentation de JSP

Le JavaServer Pages ou JSP est une technique basée sur Java qui permet aux dévelop-
peurs de créer dynamiquement du code HTML4 , XML5 ou tout autre type de page
web. Cette technique permet au code Java et à certaines actions prédéfinies d’être
ajoutés dans un contenu statique. Depuis la version 2.0 des spécifications, la syntaxe
JSP est complètement conforme au standard XML6 . La syntaxe du JSP ajoute des ba-
lises XML, appelées actions JSP, qui peuvent être utilisées pour appeler des fonctions.
De plus, cette technique permet la création de bibliothèques de balises JSP (taglib) qui agissent comme
des extensions au HTML7 ou au XML. Les bibliothèques de balises offrent une méthode indépendante
de la plate-forme pour étendre les fonctionnalités d’un serveur HTTP8 . Il existe aussi un langage de
script particulier, appelé Expression Language (EL) destiné à réduire l’injection de code java au sein
des pages JSP ainsi qu’à étendre les possibilités des taglibs, tel que la JSTL. Les JSP sont compilées par
un compilateur JSP pour devenir des servlets Java. Un compilateur JSP peut créer une servlet Java en
code source Java qui peut à son tour être compilé par le compilateur Java, ou peut créer le pseudo-code
Java interprétable directement. Dans les deux cas, il est bon de comprendre comment le compilateur JSP
transforme la page en servlet Java.

2.1.1.4 Présentation de JPA

La Java Persistence API (abrégée en JPA), est une interface de programmation Java
permettant aux développeurs d’organiser des données relationnelles dans des appli-
cations utilisant la plateforme Java.
La Java Persistence API est à l’origine issue du travail du groupe d’experts JSR9 .
La persistance dans ce contexte recouvre 3 zones :
l’API elle-même, définie dans le paquetage javax.persistence le langage Java Persistence Query (JPQL)
l’objet/les métadonnées relationnelles
La Java Persistence API repose essentiellement sur l’utilisation des annotations, introduites dans Java
5. Elles permettent de définir facilement des objets métier, qui pourront servir d’interface entre la base
de données et l’application, dans le cadre d’un mapping objet-relationnel.

2.1.2 Présentation du SGBD Postgres

4
HyperText Markup Language, est le format de données conçu pour représenter les pages web
5
eXtensible Markup Language est un langage informatique de balisage générique.
6
eXtensible Markup Language est un langage informatique de balisage générique.
7
HyperText Markup Language, est le format de données conçu pour représenter les pages web
8
HyperText Transfer Protocol, est un protocole de communication client-serveur développé pour le World Wide
Web
9
JSP : Java Specification Requests est un système normalisé ayant pour but de faire évoluer la plate-forme Java.

13
Chapitre 2. Matériels et méthodes 2.2. Méthodes

PostgreSQL est un système de gestion de bases de données relationnelles et objet

(SGBDRO). C’est un outil libre disponible selon les termes d’une licence de type
BSD.
Ce système est concurrent d’autres systèmes de gestion de base de données,
qu’ils soient libres (comme MySQL et Firebird), ou propriétaires (comme Oracle, Sy-
base, DB2 et Microsoft SQL Server).

2.1.3 Outils de développement

2.1.3.1 NetBeans IDE Version 8.2

NetBeans IDE est un environnement de développement qui s’adapte aux lan-

gages de programmation (Javascript, Python, PHP10 , Groovy, C/C++, etc.),
aux outils et aux ressources dont vous disposez. Vous pourrez ainsi créer facile-
ment des applications Web, des portails d’entreprise, des logiciels multiplate-
forme sous Java, des logiciels pour mobiles, etc. Vous disposerez de nombreux
outils d’édition, d’un debugger, d’un module de prévisualisation, de modèles
et de bibliothèques, de fonctions de complétion et d’implémentation, etc. La dernière version de Net-
Beans IDE supporte dorénavant les spécifications du langage de développement Java SE 7. Il s’intègre
également avec les serveurs Oracle WebLogic et supporte Oracle Database et GlassFish 3.1. On note au
passage la facilité d’édition HTML5 et un nouveau GridBagLayout conçu pour améliorer le développe-
ment d’interfaces utilisateur et l’édition de code Java.

2.2 Méthodes

Nous avons eu à utiliser différentes méthodes pour notre dévéloppement dont la méthode Scrum et
la modélisation UML11

2.2.1 Présentation de la méthode Scrum

2.2.1.1 Définition

Scrum est une méthode de développement agile orientée projet informatique dont les ressources sont
régulièrement actualisées. La méthode Scrum tire son nom du monde du rugby, (scrum = mêlée). Le
principe de base étant d’être toujours prêt à réorienter le projet au fil de son avancement. C’est une
approche dynamique et participative de la conduite du projet. La mêlée est une phase de jeu essentielle
au rugby. Elle permet au jeu de repartir sur d’autres bases. La réunion dans la méthode Scrum relaie la
métaphore.
10
PHP Hypertext Preprocessor, est un langage de scripts généraliste et Open Source, spécialement conçu pour
le développement d’applications web
11
UML : Unifed Modéling Language

14
Chapitre 2. Matériels et méthodes 2.2. Méthodes

2.2.1.2 Principes de la méthode Scrum

Bien entendu, la méthode Scrum est conforme aux principes des méthodes agiles. Comme toutes les
méthodes agiles, Scrum privilégie la livraison rapide d’un prototype, opérationnel par définition, afin
que les clients, donneurs d’ordre et membres de l’équipe puissent l’évaluer.

Cette démarche participative active est un atout fondamental. Elle garantit pour le client le juste équi-
libre entre l’investissement prévu et le produit finalement livré. L’étude du prototype permet l’évalua-
tion des fonctionnalités réalisées, et facilite la réflexion commune sur l’opportunité de futurs développe-
ments. D’autre part, l’étroite intimité entre les clients utilisateurs et les prestataires développeurs facilite
l’appropriation future de l’outil.

2.2.2 Présentation du modèle UML

Le langage de modélisation unifié, de l’anglais Unified Modeling Language (UML),
est un langage de modélisation graphique à base de pictogrammes conçu pour four-
nir une méthode normalisée pour visualiser la conception d’un système. Il est cou-
ramment utilisé en développement logiciel et en conception orientée objet. Il est le
résultat de la fusion de précédents langages de modélisation objet : Booch12 , OMT13
, OOSE14 . Principalement issu des travaux de Grady Booch, James Rumbaugh et Ivar
Jacobson, UML est à présent un standard adopté par l’Object Management Group (OMG)15 .

UML est utilisé pour spécifier, visualiser, modifier et construire les documents nécessaires au bon
développement d’un logiciel orienté objet et offre un standard de modélisation, pour représenter l’archi-
tecture logicielle. Les différents éléments représentables sont :

• Activité d’un objet/logiciel

• Acteurs

• Processus

• Schéma de base de données

• Composants logiciels

• Réutilisation de composants
12
Booch : de développement de logiciels pour la programmation orientée objet. Elle a été conçue par Grady
Booch qui l’a publiée en 1992 puis révisée en 1994. Elle se compose d’un langage de modélisation graphique, d’un
processus itératif de développement, et d’un ensemble de pratiques recommandées
13
OMT : (en anglais « object modeling technique », c’est-à-dire « technique de modélisation objet ») est une
technique de modélisation destinée à la conception et la modélisation pour la programmation orientée objet. Elle a
été conçue en 1991 par James Rumbaugh, Michael Blaha, William Lorensen, Frederick Eddy et William Premerlani
14
OOSE : OOSE est une méthode pour l’analyse initiale des usages de logiciels, basée sur les « cas d’utilisation
» et le cycle de vie des logiciels, créé par Ivar Jacobson
15
OMG : Object Management Group est une association américaine à but non lucratif créée en 1989 dont l’ob-
jectif est de standardiser et promouvoir le modèle objet sous toutes ses formes

15
Chapitre 2. Matériels et méthodes 2.2. Méthodes

Grâce aux outils de modélisation UML, il est également possible de générer automatiquement tout ou
partie du code d’une application logicielle, par exemple en langage Java, à partir des divers documents
réalisés.

2.2.3 Présentation des différentes diagrammes

2.2.3.1 Identification des acteurs

Un acteur représente un rôle joué par une personne qui interagit avec le système. Par définition, les
acteurs sont à l’extérieur du système. Les acteurs se récrutent parmi les utilisateurs du système et aussi
parmi les responsables de sa configuration et de sa maintenance. Du point vue fonctionnel, les différentes
acteurs de notre système sont :

• le client

• le marchand

• l’administrateur de l’API

2.2.3.2 Diagramme de cas d’utilisation

Les diagrammes de cas d’utilisation sont des diagrammes utilisés pour donner une version globale
du comportement fonctionnel d’un système logiciel. Ils sont utiles pour des présentations auprès de la
direction ou des acteurs d’un projet ; mais pour le développement, les cas d’utilisation sont plus appro-
priés. Un cas d’utilisation représente une unité discrète d’interaction entre un utilisateur (humaine ou
machine) et un système. Il est une unité significative de travail. Dans un diagramme de cas d’utilisation,
les utilisateurs sont appelés acteurs (actors), ils interagissent avec les cas d’utilisation.

16
Chapitre 2. Matériels et méthodes 2.2. Méthodes

F IGURE 2.2 – Diagramme de cas d’utilisation

2.2.3.3 Diagramme des classes

Le diagrammes des classes permet d’exprimer comment les objets et les classes vont être définis, ainsi
que les relations qui existent entre les différentes classes. Il est considéré comme le plus important de la
modélisation orientée objet. Alors que le diagramme des cas d’utilisation montre un système du point
de vue des acteurs, le diagramme de classes en montre la structure interne. Il permet de fournir une
représentation abstraire des objets du système qui vont interagir pour réaliser les cas d’utilisation.

17
Chapitre 2. Matériels et méthodes 2.2. Méthodes

F IGURE 2.3 – Diagramme de classes

2.2.3.4 Diagramme de séquence

Le diagramme de séquence est un diagramme d’interaction qui nous permettra de décrire comment
les éléments du système interagissent entre eux et avec les acteurs :

• Les objets au coeur d’un système interagissent en s’échangeant des messages dans le cadre d’un
fonctionnement particulier du système.

• Les acteurs interagissent avec le système par l’IHM

Les diagrammes de séquences servent à développer en analysant les scénariid’utisation d’un système.

18
Chapitre 2. Matériels et méthodes 2.2. Méthodes

F IGURE 2.4 – Diagramme de séquence

19
Chapitre 3
Résultats

3.1 Architecture générale de l’API eb-pay

L’architecture technique présente les différents outils utilisés dans le développement de chaque partie
du projet. La figure suivante présente l’architecture technique de notre API :

F IGURE 3.1 – Architecture générale de l’API eb-pay

1. L’internaute constitue son panier sur le site e-commerce

2. L’internaute clique sur le bouton "Passer au paiement", le serveur commerçant utilise l’API pour
afficher tous les moyens de paiement acceptés

3. En cliquant sur un de ces moyens de paiement, l’internaute se connecte au serveur de paiement eb-
pay. Le serveur de eb-pay affiche le formulaire approprié pour obtenir ses coordonnées bancaires

20
Chapitre 3. Résultats 3.2. Sécurité de l’API

4. Le serveur de eb-pay effectue une demande d’autorisation auprès d’une institution financière im-
pliquée dans le paiement sélectionné

5. et 5’. Après réception de la réponse d’autorisation, eb-pay envoie la réponse de la demande d’au-
torisation au serveur commerçant et affiche un message de confirmation sur l’écran de l’internaute

6. A partir de ce ticket, l’internaute peut cliquer sur un bouton pour retourner sur le serveur com-
merçant, qui reçoit ainsi toutes les informations concernant la transaction (identique à 5’)

7. eb-pay envoie la transaction pour remise en banque (crédit marchand et débit client)

3.2 Sécurité de l’API

Face au développement du commerce électronique et de ses failles sécuritaires, l’API eb-pay répond
aux besoins de sécurisation des paiements par l’Internet et met à la disposition de tout site marchand, un
terminal de paiement virtuel sécurisé, il utilise le protocole SSL1 pour le cryptage de toutes informations
lors des échanges entre les différents serveurs en jeux (marchand – eb-pay – Banque) avec des codes de
confirmation demandés à un moment donné aux acteurs.

3.2.1 Sécurité côté marchand

Une clé de sécurité, propre à chaque marchand, destinée à certifier les données échangées entre le
serveur du marchand et le serveur de paiement eb-pay, est indispensable pour utiliser le service de
paiement de eb-pay. Un lien, permettant de récupérer cette clé de sécurité, est envoyée par mail ou par
SMS au marchand.

Le marchand peut demander la régénération d’une nouvelle clé, périodiquement ou à l’occasion

d’évènements tels qu’une mise en production, un changement d’hébergeur, un changement de pres-
tataire, etc. Il est de la responsabilité du marchand de conserver cette clé de façon sûre et confidentielle
en exploitant les meilleurs outils disponibles de son environnement.

La clé de sécurité est représentée de façon externe par des caractères hexadécimaux (par exemple :
6A8537ABEAAD34638). Cette clé est généré en cryptant la concaténation de quelques informations spé-
cifiques du marchand avec une clé générée grâce à l’algorithme DES à un instant donné. Le schéma
suivant présente le processus de génération de la clé de sécurité du marchand :

1
Secure Sockets Layer : est un protocole de sécurisation des échanges sur Internet

21
Chapitre 3. Résultats 3.3. Principales interfaces graphiques

F IGURE 3.2 – Description du processus de génération de la clé du marchand

3.2.2 Sécurité côté client

eb-pay n’est pas une Banque, c’est une plateforme de paiement permettant au client de faire un paie-
ment sécurisé de son achat sur un site marchand en transférant l’ordre de paiement de la banque à celle
du marchand. Il ne sauvegarde aucune information bancaire du client, après chaque paiement (validé
ou non), les informations ne sont pas sauvegardé par le serveur de eb-pay. Le marchand ne connaît donc
pas les informations bancaires du client.

3.3 Principales interfaces graphiques

La conception des interfaces de l’application est une étape importante puisque toutes les interactions
avec le cœur de l’application passent à travers ces interfaces, on doit alors guider l’utilisateur avec les
messages d’erreurs et de notification si besoin, ainsi présenter un système complet. Dans cette partie,
nous allons présenter quelques interfaces de l’application, répondant aux recommandations ergono-
miques de compatibilité, de guidage, de clarté, d’homogénéité et de souplesse. Nous avons choisi l’admi-
nistrateur comme utilisateur vu qu’il présente à travers ces interactions la majeure partie des principales
fonctionnalités de l’application.

22
Chapitre 3. Résultats 3.3. Principales interfaces graphiques

3.3.1 Interface d’accueil

Cette interface présente l’eb-pay avec les moyens de paiement acceptés.

F IGURE 3.3 – Interface d’accueil

3.3.2 Formulaire de demande de l’API eb-pay

Cette interface présente le formulaire de demande de l’API eb-pay. Le marchand renseigne les infor-
matons et confirme sa demande par un lien de confirmation qui lui est envoyé par mail.

F IGURE 3.4 – Formulaire de demande de l’API eb-pay

3.3.3 Interface de connexion du marchand

Cette interface présente le formulaire de connexion du marchand à l’API eb-pay.

3.3.4 Interfaces visualisant les paramètres du marchand

Cette interface présente les paramètres du marchand.

23
Chapitre 3. Résultats 3.3. Principales interfaces graphiques

F IGURE 3.5 – Interface de connexion du marchand

F IGURE 3.6 – Interfaces visualisant les parametres du marchand

3.3.5 Interfaces de paiement du client

Cette interface présente le formulaire de paiement d’un client du marchand à travers l’API eb-pay. Ici
le client choisir son type de paiement (carte bancaire ou transaction directe).

F IGURE 3.7 – Interface de paiement

24
Chapitre 3. Résultats 3.3. Principales interfaces graphiques

Apres choix du type de paiement, le formulaire pour récupérer les informations bancaire

F IGURE 3.8 – Interface de paiement selon le type de paiement

3.3.6 Interfaces de l’administrateur de eb-pay

Cette interface présente le formulaire de connexion de l’administrateur l’API eb-pay.

F IGURE 3.9 – connexion de l’administrateur l’API eb-pay

25
Cette interface présente la liste des demandes de l’API eb-pay.

F IGURE 3.10 – Interface présentant la liste des demandes de l’API eb-pay

26
Conclusion
Notre projet de fin d’études consistait en l’étude, l’analyse, la conception et la réalisation d’une API
Java de paiement electronique sur les sites e-commerce. Cette API aidera les développeurs d’application
e-commerce dans leur réalisation.

Ce projet s’est déroulé en quatre phases. Dans la première phase, nous étions amenés à faire une étude
fonctionnelle dont le but était de spécifier et d’analyser les besoins. Dans la deuxième phase nous nous
sommes penchés sur la conception de notre système afin de bien structurer la couche métier de l’appli-
cation. La troisième phase a été consacrée à l’étude technique où l’on a détaillé l’architecture technique
et les outils et les Frameworks utilisés dans le développement. Enfin, la quatrième phase a été consacrée
à la réalisation et à la mise en œuvre des différents modules de notre système.

Ce stage a été pour nous l’occasion de faire le lien entre nos connaissances académiques et le monde
professionnel. En effet, il nous a permis de développer nos compétences techniques, d’approfondir nos
connaissances théoriques et les mettre en pratique. Cette expérience a aiguisé nos capacités d’analyse et
de synthèse, et nous a permis de renforcer nos connaissances concernant l’architecture JEE, notamment
le Framework JSP et l’API JPA.

Enfin, ce stage fut une expérience très enrichissante pour nous aussi bien sur le plan personnel que
professionnel. En effet, il a été l’occasion de découvrir le dynamisme et l’enthousiasme qui caractérisent
l’équipe de JTek-Solutions. Les réunions régulières effectuées avec le directeur de JTek-Solutions nous
ont permis de mettre en œuvre les concepts de gestion de projets acquis à l’IFRI.

27
Bibliographie
[1] Jasinska, Elisa (08/02/2017). JPA et Java Hibernate. , 500 pages ;

[2] Antonio Goncalves (3 mars 2011). Java EE 5. Collection Les cahiers du programmeur, http://www.
editions-eyrolles.com/Livre/9782212126587/java-ee-5 ;

[3] http://www.piloter.org/projet/methode/scrum.htm ; consulté le 15 Avril 2017

[4] https://fr.wikipedia.org/wiki/JavaServer_Pages#Actions_JSP ; consulté le 23 Avril

2017

[5] https://www.jmdoudoux.fr/java/dej/chap-j2ee-javaee.htm ; consulté le 1er Mai 2017

[6] https://fr.wikipedia.org/wiki/UML_(informatique) ; consulté le 16 Mai 2017

[7] https://fr.wikipedia.org/wiki/Architecture_logicielle ; consulté le 16 Mai 2017

28
 29
View publication stats