Rapport Pfe Chichi Amine GL 2022

École nationale supérieure d’informatique et
d’analyse des systèmes
Mémoire de Projet de Fin d’études Pour l’obtention

du titre d’ingénieur d’état en Informatique Filière
Génie Logiciel
Conception et développement d’une passerelle

de paiement OpenBank (PSD2)
Encadré par :
Réalisé par : Pr. BERRADA Bouchra (ENSIAS)
CHICHI Amine M. ZOUITENE Adnane (EFFYIS)
Filière :
Génie logiciel Membres du jury :
Soutenu le : Pr. EL FKIHI Sanae (Présidente - ENSIAS)
04 juillet 2022 Pr. BAINA Karim (Examinateur - ENSIAS)

Pr. BERRADA Bouchra (Encadrante - ENSIAS)
Année universitaire 2021/2022

GL ENSIAS
Dédicace
À mes chers parents

Aucune dédicace ne saurait traduire la profondeur des sentiments d’amour, de fierté
et de joie immense de vous avoir dans ma vie. Que Dieu vous protège et vous procure
une vie pleine de bonheur et de santé.
À mes chères frères, Houcine, Anas, Salma

Merci pour votre amour, votre soutien et vos encouragements. Les mots ne suffisent
guère pour exprimer l’amour, l’attachement et l’affection que je porte pour vous.
À toute ma famille
À toutes les personnes que j’ai connues à l’ENSIAS
À mes meilleurs amis
Veuillez trouver en ce modeste travail l’expression de mon profond attachement et

sincère gratitude
CHICHI Amine
2021/2022 PFE
REMERCIEMENTS
Nous tenons, avant de présenter notre travail, à exprimer notre grande reconnaissance à toutes
celles et ceux qui, de près ou de loin, nous ont accordé leur soutien. Que ces personnes puissent
trouver ici, collectivement et individuellement, l’expression de toute notre gratitude.
Les plus sincères remerciements de notre part sont adressés à M. Omar BENYAHIA et M. Younes
ARAQI HOUSSAINI, directeurs associés d’EFFYIS GROUP,et ce pour la confiance qu’ils nous ont
faite en nous confiant un projet de telle importance. Nous désirons également exprimer nos remer-
ciements à M. Mohamed Ali ESSADAK, Directeur d’EFFYIS GROUP, pour son accompagnement
précieux, ses remarques pertinentes et ses conseils.
Nous adressons nos plus vifs remerciements et toute notre reconnaissance à M. Hamza CHICHI,
M. Mounir LAHRAICHI et M. Mohamed Amine ZAHHAOUI pour l’expérience enrichissante qu’il
nous ont permis de vivre tout au long de notre stage ainsi que pour tous les conseils et tous les
renseignements qu’il nous ont fournis.
Nous voulons également remercier notre encadrant, Mme BERRADA Bouchra, pour sa disponi-
bilité à assurer la supervision et le suivi de ce travail, pour les conseils qu’elle nous a prodigués lors
de nos réunions qui ont été organisées au cours des différentes étapes de la rédaction de ce rapport.
Les échanges que nous avons entretenus nous ont permis de faire évoluer ce présent travail avec un
esprit sûr et pertinent. Nous tenons à la remercier pour les efforts qu’elle a fournis, pour sa disponi-
bilité et plus particulièrement pour ses précieux conseils qui ont largement contribué à enrichir la
qualité de ce travail.
Nous souhaitons de même remercier l’ensemble du corps professoral de l’École Nationale Supérieure
d’Informatique et d’Analyse des Systèmes (ENSIAS) pour leur intérêt accordé à la formation des fu-
turs ingénieurs.
Puissent les membres du jury trouver dans ces lignes l’expression de notre profonde reconnaissance
pour le privilège qu’ils nous accordent par leur acceptation de juger ce travail.
2
GL ENSIAS
RÉSUMÉ
Le rapport suivant porte sur notre projet de fin d’études que nous avons mené au sein du groupe
Effyis. Le projet répond à un besoin initial exprimé par les directeurs du cabinet concernant le dé-
veloppement d’un nouveau moyen de paiement en ligne basé sur l’Open Banking et la norme ISO
20022 ainsi qu’une plateforme administrative dédiée aux différents marchands souhaitant intégrer
ce nouveau système de paiement.
Ce besoin a vu le jour compte tenu de la situation sanitaire durant le COVID 19, ce qui a im-
pliqué une hausse envers l’utilisation des plateformes E-commerce de 3% entre 2019 et 2020. D’où
la nécessité d’innover et concevoir de nouvelles méthodes de paiements plus fiable, plus sécurisé,
mais surtout plus simple afin d’offrir une expérience client réussie. C’est dans ce contexte que le
paiement instantané s’inscrit pleinement dans les tendances actuelles comme étant un moyen de
paiement dématérialisé et sûr, et il présente un intérêt pour tous les participants, notamment les
banques, les prestataires de services de paiement, les commerçants et les clients.
Ainsi, les trois projets dont nous avons assuré la conception et le développement sont tout
d’abord un micro service Ecom qui gère en interaction avec d’autres services déjà mis en place tout
le processus de paiement. Ensuite une plateforme administrative dédié au marchant dont le but
est de fournir toutes sortes d’informations sur les performances de son site e-commerce en combi-
nant ses données e-commerce avec ses données financières. Ainsi qu’une vue globale de ses perfor-
mances commerciales : commandes, chiffre d’affaires, bénéfice, frais de commission, taille moyenne
des commandes. Et un portail adresser aux développeurs sous forme d’une documentation pour
faciliter aux développeurs le process d’intégration du nouveau système de paiement au sein des sites
e-commerce ainsi qu’une description détaille des APIs.
L’application est implémentée en utilisant le framework Spring Boot côté serveur ainsi que
Spring Cloud pour une architecture micro-services, React JS et ApexChart côté client pour la visua-
lisation des différents graphiques, un Serveur IBM local pour le déploiement et une base de données
Postgres. À noter que la méthodologie suivie pendant la réalisation de ce projet était une approche
Agile dans le cadre de Scrum.
Mots-clés : Passerelle de paiement, Open Banking, ISO 20022, AISP, PISP, Spring Boot, Spring Cloud,
React JS, ApexChart, Agile, Scrum.
2021/2022 PFE
GL ENSIAS
ABSTRACT
The following report is about our end of studies project that we conducted within the Effyis
group. The project responds to an initial need expressed by the directors of the firm concerning the
development of a new means of online payment based on Open Banking and the ISO 20022 standard
as well as an administrative platform dedicated to the various merchants wishing to integrate this
new payment system.
This need has emerged given the health situation during COVID 19 which implied an increase
towards the use of E-commerce platforms of 3% between 2019 and 2020.hence the need to innovate
and design new payment methods more reliable more secure but above all simpler in order to offer
a successful customer experience. It is in this context that instant payment is fully in line with
current trends as a dematerialized and secure payment method, and it is of interest to all participants,
including banks, payment service providers, merchants and customers.
Thus, the three projects that we have designed and developed are first of all an Ecom micro
service that manages the entire payment process in interaction with other services already in place.
Then an administrative platform dedicated to the merchant whose goal is to provide all kinds of
information on the performance of its e-commerce site by combining its e-commerce data with its
financial data. As well as a global view of his commercial performance : orders, turnover, profit,
commission fees, average order size. And a developer portal in the form of a documentation to
facilitate the process of integrating the new payment system into e-commerce sites as well as a
detailed description of the APIs.
The application is implemented using the Spring Boot framework on the server side as well as
Spring Cloud for a microservices architecture, React JS and ApexChart on the client side for the
visualization of the different graphs, a local IBM Server for the deployment and a Postgres database.
Note that the methodology followed during the realization of this project was an Agile approach in
the framework of Scrum.
Keywords : Payment Gateway, Open Banking, ISO 20022, AISP, PISP, Spring Boot, Spring Cloud,
React JS, ApexChart, Agile, Scrum.
2021/2022 PFE
GL ENSIAS
LISTE DES ABRÉVIATIONS
PSD2 : Payment Services Directive Two
TPP : Account Servicing Payment Service Provider
ASPSP : Account Servicing Payment Service Provider
PSU : Payment Services User
AISP : Account Information Service Provider
PISP : Payment Initiation Service Provider
PAIN : Payments Initiation
VPS : Virtual Private Server
DNS : Domain Name System
IDE : Integrated Development Environment
JSON : Java Script Object Notation
JWT : JSON Web Token
NPM : Node Package Manager
REST : Representational State Transfer
2021/2022 PFE
GL ENSIAS
TABLE DES FIGURES
1.1 Logo d’Effyis Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2 Fiche signalétique d’Effyis Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3 Organigrame d’Effyis Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.4 Schématisation des secteurs d’activités d’Effyis Group . . . . . . . . . . . . . . . . . 18
1.5 Passerelle de paiement traditionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.6 AISP workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.7 PISP workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.8 Méthodologie SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.9 Logo Trello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.10 Tableau de bord Trello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.11 Exemple de User Story . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.12 Logo Slack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.13 Logo OnlineGantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.14 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.15 Liste des tâches diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.16 Tableau de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.1 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.2 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.1 Architecture microservices spring boot . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.2 Architecture technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.3 Architecture technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.4 Connexion via ssh vers la machine virtuelle . . . . . . . . . . . . . . . . . . . . . . 47
3.5 Table Recharge du service «Switch»visualisée à partir de PgAdmin4 . . . . . . . . . 47
3.6 Table product_item du service «Ecom» visualisée à partir de PgAdmin4 . . . . . . . 48
2021/2022 PFE
4.1 Diagramme de Séquence d’authentification . . . . . . . . . . . . . . . . . . . . . . . 51
4.2 Diagramme de Séquence de récupération des revenues. . . . . . . . . . . . . . . . . 52
4.3 Diagramme de Séquence de la génération d’un Barchart des revenus. . . . . . . . . 53
4.4 Diagramme de Séquence de la génération d’un piechart représentant les status des
commandes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.5 Diagramme de Séquence : tableau de la liste détaillée des commissions. . . . . . . . 55
4.6 Diagramme de Séquence du processus de paiement E-commerce. . . . . . . . . . . . 56
4.7 Diagramme de classe du Microservice «Ecom» . . . . . . . . . . . . . . . . . . . . . 57
4.8 Préparation du Pain.001 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.9 Diagramme de classe du Microservice «Switch» . . . . . . . . . . . . . . . . . . . . 58
5.1 Logo Spring Boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.2 Logo Spring Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.3 Logo React JS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.4 Logo Material UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.5 Logo ApexCharts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.6 Logo PostreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.7 Logo JUnit 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.8 Logo Mockito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.9 Logo Intellij IDEA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.10 Logo Visual Studio Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.11 Logo Postman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.12 Logo Gitlab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.13 Logo Grafana . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.14 Logo Prometheus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.15 Interface d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.16 Interface Portail développeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.17 Interface Liste des plugins supportés . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.18 Interface Intégration du plugin sur WooCommerce . . . . . . . . . . . . . . . . . . 69
5.19 Interface Documentation de l’api d’authentification . . . . . . . . . . . . . . . . . . 70
7
5.20 Interface Ajouter un compte bancaire . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.21 Interface Authentification et confirmation auprès de la banque . . . . . . . . . . . . 71
5.22 Interface Consulter l’historique des transactions . . . . . . . . . . . . . . . . . . . . 72
5.23 Interface authentification au tableau de bord marchand . . . . . . . . . . . . . . . . 72
5.24 Interface Consulter le chiffre d’affaire, le panier moyen mensuel et les balances . . . 73
5.25 Interface consulter le chiffre d’affaire de l’année et la semaine sous forme d’un BarChart 74
5.26 Interface consulter les statuts des commandes et canaux de paiement utilisé sous
forme de PieChart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.27 Interface consulter la liste des commandes détaillée sous forme d’un tableau paginé 75
5.28 Interface consulter la liste des commandes détaillée sous forme d’un tableau paginé
et filtré par statut et date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.29 Interface consulter l’historique détaillé des commissions facturées sous forme d’un
tableau paginé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.30 Documentation Swagger de l’API Platforme (1) . . . . . . . . . . . . . . . . . . . . . 77
5.31 Documentation Swagger de l’API Platforme (2) . . . . . . . . . . . . . . . . . . . . . 77
5.32 Documentation Swagger de l’API Ecom . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.33 Interface détails de la commande au sein du site marchand . . . . . . . . . . . . . . 79
5.34 Interface détails de la transaction au sein de notre passerelle de paiement . . . . . . 80
5.35 Interface choix de la banque au sein de la passerelle de paiement . . . . . . . . . . . 81
5.36 Interface récapitulatif de la transaction avant la redirection vers le site de la banque 81
5.37 Interface authentification auprès de la banque précédemment sélectionnée . . . . . 82
5.38 Interface choix du compte bancaire pour effectuer le paiement . . . . . . . . . . . . 82
5.39 Interface récapitulatif de la transaction et confirmation du paiement . . . . . . . . 83
5.40 Interface redirection vers la page "paiement effectué avec succès" . . . . . . . . . . 83
5.41 Interface login dashboard Graphana Prometheus . . . . . . . . . . . . . . . . . . . 84
5.42 Interface dashboard de monitoring Graphana Prometheus . . . . . . . . . . . . . . . 84
8
GL ENSIAS
TABLE DES MATIÈRES
Table des figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Introduction générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1 Contexte général du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.1.1 Effyis Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.1.2 Organisation d’Effyis Group . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.1.3 Secteurs d’activités d’Effyis Group . . . . . . . . . . . . . . . . . . . . . . . 17
1.2 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.2.1 Présentation de la passerelle de paiement . . . . . . . . . . . . . . . . . . . 18
1.2.2 Les types de passerelle de paiement . . . . . . . . . . . . . . . . . . . . . . . 19
1.2.3 Fonctionnement d’une Passerelle de Paiement . . . . . . . . . . . . . . . . 19
1.2.4 L’Open Banking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.2.5 Paiements en Open Banking . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.2.6 La norme ISO 20022 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.2.7 AISP & PISP dans l’Open Banking . . . . . . . . . . . . . . . . . . . . . . . 22
1.2.8 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.2.9 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.3 Méthodologie de gestion de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.3.1 Choix de la méthodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.3.2 Présentation de la méthodologie Scrum . . . . . . . . . . . . . . . . . . . . . 26
1.3.3 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.4 Planification du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.4.1 Diagramme de GANTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2 Etude fonctionnelle et analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . 33
2.1 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2021/2022 PFE
2.1.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.1.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.2 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.2.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.2.2 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.2.2.1 Portail développeur SandBox : . . . . . . . . . . . . . . . . . . . . 36
2.2.2.2 Tableau de bord marchand : . . . . . . . . . . . . . . . . . . . . . 38
3 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.1 Architecture Logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.1.1 Coté serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.1.1.1 Architecture microservices . . . . . . . . . . . . . . . . . . . . . . 42
3.2 Architecture Technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.3 Architecture de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.1 Conception globale de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.1.1 Conception du Microservice «Ecom» . . . . . . . . . . . . . . . . . . . . . . 51
4.1.1.1 Diagramme de séquence : . . . . . . . . . . . . . . . . . . . . . . . 51
4.1.1.2 Diagramme de classe : . . . . . . . . . . . . . . . . . . . . . . . . 56
4.1.2 Conception du Microservice «Platform» . . . . . . . . . . . . . . . . . . . . 57
4.1.2.1 Diagramme de séquence : . . . . . . . . . . . . . . . . . . . . . . . 57
4.1.3 Conception du Microservice «Switch» . . . . . . . . . . . . . . . . . . . . . 58
4.1.3.1 Diagramme de classe : . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5 Mise en oeuvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.1 Outils et technologies utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.1.1 Spring Boot - Spring cloud : . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.1.2 React JS : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.1.3 Material UI : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.1.4 ApexCharts : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
10
5.1.5 PostreSQL : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.1.6 Junit 5 & Mockito : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.1.7 Intellij IDEA : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.1.8 Visual Studio Code : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.1.9 Postman : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.1.10 Gitlab : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.1.11 Grafana : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.1.12 Prometheus : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.2 Interfaces graphiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.2.1 Portail développeur : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.2.2 Tableau de bord marchand : . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.2.3 Documentation des APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.2.4 Processus de paiement depuis un site E-commerce : . . . . . . . . . . . . . 79
5.2.5 Monitoring des machines virtuelles : . . . . . . . . . . . . . . . . . . . . . . 84
5.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
11
GL ENSIAS
INTRODUCTION GÉNÉRALE
Au fil des âges, les gens ont pratiqué le commerce pour échanger des biens et des services contre
une rémunération. Ces transactions financières n’ont pas toujours impliqué des paiements moné-
taires. Il fut un temps où l’argent standard n’existait même pas et où les gens utilisaient d’autres
formes de paiement pour effectuer des transactions. Avec l’évolution de la technologie, l’argent et
les paiements ont radicalement changé. La technologie actuelle de traitement des virements et les
solutions commerciales avancées rendent les transactions financières possibles à tout moment et en
tout lieu.
L’arrivée d’Internet dans les foyers a permis le développement à grande vitesse du e-commerce,
soit la possibilité d’acheter et payer en ligne pour tout type de produit. Tandis que certains ont
lancé leurs activités de vente uniquement en ligne, d’autres marchands ont dû s’adapter et ont lancé
eux aussi leur site web et leur catalogue en ligne. Les acteurs du paiement se sont donc adaptés en
conséquence, notamment Authorize.Net qui en 1996 permette pour la première fois aux commer-
çants d’accepter les paiements par carte de crédit et par chèque électronique par le biais de leur site
web et d’une connexion IP, le paiement électronique est désormais possible.
Nous avons tous constaté que les modes de paiement traditionnels ont été remplacés par diffé-
rents types de paiement électronique qui sont rapides et efficaces. Dans le processus du paiement
électronique, l’acheteur et le vendeur utilisent des modes numériques pour envoyer ou recevoir de
l’argent. C’est un processus automatique qui permet au vendeur et à l’acheteur d’éviter de se rendre
à leur banque. Il élimine l’argent physique qui est parfois risqué à manipuler à certains moments. Au-
jourd’hui, les consommateurs peuvent effectuer des paiements par voie électronique en utilisant des
cartes ou bien directement leurs comptes bancaires à travers l’Open Banking et d’autres plateformes
qui sont mises à disposition par tous les types d’appareils intelligents.
Aussi, les banques européennes et les prestataires de services de paiement s’adaptent-elles au

changement des normes et standards de paiement pour offrir a ses clients qui utilisent de plus en
plus le paiement électronique, de nouvelles méthodes de paiements électroniques innovantes et plus
sécurisées. Ce travail de projet de fin d’études s’inscrit dans le but de développer un nouveau moyen
de paiement basée sur l’Open banking et la norme ISO 20022 et assurant des virements instan-
tané, ce système pourra être rapidement intégrable au niveau des sites E-commerce à travers des
plugins. De plus un marchant pourra piloter son site e-commerce et prendre des décisions stra-
tégiques en se basant sur les statistiques présentes dans le tableau de bord administratif "Effyis for
merchant".Finalement un siteWeb dédié aux développeurs souhaitant intégrer cette solution de paie-
2021/2022 PFE
ment bénéficierons d’une documentation détaillé des étapes à suivre ainsi qu’une documentation des
différentes API’s.
Le présent rapport présente en détail notre projet de fin d’études et comporte quatre chapitres :
• Le premier décrivant le contexte général du projet, en commençant par une présentation de

l’organisme d’accueil, puis la problématique traitée et les objectifs visées pour la bonne conduite du
projet.
• Le deuxième chapitre aborde la phase d’analyse et de spécifications des besoins, il a pour but
d’analyser l’existant et de citer les besoins de notre application.
• Pour le troisième chapitre, son objectif est de traiter l’étude technique qui a pour objectif de
proposer une architecture logicielle permettant une meilleure structuration des microservices.
• Le quatrième chapitre présente une conception détaillée de chaque microservice en se basant

sur les approches d’UML.
• Pour enfin aboutir au dernier chapitre qui expose la mise en œuvre du portage réalisé. Il
définit en premier lieu les outils utilisés dans chacun des microseriveces du projet, avant de présenter
quelques interfaces illustrant la solution réalisée.
13
Chapitre 1 Contexte général du projet
CHAPITRE 1
CONTEXTE GÉNÉRAL DU PROJET
Génie Logiciel PFE 2021/2022 - Effyis

Introduction
Au cours de ce chapitre, nous allons nous intéresser tout d’abord à la présentation du cadre
de notre projet. Il s’agit en effet d’une présentation du cabinet pour lequel ce travail a été réalisé.
Nous exposerons le sujet du travail qui nous a été confié ainsi que l’environnement qui a servi à son
achèvement.
Après l’exposition de la problématique, nous citerons les objectifs déterminés et nous présen-
terons ensuite la solution proposée. Enfin, nous clôturerons ce chapitre par une présentation de la
méthodologie de gestion du projet adaptée.
1.1 Présentation de l’organisme d’accueil
1.1.1 Effyis Group
Effyis Group est un cabinet de conseil en management et en technologie indépendant qui ac-
compagne les entreprises et les institutions dans leurs réflexions et projets de transformation. Le
cabinet propose des services de prestation à forte valeur ajoutée couvrant les trois grandes phases
de la transformation : réflexion stratégique, mise en œuvre et pérennisation du changement. Ces
prestations ont toutes été packagées dans le cadre de solutions pertinentes permettant de garantir la
satisfaction des clients grâce aux expertises pointues développées par leur large réseau international.
Figure 1.1 – Logo d’Effyis Group
Effyis Group est une Digital Factory présente dans deux pays : France et Maroc proposant
des offres personnalisées, avec un ensemble de plus de cinquante de consultants qui interviennent
exclusivement sur les problématiques des projets de transformation digitale en banque et assurance.
Nous présentons ci-dessous la fiche signalétique d’Effyis Group :
Génie Logiciel 15 PFE 2021/2022 - Effyis

Figure 1.2 – Fiche signalétique d’Effyis Group
1.1.2 Organisation d’Effyis Group
Les ressources au sein du cabinet sont réparties selon deux fonctions :
• La fonction Management : Administrative.
• La fonction Professionelle : Technique.
La constitution des équipes ne suit pas une règle de configuration immuable, les équipes sont consti-
tuées en fonction de la nature de la mission, sa durée et son niveau de complexité.
Chaque échelon supervise les tâches du niveau inférieur et reporte au niveau supérieur. Par défaut,
la mission est réalisée sous la supervision du manager, qui reporte à l’associé, qui lui-même en est
responsable devant le client.
Afin d’éclaircir l’architecture des moyens humaines au sein du cabinet, nous présentons l’organi-
grame suivant :

Figure 1.3 – Organigrame d’Effyis Group
1.1.3 Secteurs d’activités d’Effyis Group
• Banque : L’expertise du cabinet couvre le secteur des banques de détail (expérience client,
multicanal. . .), du corporate banking (cash management, financement. . .), de la banque privée (pri-
vate equity. . .), des banques d’investissement et des banques participatives. De plus, l’approche adop-
tée par le cabinet est transverse à tous les métiers bancaires et englobe autant les activités commer-
ciales (front office) qu’opérationnelles et administratives (back et middle office).
• Paiement : Le domaine de la monétique et des paiements est en mouvement permanent :

Banques, établissements de paiement, fintechs, grands remettants, startups travaillent tous sur l’amé-
lioration continue de leurs offres de produits et de services afin de proposer des parcours plus inno-
vants à leurs clients.
Effyis est au cœur de cette mutation et se positionne comme leader incontournable dans l’accompa-
gnement de bout en bout de l’ensemble de l’écosystème des paiements.
• Industrie : Le secteur industriel est soumis à des contraintes sensibles, de la gestion des ins-
tallations à l’analyse et l’optimisation des coûts, en passant par l’augmentation de la productivité, il
doit donc constamment se réinventer et évoluer afin que ses entreprises soient et restent compéti-
tives.
C’est dans cette optique qu’Effyis se propose d’accompagner les entreprises du tissu économique in-
dustriel, et notamment celles du secteur pharmaceutique, de l’automobile, des télécoms et du trans-
port, afin de maximiser leur rentabilité et croissance, en parfaite adéquation avec les technologies
de demain.

• Assurance : Le secteur de l’assurance doit faire face, à l’instar de tant d’autres, à de profonds
changements, avec comme principal facteur la révolution digitale, qui fait désormais partie inté-
grante de son écosystème.
Effyis, se propose donc d’aider les compagnies à s’adapter à cette mutation du paysage de l’assu-
rance à travers 4 leviers principaux, à savoir la stratégie, l’organisation, la transformation digitale
et l’innovation, afin de pouvoir face à toutes ces mutations et d’appréhender le futur d’une manière
sereine.
Figure 1.4 – Schématisation des secteurs d’activités d’Effyis Group
1.2 Présentation du projet
1.2.1 Présentation de la passerelle de paiement
Une passerelle de paiement est décrite comme une solution intermédiaire pour les clients entre
un e-commerce (commerce en ligne) et un fournisseur de paiement. Ainsi, une passerelle de paiement
en ligne est utilisée lorsqu’un client visite un site de commerce électronique et saisit ses informations
bancaires sur le dispositif de paiement du site. La fonction principale de la passerelle de paiement
est de transmettre de manière sécurisée les données bancaires au processeur de paiement.

1.2.2 Les types de passerelle de paiement
Il existe deux types de passerelles de paiement : les passerelles auto-hébergées et les passerelles
hébergées :
— Les passerelles de paiement auto-hébergées : exigent que le consommateur soumette ses

informations bancaires sur un site de commerce électronique, qui sont ensuite communiquées
à la passerelle de paiement.
— Passerelles de paiement non hébergées : Lorsqu’un consommateur paie un service ou un

produit, le site web le conduit à une page externe où il peut saisir ses informations bancaires.
Une fois les données saisies, le consommateur sera renvoyé sur le site web de l’entrepreneur.
1.2.3 Fonctionnement d’une Passerelle de Paiement
Les étapes ci-dessous expliquent comment les paiements en ligne fonctionnent avec une passe-
relle de paiement traditionnelle :
— Première étape : Pour accepter des paiements en ligne, il faut commencez par configurer son
site web et le connecter à une passerelle de paiement.
— Deuxième étape : le = client effectue un achat sur le site web en cliquant sur le lien de
paiement et en saisissant les données de sa carte de crédit ou de débit.
— Troisième étape : La commande et les détails de la carte sont envoyés à la passerelle de paie-
ment. Les informations relatives à la carte sont transmises de manière sécurisée à la passerelle
de paiement, de sorte que seuls le client et sa banque pourront accéder aux détails de sa carte.
— Quatrième étape : Ensuite, la passerelle de paiement vérifie les données de la carte du client
et vérifie s’il dispose de fonds suffisants pour effectuer le paiement. Si c’est le cas, la passerelle
de paiement procède à la transaction. En outre, la passerelle de paiement empêche les activités
frauduleuses à l’aide d’outils anti-fraude.
— Cinquième étape : La passerelle de paiement prend ensuite le relais et envoie une demande
à la banque émettrice du client pour lancer la transaction. La banque émettrice envoie ensuite
les fonds à la banque du commerçant qui les dépose sur le compte du commerçant.

Figure 1.5 – Passerelle de paiement traditionnelle
Les quatres grands acteurs d’un flux de paiement en ligne à travers une passerelle de
paiement :
— Le marchant : entreprise en ligne offrant un produit ou un service aux clients
— Le client : également appelé titulaire de la carte, qui souhaite accéder aux produits ou services
vendus par le commerçant et qui initie la transaction.
— La banque émettrice : est la banque du client qui émet la carte de crédit ou de débit du
titulaire de la carte pour le compte des systèmes de cartes (Visa, Mastercard).
— L’acquéreur : également appelé banque acquéreuse, l’acquéreur est l’institution financière

qui gère le compte bancaire du commerçant (appelé compte du commerçant). La banque ac-
quéreuse transmet les transactions du commerçant à la banque émettrice pour recevoir le
paiement.
1.2.4 L’Open Banking
Ce système vise à permettre aux banques d’échanger des données avec d’autres acteurs du sec-
teur financier, y compris les "fintechs". Il peut s’agir d’informations telles que l’emplacement géo-
graphique des agences bancaires et des distributeurs automatiques de billets, les services financiers
proposés dans tel ou tel établissement, ainsi que des informations sur les clients. Le règlement gé-
néral sur la protection des données (RGPD), quant à lui, oblige les banques à faire preuve d’une ou-
verture totale sur les transactions commerciales impliquant les données financières de leurs clients,

comme les dépôts, les transferts et autres activités de routine. La législation stipule que ces don-
nées ne peuvent être utilisées qu’avec l’accord préalable des clients, et qu’elles doivent être libres,
particulières, et le résultat d’une activité (signature, validation de documents, etc.).
Les responsabilités en matière de sécurité des données personnelles stipulées dans le cadre de
la loi française sur la protection des données s’appliquent aux banques ainsi qu’aux tiers tels que
les agrégateurs de services bancaires. L’Open Banking fait également référence à l’utilisation des
API (interfaces de programmation d’applications), qui permettent aux développeurs, par exemple,
de créer de nouvelles applications et de nouveaux services pour les institutions financières. C’est
une petite révolution dans l’environnement financier, où auparavant toutes les informations étaient
compartimentées et gardées.
1.2.5 Paiements en Open Banking
Les paiements sont en train d’être refondus en faveur des commerçants et de leurs consomma-
teurs grâce à l’open banking. La loi PSD2 a été mise en œuvre par l’UE en 2018, dans le but d’accroître
la concurrence dans les services financiers et de moderniser les infrastructures de paiement. Cela
nécessite la création d’un nouveau type d’entreprise de paiement capable de fournir des transactions
A2A (de compte à compte) dans toute l’Europe.
Les fournisseurs de services d’information sur les paiements (PISP) accèdent aux comptes ban-
caires des particuliers et des entreprises directement via les API des banques. Ils peuvent ainsi dé-
placer l’argent directement entre les comptes, sans autre intermédiaire.
Comparez cela aux paiements par carte. Les transactions par carte passent par une chaîne de
plusieurs entreprises. Il s’agit généralement d’une passerelle de paiement, d’un acquéreur et d’un
processeur, ainsi que d’un système de cartes et de la banque du client. Le règlement des transactions
par carte prend plusieurs jours et entraîne des frais pour chaque intermédiaire, ce qui réduit les
marges du commerçant.
Les paiements A2A via l’open banking peuvent avoir des coûts par transaction nettement in-
férieurs à ceux des paiements par carte. Ceci est dû au fait que les paiements A2A contournent
complètement l’infrastructure des cartes et les coûts qui y sont associés.
1.2.6 La norme ISO 20022
La norme ISO 20022, est une norme internationale pour l’échange de messages électroniques
entre institutions financières. Introduite pour la première fois en 2004, l’ISO 20022 a été créée pour

donner au secteur financier une plate-forme commune pour développer des messages en utilisant
une méthodologie de modélisation, un dictionnaire central et un ensemble de messages XML.
L’ISO 20022 est bien plus qu’un changement de format de message. Les paiements en temps
réel ISO 20022 permettent aux banques et à leurs clients de profiter des avantages de l’open banking
pour les paiements dans l’ensemble du paysage informatique. ISO 20022 contient davantage de don-
nées qui peuvent être intégrées pour fournir une meilleure vue à 360° des parcours des clients, par
exemple de banque à banque. Si ces données précieuses sont traitées comme telles en intégrant ces
informations à d’autres systèmes, ces données de paiement peuvent réduire les risques et fournir
de nouvelles sources de revenus aux banques. L’intégration des paiements aux outils KYC peut ré-
duire le risque d’exploitation des services bancaires et de fraude, tout en favorisant des règlements
et des prévisions de trésorerie plus rapides, voire instantanés. Les systèmes et les services peuvent
être intégrés pour fournir des informations précieuses sur les activités des clients, qui peuvent être
produites et commercialisées.
1.2.7 AISP & PISP dans l’Open Banking
— AISP (Account Information Service Provider) : Être un AISP autorisé signifie qu’une
entreprise peut accéder aux données du compte bancaire d’une personne auprès de son ins-
titution financière avec son consentement explicite. Cependant, les AISP n’ont qu’un accès
en "lecture seule". En gros, ils peuvent consulter les informations relatives aux comptes ban-
caires, mais ne peuvent pas y toucher, ce qui signifie qu’ils ne peuvent pas déplacer l’argent
d’un client.
Figure 1.6 – AISP workflow

— PISP (Payment Initiation Service Providers) : Les entreprises qui sont des PISP autorisés
peuvent non seulement consulter les données financières des consommateurs sur un compte
bancaire, mais elles sont également autorisées à effectuer des paiements au nom du client.
Cela a conduit certains commentateurs du secteur à dire que les PISP ont un accès en "lecture-
écriture".
Figure 1.7 – PISP workflow
1.2.8 Problématique
Les cartes de débit et de crédit sont depuis longtemps l’option de paiement par défaut - et souvent
la seule - dont disposent les consommateurs de commerce électronique au Royaume-Uni et dans la
plupart des pays européens. Les paiements par carte de débit ont éclipsé les espèces en tant que
méthode de paiement la plus populaire dans toutes les transactions au Royaume-Uni en 2017, avec
15,8 milliards de paiements par carte de débit au Royaume-Uni seulement en 2020.
Cependant, Amazon a déclaré en novembre 2021 qu’il n’accepterait plus les achats par carte
de crédit Visa. Alors qu’Amazon continuera à accepter les paiements par carte de débit Visa - ainsi
que les paiements par carte d’autres fournisseurs - c’est la première fois qu’un magasin de la taille
d’Amazon prend une telle mesure.Pourquoi Amazon a-t-il fait ce choix maintenant, surtout quand
les cartes de crédit sont si largement acceptées ? La question est que la technologie vieillissante
des cartes, qui a été conçue pour le monde réel, pose de nombreux problèmes aux entreprises de
commerce électronique.
Amazon a identifié les coûts exorbitants comme le principal facteur, mais d’autres problèmes

tels que la fraude par carte non présentée, l’abandon d’achat et les difficultés de rétrofacturation
sont également une source de préoccupation.
Bien que les paiements par carte soient soumis à d’importantes restrictions, ils restent l’option
de paiement la plus populaire. Pourquoi devrions-nous croire que d’autres mécanismes de paiement
sont prêts à menacer la domination des cartes ?
Lors des achats en ligne, l’open banking offre un avantage. Les paiements effectués à l’aide de
l’open banking sont plus rapides, plus simples et plus sûrs que les paiements par carte. Vous n’avez
pas à saisir physiquement les informations relatives à votre carte de crédit ou à compter sur un site
web pour les conserver pour vous. Il vous suffit de choisir votre banque parmi une sélection et de
confirmer la transaction avec votre identification (le détaillant ne peut pas enregistrer vos informa-
tions de paiement). Cela réduit efficacement la fraude.
Les paiements en Open Banking pour les commerçants :
— Sont moins coûteux car il n’y a pas de frais de traitement des cartes service aux clients
— Se règlent plus rapidement que les cartes (instantanément contre 1 à 3 jours)
— Ils se convertissent jusqu’à 40 % mieux que les cartes car ils sont conçus pour une utilisation
numérique et mobile, la procédure est moins laborieuse et les taux de réussite des paiements
sont plus élevés.
C’est dans ce cadre où s’inscrit notre projet de création d’un d’une nouvelle méthode de paie-
ment en ligne basée sur l’Open Banking et la norme ISO 20022 permettant aux marchands d’inté-
grer cette solution comme méthode de paiement au sein de leurs sites E-commerce et piloter leurs
activités depuis leurs tableau de bord marchant ainsi qu’une Sandbox de documentation pour les
développeurs.
1.2.9 Objectifs
Les objectifs de ce projet se traduisent dans la création d’un d’une passerelle de paiement pour
les E-commerçants plus performante et sécurisé mais surtout moins coûteuse et une plate-forme de
monitoring dédiées à ces derniers pour gérer leurs activités d’une manière stratégique et simple afin
d’évoluer leurs business.
Les objectifs majeurs, dont nous avons été mené de réaliser, se résument dans :
— La création d’un service Ecom assurant le processus de paiement de bout en bout.

— La création d’un tableau de bord conçu pour la visualisons des KPIs métier liées aux activités
du marchant.
— La Visualisation des différents graphes représentants les statistiques détaillées de l’activité

commercial du marchant.
— La Visualisation des différents métriques représentants les commissions facturées à la valeur

de la transaction
— La création d’un portail développeur conçu pour documenter nos APIs et accompagner les
futurs utilisateur à intégrer notre passerelle de paiement dans leurs site web.
— Implémenter des outils de pilotage et monitoring afin de surveiller les machines hébergeant
nos différentes applications.
1.3 Méthodologie de gestion de projet
1.3.1 Choix de la méthodologie
La nature et la taille du projet sont des critères capitaux afin de déterminer le choix de la mé-
thodologie à suivre.
Par exemple, pour les petits projets maîtrisés, un seul cycle de vie en cascade suffit. Alors que
lorsqu’il s’agit d’un projet où les données ne sont pas collectées dès le départ, où le besoin est in-
complet et peu clair, il faut se tourner vers une approche itérative.
Parmi les méthodes itératives, nous pouvons distinguer les méthodes AGILE largement utilisées
de nos jours à travers le monde.
Une approche AGILE est mise en œuvre dans un esprit collaboratif qui s’adapte aux approches
incrémentales, assurant ainsi une bonne communication avec le client tout en tenant compte de leurs
besoins changeants avec une meilleure visibilité du produit livrable. Elle permet également d’avoir
une gestion permanente de la qualité pour détecter les problèmes dès qu’ils surviennent, permettant
ainsi de prendre des actions correctives sans pénalité de coût et de délais.
Parmi les nombreuses méthodes Agile, l’important n’est pas de choisir la meilleure existante
mais plutôt de sélectionner la plus adaptée à notre projet, à savoir la nature évolutive de notre
projet, nous a orientées vers une méthode de type AGILE et plus particulièrement SCRUM.

1.3.2 Présentation de la méthodologie Scrum
Le principe du framework SCRUM est de développer un logiciel de manière incrémentale tout

en conservant une liste complète des demandes de changements ou de modifications à apporter.
Avec des livraisons très fréquentes, les clients reçoivent un logiciel fonctionnel à chaque itération.
En avançant dans le projet, le logiciel devient de plus en plus complet et possède davantage plus de
fonctionnalités.[6]
Figure 1.8 – Méthodologie SCRUM
Comme représenté dans la figure ci-dessus, pour mettre en place la méthode SCRUM, nous
devons d’abord définir les différentes fonctionnalités de notre application qui forment le backlog du
produit.
Par la suite, nous procédons au sprint planning afin de définir le plan détaillé d’une itération.
Durant un sprint, des réunions quotidiennes entre les différents collaborateurs du projet sont pla-
nifiées dans le but de présenter l’état d’avancement des différentes tâches en cours d’exécution, les
obstacles rencontrés ainsi que les tâches restantes à effectuer. Ces sprints durent généralement deux
à quatre semaines.

1.3.3 Organisation
Les rôles ayant pris part dans notre projet sont :
— Product Owner : C’est le responsable de l’équipe projet client ayant comme mission de définir
le besoin et prioriser les fonctionnalités du backlog en déterminant le sprint goal sur la base
des valeurs qui lui sont communiquées par l’équipe.
— Scrum Master : Il représente le vrai facilitateur du projet, il veille à la bonne application des
principes de la méthodologies Scrum en accompagnant chaque membre de l’équipe afin de
maximiser la valeur créée en éliminant les obstacles et en les protégeant des perturbations
extérieures. Il veille également à l’animation et le bon déroulement de toutes les cérémonies
Agiles.
— L’équipe de Développement : Elle se compose de développeurs qui fournissent un incrément
potentiellement publiable à la fin de chaque Sprint. Cette équipe s’organise elle-même et reste
inchangée pendant toute la durée d’un sprint.
— Intervenants : Ils observent et donnent des conseils à l’équipe.
Dans notre cas, les rôles sont répartis comme suivant :
— Product Owner : Saad AMRANI.

— Scrum Master : Saad AMRANI.
— Développeurs : Amine CHICHI, Ayoub BENYAS, Ali OUMLAL et Fouad FAKHORI
— Intervenants :
— Mohamed Amine ZAHHAOUI ( Consultant développeur )
— Mounir LAHRAICHI ( Consultant développeur )
— Hamza CHICHI ( Consultant développeur )
— Adnan ZOUITEN ( Chef de projet )
— Mohamed Ali ESSADEK ( Directeur Technique CTO )
1.4 Planification du projet
La planification d’un projet est une étape inévitable, elle représente également le premier chal-
lenge d’un manager ou chef de projet visant à atteindre les résultats souhaités et à répondre aux
attentes des équipes et des individus impliqués dans le projet.
Nous présenterons ci-dessous l’ensemble des outils utilisés durant la planification de notre pro-
jet.

— Outil de Collaboration «Trello»
Figure 1.9 – Logo Trello
Trello [7] est lancé en 2011 comme un outil open source de gestion de projet en ligne inspiré
par la méthode Kanban de Toyota. Il est basé sur l’aspect des tableaux. D’où la représentation
de chaque projet sou forme d’un tableau qui contient des cartes qui sont les tickets c’est-à-
dire les tâches à faire. Ces cartes sont assignées aux utilisateurs concernés, et elles ont des
champs pour la date de début et de fin et un indicateur coloré pour, déterminer l’avancement
des tickets.
Pour récapituler « Trello » est un outil qui permet de simplifier la gestion de projet et ses
tickets, et permet aussi de mieux visualiser l’avancement et partager l’information entre les
membres de l’équipe.
Figure 1.10 – Tableau de bord Trello

Figure 1.11 – Exemple de User Story
— Slack :
Figure 1.12 – Logo Slack
Slack[8] est une plate-forme de communication collaborative créé en aout 2013 et

officiellement lancée en 2014.
En effet, Slack est utilisé pour gérer les conversations sous forme de chat. Il dispose
des fonctionnalités qui permet de journaliser tous les échanges, et qui permet de
partager des fichiers et d’intégrer des services comme Google Drive dans les conver-
sations. Slack offre une interface graphique simple pour ses utilisateurs.

— OnlineGantt :
Figure 1.13 – Logo OnlineGantt
OnlineGantt est un logiciel de gestion de projet basé sur un diagramme de Gantt qui
vous permet, à vous et à votre équipe, de créer et de modifier des plans de projet
entièrement intégré à Google.
A l’aide de cet outil nous avons pu créer le diagramme de GANTT, qui nous a permis
de planifier les diverses tâches à accomplir.
1.4.1 Diagramme de GANTT
Diagramme de GANTT ou diagramme à barres est l’un des outils le plus utilisé de pla-
nification des diverses tâches à accomplir dans le temps constituant un projet.
La construction du GANTT prend en abscisse le temps nécessaire à l’exécution des opé-
rations et en ordonnée les tâches soit les ressources affectées aux différentes opérations.
Nous présentons ci-dessous le diagramme de GANTT illustrant l’ordonnancement des
tâches dans le temps pour notre projet :
Figure 1.14 – Diagramme de Gantt

— Liste des tâches :
Figure 1.15 – Liste des tâches diagramme de Gantt
— Tableau de Gantt :
Figure 1.16 – Tableau de Gantt

Conclusion
Tout au long de ce chapitre, nous avons abordé le contexte général du projet. En commen-
çant en premier lieu par une présentation d’Effyis Group suivi par la compréhension
du problème en deuxième lieu ainsi que la détermination des objectifs du projet.
Finalement, nous avons étalé la démarche de planification de notre projet en citant les
différentes normes assurant un suivi efficace du projet.
Le prochain chapitre est consacré à la présentation des besoins fonctionnels et non fonc-
tionnels et par une analyse de ces besoins en se basant sur les diagrammes de cas d’uti-
lisation d’UML.

Chapitre 2 Etude fonctionnelle et analyse des besoins
CHAPITRE 2
ETUDE FONCTIONNELLE ET ANALYSE DES BESOINS

Introduction
Dans ce chapitre, nous allons traiter la partie spécification et analyse des besoins, à tra-
vers l’élaboration d’une étude fonctionnelle des besoins fonctionnels et non fonctionnels
de notre projet.
Ensuite, nous allons présenter la conception de notre application en exposant les diffé-
rents diagrammes de classe et de séquences.
2.1 Spécification des besoins

Dans un projet, les besoins fonctionnels représentent les fonctionnalités concrètes du
produit, tandis que les besoins non fonctionnels indiquent la qualité de l’exécution de
ces besoins fonctionnels.
Après une étude détaillée du projet, nous allons dénombrer dans cette partie l’ensemble
des besoins fonctionnels et non fonctionnels de notre application.
2.1.1 Besoins fonctionnels
Le but d’un projet est de répondre à un besoin.Les besoins fonctionnels sont alors l’ex-
pression de ce que le service délivré par le projet devrait être ou faire. C’est dans ce
contexte qu’on présente ci-dessous la liste de l’ensemble de ces besoins :
• Mise en place de l’authentification aux différents services coté BackEnd et FrontEnd
• Assurer le processus de paiement de bout en bout depuis le site E-commerce jusqu’à
la banque du marchand.
• Affichage des KPIs et statistiques au niveau du tableau de bord marchand
• Affichage des graphes représentants les statuts des commandes et les canaux de paie-
ments utilisés par les clients
• Affichage de l’historique détaillé des commandes
• Affichage de l’historique détaillé des commissions facturées à la valeur de la tran-
saction
• Décrire en détails les différentes étapes afin d’intégrer les plugins sur des sites E-
commerce (Wordpress, OpenCart, Magento, Prestashop)
• Décrire en détails les différentes étapes afin d’intégrer la solution sur des sites E-
commerce natifs.
• Documenter les différentes APIs au profit des développeurs

2.1.2 Besoins non fonctionnels
En plus des besoins fonctionnels mentionnés ci-dessus, afin de répondre aux besoins des
utilisateurs, le système doit être en mesure de répondre aux besoins non fonctionnels
suivants :
• L’ergonomie et la convivialité : Les applications doivent fournir une interface
simple et conviviale sans aucune exigence préalable, de sorte que tous les types d’uti-
lisateurs puissent l’utiliser.
• La sécurité : Les informations ne sont accessibles qu’après vérification des privi-
lèges des droits d’accès.
Par conséquent, tout utilisateur passera par la phase d’authentification pour se ré-
férer aux services fournis par l’application.
• L’extensibilité : Notre application est fermée à la modification mais ouverte à l’ex-
tension, son architecture permettra le développement et la maintenance de ses dif-
férents modules de manière dynamique.
• Performance : L’optimisation du temps de réponse de notre application ainsi que
le chargement et délai de rafraîchissement.
2.2 Analyse des besoins

Dans le cadre de notre projet, nous avons adopté la méthodologie UML pour la modélisa-
tion des différents diagrammes . Cette étape correspond à la vision « fonctionnelle » de
l’architecture du système. Aussi commencerons-nous par présenter le diagramme de cas
d’utilisation général avec les principaux cas d’utilisation qui seront détaillés ultérieure-
ment.
2.2.1 Identification des acteurs
Pour procéder à l’analyse d’une application, il faut dans un premier temps identifier ses
différents acteurs. En analysant l’interaction du système avec son environnement exté-
rieur, nous avons pu déterminer trois acteurs principaux :
• Client d’un site E-commerce : Déclenche le début du processus de paiement en
procédant au paiement de sa facture
• Marchand : S’authentifie au niveau de son tableau de bord marchant et pilote ses
activités

• Développeur : Consulte le site de la SandBox ( Portail développeur )
2.2.2 Diagramme de cas d’utilisation
Le diagramme de cas d’utilisation sert à définir l’interopérabilité qui existe entre le sys-
tème et les acteurs, soit toutes les fonctionnalités devant être fournies par le système.
Ci-dessous, nous présentons les principaux cas d’utilisation de notre système :
2.2.2.1 Portail développeur SandBox :
Figure 2.1 – Diagramme de cas d’utilisation

Pour mieux comprendre ces fonctionnalités, nous présentons ci-dessous les descriptions
de certains cas d’utilisation :
• Fiche descriptive du cas d’utilisation "Consulter la documentation d’intégration

des plugins " :
Cas d’utilisation Consulter la documentation d’intégration des plugins.

Description Permet de consulter les étapes en détails afin d’intégrer les plugins de
(Wordpress, Magento ...) au niveau du site web du marchand.
Acteurs Développeur.
Scénario nominal
1. L’utilisateur clique sur le bouton «Portail développeur» sur la nav-
bar de la page d’accueil.
2. Le système réoriente l’utilisateur à la page "Portail développeur".
3. L’utilisateur choisit "Explorer" les modules sur les cartes affichées.
4. L’utilisateur choisit entre quatre options : Magento, Joomla, Open
Cart, WooCommerce.
Table 2.1 – Fiche descriptive de "Consulter la documentation d’intégration des plugins"
• Fiche descriptive du cas d’utilisation "Consulter la documentation d’intégration

de l’application nativement " :
Cas d’utilisation Consulter la documentation d’intégration de l’application nativement.

Description Permet de consulter les étapes en détails afin d’intégrer la passerelle
de paiement dans un site E-commerce natif et personnalisé.
Acteurs Développeur.
Scénario nominal
1. L’utilisateur clique sur le bouton «Portail développeur» sur la nav-
bar de la page d’accueil.
2. Le système réoriente l’utilisateur à la page "Portail développeur".
3. L’utilisateur choisit "Payment Gateway" sur les cartes affichées.
4. L’utilisateur arrive sur la page décrivant les étapes pour intégrer
la passerelle de paiement nativement au sein de son site
Table 2.2 – Fiche descriptive de "Consulter la documentation d’intégration de l’application native-

ment"

2.2.2.2 Tableau de bord marchand :
Figure 2.2 – Diagramme de cas d’utilisation

Pour mieux comprendre ces fonctionnalités, nous présentons ci-dessous les descriptions
de certains cas d’utilisation :
• Fiche descriptive du cas d’utilisation "Consulter les KPIs " :
Cas d’utilisation Consulter les KPIs.

Description Permet de consulter les KPIs journaliers ainsi que le panier moyen
mensuelle et les balances du marchand.
Acteurs Marchand.
Prérequis Être authentifié.
Scénario nominal
1. L’utilisateur clique sur le bouton «Tableau de bord» sur la sidebar.
2. Le système affiche trois cartes dédiées aux revenues du jour, le pa-
nier mensuel et la balance prévisionnelle.
3. L’utilisateur peut filtrer l’affichage des revenues pour voir les
chiffres du mois courant ou l’année courante ainsi que la balance
réelle en choisissant un filtre précis.
Table 2.3 – Fiche descriptive de "Consulter les KPIs"
• Fiche descriptive du cas d’utilisation "Consulter le graphe canaux des commandes" :
Cas d’utilisation Consulter le graphe canaux des commandes.

Description Permet de consulter les taux affectés à chaque canal de paiement utilisé
par les clients.
Acteurs Marchand.
Scénario nominal
2. Le système affiche un graphe sous la forme d’un PieChart qui re-
présente les taux de chaque canal de paiement à savoir Lien, QR
code, NFC.
3. L’utilisateur peut filtrer l’affichage des taux par mois et par année
4. L’utilisateur peut exporter le graphe sous format : svg, png, ou csv.
Table 2.4 – Fiche descriptive de "Permet de consulter les taux affectés à chaque canal de paiement
utilisé par les clients"

• Fiche descriptive du cas d’utilisation "Consulter l’historique des commandes" :
Cas d’utilisation Consulter l’historique des commandes.

Description Permet de consulter la liste des commandes en détails avec la possibilité
de filtrer par date, statut de commande et type de canal.
Acteurs Marchand.
Scénario nominal
2. L’utilisateur défile jusqu’à la fin de la page.
3. Le système affiche un tableau qui représente les commandes et les
informations associées en détails.
4. L’utilisateur peut filtrer l’affichage des commandes par date, type
de canal, et le statut courant de la commande.
Table 2.5 – Fiche descriptive de "Permet de consulter les taux affectés à chaque canal de paiement
utilisé par les clients"
Conclusion
Ce chapitre nous a fait établir une étude préliminaire dans le but de déterminer les be-
soins fonctionnels et non fonctionnels de notre projet ainsi que de bien illustrer notre
diagramme de cas d’utilisation.
Ceci servira dans les prochaines étapes de la conception détaillée et de la mise en oeuvre
de l’application.

Chapitre 3 Architecture de l’application
CHAPITRE 3
ARCHITECTURE DE L’APPLICATION

Introduction
La mise en place d’une architecture logicielle permet de décrire de manière symbolique
les interactions des différents composants d’une application et réponds aux spécifications
fonctionnelles pour la conception du système d’information.
3.1 Architecture Logicielle
3.1.1 Coté serveur
Il existe plusieures architectures coté serveur qui sont très populaire notament l’archi-
tecutre MVC ( Model View Controller), or pour notre cas, cette dernière ne répond pas
au besoin non fonctionnel lié à la performance, scalabilité et la maintenabilité de l’appli-
cation surtout que la non disponibilité et le crash de l’application constitue un blocage
total du sytème. Afin de fournir une solution qui prend en charge ces besoins techniques,
nous avons choisi d’adopter une architecture basée sur les microservices.
3.1.1.1 Architecture microservices
Définition :
L’architecture microservice consiste à décomposer l’application en plusieurs services
indépendants, chacun avec sa propre base de données et qui communiquent les uns avec
les autres de manière synchrone basée sur les API REST, ou bien de manière asyn-
chrone qui consiste à l’envoie de message dans une file d’attente RabbitMQ ou bien en
utilisant des Brokers comme celui de Kafka.
En effet, NETFLIX est considéré comme l’un des pionniers de l’architecture microservice
vue que son équipe de développement a mis en place Netflix OSS (Open Source Soft-
ware Center) qui contient plusieurs projet parmi eux on cite Spring Cloud Netflix qui
fournit des intégrations pour les applications Spring Boot [10].

Caractéristiques :
L’architecture microservices permet de développer une application modulaire non mo-
nolithique et qui doit avoir les caractéristiques suivants :
• Élastique : Chaque microservice doit être déployer indépendamment des autres

services et doit être verticalement et horizontalement scalable, autrement dit, le service
peut être dupliqué en plusieurs instances en fonction de la charge et de la demande.
• Résilient : La non disponibilité d’un service ne doit pas impacter le fonctionne-

ment d’un autre service , l’application doit être capable d’assurer la continuité du fonc-
tionnement malgré les défaillances des éléments du système.
• Service exposé par une API : Chaque service doit avoir une API qui va lui per-
mettre de communiquer et de recevoir les données des autres services, cette api doit être
documentée et stable.
• Décentralisation : Chaque service est déployé d’une manière indépendantes des

autres service, ceci amène à une architecture décentralisée capable d’assurer la disponi-
bilité de l’application.[11]

Architecture de l’application :
Figure 3.1 – Architecture microservices spring boot
Ainsi l’architecture adopté pour notre projet, qui contient les microservices suivant :
• Gateway : C’est l’entrée principale du back end qui contient tous les microser-
vices déployés, elle joue le rôle d’intermédiaire entre le client (front end ) et le back end
(ensemble des microservices ) . Elle permet de faire le routage entre la requête reçue du
front end et le microservice destinataire. Ainsi elle peut être considérée comme un outil
de gestion de trafic et surveillance de l’application.
• Service Discovery : C’est l’annuaire de tous les microservices de l’application, il

permet de localiser tous les microservices avec leurs ports et identifiant ce qui rend la
communication entre services facile et rapide.
• Platform : C’est un service qui a pour objectif de préparer le message ISO SEPA
d’initiation du paiement Pain.001 sous format JSON.
• Switch : C’est le service qui englobe la partie AISP et PISP, il gère le processus de
paiement et la communication avec les banques partenaires.

• Ecom : C’est le service qui gère la partie marchand depuis le déclenchement du

paiement en passant par la génération des KPIs, métriques et statistiques qui seront affi-
chées par la suite au niveau du tableau de bord marchand.
3.2 Architecture Technique
Figure 3.2 – Architecture technique
Notre architecture technique est la suivante, l’application est développée en utilisant

le framework Spring Boot côté serveur ainsi que Spring Cloud pour une architecture
micro-services et une base de données PostgreSQL tout les trois sont dockerisé et déployé
dans des conteneurs docker, le déploiement de l’environnement back est sous un VPS
CentOS 7 au sein d’un serveur local au cabinet, et côté client, React JS et ApexCharts
permettent pour la visualisation des différents graphiques et la communication via des
requêtes HTTPS en format JSON, la partie front est aussi dockerisé. Git et Github pour
la version de contrôle et la centralisation pour des dépôts.

Nous allons voir en détail ces différents outils technologiques dans le cinquième et der-
nier chapitre : Mise en oeuvre.
3.3 Architecture de déploiement
Figure 3.3 – Architecture technique
Le déploiement de notre application vers une machine distante s’est fait grâce à un ser-
veur physique IBM au sein du cabinet , il fallait créer un VPS (Virtual Private Server).
Sa mise en place a été faite par une stagiaire sécurité et infrastructure.
Le back-end est composé de plusieurs entités qui sont dépendantes les unes des autres
dockerisées et qui permettent la fluidité de transport des données jusqu’au client, ainsi,
tout client accédant au site via le lien sécurisé avec le nom de domaine fournie par un
DNS, communique avec le serveur Web via des requêtes HTTPS qui à son tour répond
au client avec du contenu statique (des pages HTML, des fichiers, des images ...).
Le serveur d’applications prend en charge la logique métier et permet donc de gérer les
parties interactives du site qui peuvent apparaître différemment selon le contexte de la

demande.
Le serveur est lancé dans une machine virtuelle Cent OS 7, pour notre cas, on a choisi
d’installer java 8, la norme de production privilégiée.
Pour accéder à la machine distante, on se connecte en utilisant un client SSH en utilisant
la clé fournie par l’équipe infrastructure, l’adresse IP publique et nom d’utilisateur.
Figure 3.4 – Connexion via ssh vers la machine virtuelle
Pour la base de données PostgreSQL, on a choisi d’utiliser Docker avec des volume afin
d’assurer la persistance des données.
Figure 3.5 – Table Recharge du service «Switch»visualisée à partir de PgAdmin4

Figure 3.6 – Table product_item du service «Ecom» visualisée à partir de PgAdmin4
Conclusion
En conclusion, le présent chapitre nous a donc permis de bien connaître la structure de
notre application avec ses différents composants.
Cela dans le but de pouvoir établir le plan technique que nous allons suivre par la suite
pour satisfaire les besoins techniques et fonctionnels de l’application.

Chapitre 4 Conception
CHAPITRE 4
CONCEPTION

Introduction
Au cours de ce chapitre, nous mettrons en évidence le coté conceptuel de notre applica-
tion qui constitue une étape indispensable précédant la partie de l’implémentation.
En effet, elle nous permettra de détailler les différents diagrammes de classe et scénarios
à mettre en oeuvre dans la phase suivante.
4.1 Conception globale de l’application

L’application se compose de 3 microservices indépendants :
— Microservice «Switch» C’est un micro-service qui gère tous ce qui est paiement
et interfaçage avec la banque, à savoir les processus AISP et PISP pour ainsi offrir
des services liés à l’agrégation des comptes ou bien établir des paiements en ligne.
— Microservice «Platform» C’est un micro-service qui fournit une seule fonction-

nalité, préparer des messages d’initiation de paiement ISO de type Pain.001. Il inter-
agit directement avec le microservices Switch qui à son tour reçoit le Pain.001 et le
communique à la banque afin de déclencher la procédure de paiement.
— Microservice «Ecom» C’est un micro-service qui gère la partie marchand depuis

le déclenchement du paiement en passant par la génération des KPIs, métriques et
statistiques qui seront affichées par la suite au niveau du tableau de bord marchand.

4.1.1 Conception du Microservice «Ecom»
4.1.1.1 Diagramme de séquence :
Le diagramme de séquence suivant décrit le scénario de « Authentification »
Figure 4.1 – Diagramme de Séquence d’authentification
Le diagramme de séquence suivant décrit le scénario de « Récupération des revenues

journalières, mensuels, annuels »

Figure 4.2 – Diagramme de Séquence de récupération des revenues.
Le diagramme de séquence suivant décrit le scénario de « Génération d’un Barchart des

revenus »

Figure 4.3 – Diagramme de Séquence de la génération d’un Barchart des revenus.
Le diagramme de séquence suivant décrit le scénario de « Génération d’un piechart re-

présentant les status des commandes »

Figure 4.4 – Diagramme de Séquence de la génération d’un piechart représentant les status des
commandes.
Le diagramme de séquence suivant décrit le scénario de « Génération d’un tableau re-

présentant la liste détaillée des commissions »

Figure 4.5 – Diagramme de Séquence : tableau de la liste détaillée des commissions.
Le diagramme de séquence suivant décrit le scénario de « Processus de paiement E-

commerce »

Figure 4.6 – Diagramme de Séquence du processus de paiement E-commerce.
4.1.1.2 Diagramme de classe :
Le diagramme de classe ci-dessous illustre les différentes classes qui s’interagissent entre
elles afin de définir la logique du service Ecom.

Figure 4.7 – Diagramme de classe du Microservice «Ecom»
4.1.2 Conception du Microservice «Platform»
4.1.2.1 Diagramme de séquence :
Le diagramme de séquence suivant décrit le scénario de « Préparation du Pain.001»
Figure 4.8 – Préparation du Pain.001

4.1.3 Conception du Microservice «Switch»
Le diagramme de classe ci-dessous illustre les différentes classes qui s’interagissent entre
elles afin de définir la logique du service Switch.
4.1.3.1 Diagramme de classe :
Figure 4.9 – Diagramme de classe du Microservice «Switch»
4.2 Conclusion
Ce chapitre nous a ainsi permis de bien comprendre et modéliser les différents compo-
sants de notre application. Cela va nous aider à répondre aux besoins fonctionnels et
techniques de l’application.

Chapitre 5 Mise en oeuvre
CHAPITRE 5
MISE EN OEUVRE

Introduction
Ce chapitre est consacré à la réalisation du projet. La première partie est consacrée aux
outils et technologies utilisés pour la mise en œuvre de la solution. La partie suivante est
consacrée à la présentation des interfaces graphiques réalisées.
5.1 Outils et technologies utilisés
5.1.1 Spring Boot - Spring cloud :
Figure 5.1 – Logo Spring Boot
Le Framework Spring est un framework et conteneur d’inversion de contrôle pour la

plate-forme Java.
Le projet Spring Boot est une extension du Spring Framework pour mettre en place
rapidement des applications Java. Grâce à un système modulaire de dépendances et un
principe de configuration automatique, il permet de disposer d’une structure de projet
complète et immédiatement opérationnelle. La perte de souplesse dans les choix d’ar-
chitecture est contre-balancée par la rapidité de mise en place et un large choix de para-
mètres de configuration. Spring Boot n’est pas un nouvelle version du Spring Framework.
Il s’agit d’une utilisation particulière du framework, évitant aux développeurs de gérer
une complexité technique souvent inutile au moment de l’initialisation d’un projet.
Figure 5.2 – Logo Spring Cloud
Spring Cloud fournit des outils pour créer rapidement certains des modèles pour les sys-
tèmes distribués (Gestion de configuration, Service Discovery, Routage ,Load Balancing,

Gateway et proxy, clusturisation ...). Ainsi avec une architecture distribué, le système
fonctionne bien dans n’importe quel environnement sois localement, dans le cloud en
implémentant les patterns spécifiques aux architectures microservice .
5.1.2 React JS :
Figure 5.3 – Logo React JS
React (également connu sous le nom de React.js ou ReactJS) est une boîte à outils JavaS-
cript frontale gratuite et open-source permettant de créer des interfaces utilisateur basées
sur des composants. Elle est gérée par Meta (anciennement Facebook) et une commu-
nauté de développeurs individuels et de sociétés. Avec des frameworks comme Next.js,
React peut être utilisé comme base pour développer des applications monopages, mo-
biles ou avec rendu serveur. Cependant, comme React ne s’occupe que de la gestion de
l’état et de la présentation de ces informations au DOM, le développement d’applications
React nécessite souvent l’utilisation de bibliothèques supplémentaires pour le routage et
certaines fonctions côté client.
5.1.3 Material UI :
Figure 5.4 – Logo Material UI
Material-UI, en quelques mots, est un projet open-source qui comprend des composants
React appliquant le Material Design de Google. Il a débuté en 2014, juste après la sortie
de React au public, et sa popularité n’a cessé de croître depuis. Material-UI est l’un des
frameworks d’interface utilisateur React les plus populaires, avec plus de 35 000 étoiles
sur GitHub. Son triomphe, cependant, ne s’est pas fait sans difficultés. Material-UI v0.x,
qui a été conçu avec LESS, était sujet à des erreurs CSS de base, telles que la portée

globale, ce qui a conduit le projet sur la voie du CSS-in-JS. En 2016, c’est ainsi qu’est né
next.
5.1.4 ApexCharts :
Figure 5.5 – Logo ApexCharts
ApexCharts est une bibliothèque de graphiques gratuite et open source qui permet de
créer des graphiques sur un application Web. Cette bibliothèque fournit fonctionnalités
puissantes pour répondre aux besoins de visualisation de données parmis eux on peut
citer : L’aspect reactive pour tous les écrans soit ordinateurs de bureau, aux tablettes ou
mobiles, des graphes qui sont interactive est dynamique, la performance pour l’affichage
en masse des données ...
5.1.5 PostreSQL :
Figure 5.6 – Logo PostreSQL
PostgreSQL est un système de gestion de base de données relationnelle orienté objet

puissant et open source qui est capable de prendre en charge en toute sécurité les charges
de travail de données les plus complexes. Robuste et puissant, aux fonctionnalités riches
et avancées, il est capable de manipuler en toute fiabilité de gros volumes de données,
mêmes dans des situations critiques.

5.1.6 Junit 5 & Mockito :
Figure 5.7 – Logo JUnit 5
JUnit 5 est la prochaine génération de JUnit. L’objectif est de créer une base à jour pour
les tests côté développeur sur la JVM. Cela inclut de se concentrer sur Java 8 et versions
ultérieures, ainsi que de permettre de nombreux styles de test différents.
Figure 5.8 – Logo Mockito
Mockito est un framework Java qui permet de générer automatiquement des objets mo-
ckés. Ainsi avec JUnit, il permet de tester le comportement des objets réels qui sont as-
sociés à des objets mockés ce qui facilite l’écriture des tests unitaires.
5.1.7 Intellij IDEA :
Figure 5.9 – Logo Intellij IDEA
IntelliJ IDEA également appelé « IntelliJ », « IDEA » ou « IDJ » est un environnement

de développement intégré (en anglais Integrated Development Environment - IDE) des-
tiné au développement de logiciels informatiques reposant sur la technologie Java. Il est
développé par JetBrains (anciennement « IntelliJ ») et disponible en deux versions, l’une
communautaire, open source, sous licence Apache 2 et l’autre propriétaire, protégée par
une licence commerciale. Tous deux supportent les langages de programmation Java,
Kotlin, Groovy et Scala.

5.1.8 Visual Studio Code :
Figure 5.10 – Logo Visual Studio Code
Visual Studio Code est un éditeur de code extensible développé par Microsoft pour
Windows, Linux et macOS2. Les fonctionnalités incluent la prise en charge du débogage,
la mise en évidence de la syntaxe, la complétion intelligente du code, les snippets, la
refactorisation du code et Git intégré. Les utilisateurs peuvent modifier le thème, les rac-
courcis clavier, les préférences et installer des extensions qui ajoutent des fonctionnalités
supplémentaires.
5.1.9 Postman :
Figure 5.11 – Logo Postman
Postman est un environnement de développement d’API qui aide les utilisateurs à créer,
documenter, surveiller et publier la documentation de leurs APIs. Il est devenu très popu-
laire pour tester les Microservices, notamment grâce à sa simplicité et ses fonctionnalités
très spécialisées.
Les tests des API sont utilisés pour déterminer si les API retournent la réponse correcte
(dans le format attendu) pour une large gamme de requêtes réalisables, réagissent cor-
rectement aux cas de bords tels que les échecs et les entrées inattendues/extrêmes, four-
nissent des réponses dans un délai acceptable et répondre en toute sécurité aux attaques
de sécurité potentiels.

5.1.10 Gitlab :
Figure 5.12 – Logo Gitlab
GitLab Inc. est une organisation à but non lucratif qui fournit GitLab, un progiciel De-
vOps qui intègre la capacité de construire, protéger et exécuter des logiciels dans une
seule application. Le développeur ukrainien Dmitriy Zaporozhets et le développeur néer-
landais Sytse Sijbrandij ont fondé ce projet de logiciel open source. Le logiciel GitLab a
été initialement créé en Ruby, certains composants ayant ensuite été réécrits dans le lan-
gage de programmation Go. Il a commencé comme un système de gestion du code source
pour la collaboration d’équipe sur le développement de logiciels, puis s’est développé en
une solution intégrée couvrant le cycle de vie du développement de logiciels, et enfin
l’ensemble du cycle de vie DevOps. Go, Ruby on Rails et Vue.js sont des exemples de
technologies logicielles modernes.
5.1.11 Grafana :
Figure 5.13 – Logo Grafana
Grafana Grafana est une solution open source permettant d’effectuer des analyses de
données, d’extraire des métriques qui donnent un sens à l’énorme quantité de données
et de surveiller nos applications à l’aide de tableaux de bord personnalisables. Grafana
se connecte à toutes les sources de données possibles, communément appelées bases de
données, telles que Graphite, Prometheus, Influx DB, ElasticSearch, MySQL, PostgreSQL,
etc. Grafana étant une solution open source, il nous permet également d’écrire des plu-
gins à partir de zéro pour l’intégration avec plusieurs sources de données différentes.
L’outil nous aide à étudier, analyser et surveiller les données sur une période de temps,

ce qui est techniquement appelé analyse de séries chronologiques. Il nous aide à suivre le
comportement de l’utilisateur, le comportement de l’application, la fréquence des erreurs
qui apparaissent dans un environnement de production ou de pré-prod, le type d’erreurs
qui apparaissent et les scénarios contextuels en fournissant des données relatives.
5.1.12 Prometheus :
Figure 5.14 – Logo Prometheus
Prometheus L’outil de surveillance open-source Prometheus offre une fonctionnalité

intégrée de tableau de bord, même s’il considère Grafana comme sa solution de visuali-
sation. Le tableau de bord Prometheus et Grafana permettent tous deux aux utilisateurs
d’interroger et de représenter graphiquement des métriques de séries temporelles sto-
ckées dans la base de données Prometheus, de sorte que la décision d’utiliser Grafana
avec Prometheus dépend de vos besoins en matière de surveillance.
5.2 Interfaces graphiques
5.2.1 Portail développeur :
— Interface d’accueil : C’est la première interface qui représente une vue générale
du contenu du siteWeb et ses différentes sections.

Figure 5.15 – Interface d’accueil
— Interface Portail développeur : C’est l’interface qui englobe les documentations

de notre Sandbox à savoir la documentation des APIs et des plugins.

Figure 5.16 – Interface Portail développeur
— Interface Intégration des CMS : C’est l’interface qui englobe les documentations
de notre Sandbox à savoir la documentation des APIs et des plugins.
Figure 5.17 – Interface Liste des plugins supportés
— Interface Intégration du plugin sur WooCommerce : C’est l’interface qui illustre

les étapes nécessaire afin d’ingérer le plugin au sein d’un site-web Wordpress.

Figure 5.18 – Interface Intégration du plugin sur WooCommerce
— Interface Documentation de l’api d’authentification : C’est l’interface qui pré-

sente les différents Endpoints de l’api d’authentification.

Figure 5.19 – Interface Documentation de l’api d’authentification
— Interface Sandbox "Ajouter un compte bancaire" : C’est l’interface qui nous

permet de choisir sa banque et d’ajouter un compte bancaire.

Figure 5.20 – Interface Ajouter un compte bancaire
— Interface Sandbox "Authentification et confirmation auprès de la banque" :

C’est l’interface qui nous permet de s’auhtentifier auprès de la banque et autoriser
au TPP l’accès aux données bancaires.
Figure 5.21 – Interface Authentification et confirmation auprès de la banque
— Interface Sandbox Consulter l’historique des transactions : C’est l’interface

qui nous permet de consulter l’historique des transactions selon le compte bancaire
choisi.

Figure 5.22 – Interface Consulter l’historique des transactions
5.2.2 Tableau de bord marchand :
— Interface authentification au tableau de bord marchand : C’est l’interface qui

nous permet de se connecter au tableau de bord marchand.
Figure 5.23 – Interface authentification au tableau de bord marchand

— Interface Consulter le chiffre d’affaire, panier moyen mensuel et la balance :

C’est l’interface qui nous permet de consulter le chiffre d’affaire journalier, mensuel
et annuel ainsi que le panier moyen mensuel et les balance réelle et prévisionnelle.
Figure 5.24 – Interface Consulter le chiffre d’affaire, le panier moyen mensuel et les balances
— Interface consulter le chiffre d’affaire détaille de l’année et la semaine sous

forme d’un BarChart : C’est l’interface qui nous permet de consulter le chiffre
d’affaire de chaque mois de l’année courante et précédente.

Figure 5.25 – Interface consulter le chiffre d’affaire de l’année et la semaine sous forme d’un Bar-
Chart
— Interface consulter les statuts des commandes et canaux de paiement utilisé

sous forme de PieChart : C’est l’interface qui nous permet de visualiser les taux
des status des commandes ainsi que les taux des canaux de paiement utilisé.
Figure 5.26 – Interface consulter les statuts des commandes et canaux de paiement utilisé sous forme
de PieChart

— Interface consulter la liste des commandes détaillée sous forme d’un tableau
paginé : C’est l’interface qui nous permet de visualiser les détailles de chaque com-
mande avec la possibilité de filtrer le résultat par date, canal et statut de commande.
Figure 5.27 – Interface consulter la liste des commandes détaillée sous forme d’un tableau paginé
Figure 5.28 – Interface consulter la liste des commandes détaillée sous forme d’un tableau paginé
et filtré par statut et date

— Interface consulter l’historique détaillé des commissions facturées à la va-

leur de la transaction sous forme d’un tableau paginé : C’est l’interface qui
nous permet de visualiser les détailles de chaque commission facturé avec la possi-
bilité de filtrer le résultat par date.
Figure 5.29 – Interface consulter l’historique détaillé des commissions facturées sous forme d’un
tableau paginé
5.2.3 Documentation des APIs
Chacun des services développés est muni d’une interface pour la documentation
permettant de bien exploiter les fonctionnalités fournies par chaque service.
Pour ce faire, nous nous servons de l’outil pour la documentation Swagger et ci-
dessous nous exposons comme exemple la documentation relative au service Ecom
et Platform.

Figure 5.30 – Documentation Swagger de l’API Platforme (1)
Figure 5.31 – Documentation Swagger de l’API Platforme (2)

Figure 5.32 – Documentation Swagger de l’API Ecom

5.2.4 Processus de paiement depuis un site E-commerce :
— Interface Paiement E-commerce de bout en bout par virement instantané à

travers notre passerelle OpenBank :
C’est les interfaces qui mettent en valeur le processus de paiement E-commerce ainsi
que les acteurs impliqués à savoir le site marchand, notre passerelle de paiement et
le site de la banque.
Figure 5.33 – Interface détails de la commande au sein du site marchand

Figure 5.34 – Interface détails de la transaction au sein de notre passerelle de paiement

Figure 5.35 – Interface choix de la banque au sein de la passerelle de paiement
Figure 5.36 – Interface récapitulatif de la transaction avant la redirection vers le site de la banque

Figure 5.37 – Interface authentification auprès de la banque précédemment sélectionnée
Figure 5.38 – Interface choix du compte bancaire pour effectuer le paiement

Figure 5.39 – Interface récapitulatif de la transaction et confirmation du paiement
Figure 5.40 – Interface redirection vers la page "paiement effectué avec succès"

5.2.5 Monitoring des machines virtuelles :
— Interface login de notre dashboard Graphana Prometheus :
Figure 5.41 – Interface login dashboard Graphana Prometheus
— Interface dashboard de monitoring Graphana Prometheus :

Ce sont les interfaces qui mettent en valeur les métriques concernant de notre ma-
chine virtuelle telles que l’usage CPU, RAM, Network et d’autres KPIs utiles
Figure 5.42 – Interface dashboard de monitoring Graphana Prometheus

5.3 Conclusion
Ce chapitre a permis de montrer le produit de notre travail, nous y avons vu les différents
outils de réalisation ainsi que des captures d’écran de nos applications.

GL ENSIAS
CONCLUSION GÉNÉRALE
Ce projet de fin d’études chez Effyis Group a constitué pour nous une importante étape
de notre cursus universitaire, nous permettant de franchir le pas vers le monde profes-
sionnel, tout en participant à la réalisation d’un projet de monétique innovant.
La mission qui nous a été confiée était de concevoir un prototype d’une nouvelle pas-
serelle de paiement Next-Gen plus souple, sécurisé, et rapide basée sur l’open banking
et la norme ISO 20022 ainsi qu’un tableau de bord marchant ou ce dernier peut piloter
son activité et consulter les différentes métriques et graphes générées afin de prendre des
décisions stratégiques.
Cette expérience nous a notamment permis de découvrir une large panoplie d’outils et
de documents, avec pour objectif leur conversion en des produits rentables sur le long
terme. Par ailleurs, nous avons pu apprendre à adapter notre savoir-faire aux exigences
d’un éventuel client, mais aussi à élaborer des livrables qui soient consommables et faciles
à déployer.
Ce stage a été une chance unique pour nous de pouvoir travailler sur un véritable projet
d’une grande ampleur, mais aussi de développer nos compétences dans le cadre d’un tel
projet. Le présent projet fait partie d’une nouvelle tendance dans le domaine des moyens
de paiement, qui engendre un fort besoin d’outils de paiement électronique efficaces, et
permettant au commerce électronique de pouvoir en bénéficier.
Durant la période de stage j’ai pu couvrir 80% des objectifs eu préalable. En ce qui
concerne les futures perspectives, nous prévoyons d’établir une série de tests de charge
et de performance en se basant sur l’outil Jmeter et de de mettre en place une infra-
structure monitoré à travers un APM tel que Instana d’IBM et automatiser le build et le
déploiement à travers un pipeline CI/CD pour ainsi voir notre projet intégrer par la suite
non seulement les banques européenne mais des banques africaines et américaines aussi.
Nous souhaitons également améliorer notre projet grâce à des outils mettant en œuvre
l’intelligence artificielle et la vision par ordinateur.
2021/2022 PFE
GL ENSIAS
BIBLIOGRAPHIE
[1] Les limitations du paiement par carte

https://truelayer.com/blog/biggest-limitations-card-payments-ecommerce-
businesses
[2] La norme PSD2 et OpenAPI

https://www.galitt.com/wp-content/uploads/2020/11/Livre-Blanc-Galitt-DSP2-
OPEN-API-En-route-vers-Open-Banking.pdf
[3] Avantages de l’open banking

https://truelayer.com/openbanking/open-banking-payments-vs-other-
payment-methods/
[4] Comprendre la monétique

http://www.indg.fr/MOE/monetique.html
[5] ISO 20022

https://www.iso20022.org/
[6] Méthode Agile

https://bubbleplan.net/blog/agile-scrum-gestion-projet/
[7] Trello website

https://trello.com/fr
[8] Slack website

https://slack.com
[9] Material UI
https://mui.com/material-ui/getting-started/overview/
[10] Spring Cloud Netflix

https://spring.io/projects/spring-cloud-netflix
[11] Microservice Architecture

https://microservices.io/
[12] Introduction to React JS

https://jscomplete.com/learn/complete-intro-react
2021/2022 PFE

Rapport Pfe Chichi Amine GL 2022

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport Pfe Chichi Amine GL 2022

Transféré par

Droits d'auteur :

Formats disponibles

École nationale supérieure d’informatique et

d’analyse des systèmes

Mémoire de Projet de Fin d’études Pour l’obtention

Conception et développement d’une passerelle

Soutenu le : Pr. EL FKIHI Sanae (Présidente - ENSIAS)

04 juillet 2022 Pr. BAINA Karim (Examinateur - ENSIAS)

Année universitaire 2021/2022

À mes chers parents

À mes chères frères, Houcine, Anas, Salma

À toutes les personnes que j’ai connues à l’ENSIAS

À mes meilleurs amis

Veuillez trouver en ce modeste travail l’expression de mon profond attachement et

LISTE DES ABRÉVIATIONS

PSD2 : Payment Services Directive Two

TPP : Account Servicing Payment Service Provider

ASPSP : Account Servicing Payment Service Provider

PSU : Payment Services User

AISP : Account Information Service Provider

PISP : Payment Initiation Service Provider

PAIN : Payments Initiation

VPS : Virtual Private Server

DNS : Domain Name System

IDE : Integrated Development Environment

JSON : Java Script Object Notation

JWT : JSON Web Token

NPM : Node Package Manager

REST : Representational State Transfer

TABLE DES FIGURES

1.1 Logo d’Effyis Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.2 Fiche signalétique d’Effyis Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.3 Organigrame d’Effyis Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.4 Schématisation des secteurs d’activités d’Effyis Group . . . . . . . . . . . . . . . . . 18

1.5 Passerelle de paiement traditionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . 20

1.6 AISP workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

1.7 PISP workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1.8 Méthodologie SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

1.9 Logo Trello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

1.10 Tableau de bord Trello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

1.11 Exemple de User Story . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

1.12 Logo Slack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

1.13 Logo OnlineGantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

1.14 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

1.15 Liste des tâches diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . 31

1.16 Tableau de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.1 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2.2 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.1 Architecture microservices spring boot . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.2 Architecture technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.3 Architecture technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.4 Connexion via ssh vers la machine virtuelle . . . . . . . . . . . . . . . . . . . . . . 47

3.5 Table Recharge du service «Switch»visualisée à partir de PgAdmin4 . . . . . . . . . 47

3.6 Table product_item du service «Ecom» visualisée à partir de PgAdmin4 . . . . . . . 48

4.2 Diagramme de Séquence de récupération des revenues. . . . . . . . . . . . . . . . . 52

4.3 Diagramme de Séquence de la génération d’un Barchart des revenus. . . . . . . . . 53

4.5 Diagramme de Séquence : tableau de la liste détaillée des commissions. . . . . . . . 55

4.6 Diagramme de Séquence du processus de paiement E-commerce. . . . . . . . . . . . 56

4.7 Diagramme de classe du Microservice «Ecom» . . . . . . . . . . . . . . . . . . . . . 57

4.8 Préparation du Pain.001 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.9 Diagramme de classe du Microservice «Switch» . . . . . . . . . . . . . . . . . . . . 58

5.1 Logo Spring Boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.2 Logo Spring Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.3 Logo React JS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.4 Logo Material UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61