PFE Bridge

Rapport PFE
Enrichissement du catalogue des APIs

Bridge
Réalisé par :CHQIR Samia
Encadrant interne :Mme Membres du Jury :

ETTAZI Widad Pr.
Encadrant externe :Mr RAFIK Pr.
Zakaria
Encadrant externe :Mr SAKHI
Mohamed
Année universitaire 2021-2022

2
Dédicaces
Je dédie ce modeste travail
A mes chers parents,

Aucune dédicace ne peut exprimer mon grand amour, mon respect et ma considération
pour tous les sacrifices que vous avez consentis pour mon instruction et mon bien-être,
puisse Allah, le Très Haut, vous accorde santé, bonheur et longue vie.
A ma sœur Aya,
Les mots ne suffisent guère pour exprimer l’attachement, l’amour et l’affection que je porte
pour toi. Je te dédie ce travail avec tous mes vœux de bonheur, de santé et de réussite.
A ma sœur Manal,
Je ne te remercierai jamais assez pour ta présence, ton écoute et ta confiance. Je te
souhaite une vie pleine de bonheur et de succès.
A mes exceptionnels amis,

Mes amis, avec qui j’ai passé des moments de joie et de bonheur. Avec qui, j’ai partagé
des discussions sans fin.Vous étiez toujours présents pour moi.Une présence bienveillante
et chaleureuse. Votre amitié est une véritable chance qui ne peut guère se briser.
A mes encadrants et tous mes professeurs,

Pour le profit que j’ai continuellement tiré, de leur savoir et de leurs compétences. Qu’ils
trouvent dans ce modeste travail l’expression de mes sincères reconnaissances et
admirations.
A toute ma grande famille,
A tous ceux qui m’aiment,
À tous ceux qui ont participé de près ou de loin à l’élaboration de ce travail.
Samia CHQIR
3
Remerciements
Au terme du stage de fin d’études effectué au sein de la digital factory du SOCIETE GE-
NERALE AFRICAN BUSINESS SERVICES, je tiens à remercier vivement Mme ETTAZI Wi-
dad professeur à l’ENSIAS, pour son encadrement, son soutien, ainsi que pour ses conseils
instructifs durant toute la période de l’établissement de ce travail. Je remercie également
mon encadrant à SOCIETE GENERALE ABS,Mr RAFIK Zakaria, qui était attaché au bon
déroulement de ce projet et ayant facilité à travers sa coordination et sa disponibilité, de ré-
pondre à mes engagements aussi bien envers l’école qu’envers la société. Je remercie plus
particulièrement Mr SAKHI Mohamed mon manager pour son soutien et ses conseils. Je re-
mercie l’organisme d’accueil SOCIETE GENERALE ABS et tous les collaborateurs avec qui
j’ai travaillé en son sein qui ont permis mon intégration dans l’entreprise, et m’ont fourni tous
les moyens pour mener à bien mon projet. Je remercie plus particulièrement les membres
de l’equipe GATE UP et UNIBANK pour leur soutien leurs conseils et surtout leur joie de
vivre. Je ne saurais oublier dans mes remerciements tout le corps professoral, la direction
de l’ENSIAS et plus particulièrement le département GL pour les efforts qu’ils fournissent
afin de nous garantir une formation de qualité. Je tiens aussi à remercier tous les membres
du jury qui nous ont fait l’honneur d’accepter de juger mon travail. Un Merci, encore une fois,
à toute personne ayant contribué de près ou de loin à la réalisation de ce projet.
4
Résumé
Le présent rapport synthétise le travail réalisé dans le cadre de mon projet de fin d’études
effectué au sein de la SOCIETE GÉNÉRALE AFRICAN BUSINESS SERVICES. Il s’inscrit
dans le cadre d’un programme visant à mettre à disposition des projets des APIs multi filiales
au sein de la Digital Factory de la SOCIETE GÉNÉRALE AFRICAN BUSINESS SERVICES.
L’objectif principal de ce projet est de développer un catalogue d’APIs Bridge afin de ré-
pondre aux besoins des différents projets. En fait, la plateforme digitale UNIBANK est une
solution « In-House » ayant pour objectif d’accélérer le Time To Market en délivrant plus vite
des solutions pour les filiales de la zone AFS. Elle doit permettre de couvrir 80 % des besoins
courants de nos filiales en matière d’applications digitales. Le premier usage développé au-
tour de cette plateforme est la banque à distance Retail (projet Bank-Up). Elle est composée
de librairies front (web, mobile) contenant les parcours clients et d’une couche d’APIs (Appli-
cation Programming Interface) dont la gouvernance est portée par le programme Unibank.
Cette dernière permet de masquer la complexité technique vis-à-vis des applications com-
muniquant avec le SI (pas uniquement CBS) ou avec d’autres systèmes externes. Cette
plateforme est construite sur une technologie open-source appelée WSo2.
Le projet suit la méthode Agile et précisément le framework Scrum avec ses différents
profils (Product Owner, Scrum Master, Equipe de développement), et ses différents rituels
(Sprint Planning, Daily Meeting, Sprint Review, Rétrospective, Backlog Refinement).
Mots clés : API, Bridge, Zone AFS, CBS, WSo2, SMG, CBS.
5
Abstract
This document is the result of the work done as part of my final year project in SOCIETE
GENERALE AFRICAN BUSINESS SERVICES.
It is part of a program aimed at providing projects with multi-subsidiary APIs within the
Digital Factory of SOCIETE GENERALE AFRICAN BUSINESS SERVICES.
The main objective of this project is to develop a catalogue of APIs Bridge to meet the
needs of the various projects. In fact, The digital platform is an «In-House» solution with the
objective of accelerating the Time To Market by delivering solutions faster for the subsidia-
ries in the AFS area. It should cover 80% of the current needs of our subsidiaries in terms of
digital applications.
The first use developed around this platform is the remote banking Retail. It consists of front
(web, mobile) libraries containing customer journeys and a layer of APIs whose governance
is supported by the Unibank program.
This makes it possible to mask the technical complexity with regard to applications commu-
nicating with our IS or with other external systems. This platform is built on an open-source
technology called WSo2.
The project follows the Agile method and precisely the Scrum framework with its different
profiles (Product Owner, Scrum Master, Development Team), and its different rituals (Sprint
Planning, Daily Meeting, Sprint Review, Retrospective, Backlog Refinement).
We obtained as a result a catalogue of reusable APIs ready to be consumed. It is a ge-

neric solution that ensures fast delivery and accelerates Time to Market while aligning with
SG Group’s obligations in terms of security regulations.
Keywords : API, Bridge, AFS, CBS, WSo2, SMG, REST, GraphQL.
6
Liste des abréviations
Abréviations Signification
SOCIETE GENERALE AFRICAN BUSINESS

SG ABS SERVICES
AFS Africaine sub-sahariène
DF Digital Factory
API Application Programming Interface
CBS Core Banking System
SA Société Anonyme
BD Base de données
AFMO Afrique Méditerranée et Outre-mer
SMG Services Métier Génériques
US User Story
CI Continuous Integration
CD Continuous Delivery
7
8 Introduction
Abréviations Signification
EDB EXPRESSION DES BESOINS
JSON JavaScript Object Notation
SI système d’information
JWT JSON Web Token

Table des figures
1.1 Logo de l’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.2 Organisation de la DiFa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.3 Méthode Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.4 Pizza Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.5 Devops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.6 Diagramme Gantt 1 du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.1 Exemple d’user story publiée sur JIRA pour lister les taux de change . . . . . 31
2.2 Les sous taches des user stories . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3 EDB d’un convertisseur de devises-1 . . . . . . . . . . . . . . . . . . . . . . . 33
2.4 EDB d’un convertisseur de devises-2 . . . . . . . . . . . . . . . . . . . . . . . 34
2.5 Maquette du convertisseur de devises . . . . . . . . . . . . . . . . . . . . . . 35
2.6 Critères d’acceptation et UATs - Taux de change . . . . . . . . . . . . . . . . 36
2.7 Les règles de gestion - Taux de change . . . . . . . . . . . . . . . . . . . . . 36
2.8 diagramme de cas d’utilisation des APIs du Bridge . . . . . . . . . . . . . . . 38
3.1 Rôle des APIs Unibank dans le cadre du programme Bank Up . . . . . . . . 41

3.2 Cartographie de la plateforme . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.3 Architecture en couches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.4 Architecture technique de Unibank . . . . . . . . . . . . . . . . . . . . . . . . 45
3.5 Les anciennes architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.6 L’architecture CQRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.7 Exemple des données d’un utilisateur en se basant sur son Token . . . . . . 47
3.8 Le principe d’algorithme RS256 . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.9 Diagramme de séquence d’amplitude . . . . . . . . . . . . . . . . . . . . . . 49
3.10 Diagramme de séquence de transformation . . . . . . . . . . . . . . . . . . . 50
3.11 exemple d’implementation d’infobip -chaine de souscription . . . . . . . . . . 51
3.12 Authentification SAFE viale socle WSO2 . . . . . . . . . . . . . . . . . . . . . 56
3.13 Authentification SAFE viale socle WSO2 . . . . . . . . . . . . . . . . . . . . . 57
3.14 Authentification des transactions sur mobile . . . . . . . . . . . . . . . . . . . 58
3.15 Authentification des transactions sur WEB . . . . . . . . . . . . . . . . . . . . 59
3.16 diagramme de classes des APIs du Bridge . . . . . . . . . . . . . . . . . . . 60
4.1 Gitflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
9
10 Table des figures
4.2 Qualité du code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.3 Jenkins pour la livraison continue . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.4 Nomad pour le déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.5 Consule comme mémoire de clés/valeurs . . . . . . . . . . . . . . . . . . . . 68
4.6 Arhitecture Vault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.7 A/B testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.8 Traefik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.9 Architecture de Spring MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.10 Interface de gestion de notre projet sur JIRA . . . . . . . . . . . . . . . . . . 83
4.11 Capture d’écran du calendrier des réunions sur Teams . . . . . . . . . . . . . 84
4.12 Interface des formations sur My Learning . . . . . . . . . . . . . . . . . . . . 85
4.13 Page d’accueil - SG CONNECT - Application Web . . . . . . . . . . . . . . . 86
4.14 Page d’accueil - SG CONNECT - Application Mobile . . . . . . . . . . . . . . 87
4.15 Maquette du convertisseur des devises sur le SG Connect . . . . . . . . . . 88
4.16 Interface de Taux de change - Application web . . . . . . . . . . . . . . . . . 88
4.17 Interface de Taux de change 1 - Application Mobile . . . . . . . . . . . . . . . 89
4.18 Interface de Taux de change 2 - Application Mobile . . . . . . . . . . . . . . . 90
4.19 Commande de chéquier - Application Web . . . . . . . . . . . . . . . . . . . 91
4.20 Formulaire de commande de chéquier - Application Web . . . . . . . . . . . 93
4.21 Formulaire de commande de chéquier - Application mobile . . . . . . . . . . 94
4.22 Interface de l’application web -1 . . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.23 Interface de l’application web -2 . . . . . . . . . . . . . . . . . . . . . . . . . . 95
4.24 Activité d’un compte bancaire - Application Web . . . . . . . . . . . . . . . . 95
4.25 Activité d’un compte bancaire - Application Mobile . . . . . . . . . . . . . . . 96
4.26 Rapport de SonarLint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
4.27 Rapport des tests unitaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.28 Interface de Karaté . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.29 Interface de Postman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.30 Pilot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
4.31 A/B testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Liste des tableaux
1.1 Fiche Signalétique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.2 Planification du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1 Comparaison entre Spring Boot et Node.js . . . . . . . . . . . . . . . . . . . 54

3.2 Comparaison entre Gradle et Maven . . . . . . . . . . . . . . . . . . . . . . . 55
3.3 Description des classes utilisés 1 . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.4 Description des classes utilisés 2 . . . . . . . . . . . . . . . . . . . . . . . . . 62
11
Table des matières
Dédicaces 3
Introduction générale 14
1 Contexte général du projet 15

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2 Le groupe SGABS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2.1 Présentation générale du groupe . . . . . . . . . . . . . . . . . . . . . 16
1.2.2 Fiche signalétique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2.3 Organigramme et administration de l’entreprise . . . . . . . . . . . . . 18
1.3 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.3.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.3.2 Objectifs du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.4 Conduite de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.4.1 Ressources humaines . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.4.2 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.4.3 Planification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2 Étude détaillée du projet 28

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.2 Analyse de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3 Limitations de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.4 Analyse et identification des besoins . . . . . . . . . . . . . . . . . . . . . . . 30
2.4.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.4.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.5 Diagramme des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3 Etude technique 40
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2 Architecture d’UNIBANK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.3 Architecture technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.3.1 Architecture hexagonal . . . . . . . . . . . . . . . . . . . . . . . . . . 43
12
Table des matières 13
3.3.2 Domain-driven design . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.3.3 Command and Query Responsibility Segregation . . . . . . . . . . . . 45
3.3.4 Utilisation des Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.4 Connecteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.4.1 AMPLITUDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.4.2 INFOBIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.4.3 EMAIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.4.4 TagPay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.4.5 Delta Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.5 Etude benchmarking des outils . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.5.1 Spring Boot et Node.js . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.5.2 Gradle et Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.6 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.6.1 Diagrammes de séquences . . . . . . . . . . . . . . . . . . . . . . . . 56
3.6.2 scénario d’authentification des transactions (canaux mobile et web) . 58
3.6.3 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4 Réalisation et mise en oeuvre 63

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.2 Outils techniques et methodes . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.2.1 DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.2.2 Outils utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.2.3 Outil de collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.2.4 Outil de formation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.3 Réalisation des APIs par sprint . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.3.1 Développement des APIs . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.3.2 Qualité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
4.3.3 Les tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
4.3.4 Déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
4.3.5 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Conclusion générale 104
Webographie 105
Webographie 105
Annexes 107
Introduction générale
Le secteur bancaire ne cesse de se transformer. L’Open Banking (système bancaire ou-

vert) fait partie des nombreuses innovations qui bouleversent et métamorphosent complète-
ment le marché. Cette technologie vise à permettre aux banques de partager leurs données
avec d’autres acteurs du secteur financier pour assurer leur ouverture et transparence, en
faisant référence à l’utilisation d’API (interfaces de programmation) permettant, par exemple,
à des développeurs de créer des applications et des services novateurs pour les institutions
financières. Une petite révolution dans l’écosystème bancaire dans lequel toutes les infor-
mations étaient jusqu’ici cloisonnées et sécurisées.
Pour s’aligner avec la demande de ses clients de la région AFS, accélérer le Time to
market et répondre rapidement à la vive concurrence africaine qui ne cesse de prendre de
l’ampleur, la Digital Factory de la SGABS, à travers sa plateforme digitale ”Unibank”, devient
dès lors un accélérateur de la transformation digitale pour les filiales AFS.
La plateforme digitale ”Unibank” est une solution ”In-house” contenant une couche d’APIs.
Elle permet de masquer la complexité technique vis-à-vis des applications communiquant
avec notre SI ou avec d’autres systèmes externes. La couche d’APIs se divise en deux
genres : Le premier est les APIs Bridge dont le rôle est de transformer les données re-
montées des systèmes externes, de communiquer de manière sûre avec eux et assurer la
traduction entre les APIs Unibank et ces systèmes, tandis que le second est les APIs métier
dont le rôle est d’utiliser les API Bridge en appliquant des règles de gestion métier afin de
répondre à un besoin défini du client applicatif.
Notre projet vise à Enrichir le catalogue des APIs de la couche Bridge en développant
des APIs bridge pour des services déjà en production mais aussi en anticipant les besoins
des projets commanditaires de nouveaux services.
Le rapport présent synthétise l’intégralité du travail effectué dans le cadre de ce projet.
Le premier chapitre donne un aperçu général sur le projet à réaliser. Le deuxième chapitre
englobe l’analyse et l’étude fonctionnelle de ce qui est demandé. Le troisième chapitre met
en évidence la conception du projet et l’étude technique du travail effectué. Quant au der-
nier,montre la réalisation du travail effectuée.
14
Chapitre 1
Contexte général du projet
15
16 Chapitre 1. Contexte général du projet
1.1 Introduction
Chaque organisation possède ses propres spécificités et se distingue des autres struc-
tures qui l’entourent. Il est donc nécessaire de la présenter sous ses différents aspects or-
ganisationnels et fonctionnels afin d’avoir une idée précise sur la nature de ses activités et
ses relations, souvent complexes, qu’elle peut entretenir avec son environnement aussi bien
interne qu’externe.
Ce chapitre présente d’une manière générale le portrait de l’organisme d’accueil qui en-
globe l’historique de la société générale, sa mission,ses objectifs et ses activités.Il présente
aussi le contexte général du projet et les besoins de l’entreprise ainsi que la méthodologie
et la conduite du projet.
1.2 Le groupe SGABS
1.2.1 Présentation générale du groupe

Société Générale est l’un des tout premiers groupes européens de services financiers.
S’appuyant sur un modèle diversifié et intégré, le Groupe allie solidité financière, dynamique
d’innovation et stratégie de croissance durable afin d’être le partenaire de confiance de ses
clients, engagé dans les transformations positives des sociétés et des économies.
Acteur de l’économie réelle depuis plus de 150 ans avec un ancrage solide en Europe
et connecté au reste du monde, Société Générale emploie plus de 147 000 collaborateurs
dans 67 pays et accompagne au quotidien 31 millions de clients particuliers, entreprises et
investisseurs institutionnels à travers le monde, en offrant une large palette de conseils et
de solutions financières sur mesure. [1]
Figure 1.1 – Logo de l’entreprise
Avec une présence historique en Afrique, le Groupe Société Générale, acteur de réfé-
rence sur le marché bancaire, présente un positionnement unique sur la région, qui lui permet
d’offrir à ses clients l’expertise et le savoir-faire d’une banque internationale et la proximité
1.2. Le groupe SGABS 17
d’une banque locale.
Société Générale accompagne les économies locales et sert 3,7 millions de clients dont
150 000 entreprises. Pour asseoir ce positionnement, le Groupe a renforcé l’expertise tech-
nique sur la région de l’Afrique avec la création de son hub technologique panafricain.
Société Générale African Business Services (SG ABS) se positionne comme un centre
d’expertise des filières IT, et envisage d’accroître son effectif sur les prochaines années avec
une orientation axée sur l’accompagnement des métiers dans leur stratégie de création de
valeur pour leurs clients bancaires finaux, dont les besoins évoluent très rapidement dans
un contexte d’innovations technologiques.
SG ABS est une entité globale, autonome dans ses activités avec une vision de servir
l’Afrique depuis l’Afrique. SG ABS a un projet panafricain visant l’excellence et une équipe
épanouie, grâce au management de proximité, l’agilité des processus et politique de forma-
tion et de développement. SG ABS est une entreprise en pleine croissance sur le continent
africain. Chez SG ABS il y a quatre valeurs fortes : Engagement, Esprit d’équipe, Respon-
sabilité et passion pour des projets innovants [2].
Le challenge du groupe sur le continent africain est d’améliorer ces parts de marché
en continuant à être innovants et en s’appuyant sur toutes les expertises du Groupe pour
développer sa position.
1.2.2 Fiche signalétique
Dénomination sociale Société Générale African Business Services

Secteur Banque et Finance, Centre d’expertise IT, Hub technologique
panafricain, IT Bancaire.
Type Société anonyme, SA.
Taille de l’entreprise 500-600 employés.
Spécialisations Centre d’expertise IT, Hub technologique panafricain, Banque
et Finance, IT Bancaire, Digital Factory, Testing Factory, Études
et Développement, Architecture d’entreprise, Organisation et Proces-
sus, Qualité et Méthodes, Ingénierie et Technologies.
Siège social Casablanca, Maroc .
Adresse principale SOCIÉTÉ GÉNÉRALE AFRICAN BUSINESS SERVICES, Boulevard
Sidi Mohamed Ben Abdellah, Tour Ivoire 2, Marina Casablanca.
Site Web https ://particuliers.societegenerale.fr
Table 1.1 – Fiche Signalétique

1.2.3 Organigramme et administration de l’entreprise
C’est dans le département Digital Factory (encadré en rouge) où j’ai effectué mon stage
de fin d’études. il s’agit d’une entité qui travaille sur tout ce qui est en relation avec la pro-
grammation informatique, management des projets informatiques, pilotage des projets in-
formatiques, la partie monétique, et aussi sur la partie innovation. DiFa (Digital Factory) en
général travaille sur des types spécifiques des projets à savoir :
— Solutions innovantes multicanales (web, mobile, ...) … au bénéfice des clients ou des
collaborateurs
— Développements internes
Raison d’être et objectifs
— Réaliser des solutions digitales à destination des filiales de la région AFS, 1

DiFa a comme objectif de répondre rapidement à la vive concurrence africaine qui
ne cesse de prendre de l’ampleur. Nous contribuons à faire en sorte que les AFS
puissent répondre à ses objectifs stratégique, à savoir :
— Augmentation du PNB 2 .
— Participer à la réduction des coûts et de la rentabilité du réseau d’agences des
filiales.
— Fidélisations des clients en regard de leur segmentation.
— Consolidation du portefeuille client en favorisant le time value 3 de nos clients
importants et fidèles.
— Faciliter le positionnement d’offres et de produits bancaires sur de nouveaux mar-
chés (océan bleu), grâce à des solutions digitales et au travers de canaux digitaux.
Digital Factory SGABS devient dès lors, un accélérateur de la transformation digitale
pour les filiales AFS et a mis en place :
1. AFS : (se constitue de 11 pays) SGCI,SGBF,SGM,SGBG,SGMADA,SGCAM,SGT,SGC,SGB,SGBS
2. PNB : Produit Net Bancaire
3. time value : la disponibilité d’un produit ou d’un service
1.2. Le groupe SGABS 19
— Un Product Management Agile, afin de construire un produit basé sur la valeur de

façon itérative et incrémentale
— Une approche Client Centric 4 (UX Design), permet d’augmenter la satisfaction
client (qualité et délai)
— L’industrialisation des processus de livraison des releases (CI/CD), afin de réduire
le Time To Market
— Garantir une interopérabilité fonctionnelle et technologique grâce à une plateforme
digitale évolutive et innovante.
— Des usines logicielles fiabilisant la conception et la réalisation de nos solutions
digitales
Figure 1.2 – Organisation de la DiFa
La DiFa, avec ses choix technologiques, a mis en place une plate-forme digitale (In-
House 5 ) innovante permettant de répondre à la majorité des besoins digitaux de nos filiales
et de remplir sa promesse en terme de Time To Market.
Les programmes de la DiFa
En effet la DiFa durant des années, a essayé de construire des solutions IT pour ces
clients (les filiales), et pour ce faire la DiFa a lancé trois programmes 6 principaux pour sa-
tisfaire les besoins de ses clients et répondre à la forte concurrence dans l’Afrique :
Programme Bank-UP
C’est une application Bancaire en ligne (Web et mobile) conforme aux attentes du Groupe
en matière de time to market, sécurité et risques opérationnels.Une plateforme Digitale mu-
tualisée qui servira les filiales de la Zone AFS.
4. Client Centric : c’est prendre vos décisions en évaluant systématiquement leurs impacts sur vos clients
5. In House : zefzefzce
6. programme : constitué de plusieurs projets dont l’objectif est la production des solutions IT
Programme OpenR
Application qui facilite l’entrée du client en relation, et vérifie son éligibilité à créer un
compte auprès de la banque.
Programme Unibank
UniBank permet de connecter rapidement les applications (hébergées en interne ou ex-

terne) aux CBS des différentes filiales de la zone AFS :
— à travers un accès unifié et sécurisé (authentification de l’utilisateur basée sur des
standards, gestion des habilitations et piste d’audit).
— en faisant abstraction des SMGs sous forme d’APIs (Application Programming Inter-
face).
— UniBank est un sous-jacent technique structurant de la plateforme Digital Banking 7
que nous construisons avec le projet Bank-Up.
1.3 Présentation du projet
1.3.1 Problématique
Dans un monde qui va contre la multidisciplinarité, vers le centre de préoccupation unique,

il devient très difficile de créer un système qui pourrait fonctionner indépendemment des
autres entités.La collaboration avec d’autres systèmes est donc devenue une obligation car
de nos jours l’efficacité est devenue primordiale et un critère nécessaire . Ceci dit ,le SI
bancaire se trouve obligé de déléguer des tâches à des systèmes externes qui sont plus
efficaces. Cette pratique se montre très bénéfique dans plusieurs domaines mais elle est un
peu critique lorsque les données sont l’argent du client. En effet,plus le nombre d’interac-
tions avec les systèmes externes est grand plus les cybers attaques sont imminents.C’est
l’un des problèmes que nous essayons de résoudre dans notre projet. UNIBANK,le moteur
BACK-END de plusieurs projets au sein de SG-ABS, n’est plus capable de fonctionner de
manière autonome.En effet,avoir plusieurs projets consommant nos APIs fait de la gestion
des droits d’accès et des protocoles de communication une lourde problématique à traiter,
à titre d’exemple le connecteur CORE-BANKING AMPLITUDE fourni par SOPRA n’utilise
que le protocole SOAP, certains n’utilisent que le protocole REST, alors que d’autres uti-
lisent uniquement GRAPHQL, ceci rend le développement des API métier plus ardu , elles
doivent comprendre la logique des protocoles de communication utilisés par tous les four-
nisseurs externes.Ceci dit, au cas où un provider a été ajouté ou remplacé, tous les API
métier qui l’utilisent doivent être mises à jour. Actuellement les API métier transforment de
manière non appropriée les données envoyées par des prestataires externes et les utilisent
7. Digital Banking : Il s’agit de la digitalisation des usages bancaires.
1.4. Conduite de projet 21
sans les adapter au format interne et les conventions de la DIFA.Ce problème nous rend for-
tement couplés à ce provider ce qui rend le domaine métier également couplé au domaine
du provider, ceci posera problème tôt ou tard.
1.3.2 Objectifs du projet
L’objectif de notre projet de fin d’études consiste à développer un catalogue d’APIs Bridge
pour aboutir aux objectifs essentiels de la solution qui sont :
• Assurer une livraison rapide afin de réduire le Time To Market.
• Définir les fonctionnalités du système sous forme d’APIs génériques réutilisables prêtes à
être consommer.
• Mise en place d’une couche qui englobe l’ensemble des protocoles de communication uti-
lisés par les projets consommateurs.
• Supprimer toute communication directe avec les SMGs et encapsuler la communication
avec les systèmes d’information par des couches de sécurité supplémentaires. En effet,
notre solution doit s’aligner avec les obligations du groupe SG en matière de réglemen-
tations sécuritaires en ne permettant plus aux tiers de communiquer directement avec les
SMGs mais plutôt de passer impérativement par le Bridge pour gérer les autorisations de
communications et l’authentification.
1.4 Conduite de projet
Le choix de la conduite du projet est une phase déterminante pour accomplir le projet
dans les bonnes conditions. Il faut donc bien définir le processus de développement et en
déduire le planning du projet à suivre.
1.4.1 Ressources humaines
Dans le tableau suivant nous présentons les ressources humaines qui ont participé au
développement de notre projet.
Nom et prénom Rôle

Comité de suivi Madame ETTAZI Widad Professeur à l’ENSIAS
Monsieur RAFIK Zakaria Tech lead à SG ABS
Maîtrise d’œuvre CHQIR Samia Elève ingénieur à l’ENSIAS
BENSIALI Abdellah Directeur DIFA
MORCHID Abdellah Manager Opérationnel
SAKHI Mohamed Directeur de programme
RAFIK Zakaria Tech lead
ELKHATIB Mohammed Tech lead
BELEFKIH Zakaria PPO
EL MANNANI Hiba BA
Maîtrise d’ouvrage Société Générale ABS Commanditaire du projet
1.4.2 Méthodologie de travail
Afin de structurer les différentes phases de notre projet, et qui vont être explicitées par
la suite, et afin de garantir une organisation optimale, il est nécessaire de fixer un cadre qui
simplifie indéniablement le lancement du projet, sa progression et sa réussite par la suite.
La méthodologie de développement, pour être opérationnelle, doit être basée sur 3 com-
posantes : une démarche qui définit les étapes, phases et tâches de mise en œuvre, des
formalismes ou en d’autres termes l’ensemble des modélisations, et finalement une organi-
sation et des moyens de mise en œuvre. La première étape est le positionnement par rapport
aux objectifs de notre projet. Ceci dit il fallait identifier rapidement les enjeux et les outils de
travail auxquels nous allons avoir recourt dans les étapes suivantes du travail. Ensuite vient
l’ordonnancement du projet, c’est-à-dire le découpage des tâches selon l’ordre de nécessité.
Il fallait également estimer le temps de réalisation de chaque tâche. Une fois que le projet
est en route, il fallait en assurer le suivi, pour contrôler l’avancement global, le respect du
planning, et pour apporter des ajustements au fur et à mesure du développement. En paral-
lèle, une évaluation des tâches effectuées avait lieu avec mes encadrants afin de prendre
en compte les remarques consignées et de garantir que la progression du travail ne déborde
pas du cadre antérieurement fixé.Afin d’assurer le respect des délais et le bon déroulement
du projet, nous avons opté pour la méthode agile SCRUM qui nous fournit un cadre d’agilité
simple à comprendre. Elle se compose de rôles et d’événements , ainsi que des règles per-
mettant un rythme fixe et des réunions planifiées à l’avance dans un but bien défini. SCRUM
nous a permis de contourner les difficultés et les imprévus avec une flexibilité opportune tout
au long du processus de développement.
Figure 1.3 – Méthode Scrum
Cette figure schématise les étapes suivantes :
• Les fonctionnalités souhaitées sont collectées dans le product Backlog et classées par
priorité.
• Le développement du produit est rythmé par une série d’itérations, qui sont appelées
des sprints. Le contenu du sprint est défini par l’équipe, en tenant compte des priorités et
de sa capacité. A partir de ce contenu, l’équipe identifie les tâches nécessaires et s’engage
pour réaliser les fonctionnalités sélectionnées pour le sprint.
• Pendant un sprint, des points de contrôle sur le déroulement des tâches sont effectués
quotidiennement. Cela permet d’identifier les obstacles qui ralentissent l’équipe, déterminer
l’avancement par rapport aux engagements et d’appliquer des ajustements pour assurer le
succès du sprint.
• A la fin de chaque sprint, l’équipe présente dans la démo ce qu’elle a ajouté au produit
pendant le sprint. Cet incrément du produit est potentiellement livrable, son évaluation per-
met d’ajuster le carnet de produit pour le sprint suivant.
Comme illustré sur la figure, la méthode SCRUM repose sur le découpage d’un projet en
Itérations, nommées « sprint », d’une durée de 1 à 4 semaines (dans notre cas 2 semaines).
Une équipe au sens Agile est un petit groupe de personnes, affectées au même projet ou
programme. Une petite minorité des membres de l’équipe peut être des collaborateurs à
temps partiel.
La notion d’équipe implique une responsabilité partagée : les résultats, bons ou mauvais,
devraient être attribués à toute l’équipe plutôt qu’à n’importe quel individu.
Une équipe agile est une équipe auto-organisée et pluridisciplinaire. Elle choisit la meilleure
façon d’accomplir son travail, au lieu d’être dirigée par des personnes externes à l’équipe,elle
a toute les compétences nécessaires pour effectuer le travail sans dépendre d’autres per-
sonnes n’appartenant pas à l’équipe, qu’elles soient techniques (conception, développe-
ments, , tests) ou fonctionnelles (connaissance du domaine métier, capacité et habilité de
prise de décision).
Au niveau de la DiFa, une équipe agile est appelée Pizza Team d’une taille de 5 à 11
personnes max et d’une Extended Team avec des rôles supports :
— Pizza Team :
— Product Owner [3]
— Proxy Product Owner[4]
— Business Analyst[5]
— Scrum Master[6]
— Tech Lead[7]
— Développeur[8]
— Extended Team :
— Directeur de programme
— PMO
— Architecte solution
— Ingénieur DevOps
— UX Designer
— UI Designer
— Coach agile[9]
Pizza Team
Vue que l’organisation humaine au sien de la DiFa ne ressemble pas réellement à Scrum,
DiFa a proposé une solution pour s’y adapter, c’est la Pizza Team :
Figure 1.4 – Pizza Team
DevOps
Nous avons utiliser l’approche devops dans le but de dynamiser et améliorer le dévelop-
pement et accélérer la mise à disposition de nouvelles fonctionnalités.
Cette approche sera explicitée par la suite.
Figure 1.5 – Devops
1.4.3 Planification
La planification du projet est une phase importante dans un projet. Elle consiste à prévoir
le déroulement de ce dernier tout au long des phases constituant le cycle de réalisation. Le
fait que le projet adopte Scrum comme processus de développement, impose une planifica-
tion partielle du projet.
La démarche que nous avons suivie pour mettre au point notre système est explicitée par le
tableau suivant :
Taches Durée Début Fin

Cadrage du projet 1mois 15/02/2022 22/03/2022
Sprint 1 15 jours 23/03/2022 06/04/2022
Sprint 2 14jours 07/04/2022 22/04/2022
Sprint 3 14jours 25/04/2022 10/05/2022
Sprint 4 14jours 11/05/2022 26/05/2022
Sprint 5 14jours 27/05/2022 13/06/2022
Rédaction 4mois 01/03/2022 15/06/2022
Table 1.2 – Planification du projet
Diagramme de GANTT
Pour organiser mon projet en phases chronologiques et organisationnelles, j’ai élaboré

un diagramme de GANTT représentant la phase de planification. Cette phase consiste à pré-
voir le déroulement du projet tout au long des phases constituant le cycle de développement.
Un extrait de ce diagramme est présenté dans la figure ci-dessous.
Figure 1.6 – Diagramme Gantt 1 du projet

1.5. Conclusion 27
1.5 Conclusion
Dans ce chapitre, nous avons introduit le cadre général du stage. En premier lieu, nous
avons présenté l’organisme d’accueil et ses activités principales. Ensuite, nous avons cla-
rifié le contexte et la problématique du projet, les objectifs généraux à atteindre ainsi que
les étapes suivies lors de la mise en œuvre. Finalement, la planification des tâches a été
exposée. Le chapitre suivant sera consacré à l’analyse des besoins.
Chapitre 2
Étude détaillée du projet
28
2.1. Introduction 29
2.1 Introduction
Dans ce chapitre, nous menons une analyse des besoins pour détailler ensuite le dia-
gramme de cas d’utilisation. La phase d’analyse et spécification des besoins présente une
étape primordiale dans le développement d’un projet. En effet, elle permet de mieux com-
prendre le travail demandé en dégageant les besoins des différents utilisateurs de notre
système. Nous allons alors rechercher à caractériser les fonctions offertes par ce dernier
pour satisfaire les besoins de ses différents utilisateurs.
2.2 Analyse de l’existant
L’Open Banking est une initiative réglementaire qui exige aux banques d’ouvrir leurs API à
des services tiers. L’objectif est de permettre aux APIs de partager les données financières
des clients avec les tiers qu’ils souhaitent, de manière conforme et standardisée. L’Open
Banking fournit des orientations sur la manière dont les banques peuvent moderniser leurs
approches et améliorer le service aux clients. Cependant, chaque banque adoptera sa propre
approche en pratique pour que ces projets fonctionnent pour son activité et c’est pourquoi la
Digital Factory a créé sa plateforme digitale UNIBANK.
Unibank est une plateforme d’Open Banking qui ouvre le SI de SG et partage des don-
nées avec des tiers en toute sécurité et consentement du client. Elle permet de connecter
les applications consommatrices et APIs développées avec des ressources et partenaires
externes. Elle est composée d’une couche d’APIs qui permet de masquer la complexité tech-
nique vis-à-vis des applications communiquant avec le SI (pas uniquement CBS) ou avec
d’autres systèmes externes. Cette plateforme est construite par plusieurs couches.
La couche Bridge où s’inscrit notre projet a été mise en place pour faciliter la communica-
tion avec le SI bancaire tout en assurant la séparation du métier et du technique en englobant
justement la technicité des services qui y sont implémentés. Cependant, cette contrainte n’a
pas été respecté à cause de la charge de travail qui pesait sur l’équipe, le Bridge a été donc
pollué par des données et des règles de gestion métier. C’est dans ce cadre que notre projet
a vu le jour. Le Bridge va donc assurer également le respect de la réglementation sécuritaire
et assurer aussi la sécurité du groupe et de ses clients.
Le premier usage développé autour de cette plateforme est la banque à distance Retail
SG Connect qui est le projet Bank-Up. Elle est considérée comme la solution phare de la
Digital Factory. SG CONNECT est une application Mobile et Web permettant aux clients de
la Société Générale de la Région de l’Afrique de disposer de différents services bancaires
à distance accessible 24H/24 ET 7J/7.Ce service permet d’accéder aux comptes bancaires
et de réaliser des transactions. L’application est aujourd’hui disponible pour les filiales sui-
vantes : Burkina Faso, Madagascar, Mauritanie, Congo, Tchad, Bénin, Sénégal, Ghana, Gui-
née, Côte d’ivoire, Cameroun. Elle englobe plusieurs fonctionnalités comme la consultation
des comptes courants et épargnes, l’accès Wallet, Virements ...
30 Chapitre 2. Étude détaillée du projet
2.3 Limitations de l’existant

La Société Générale African Business Services dispose déjà de la solution UNIBANK, qui
est considérée comme un premier pas dans la transformation digitale. Aujourd’hui cette solu-
tion présente des limitations en termes d’architecture,ce qui rend pénible l’ajout de nouvelles
fonctionnalités.Ceci dit,les besoins actuels de SGABS dépassent largement les fonctionna-
lités offertes par ces APIs.
Nous allons énumérer ci-dessous les limitations de cette solution :
• Des APIs non personnalisées, purement métier et non génériques.
• Plusieurs fonctionnalités faisant appel au même SMG enclencherons une redondance du
développement de la phase de transformation et mapping, ce qui enfle et augmente le Time
To Market et ralentit le développement dû à l’inexistence d’une couche englobant les APIs
techniques.
• La surcharge de la plateforme digitale avec des données indésirables, en fait, la couche
bridge a été polluée par les données métier et la réponse du SMG y était personnalisée sui-
vant le besoin ce qui doit normalement être fait dans la couche métier dédiée à cette fin.
• L’appel aux connecteurs externes engendre un problème de gestion d’authentification.
• Les SMGs utilisent le protocole d’échange d’information SOAP alors que les APIs métiers
communiquent avec le REST ou le GraphQL.
2.4 Analyse et identification des besoins

Nous avons abordé dans la partie précédente l’ensemble des limitations de l’existant.Afin
d’atteindre les objectifs souhaités, il faut bien identifier les besoins fonctionnels et non fonc-
tionnels. Aujourd’hui SG ABS veut encore étendre les fonctionnalités de son système, ses
besoins s’articulent autour des points suivants :
2.4.1 Besoins fonctionnels

En effet, les différentes réunions du Backlog grooming ont permis de spécifier les exi-
gences fonctionnelles que le projet doit satisfaire. Ainsi, la solution dans sa globalité doit
remplir les spécifications fonctionnelles suivantes :
• Récupération de la liste des taux de base.
• Consultation du détail des dirigeants.
• Recherche des détails de l’activité d’un compte.
• Gestion des chéquiers.
• Consultation des taux de change.
• Consultation des devises.
• Récupération de la liste des relations.
• Consultation de la liste des emplois et revenus.
• Récupération des détails d’un employeur .
2.4. Analyse et identification des besoins 31
Puisque nous utilisons la méthodologie Scrum, nous avons exprimé les besoins fonctionnels
de notre projet sous forme d’user stories :
Figure 2.1 – Exemple d’user story publiée sur JIRA pour lister les taux de change
Figure 2.2 – Les sous taches des user stories
Ainsi pour exprimer le besoin permettant à l’utilisateur de convertir des devises rapide-
ment et facilement au niveau de l’application web et mobile nous avons rédigé l’EDB suivant :
Figure 2.3 – EDB d’un convertisseur de devises-1

Figure 2.4 – EDB d’un convertisseur de devises-2

Figure 2.5 – Maquette du convertisseur de devises
Les figures suivantes présentent les critères d’acceptation et UATs de cette fonctionnalité
ainsi que les règles de gestion :
Figure 2.6 – Critères d’acceptation et UATs - Taux de change
Figure 2.7 – Les règles de gestion - Taux de change
2.4.2 Besoins non fonctionnels
Avant de présenter le diagramme de cas d’utilisation, il reste important de présenter éga-

lement les besoins non fonctionnels, comme contraintes auxquelles est soumis le système
pour sa réalisation et son bon fonctionnement, et que nous devons respecter pour garantir
la performance de notre projet. Donc pour fournir un produit performant qui respecte les exi-
gences de la DIFA et afin de garantir la satisfaction de nos clients, des contraintes doivent
être prises en compte tout au long du développement du projet :
2.5. Diagramme des cas d’utilisation 37
• Rapidité : En termes d’optimisation des traitements pour avoir un temps d’exécution

raisonnable tout en répondant aux besoins exprimés.
• Efficacité : La platforme digitale doit être fonctionnelle indépendamment de toutes

circonstances pouvant entourer les consommateurs.
• Maintenabilité et scalabilité : Le code doit être lisible et structuré afin d’assurer son
état évolutif et extensible par rapport aux besoins qui peuvent submerger.
• Réutilisabilité : Le code doit être facile à comprendre, à exploiter et à utiliser.
• Sécurité : Gestion des droits d’accès et supprimer toute communication directe avec
les SMGs.
• Fiabilité du système :capacité à gérer les erreurs.
2.5 Diagramme des cas d’utilisation
Chaque usage que les acteurs font du système est représenté par un cas d’utilisation.
Chaque cas d’utilisation représente une fonctionnalité qui leur est offerte afin de produire le
résultat attendu. Ainsi, le diagramme de cas d’utilisation décrit l’interaction entre le système
et l’acteur en déterminant les besoins de l’utilisateur et tout ce que doit faire le système pour
l’acteur. Ci-dessous le diagramme de cas d’utilisation général de notre projet :
Figure 2.8 – diagramme de cas d’utilisation des APIs du Bridge
Les acteurs dans le diagramme des cas d’utilisation de notre système sont : Bank-UP,
NEXTGEN, OpenR et LDV qui représentent les projets consommateurs des APIs que nous
développons.Amplitude, TAGPAY, GIP, DELTA, INFOBIP, EMAIL représentent les ressources
connectés au bridge.
Bank-UP : banque à distance qui permet aux utilisateurs la gestion complète de leurs comptes
sans avoir besoin de visiter l’agence.
NEXTGEN : banque d’entreprise permettant à différentes sociétés de bénéficier de fonction-
2.6. Conclusion 39
nalités exclusives.
OpenR : Application qui facilite l’entrée du client en relation, et vérifie son éligibilité à créer
un compte auprès de la banque.
LDV : Programme vérifiant l’éligibilité d’un client à bénéficier d’un crédit en une heure.
Amplitude : système bancaire permettant de gérer toutes les opérations et transactions ban-
caires.
TAGPAY : système qui facilite le paiement des factures de nombreux émetteurs de factures
externes existant dans le monde.
INFOBIP : système qui reçoit les demandes d’envoi des SMS afin de les traiter et renvoyer
les notifications SMS aux utilisateurs.
EMAIL : système permettant la notification des utilisateurs des opération exécutés par son
compte et aussi le partage de l’historique des transaction etc...
GIP : système qui permet d’effectuer des virements instantanément.
DELTA : une solution qui stocke les cartons de signature d’un client de la banque.
compilance : système qui vérifie l’éligibilité d’un client à créer un compte auprès de la banque.
2.6 Conclusion
Ce chapitre nous a permis la spécification des besoins auxquels doit répondre notre sys-
tème, et ensuite l’analyse de ces besoins . Nous avons essayé de couvrir les différents
besoins fonctionnels et non fonctionnels de notre système. Nous avons fourni une analyse
plus détaillée de ces besoins grâce à un diagramme de cas d’utilisation relatif à tous les ac-
teurs réagissant avec notre système.Nous essayerons dans le chapitre qui suit de concevoir
clairement l’architecture de notre système.
Chapitre 3
Etude technique
40
3.1. Introduction 41
3.1 Introduction
Après l’analyse et la spécification des besoins qui a servi à identifier à chaque sprint les
acteurs réactifs du système et leur associer chacun l’ensemble d’actions avec lesquelles il
intervient, nous passons, à travers ce chapitre, pour décrire l’architecture de notre solution et
la conception élue pour réaliser convenablement le travail demandé dans l’objectif de donner
un résultat optimal et satisfaisant au client. Nous allons par la suite détailler les différents élé-
ments de conception, à savoir l’architecture de notre solution tout en répondant aux besoins
déjà cités, dans le but de décrire en détail chaque couche et de mettre en évidence l’utilité
de notre projet et sa valeur ajoutée dans le processus de digitalisation au sein de SG ABS.
3.2 Architecture d’UNIBANK

La plateforme digitale UNIBANK innovante permettant de répondre à la majorité des be-
soins digitaux des filiales.
C’est une plateforme Open Banking permet aujourd’hui de construire rapidement des so-
lutions consommant des services CBS (ou autre) en faisant abstraction de la complexité du
CBS.
Figure 3.1 – Rôle des APIs Unibank dans le cadre du programme Bank Up
On distingue 3 couches au sein de la plateforme Unibank :
L’API Bridge dont le rôle est de communiquer de manière sûre avec les systèmes d’infor-
mations externes (SMGs, Infobip, …) et assurer l’intégration et le mapping et la traduction
entre les APIs Unibank et ces systèmes.
42 Chapitre 3. Etude technique
Les APIs métier dont le rôle d’exploiter les données remontées du bridge ou issues des
systèmes externes en appliquant des règles de gestion métier afin de répondre à un besoin
défini du client applicatif (ex : afficher les comptes, effectuer un virement,…).
Des composants supplémentaires appelés Gateways dont l’objectif est d’assurer un ac-
cès sécurisé aux APIs Unibank via un mode d’authentification et d’exposer au client applicatif
les données provenant des APIs Unibank.
Cartographie de la plateforme digitale UNIBANK
Figure 3.2 – Cartographie de la plateforme
Avantages de la consommation des APIs Unibank :

- Architecture multi-tenant et un socle technique permettant le développement des services
digitaux multi-filiale rapidement.
- La brique IAM (Identity and Access management) de la plateforme offre les capacités né-
cessaires pour sécuriser les accès aux APIs et aux clients frontaux en proposant une Au-
thentification multi-facteurs (TOTP, SecureID), ainsi que la gestion des autorisations et des
rôles.
- Grâce aux services SG cloud managés, les capacités d’infrastructure sont mises à la dis-
position des équipes pour construire de manière plus rapide les différents environnements
de développement à la production.
- L’intégration avec les services Legacy et les partenaires devient plus rapide et transparente
et ceci grâce au Design et découpage par domaine métier : (ex : Domaine Accounts, Loans,
Transfers, Branches ATMs ...etc).
3.3. Architecture technique 43
3.3 Architecture technique

Pour implémenter sa solution, unibank a suivi une architecture assez robuste, c’est l’ar-
chitecture hexagonale, l’objectif principal de cette architecture est de découpler la partie
métier d’une application de ses services techniques dans le but de préserver la partie métier
pour qu’elle ne contienne que des éléments liés aux traitements fonctionnels. Cette architec-
ture est aussi appelée “Ports et Adaptateurs” car l’interface entre la partie métier et l’extérieur
se fait, d’une part, en utilisant les ports qui sont des interfaces définissant les entrées ou sor-
ties et d’autre part, les adaptateurs qui sont des objets adaptant le monde extérieur à la partie
métier.
Dans la plupart des logiciels, la logique métier qui est implémentée est ce qui constitue la
plus grande valeur ajoutée puisque c’est cette logique qui rend le logiciel fonctionnel. Pour-
tant très souvent une grande partie du développement se concentre sur l’interface graphique,
la persistance des données ou le partage d’informations avec des systèmes externes.
3.3.1 Architecture hexagonal

L’idée est donc de tenter de préserver ce qui représente la plus grande valeur ajoutée
d’une application : la logique métier.
Figure 3.3 – Architecture en couches
Domaine métier (User Side)
C’est le côté par lequel l’utilisateur ou les programmes extérieurs vont interagir avec l’ap-
plication. On y trouve le code qui permet ces interactions. Typiquement, le code d’interface
utilisateur, les routes HTTP pour une API, les sérialisations en JSON à destination de pro-
grammes qui consomment l’application sont ici.
C’est le côté où l’on retrouve les acteurs qui pilotent l’application.
Application (Business Logic)
C’est la partie que l’on veut isoler de ce qui est à gauche et à droite. On y trouve tout
le code qui concerne et implémente la logique métier. Le vocabulaire métier et la logique
purement métier, ce qui se rapporte au problème concret que résout l’application, tout ce qui
en fait la richesse et la spécificité est au centre. Dans l’idéal, un expert du métier qui ne sait
pas coder pourrait lire un bout de code de cette partie et vous pointer une incohérence.
Infrastructure (Server Side)
C’est ici qu’on va retrouver ce dont l’application a besoin, ce qu’elle pilote pour fonction-
ner. On y trouve les détails d’infrastructure essentiels comme le code qui interagit avec la
base de données, les appels au système de fichier, ou le code qui gère des appels HTTP
d’autres applications .
Au sein de la DiFa, Unibank a adapté cette architecture pour répondre a ses besoins tech-
niques et surtout fonctionnels, mais vu que le Bridge dépend d’un CBS externe, nous étions
obligés de faire quelques modifications coté architecture et donc nous nous sommes basés
principalement sur deux couches :
unibank-domain (Domain layer)
Au niveau d’unibank-domain, nous avons mis deux sous projets java :
— Platform model : présente le socle technique du domaine (les annotations, gestions
des permissions, documentations ...)
— Core domain : contient des classes java qui présentent un besoin qui a été anticipé.
En géneral, ce module représente la logique métier de la banque qui est divisé en
trois packages :
— Base : Un package qui contient les classes pojo nécessaires pour créer une re-
quête/réponse pour satisfaire un besoin anticipé.
— Business : Un package qui a comme objectif la gestion des administrateurs et
utilisateurs.
— Providers : C’est ici que la majorité de notre travail a été faite.Il représente les
classes pojo utilisées par presque tous les connecteurs.
unibank-bridge (Application Layer)
Il contient en général un ensemble des connecteurs qui seront explicités par la suite, un
module de configuration et un module d’exposition qui joue le rôle d’un Adaptateur :
— Les connecteurs : Des modules qui exposent des APIs selon un besoin souvent tech-
nique.
— Module de configuration : Ce module gère la partie de la configuration des filiales et
des connecteurs, chaque environnement de développement a sa propre configuration
(fichier de configuration ou bien Vault).

— Module d’exposition (Adaptateur) : Pour assurer un couplage faible, unibank a pro-
posé ce module pour gérer la partie de la création des Beans java.Dans ce module et
en se basant sur le module de configuration en peut exposer nos APIs pour n’importe
quelle connecteur.
La figure ci-dessous montre l’architecture technique.
Figure 3.4 – Architecture technique de Unibank
3.3.2 Domain-driven design

La conception basée sur le domaine (Domain-driven design) est une approche de concep-
tion logicielle axée sur la modélisation de logiciels pour faire correspondre un domaine en
fonction des commentaires des experts de ce domaine.
En terme de programmation orientée objet, cela signifie que la structure et le langage
du code logiciel (noms de classes, méthodes de classes, variables de classes) devraient
correspondre au domaine métier.
Domain-driven design repose sur les objectifs suivants :
— mettre l’accent sur le domaine de base et la logique du domaine.
— lancer une collaboration créative entre les experts techniques et les experts de do-
maine pour peaufiner itérativement un modèle conceptuel qui aborde des problèmes
de domaine particuliers.
3.3.3 Command and Query Responsibility Segregation

En effet, le bridge est basé aussi sur un pattern de séparation entre les opération de lec-
ture et d’écriture. Ce pattern est basé sur une idée simple qui consiste à séparer le domaine
en se basant sur le type d’opération voulue.Pour expliciter l’idée nous allons prendre par
exemple les deux scénarios suivants :
— scénario 1 : un utilisateur veut voir sa liste des charges, techniquement la liste des
charges est une simple classe dans le domain, l’utilisateur va donc s’authentifier et il
peut par la suite voir sa liste des charges.La consultation de la liste des charges ne
demande pas une logique métier ou une validation assez avancée des champs, car
on va seulement faire appel a une base de donnée.
— scénario 2 : un utilisateur veut modifier une charge, là les choses vont être un peu
complexe car on va modifier dans la base de données,ceci n’est pas évident au niveau
technique et architectural parce qu’il faut commencer par la validation, la gestion des
transactions et la sécurisation des données qui vont être envoyées.
Nous pouvons donc déduire que si les deux scénario utilisent la même classe dans le domain,
cela va générer un problème :
— si on utilise une classe domain qui a de la logique derrière, donc le deuxième scénario
va réussir, mais le premier non.
— si on utilise une classe domain qui n’a pas de logique derrière, donc le premier scé-
nario va réussir, mais le deuxième non.
Les charges de travail de lecture et d’écriture sont souvent asymétriques, avec des exigences
de performance et d’échelle très différentes.
Figure 3.5 – Les anciennes architectures
On peut dire généralement que les anciennes architectures qui se basent pas sur CQRS
génèrent plusieurs problèmes, notamment :
— Décalage entre les représentations en lecture et en écriture des données, comme des
colonnes supplémentaires ou des propriétés qui doivent être mises à jour correcte-
ment même si elles ne sont pas nécessaires dans le cadre d’une opération.
— La contention des données peut se produire lorsque des opérations sont effectuées
en parallèle sur le même ensemble de données.
— L’approche traditionnelle peut avoir un effet négatif sur les performances en raison
de la charge sur le stockage de données et la couche d’accès aux données, et de la
complexité des requêtes requises pour récupérer les informations.
— La gestion de la sécurité et des autorisations peut devenir complexe, car chaque entité
est soumise à des opérations de lecture et d’écriture, ce qui peut exposer des données
dans le mauvais contexte.
Solution :
Le CQRS sépare la lecture et l’écriture dans différents modèles, en utilisant des commandes
pour mettre à jour les données et les requêtes pour lire les données.
Figure 3.6 – L’architecture CQRS
3.3.4 Utilisation des Tokens

Après la génération du Token par WSO2,il passe obligatoirement par une couche dans la-
quelle on vérifie si le Token est valide,expiré et on vérifie le type d’utilisateur qui le consomme,
pour cela un package nommé Jwt dans unibank-platform va nous servir. On peut résumer la
vérification des Tokens comme suit :
1. L’utilisateur envoi le Token dans le header de la requête Http.
2. En se basant sur un Http filter qui est implémenté dans unibank-platform, en appli-
quant la méthode parseToken on peut capter les informations d’utilisateur :
Figure 3.7 – Exemple des données d’un utilisateur en se basant sur son Token
3. La méthode parseToken permet de déchiffrer le token en se basant sur l’algorithme

RS256 que nous allons détaillé par la suite.
4. Aprés le déchiffrage du Token, on peut savoir l’utilisateur qui veut consommer l’API,
ainsi que ses droits.
L’algorithme RS256
est un algorithme de cryptographie asymétrique, ce qui signifie que l’émetteur a une clé
privée qu’il utilise pour générer la signature et le consommateur JWT utilise une clé publique
pour valider la signature. Cet algorithme est utilisé généralement pour échanger des données
confidentielles sur un réseau.
Figure 3.8 – Le principe d’algorithme RS256
Cet algorithme est basé sur une problématique mathématique assez célèbre, en effet
supposant qu’on a p * q = n avec n ∈ Z et p et q sont des nombres premiers, si nous savons
p et q en peut déduire n, mais le contraire est très difficile.
3.4 Connecteurs
3.4.1 AMPLITUDE
Amplitude est un système bancaire de base (CBS)utilisé pour prendre en charge les
transactions les plus courantes d’un établissement bancaire.
Les éléments d’un système bancaire de base sont notamment les suivants :
— générer et gérer des emprunts.
— ouvrir des comptes.
— traiter des dépôts et des retraits d’espèces.
— traiter des paiements et des chèques.
— calculer des intérêts.
— conduire des activités de gestion de la relation client (CRM, Customer Relationship
Management).
— gérer les comptes de la clientèle.
3.4. Connecteurs 49
— établir des critères tels que solde minimum, taux d’intérêt ou encore nombre de retraits
autorisés.
— fixer des taux d’intérêt.
— gérer l’enregistrement de toutes les transactions bancaires.
Les fonctions bancaires de base diffèrent selon le type spécifique de l’établissement,ils sont
souvent spécialisées dans un type particulier d’opérations bancaires.
Pour répondre a ses besoin métiers, La DiFa utilise le CBS de Sopra, cette dernière a pro-
posé une solution assez robuste, il s’agit de la solution amplitude qui est disponible en deux
versions : V10 et V11, la différence entre eux se manifeste dans le header envoyé. Chacune
des filiales possède une version d’AMPLITUDE(la V10 ou la V11) .
En effet,il y’a une classe abstraite AmplitudeBankingProvider qui contient les méthodes
nécessaires pour envoyer des requêtes Https au CBS pour les APIs qui sont utilisées dans
les deux versions,mais dans le cas contraire lorsqu’une API est utilisée que par une ver-
sion alors elle sera implementée dans l’une des classes AmplitudeBankingProviderV10 ou
AmplitudeBankingProviderV11 selon la version voulue.Ces classes héritent de la classe Am-
plitudeBankingProvider, et cette dernière se base sur AmplitudeClient qui a des méthodes
qui facilite l’envoi des requêtes Https au CBS. Pour mieux illustrer,la figure suivante montre
le diagramme de séquence du connecteur Amplitude.
Figure 3.9 – Diagramme de séquence d’amplitude
Afin de mieux comprendre le processus de transformation ,nous allons se baser sur la

figure suivante :
Figure 3.10 – Diagramme de séquence de transformation
En effet, une fois request reçue ,la classe transform engine charge le fichier correspon-
dant et fait appel a la dépendance de pebble afin de remplir la template par les informations
voulues.Après avoir reçu request sous format XML le bridge l’envoie à SMG afin de rece-
voir une réponse qui va parcourir presque le même chemin .En effet, la réponse passe par
transform engine qui fait appel au fichier des specs JOLT qui nous rend une reponse sous
format JSON qu’on peut exploiter par la suite.
3.4.2 INFOBIP
Infobip reçoit les demandes d’envoi des SMS afin de les traiter,il renvoit un code au client
qui est d’une durée de validité de 2 min puisqu’ils sont soumis à une authentification forte.
Exemple d’implementation d’INFOBIP-souscription
Après la souscription a un produit BankUp depuis le module spécifique «Souscription»

Pour chaque Souscription , un fichier JSON contenant les informations clients est généré et
transmis à la plateforme UNIBANK.
3.4. Connecteurs 51
Figure 3.11 – exemple d’implementation d’infobip -chaine de souscription
La chaine de souscription UNIBANK récupère les fichiers JSON et procède à des vérifi-
cations de la structure et du contenu avant de procéder à la création des clients. Un premier
SMS contenant le mot de passe temporaire est envoyé au client sur son numéro de télé-
phone contractuel.
3.4.3 EMAIL
Le courrier électronique repose sur le concept du client/serveur. Ainsi, l’utilisation d’e-
mails requiert deux composants :
— un client de mails (Mail User Agent : MUA) tel que Outlook, Messenger, Eudora, ...
— un serveur de mails (Mail Transport Agent : MTA) tel que SendMail.
Les clients de mails s’appuient sur un serveur de mails pour obtenir et envoyer des mes-
sages.
L’envoi des mails par les API backend est primordiale dans le monde bancaire, car il va
rendre le traitements des données des clients sécurisés, et le client reste toujours notifié par
toutes les opérations qui sont exécutés par son compte, c’est pour ça qu’EMAIL connecteur
va faciliter l’envoi des mails aux clients après une ou plusieurs opérations.
3.4.4 TagPay
TagPay est une solution qui aide à payer les factures de nombreux émetteurs de factures
externes existant dans le monde classés par le service qu’ils fournissent. Il fonctionne en 5
étapes :
— Chargement de la liste des facturiers : Cette étape consiste à récupérer la liste
des facturiers et leurs categories. Elle permet également de récupérer, pour certains
facturiers, quelques champs du formulaire de paiement.
— Exécuter le paiement : Cette étape consiste à réaliser l’opération de paiement.
— Réconciliation et comptabilisation : La réconciliation des transactions d’une pé-

riode consiste à comparer la liste des opérations réalisées par les clients sur cette
période et la liste des opérations confirmées par les facturiers (liste reçue de Tag-
Pay).
— Règlement : Cette étape consiste à réaliser un flux financier de règlement à TagPay

. Le règlement portera sur le montant des factures payées sur une période (la même
période de réconciliation) Les règles de partages de commission sont à définir avec
la filiale
3.4.5 Delta Signature
Delta Signature est une solution pour stocker un carton de signature d’un client de la
banque. Il est basé sur le protocole de communication SOAP.Un carton de signature est un
document interne à un organisme bancaire et sur lequel apparaît l’identité d’une personne
ayant un compte dans cet organisme. Delta Signature autorise 7 opérations :
— startSession : permet d’ouvrir une session en donnant un jeton
— getClient : permet de renvoyer les informations d’un client en se basant sur son code
— getCompte : permet de renvoyer les informations du compte d’un client en se basant
sur son numéro de compte
— getTypeCarton : permet de renvoyer un type de carton de signature
— setCarton : permet de stocker un carton de signature
— valCarton : permet de renvoyer les types du carton de signature qui existent
— endSession : permet de fermer la session en donnant un jeton
Le bridge expose un endpoint en Rest et en GraphQL qui ne fait appel qu’aux 4 opérations
fournies par Delta Signature à savoir :
— Ouverture de session
— Récupération du client
— Stockage du carton de signature
— Fermeture de session
Le stockage du carton de signature d’un client est une étape très importante dans le pro-
cessus d’entrer en relation, il aide à authentifier les chèques d’un client et autres documents,
par exemple une demande de crédit. Lors du processus d’entrer en relation, le chargé de
clientèle scanne et stocke le carton de signature après avoir créé le compte et le client dans
Amplitude (Core Banking System).
3.5 Etude benchmarking des outils
Après avoir vu l’architecture de notre solution, il est primordial de passer au choix entre
les différentes outils existantes. Nous allons donc effectuer une étude comparative entre les
solutions les plus populaires.
3.5. Etude benchmarking des outils 53
3.5.1 Spring Boot et Node.js
Présentation de Spring Boot
Implémenté en Java, Spring Boot permet le démarrage rapide d’une application auto-
nome de niveau production. Il s’agit d’une version bootstrapped de la plate-forme Spring.
L’idée de Spring Boot est qu’il est très facile à exécuter, ce qui minimise la quantité de tracas
liés à l’exécution d’une application.
Spring Boot tourne autour des dépendances. Il repose fortement sur des annotations
ou XML. Cela simplifie la configuration, ce qui est énorme lorsque le projet se développe
et que nous commençons à avoir une tonne de dépendances à gérer. Tout est configuré
automatiquement.
Spring Boot est multi-thread. Ceci est très utile lorsqu’il s’agit d’opérations longues ou
répétitives. Lorsque le thread principal est consommé, d’autres sont utilisés simultanément.
La création de microservices a également été simplifiée. La création d’une nouvelle suite

de services indépendants basés sur le cloud peut être effectuée facilement avec l’ensemble
des fonctionnalités fournies par Spring Boot.
Présentation de Node.js
Node.js, développé principalement en JavaScript, utilise un modèle d’E/S piloté par des
événements, monothread et non bloquant. Cela le rend incroyablement efficace et léger.
Parfait pour les applications très gourmandes en données qui doivent fonctionner en temps
réel sur des appareils distribués. Cela implique également une faible utilisation de la mé-
moire.
Comparaison entre Spring Boot et Node.js
Avantages Spring Boot Avantages Node.js

communauté Java : mature et prospère communauté Javascript : en croissance ra-
pide
rapide et léger Typé statiquement
Multi-thread mono-thread :faible utilisation de la mé-
moire
excellent pour les tâches E/S support et maintenabilité à long terme et de
nombreuses dépendances facilement utili-
sables
Inconvénients Spring Boot Inconvénients Node.js
Utilisation élevée de la mémoire Ne prend pas en charge le multi-threading
peut inclure des dépendances inutilisées l’absence de vérification de type stricte peut
conduire à de sérieux problèmes d’exécu-
tion, en plus du fait qu’il est déconseillé pour
la programmation lourde
Table 3.1 – Comparaison entre Spring Boot et Node.js
Conclusion
Ce benchmarking nous a permit de voir que dans le contexte de la SGABS et de la Dgital

Factory, et suivant les critères qui nous sont les plus importants pour notre solution et dans
l’industrie bancaire, qui nécessite de la programmation lourde et la maintenabilité, Spring
Boot reste la meilleure option.
3.5.2 Gradle et Maven
Présentation de Gradle
Gradle est un système d’automatisation de la construction entièrement open source qui

utilise les concepts qu’on voit sur Apache Maven et Apache Ant. Il utilise un langage spéci-
fique au domaine basé sur le langage de programmation Groovy, le différenciant d’Apache
Maven, qui utilise XML pour sa configuration de projet. Il détermine également l’ordre des
tâches exécutées à l’aide d’un graphique acyclique dirigé.
Il a été conçu pour prendre en charge les constructions multi-projets qui devraient être
énormes. Les tâches qui dépendent des parties mis à jour ne sont plus réexécutées. Il prend
en charge le développement et le déploiement subséquent à l’aide de Java, Scala et Groovy,
avec d’autres ”workflow” projets et langages introduits à l’avenir.
3.5. Etude benchmarking des outils 55
Présentation de Maven
Maven est utilisé pour l’automatisation de la construction de projets à l’aide de Java. Il

nous aide à cartographier la façon dont un logiciel particulier est construit, ainsi que ses
différentes dépendances. Il utilise un fichier XML pour décrire le projet, les dépendances
du logiciel en ce qui concerne les parties et les modules tiers, l’ordre de construction, ainsi
que les plugins nécessaires. Il existe des objectifs prédéfinis pour des tâches telles que le
”packaging” et la compilation.
Maven téléchargera les bibliothèques et les plugins à partir des différents référentiels,
puis les mettra tous dans un cache sur la machine locale. Bien qu’il soit principalement uti-
lisé pour les projets Java, vous pouvez l’utiliser pour Scala, Ruby et C, ainsi que pour une
foule d’autres langages.
Comparaison entre Gradle et Maven
Maven Gradle
un outil de gestion et de compréhension de un système d’automatisation de la
projets logiciels principalement utilisé avec construction open-source reposant sur
des projets basés sur Java les concepts d’Apache Ant et d’Apache
Maven
utilise XML n’utilise pas XML
facilite le processus de construction, fournit permet de structurer la construction, il
des directives sur les meilleures pratiques prend en charge les générations de plu-
de développement et permet une migration sieurs projets, augmente la productivité,
transparente vers de nouvelles fonctionna- offre un moyen facile de migrer et diffé-
lités, et est mieux adaptés aux projets de rentes techniques de gestion des généra-
grande envergure tions
Table 3.2 – Comparaison entre Gradle et Maven
Conclusion
Suivant cette étude de benchmarking entre Maven et Gradle, Gradle reste la meilleure
option puisqu’il offre plus de fonctionnalités et s’adapte plus pour les projets de grande en-
vergure.
3.6 Conception
3.6.1 Diagrammes de séquences
Scénario d’authentification des utilisateurs internes
Le diagramme ci-après détaille le mécanisme d’authentification pour les utilisateurs in-

ternes (administrateurs fonctionnels et techniques).
Figure 3.12 – Authentification SAFE viale socle WSO2
Scénario d’authentification des clients
L’authentification des clients permet :

° Protection contre les tentatives malicieuses : Toute la politique de sécurité (blocage
de compte après plusieurs tentatives infructueuses, brute-force, etc) est portée par le
serveur d’identité (WSO2).
° Gestion des tokens : La solution SG-Connect créé des tokens avec la stratégie sui-
vante :
° Le refreshtoken a une durée de vie de 90 jours(stratégie pour réduire l’impact sur
l’expérience utilisateur sur le mobile).
L’accesstoken a une durée de vie de 60mn :
-Au moment de la déconnection de l’utilisateur :
*Le storage local est vidé des tokens.
*Une requête d’invalidation des tokens est transmise au serveur d’identité (WSO2)
3.6. Conception 57
Figure 3.13 – Authentification SAFE viale socle WSO2

3.6.2 scénario d’authentification des transactions (canaux mobile et

web)
Figure 3.14 – Authentification des transactions sur mobile

3.6. Conception 59
Figure 3.15 – Authentification des transactions sur WEB
3.6.3 Diagramme de classes
Le diagramme de classes montre la structure interne du système. Il permet de fournir une

représentation abstraite des objets du système, qui vont interagir ensemble pour réaliser les
cas d’utilisation.
Figure 3.16 – diagramme de classes des APIs du Bridge
Le tableau ci-dessous représente la description des classes utilisées dans le projet.

3.6. Conception 61
Classe Description
Employer Présente les employeurs. Elle contient les données des em-
ployeurs et entreprises clientes.
Leader Présente les dirigeants. Elle contient les informations des

dirigeants des entreprises clientes.
Customer Présente le client qui a un compte bancaire de SG. un client

peut être moral, ou bien physique.
ThirdParty Présente le client qui n’a pas une relation directe avec la
banque SG. Elle contient les informations nécessaires des
tiers avec lesquelles interagissent les clients de la banque.
IdentityDocuments Présente les informations sur les documents d’identité des

clients SG.
Account Présente le compte bancaire d’un client SG. Elle contient

les informations du compte du client.
Global Limit Présente les limites et les plafonds d’un compte bancaire.
Overdraft Présente les autorisations de découvert d’un compte ban-

caire, lorsque la banque vous autorise à rendre votre
compte débiteur dans une certaine limite de montant et pen-
dant une certaine période.
Branch Présente les agences de SG. Elle contient les informations

de chaque agence.
Subsidiary Présente les filiales de la zone AFS.
Currency Présente les devises. Elle contient le code interne et le code

normalisé ISO des devises.
Exchange Rate Présente les taux de change.
Table 3.3 – Description des classes utilisés 1

Chequebook Présente le chéquier d’un compte bancaire.
Guarantor Présente les garants. Elle contient les informations des ga-
rants des clients qui garantissent leurs emprunts.
Collatoral Présente les garanties. Elle contient les détails des garan-
ties acceptées par la banque pour sécuriser les emprunts.
Table 3.4 – Description des classes utilisés 2
3.7 Conclusion
Après compréhension et analyse des objectifs, nous avons à présent mené une phase
importante de notre travail, qui est la conception de la solution du problème posé. L’activité
de la conception est indispensable afin de faciliter la compréhension de notre système, qui
ébauche vers l’activité réalisation et implémentation.
Chapitre 4
Réalisation et mise en oeuvre
63
64 Chapitre 4. Réalisation et mise en oeuvre
4.1 Introduction
Après avoir mené les phases précédentes, passant par la phase d’analyse et spécification
suivie par les phases de la conception détaillée et l’étude technique, l’étape suivante sera
consacrée à la réalisation du projet.
4.2 Outils techniques et methodes
4.2.1 DevOps
Dans notre groupe, DevOps est une culture.
Intégration continue
L’intégration continue (CI) est la pratique qui permet d’automatiser l’intégration des modi-
fications du code provenant de plusieurs contributeurs dans un même projet logiciel. Il s’agit
d’une des principales bonnes pratiques DevOps, qui permet aux développeurs de fusionner
fréquemment les modifications de code dans un répertoire central où les builds et les tests
sont ensuite exécutés. Des outils automatisés sont utilisés pour garantir la conformité du
nouveau code avant son intégration.
Un système de contrôle de la version du code source est l’élément central du processus

de CI. Le système de contrôle de version est également complété par d’autres contrôles
tels que les tests de qualité du code, les outils de révision du style syntaxique, etc. Il existe
plusieurs techniques utilisés dans cette phase de gestion du code source GITHUB :
— Gitflow : GitFlow est un modèle de gestion des branches pour Git.Il est très bien
adapté à la collaboration et à la mise en échelle de l’équipe de développement.
4.2. Outils techniques et methodes 65
Figure 4.1 – Gitflow
L’un des plus grands avantages de GitFlow est qu’il facilite le développement parallèle
en isolant les nouveaux développements des tâches finies. Les nouveaux dévelop-
pements (tels que les fonctionnalités et les corrections de bogues non urgentes) sont
effectués dans les branches de fonctionnalités et ne sont réintégrés dans le corps
principal du code que lorsque les développeurs sont satisfaits du code et le juge prêt
à être publié.
Avant que notre branche de fonctionnalité soit intégrée dans la branche de développement,
elle doit répondre à certaines exigences de qualité, ces exigences sont appelées QUALITY-
GATE qui est vérifiée par :
— Sonarqube : qui est une plateforme de qualité logicielle open-source. Il enregistre les
mesures de qualité dans une base de données et les présente dans un tableau de
bord. Il fournit des tendances et des indicateurs avancés. L’idée principale est de four-
nir un jour à chaque développeur les mesurer la qualité du code de ses projets. Leur
devise : “L’inspection continue doit devenir aussi courante que l’intégration continue”.
Figure 4.2 – Qualité du code

Vu que les développeurs ont besoin d’un feedback rapide sur leur code avant même d’être
traité par Jenkins, nos architectes ont décidé de créer un outil appelé :
— BOLT-CI : Une solution interne qui se charge des builds et des tests et qui informe
les développeurs de l’état de leur travail par mail ou dans leur profil github à chaque
commit, dans les deux premières minutes après avoir déposé le code dans la reposi-
tory.
Livraison continue
La livraison continue est une pratique de développement logiciel dans laquelle les mo-
difications du code sont automatiquement préparées pour une mise en production. C’est le
pilier du développement d’applications modernes, la livraison continue s’appuie sur l’intégra-
tion continue en déployant toutes les modifications du code dans un environnement de test
et/ou un environnement de production après la phase de construction. Lorsqu’elle est cor-
rectement mise en œuvre, les développeurs disposent toujours d’un artefact de construction
prêt à être déployé qui a été soumis à un processus de test standardisé. Cette technique est
réalisée dans notre projet en utilisant deux outils :
— Jenkins : Jenkins est un outil d’automatisation open-source écrit en Java avec des
plugins construits pour les besoins de la livraison continue. Jenkins est utilisé pour
builder et tester les projets logiciels en temps réel, ce qui permet aux développeurs
d’intégrer plus facilement les modifications apportées au projet et aux utilisateurs d’ob-
tenir plus facilement une nouvelle version.
Figure 4.3 – Jenkins pour la livraison continue

Dans notre projet, Jenkins build le pack après avoir effectué les vérifications et validations
nécessaires, puis il transmet le fichier exécutable à un gestionnaire des artefacts qui simplifie
le stockage et leur récupération .Ce gestionnaire est appelé :
— Nexus : C’est un gestionnaire de dépôt qui permet de stocker et de récupérer des

artefacts de build. Il s’agit d’une version privée similaire aux gestionnaires de dépôts
publics populaires comme Maven Central Repository et jcenter de Bintray, que tout le
monde peut utiliser pour récupérer les dépendances publiques pour un projet Maven.
[11]
Déploiement
Le déploiement continu est une stratégie de développement logiciel dans laquelle les
modifications apportées au code d’une application sont publiées dans l’environnement de
production. Cette automatisation est pilotée par une série de tests prédéfinis. Une fois que
les nouvelles mises à jour passent ces tests, le système envoie les mises à jour directement
aux utilisateurs du logiciel.
Le premier outil que nous utilisons pour atteindre ce niveau de déploiement continu est :
— Bolt : Il s’agit d’un outil développé en interne et fonctionnant dans tous les nœuds
des machines virtuelles de notre infrastructure. Il fournit une interface de ligne de
commande simple pour déclencher l’exécution de divers types d’applications avec
une syntaxe à la fois simple et puissante.
Puisque BOLT fonctionne en interne dans tous nos nœuds, nous devons trouver un moyen
d’y accéder et de le déclencher dans une ou plusieurs machines bien précises :
— Nomad :est un gestionnaire de charge moderne et léger.Il est également connu comme
un moteur d’orchestration .Il permet à toute organisation de déployer et de gérer faci-
lement ses applications. Il peut non seulement orchestrer des applications conteneu-
risées mais aussi des applications patrimoniales à l’aide d’un flux de travail unique et
unifié. Nomad peut également exécuter des applications Docker, non conteneurisées
et microservices.
Figure 4.4 – Nomad pour le déploiement

Dans notre système,nomad permet de nous conduire directement au bolt fonctionnant dans
l’instance sur laquelle nous voulons que notre application soit déployée, Pour ce faire, il doit
aussi être déclenché par :
— Consul : Outre la découverte de services, la vérification intégrée de l’état de santé et la

sécurisation du trafic réseau, Consul comprend un magasin de clés/valeurs, que vous
pouvez utiliser pour configurer dynamiquement des applications, coordonner des ser-
vices, gérer l’élection de leaders ou servir de back-end de données pour Vault, ainsi
qu’une multitude d’autres utilisations.
Figure 4.5 – Consule comme mémoire de clés/valeurs

Consul, dans notre système, est le déclencheur des jobs de NOMAD, il reçoit une notification
de boltCI avec la version que nous voulons déployer et il l’ajoute à son registre de clés/valeurs
et signale à nomad la version que nous souhaitons déployer, puis nomad prend le relais et
progresse dans le processus de déploiement.
Le dernier outil de ce processus de deploiment est BoltCI
— BoltCI : Avec boltCI nous avons le processus complet de déploiement qui commence
avec une personne qui veut deployer une version,qui crée un MARKDOWN dans
un répertoire appelé déploiements dans le serveur Github.A ce stade BoltCI est à

l’écoute de tous les événements sur la repository.Une fois il détecte qu’un nouveau
fichier markdown est ajouté, il extrait le numéro de version du nom du fichier, et mo-
difie le registre de clés/valeurs dans Consul pour le mettre à jour, quand ce registre
de clés/valeurs est modifié, nomad détecte ce changement, il télécharge la nouvelle
version depuis Nexus et lance un nouveau job de déploiement pour cette version.
Maintenant que l’application est déployée et fonctionne bien, il faut vérifier la configuration de
l’application, comme les mots de passe, les liens et les données qui sont spécifiques à l’en-
vironnement, ces informations restreintes sont habituellement stockées dans des variables
d’environnement ou programmées manuellement, mais il existe un moyen plus approprié de
le faire en utilisant :
— VAULT : Vault est un système de gestion des secrets et du chiffrement.Il fournit des
services de cryptage qui sont contrôlés par des méthodes d’authentification et d’auto-
risation. À l’aide de l’interface utilisateur, de l’interface CLI ou de l’API HTTP de Vault,
l’accès toute donnée sensible peut être stocké et géré en toute sécurité, rigoureuse-
ment contrôlé et vérifiable.
Figure 4.6 – Arhitecture Vault

En effet,les stratégies de déploiement suivies dans notre projet sont différentes selon l’en-
vironnement sur lequel nous nous retrouvons.Dans ce qui suit,nous allons présenter les
différents environnements qui existent :
— OFFLINE : Cet environnement se trouve dans chaque machine locale de chaque
développeur, il simule tous les providers des services externes avec des réponses
simulées hors ligne et il fonctionne sans avoir besoin d’une connexion Internet ou de
tout autre service, il est conçu pour tester le code par lui-même pour valider s’il fonc-
tionne sans interférence avec tout autre système, il prend sa configuration à partir des
fichiers de configuration inclus dans le code source.
— LOCAL : Comme l’environnement OFFLINE,l’environnement LOCAL est configuré

sur chaque machine locale des developpeurs, la principale différence entre ces deux
environnement est qu’il communique avec les autres systèmes à partir de la machine
locale avec les configurations fournies localement, il a donc besoin d’un accès Inter-
net et d’une autorisation proxy. Pour fonctionner.
— Development [DEV] : il s’agit du premier niveau de machines individuelles, à ce stade

l’application est hébergée dans un ou plusieurs agents nomade dans une ou plusieurs
machines virtuelles fonctionnant dans nos centres de données cloud privés, la confi-
guration de l’application à ce stade est assurée par Vault, et seuls les développeurs
y ont accès pour valider la fonctionnalité de leur application lors de l’exécution.
— Homologation Fonctionnelle [HF] : Maintenant, nous sommes au deuxième niveau,

tout comme le DEV, cet environnement est hébergé dans un agent nomade avec des
informations d’identification et des données stockées dans le coffre-fort, la principale
différence est que ces données sont évidemment différentes car elles doivent commu-
niquer avec d’autres instances d’autres systèmes, cet environnement est créé pour
que les Business Analyst,les Proxy Product Owner et les Product Owner puissent y
exécuter leurs tests d’acceptance et valider le comportement de l’application.
— Homologation Technique [HT] : C’est l’environnement le plus proche de la produc-

tion et il est également appelé ISO-PROD, ce qui signifie qu’il est exactement le même
que la production.Cet environnement permet de tester l’application dans un environ-
nement de type production, et valider qu’elle supporte la charge de travail, les critères
du système et tout incidents techniques pouvant survenir en production.
— Production [PROD] : Et maintenant notre application est entièrement testée et vali-

dée pour être accessible à nos clients, elle est bien sûr dupliquée dans plusieurs ins-
tances, différentes machines physiques, et aussi différentes régions géographiques
pour assurer une disponibilité la plus proche possible.
Maintenant, après avoir pris connaissance des différents environnements de déploiement,

nous pouvons passer aux stratégies de déploiement utilisées dans ces environnements, il
existe principalement deux stratégies :
— Recreate : ”Version A is terminated then version B is rolled out” La version A est ter-
minée puis la version B est déployée”. Cette stratégie est utilisée en DEV, HF et HT,
puisque ”0 temps d’arrêt” n’est pas une obligation et nous attendons tous la prochaine
version pour exécuter notre test, nous pouvons donc attendre pour que la prochaine
ait lieu pour lancer nos tests sachant qu’ils sont exécutés sur la nouvelle version.
— A/B testing : ”Version B is released to a subset of users under specific condition” La

version B est disponible pour un sous-ensemble d’utilisateurs sous certaines condi-
tions”. Nous l’appelons FF Friends and Family ces utilisateurs sont sélectionnés par
chaque agence, et ils peuvent tester la nouvelle version et nous fournir leurs com-
mentaires que nous pouvons analyser avec les logs et les métriques pour décider de
rediriger tout le flux à cette version ou continuer à l’améliorer davantage.
Figure 4.7 – A/B testing
Orchestration
à ce niveau, notre application est opérationnelle dans plusieurs instances, la seule chose
qui reste est de permettre aux utilisateurs d’y accéder, la première chose à faire est d’équi-
librer la charge entre les deux adresses IP que nous cachons localement à l’aide d’un :
— VIP : Signifie «virtuel IP adress ». C’est une adresse IP publique qui peut être parta-
gée par plusieurs appareils connectés à Internet. En interne, chaque appareil a une
adresse IP locale unique, mais en externe, ils partagent tous la même.
En utilisant la technique VIP, nous avons réalisé un routage interne entre les instances, il
nous reste alors que le routage externe, pour ce faire, nous utilisons :
— Traefik : il s’agit d’un proxy inverse et d’un load balancer qui facilite le déploiement de
microservices. Il s’intègre aux composants d’infrastructure existants et se configure
automatiquement et dynamiquement.
Figure 4.8 – Traefik
Monitoring
Afin de garantir la disponibilité et la performance de leur système d’information, les en-

treprises font appel à différents outillages pour surveiller l’infrastructure, les équipements,les
logiciels et les processus supportant les données. Pour y répondre, il faut : s’assurer qu’au-
cun dysfonctionnement technique ne perturbe le service, mesurer la performance au regard
des attentes, communiquer et prendre en charge au plus vite un dysfonctionnement. La sur-
veillance informatique, c’est-à-dire la supervision, couvre :
— La disponibilité des serveurs, réseaux, logiciels, processus, switchs, routeurs, pare-

feux, onduleurs, connexions internet, bornes wifi…
— La disponibilité des ressources d’un système, tel que l’espace disque, la mémoire, le
CPU...
— La santé des équipements postes de travail, téléphonie, imprimantes…
— La performance, par exemple les temps de réponse d’une application, le débit ré-
seau...
— La fiabilité / qualité, par analyse de la disponibilité sur une période
— La sécurité, pour prévenir des attaques, (vol de données confidentielles clients ou
internes, virus…)
En effet,avoir une solution qui vous permet de faire du monitoring est bien évidemment obli-
gatoire surtout dans le secteur bancaire. La solution proposée par la Difa se base principa-
lement sur trois outils :
— Actuator :
Avec une architecture micro-service il fait appel à

plusieurs services de type REST ou SOAP, un peu
près une vingtaine de services répartis et gérés par
différentes équipes. Pour assurer le bon fonction-
nement de tous ces services nous avons besoin de
surveiller et gérer efficacement toutes les dépendances
externes.SpringBoot fournit une librairie (ACTUATOR)
très efficace et simple à configurer qui nous permet de
mettre en place rapidement une surveillance détaillée
de toutes les dépendances externes utilisées avec un
ensemble des API qui sont utilisées par Grafana et
Kibana comme source de données.
— Grafana :
Au sien de la DiFa, garantir la disponibilité des services
informatique est primordiale, pour cela l’équipe a
décidé d’utiliser grafana comme étant un outil de re-
porting,c’est une plateforme open source taillée pour la
surveillance, l’analyse et la visualisation des métriques.
Elle est livrée avec un serveur web permettant d’y
accéder via une API HTTP.
— Kibana :
Pour rendre les logs visibles et simple à comprendre,

la DiFa a decidé d’utiliser Kibana qui est est une ap-
plication frontend gratuite et ouverte qui s’appuie sur la
Suite Elastic. Elle permet de rechercher et de visualiser
les données indexées dans Elasticsearch.
4.2.2 Outils utilisés
IntelliJ IDEA
IntelliJ IDEA également appelé « IntelliJ », « IDEA » ou

« IDJ » est un environnement de développement intégré
(en anglais Integrated Development Environment - IDE)
destiné au développement de logiciels informatiques re-
posant 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 lan-
gages de programmation Java, Kotlin, Groovy et Scala.
Gradle
Gradle est un moteur de production fonctionnant sur la

plateforme Java. Il permet de construire des projets en
Java, Scala, Groovy voire C++.
Concepts de Gradle
— Projets : Un projet représente une chose à faire, comme le déploiement d’applica-
tions dans des environnements de test. Un projet Gradle nécessite l’exécution d’un
ensemble de tâches.
— Tâches : Une tâche fait référence à un travail effectué par un build. Cela peut être
quelque chose d’aussi simple que compiler des classes, créer des fichiers JAR, créer
Javadoc ou publier des archives.
— Créer des scripts : Un script de construction est appelé build.gradle et se trouve dans
le répertoire racine du projet. Chaque construction Gradle comprend un ou plusieurs
projets.
Avantages de Gradle
— haute performance : Gradle exécute rapidement une tâche.Ceci se fait en consi-
dérant les résultats des exécutions précédentes. Les travaux dont les entrées sont
modifiées sont les seuls qui sont exécutés. Cela permet d’obtenir de meilleures per-
formances.
— Construction de logiciel multi-projets : Gradle assure une prise en charge des
builds multi-projets. Ces projets peuvent contenir un projet racine et un nombre illi-
mité de sous-projets. Il prend en charge les constructions partielles, ce qui indique
que l’outil déterminera si un projet dont notre projet dépend, a besoin d’un type de re-
construction. Au cas où le projet aurait besoin d’être reconstruit, Gradle le fera avant
de construire d’autres projets.
Java
Java est un langage de programmation inspiré du lan-

gage C++, avec un modèle de programmation orienté
objet. Java permet de créer des applications complètes.
Il peut également servir à créer un petit module d’appli-
cation, dit applet, à intégrer dans une page Web. Les
principales caractéristiques de Java sont les suivantes :
— Les programmes créés sont portables. Le programme source est compilé dans un «
code », qui peut être exécuté sur un serveur ou un client doté d’une machine virtuelle
Java. Cette dernière traduit le code compilé en code exécutable sur le matériel infor-
matique. Cela signifie que les différences entre les plateformes, comme la longueur
des instructions, peuvent être reconnues et gérées en local au fil de l’exécution du
programme. Il n’est donc plus nécessaire de créer des versions différentes du pro-
gramme pour chaque plateforme.
— Le code est robuste. Cela qui signifie que les objets Java ne peuvent contenir aucune
référence à des données qui leur sont externes à ou à d’autres objets connus. Ce
mécanisme garantit qu’une instruction ne contiendra pas l’adresse de données sto-
ckées dans une autre application ou dans le système d’exploitation lui-même, ce qui
provoquerait l’arrêt ou le « plantage » du programme, voire du système d’exploitation.
La machine virtuelle Java procède à diverses vérifications sur chaque objet pour en
assurer l’intégrité.
— Java est orienté objet, ce qui implique, entre autres caractéristiques, qu’un objet tire
parti de son appartenance à une classe d’objets pour hériter du code commun à cette
classe. Les objets sont considérés comme des « noms » auxquels un utilisateur peut
se rapporter, plutôt qu’à des « verbes » traditionnellement utilisés dans les procédures.
Ainsi, une méthode peut être considérée comme l’une des fonctionnalités ou l’un des
comportements de l’objet.
La machine virtuelle Java comprend un compilateur JIT (Just-In-Time), ou compilateur à la

volée qui compile dynamiquement le code source en code exécutable au lieu de l’interpréter
instruction par instruction.
Java EE
Jakarta EE (ou Java EE), est une spécification pour la
plate-forme Java d’Oracle, destinée aux applications
d’entreprise. 22La plate-forme étend Java Platform,
Standard Edition (Java SE) en fournissant une API
de mapping objet-relationnel, des architectures distri-
buées et multitiers, et des services web. La plate-forme
se fonde principalement sur des composants modu-
laires exécutés sur un serveur d’applications. Pour ce
faire, Java EE définit les éléments suivants :
— Une plate-forme (Java EE Platform), pour héberger et exécuter les applications, in-
cluant outre Java SE des bibliothèques logicielles additionnelles du Java Develop-
ment Kit (JDK).
— Une suite de tests (Java EE Compatibility Test Suite) pour vérifier la compatibilité.
— Une réalisation de référence (Java EE Reference Implementation), dénommée Glass-
Fish.
— Un catalogue de bonnes pratiques (Java EE BluePrints).
— Un code script. À chaque version de Java EE correspond notamment, comme toutes
les éditions Java :
— Les Java Specification Requests (JSR), constituant les spécifications de la version
considérée ;
— Un Java Development Kit (JDK), contenant les bibliothèques logicielles ;
— Un Java Runtime Environment (JRE), contenant le seul environnement d’exécution
(compris de base dans le JDK).
Spring framework
Le Spring Framework est très largement utilisé dans la
communauté Java. Il permet d’accélérer le développe-
ment d’applications d’entreprise (notamment le déve-
loppement d’applications Web et d’API Web). Mais on
trouve des applications fondées sur le Spring Frame-
work dans d’autres domaines.
Les fonctionnalités de base de Spring Framework peuvent être utilisées pour développer
n’importe quelle application Java, mais il existe des extensions pour créer des applications
Web sur la plate-forme Java EE. Le framework Spring vise à rendre le développement J2EE
plus facile à utiliser et promeut les bonnes pratiques de programmation en activant un modèle
de programmation basé sur POJO.
Injection de dépendance
L’inversion de contrôle (IoC) est un concept général et peut être exprimé de différentes
manières. L’Injection de Dépendance n’est qu’un exemple concret d’Inversion de Contrôle.
Lors de l’écriture d’une application Java complexe, les classes d’application doivent être
aussi indépendantes que possible des autres classes Java afin d’accroître la possibilité de
réutiliser ces classes et de les tester indépendamment des autres classes lors des tests
unitaires. L’injection de dépendance aide à coller ces classes ensemble et en même temps
à les maintenir indépendantes.
Par exemple, la classe A dépend de la classe B. Voyons maintenant la deuxième partie,
l’injection. Cela signifie simplement que la classe B sera injectée dans la classe A par l’IoC.
L’injection de dépendance peut se produire en passant des paramètres au constructeur
ou en post-construction à l’aide de méthodes setter.
Spring Boot
Spring Boot est un framework qui permet la mise en
place d’application Spring rapidement et facilement.
Il se base sur le Framework Spring et permet de
s’affranchir de la plupart des configurations de celui-ci
à mettre en place pour créer une application. Les
principales fonctions :
— Une gestion des dépendances Spring simplifiée

— -Un déploiement facilité
— Intégrez directement Tomcat, Jetty ou Undertow (inutile de déployer des fichiers WAR
(Web Application Resource))
— La configuration automatique de bibliothèques Spring et autres
— La configuration des propriétés externes plus lisible
— Facilités pour créer des repositories - Des possibilités de déclarer des sorties JSON
(JavaScript Objet Notation) multiples
— L’exposition des ressources par REST juste avec une annotation
— Aucune génération de code et aucune exigence pour la configuration XML (Extensible
Markup Language)
Spring MVC
Le framework Spring Web MVC fournit une architecture Model-View-Controller (MVC)

et des composants prêts qui peuvent être utilisés pour développer des applications Web
flexibles et à couplage lâche. Le modèle MVC permet de séparer les différents aspects de
l’application (logique d’entrée, logique métier et logique d’interface utilisateur), tout en assu-
rant un couplage lâche entre ces éléments.
— Le Modèle encapsule les données de l’application et en général elles seront compo-

sées de POJO.
— La vue est responsable du rendu des données du modèle et génère en général une
sortie HTML que le navigateur du client peut interpréter.
— Le Contrôleur est responsable du traitement des demandes des utilisateurs et de la
construction d’un modèle approprié et le transmet à la vue pour le rendu.
L’infrastructure Spring Web model-view-controller (MVC) est conçue autour d’un Dispatcher-
Servlet qui gère toutes les requêtes et réponses HTTP. Le flux de travail de traitement des
demandes du Spring Web MVC DispatcherServlet est illustré dans le diagramme suivant.
Figure 4.9 – Architecture de Spring MVC
Voici la séquence d’événements correspondant à une requête HTTP entrante adressée

à DispatcherServlet :
— Après réception d’une requête HTTP, DispatcherServlet consulte le HandlerMapping
pour appeler le Controller approprié.
— Le contrôleur prend la demande et appelle les méthodes de service appropriées ba-
sées sur la méthode GET ou POST utilisée. La méthode de service définira les don-
nées du modèle en fonction de la logique métier définie et renverra le nom de la vue
au DispatcherServlet.
— Le DispatcherServlet demandera l’aide de ViewResolver pour récupérer la vue définie
pour la requête.
— Une fois la vue finalisée, The DispatcherServlet transmet les données du modèle à la
vue qui est finalement affichée sur le navigateur.
Spring Security
Spring Security, est un contrôleur d’authentification flexible et puissant pour assurer une
application Web Java basé sur Spring.
JSON Web Token

JSON Web Token (JWT) est un standard ouvert défini
dans la RFC 75191. Il permet l’échange sécurisé de je-
tons (tokens) entre plusieurs parties. Cette sécurité de
l’échange se traduit par la vérification de l’intégrité et
de l’authenticité des données. Elle s’effectue par l’algo-
rithme HMAC ou RSA. Un jeton se compose de trois
parties :
— Un en-tête (header), utilisé pour décrire le jeton.
Il s’agit d’un objet JSON.
— Une charge utile (payload) qui représente les in-
formations embarquées dans le jeton. Il s’agit
également d’un objet JSON.
— Une signature numérique.
Il existe des outils en ligne permettant de les dé-
chiffrer.
Pebble
Pebble est un moteur de template Java inspiré de Twig
et similaire à la syntaxe Python Jinja Template Engine. Il
propose un héritage de modèles et une syntaxe facile à
lire. Un moteur de template est un outil de modèle struc-
turé qui simplifie la syntaxe pour assurer une bonne
maintenance de son projet web. Il permet de dissocier
la présentation de la partie (HTML) de la programma-
tion de la partie (PHP, JS…).
L’utilisation de Pebble dans notre projet était la créa-
tion d’un fichier qui s’appelle la template contenant la
requête xml ensuite l’appel à pebble pour le remplis-
sage des données dans la requête afin de taper sur les
SMGs, ces derniers sont des web services SOAP du
coup ils comprend que le xml. En outre, pebble nous
a permis de gérer les règles métier au niveau des re-
quêtes xml à travers des condtions qu’on ajoute dans
la template.
JOLT
Bibliothèque de transformation JSON vers JSON écrite en Java où la ”spécification” de
la transformation est elle-même un document JSON. Utile pour :
— Transformer les données JSON d’ElasticSearch, MongoDb, Cassandra, etc. avant de

les envoyer au monde entier
— Extraire des données d’un grand document JSON pour votre propre consommation
Cette librairie nous a permis de transformer les structures de données envoyées par
Amplitude à nos conventions de nomination interne, afin de respecter le langage métier au
sein de SGABS. Ceci était faite par une création d’un fichier JSON de specification contenant
les changements souhaités et un autre fichier contenant la réponse du SMGs, apès nous
faisons appel à JOLT pour les transformations.
GraphQL
GraphQL est un langage de requête et un environne-

ment d’exécution côté serveur pour les interfaces de
programmation d’application (API) qui s’attache à four-
nir aux clients uniquement les données qu’elles ont de-
mandées, et rien de plus.
GraphQL est conçu pour être mis à la disposition des
développeurs des API rapides, flexibles et faciles à uti-
liser. Il est même possible de l’éprouver dans un en-
vironnement de développement intégré (IDE), appelé
GraphiQL. Utilisé à la place de REST, GraphQL permet
aux développeurs de créer des requêtes qui extraites
les données de plusieurs sources à l’aide d’un seul ap-
pel d’API.
En outre, avec GraphQL, les équipes chargées de la
maintenance des API peuvent ajouter ou retirer libre-
ment des champs sans perturber les requêtes exis-
tantes. De leur côté, les développeurs pourront créer
des API en utilisant les méthodes de leur choix. La spé-
cification de GraphQL garantit que leur fonctionnement
sera attendu auprès des clients.
JUnit
JUnit est un framework open source pour le dévelop-

pement et l’exécution de tests unitaires automatisables.
Le principal intérêt est de s’assurer que le code répond
toujours aux besoins même après d’éventuelles modifi-
cations. Plus généralement, ce type de tests est appelé
tests unitaires de non-régression. Le but est d’automa-
tiser les tests. Ceux-ci sont exprimés dans des classes
sous la forme de cas de tests avec leurs résultats atten-
dus. JUnit exécute ces tests et les comparent avec ces
résultats. Cela permet de séparer le code de la classe,
du code qui permet de la tester. Souvent pour tester
une classe, il est facile de créer une méthode main()
qui va contenir les traitements de tests. L’inconvénient
est que ce code ”superflu” est inclus dans la classe. De
plus, son exécution doit se faire manuellement.
Avec JUnit, l’unité de test est une classe dédiée qui regroupe des cas de tests. Ces cas
de tests exécutent les tâches suivantes :
— création d’une instance de la classe et de tout autre objet nécessaire aux tests
— appel de la méthode à tester avec les paramètres du cas de tests
— comparaison du résultat attendu avec le résultat obtenu : en cas d’échec, une excep-
tion est levée
Karate
Le framework de karaté suit le style d’écriture du

programme de Cucumber qui suit l’approche BDD
(Behavior-Driven Development). La syntaxe est facile
à comprendre par des non-programmeurs. Et ce fra-
mework est le seul outil de test d’API qui a combiné
l’automatisation de l’API, les tests de performances et
même l’automatisation de l’interface utilisateur dans un
seul outil autonome. Il offre aux utilisateurs la possibilité
d’exécuter les cas de test en parallèle et d’effectuer les
contrôles JSON et XML.
Voici quelques fonctionnalités du cadre de test de karaté :

— Utilise le langage Gherkins facile à comprendre.
— Il ne nécessite aucune connaissance de programmation technique comme Java.
— Il est basé sur les standards populaires de Cucumber.

— UI pour le débogage du test.
— Appel d’un fichier .feature à partir d’un autre fichier.
— Fournit un supports pour le Data Driver Testing qui sont construits en interne, donc
pas besoin de dépendre de frameworks externes.
— Rapports de Rest natifs intégrés. De plus, il peut être intégré à Cucumber pour de
meilleurs rapports d’interface utilisateur et plus de clarté.
— Fournit une assistance en interne pour la configuration du changement dans différents
environnements de test (QA, Stage, Prod, Pre-Prod).
— Capable de gérer différents appels HTTP :
— Prise en charge des sockets Web

— Requête SOAP
— HTTP
— Gestion des cookies du navigateur
— HTTPS
— Données de formulaire HTML
— Requête XML
Swagger
Swagger est un langage de description d’interface

permettant de décrire des APIs RESTful exprimées à
l’aide de JSON. Swagger est utilisé avec toute une sé-
rie d’outils logiciels open source pour concevoir, créer,
documenter et utiliser des services Web RESTful. [13]
Soap UI
SoapUI est une application open source permettant le

test de web service dans une architecture orientée ser-
vices. Ses fonctionnalités incluent l’inspection des web
service, l’invocation, le développement, la simulation,
le mocking, les tests fonctionnels, les tests de charge
et de conformité. [14]
4.2.3 Outil de collaboration
Jira
Pour réussir Scrum, la Société Générale African

Business Services se servit de ‘JIRA’ qui est un outil
de gestion de projet développé par Atlassian et publié
pour la première fois en 2002.
JIRA fait partie d’une gamme de produits conçus pour

aider les équipes de tous types à gérer leur travail.
C’est une plateforme multifonction qui vise à faciliter la
gestion de projet en aidant à suivre les tâches, identifier
les blocages et partager des informations entre les
membres d’une équipe. Il est basé sur une organisa-
tion des projets en tickets, chacune représentant des
tâches.[12]
De plus, JIRA permet d’assurer le suivi des tickets et la définition d’un workflow adapté
aux méthodes de travail. JIRA génère aussi des graphiques et visuels qui permettent de
repérer en un coup d’œil l’état des différentes missions et d’identifier les problèmes à régler
en priorité pour pouvoir avancer.
Figure 4.10 – Interface de gestion de notre projet sur JIRA

Teams
Microsoft TEAMS est ainsi utilisé afin de communiquer

entre les membres de l’équipe à travers des réunions.
Des réunions quotidiennes sont programmées avec

l’équipe, afin de discuter l’état d’avancement de chaque
membre, les tickets traités, ainsi que les problèmes et
les blocages rencontrés. Des formations sont égale-
ment programmées si le besoin est exprimé, notam-
ment dans le cadre de notre périmètre, pour mieux
connaître les fondements du métier de la banque.
Figure 4.11 – Capture d’écran du calendrier des réunions sur Teams

4.2.4 Outil de formation
Confluence
Confluence est une solution de travail collaboratif qui

permet de créer et de stocker des fichiers sur une
seule plateforme. Comptes rendus de réunions, plans
marketing, politiques RH...
L’outil permet de créer des pages de toutes pièces
ou d’utiliser des modèles personnalisables parmi les
nombreuses listes d’exemples fournies.
Ces pages peuvent être commentées, riches en

images, vidéos ou GIF, et liées dans un espace dédié
que les membres de l’équipe peuvent visiter pour
recueillir leurs impressions, demander de l’aide ou
accélérer la prise de décision.[10]
My Learning
My Learning est une plateforme d’apprentissage des

activités professionnelles. L’objectif est de s’adapter à
l’évolution constante de la technologie et du monde du
travail et acquérir de nouvelles compétences.
Figure 4.12 – Interface des formations sur My Learning

4.3 Réalisation des APIs par sprint
4.3.1 Développement des APIs
Sprint 1
Dans ce premier sprint , nous avons développés deux APIs REST et GraphQL avec leur
documentation Swagger :
- Le getEmployerList qui permet de lister les informations liées aux employeurs avec la
possibilité de filtrer selon le numéro d’identifiant national, les informations d’un employeur,
ou bien le type d’employeur. Cette fonctionnalité sera utiliser dans le projet NEXTGEN.
- Le getExchangeRateList qui permet de lister les taux de change avec la possibilité de

filtrer selon la devise d’origine, la devise d’arrivée, la date d’application du taux, l’origine des
taux (locaux ou étrangers), ou bien l’agence. Ce service est intégré dans l’application web
et mobile SG Connect.
Les figures suivantes illustrent la page d’accueil de l’application SG CONNECT mobile

et web qui consomme les fonctionnalités développées dans notre catalogue d’APIs.
Figure 4.13 – Page d’accueil - SG CONNECT - Application Web

4.3. Réalisation des APIs par sprint 87
Figure 4.14 – Page d’accueil - SG CONNECT - Application Mobile
En utilisant l’API getExchangeRateList de notre catalogue Bridge et afin d’aider les clients
SG Connect à convertir les devises rapidement et facilement, un convertisseur de devises
est en cours d’intégration dans l’application. En fait cette fonctionnalité utilise les taux de
change remonté depuis l’API et calcule rapidement le montant converti après saisie du mon-
tant et de deux devises.
Nous présentons une capture d’écran de la maquette réalisée :

Figure 4.15 – Maquette du convertisseur des devises sur le SG Connect
Par contre l’interface des taux de change est intégré. C’est une fonctionnalité qui permet
de consulter les taux de change en mode connecté et déconnecté et avoir à titre indicatif le
cours de référence de la banque centrale et le cours de change manuel Achat et Vente.
Figure 4.16 – Interface de Taux de change - Application web

Figure 4.17 – Interface de Taux de change 1 - Application Mobile

Figure 4.18 – Interface de Taux de change 2 - Application Mobile
Sprint 2
Dans ce sprint , nous avons développés deux APIs REST et GraphQL avec leur docu-
mentation Swagger :
- Le getCheckbookRequestList qui permet de consulter les commandes de chéquier avec

la possibilité de filtrer selon le numéro de compte du client, l’agence, ou le type de chéquier.
- Le createChequeBookRequest qui permet de commander un chéquier. Les inputs obli-

gatoires de ce service sont : le code d’agence de la commande, l’origine de la demande de
chéquier, le mode d’expédition du chéquier, le lieu d’expédition du chéquier, et les types de
chéquiers de la commande.
Ces deux fonctionnalités sont intégrées dans l’application web et mobile SG Connect.
La figure suivante présente l’interface de l’application web dédiée à la gestion de ché-

quier. Le but de cette fonctionnalité est de permettre au client SG Connect de commander
un chéquier.
Figure 4.19 – Commande de chéquier - Application Web
En haut de la page, il y a un bouton « Nouveau chéquier ».

Si on clique sur ce bouton, un formulaire est affiché où on va renseigner le compte émetteur
de chéquier, et le type de chéquier :
Figure 4.20 – Formulaire de commande de chéquier - Application Web
Dans l’interface de l’application mobile dédiée à la gestion de chéquier, il y a un bouton

« Nouveau chéquier ».
Si on clique sur ce bouton, un formulaire est affiché où on va renseigner le compte émetteur
de chéquier, et le type de chéquier :
Figure 4.21 – Formulaire de commande de chéquier - Application mobile
Sprint 3
mentation Swagger :
- Le getAccountActivity qui permet de de rechercher le détail de l’activité d’un compte avec
la possibilité de filtrer selon Identifiant du compte bancaire, des critères techniques tel que le
nombre maximum d’enregistrements à retourner, ou bien la période. Ce service est intégré
dans l’application web et mobile SG Connect.
La figure suivante présente l’interface de l’application web et mobile de SG Connect dédiée
à l’affichage du détail de l’activité d’un compte bancaire.
Figure 4.22 – Interface de l’application web -1

Figure 4.23 – Interface de l’application web -2
Figure 4.24 – Activité d’un compte bancaire - Application Web

Figure 4.25 – Activité d’un compte bancaire - Application Mobile
- Le getCustomerRelationList qui permet de consulter la liste des relations de clients

en entrant le customerCode. Cette fonctionnalité va être intégrer dans OpenR.
Sprint 4
Durant ce sprint , nous avons développés deux APIs REST et GraphQL avec leur docu-
mentation Swagger :
- Le getCustomerProfessionAndIncomeList qui permet de lister les revenus et emplois

d’un client,avec la possibilité de filtrer selon le numéro du client ou la date d’emplois.
- Le getBaseRateList qui permet de lister les taux de base. avec la possibilité de filtrer
selon le code du taux de base ou la date de validité du taux de base.
Ces deux fonctionnalités vont être intégrer dans l’application web et mobile SG Connect.
Sprint 5
mentation Swagger :
- Le getCustomerLeadersDetail qui permet de renvoyer le détail des dirigeants d’un client

avec la possibilité de filtrer selon l’identifiant du client, ou du dirigeant. Cette fonctionnalité
sera utiliser dans le projet LDV.
- Le getCurrencyList qui permet de consulter de lister les devises.
4.3.2 Qualité
Nous avons utilisé SonarLint qui est un plugin permettant de réaliser les analyses du
qualité code au fil des développements, directement dans notre IDE Intellij. Un bon coup de
pouce pour identifier au plus tôt, c’est-à-dire avant même le commit, les points à corriger. De
ce fait, le coût de la qualité du code est extrêmement réduit, voire invisible.
La figure suivante montre les problèmes majeurs et critiques de notre projet qu’il faut
corriger , comme par exemple les codes dupliqués à supprimer, les bibliothèques importées
mais ne sont pas utilisées, il faut donc les enlever aussi.
Figure 4.26 – Rapport de SonarLint
4.3.3 Les tests

Un produit logiciel correctement testé garantit la fiabilité, la sécurité et des performances
élevées, ce qui se traduit en outre par un gain de temps, une rentabilité et une satisfaction
client.
Les tests API au cours du développement sont principalement faits via des tests unitaires et
tests fonctionnels dans la code base. En effet , nous avons fait passer notre logiciel par trois
phases de test à savoir :
— Phase de tests unitaires.
— Phase de tests fonctionnels.
— Phase de tests d’intégration avec l’outil Pilot.
Pour structurer les tests nous avons utilisé la méthode AAA, ou Arrange-Act-Assert :
Arrange : initialiser tous les entrants nécessaires et le système à tester si besoin.
Act : exécuter le système à tester avec les entrants précédemment initialisés.
Assert : valider les sortants en fonction de ce qui est attendu par rapport aux entrants.
Conclure alors si c’est en succès ou en échec.
Tests Unitaires
Un test unitaire est un moyen de tester une unité - le plus petit morceau de code - qui
peut être isolé logiquement dans un système.
Dans notre logiciel, cette unité était une fonction handle() qui se charge d’appeler Pebble
pour le remplissage des requêtes xml et de faire les transformations Jolt, mais cette fonc-
tion handle() n’est liée qu’à une use case. Cette dernière représente une fonctionnalité
fournie par le CBS Amplitude.
Pour assurer que nous avons testé qu’une seule unité, nous avons opté à faire les tests uni-
taires dans l’environnement Offline, afin de mocker tous les systèmes externes dont notre
logiciel dépend. Nous avons utilisé pour cela JUnit.
Figure 4.27 – Rapport des tests unitaires

Tests Fonctionnels
Le test fonctionnel est un type de test logiciel qui valide le système logiciel par rapport aux
exigences/spécifications fonctionnelles. L’objectif des tests fonctionnels est de tester chaque
fonction de l’application logicielle, en fournissant des entrées appropriées, en vérifiant la sor-
tie par rapport aux exigences fonctionnelles et en couvrant les différents scénarios de test.
À l’aide des deux outils Postman et Karaté , nous avons pu tester fonctionnellement toutes
les APIs que nous avons développée.
Karaté nous fournit une interface où nous pouvons voir les détails de chaque scénario
exécuté, vérifier si un scénario est exécuté avec succès ou pas et pourquoi il a échoué. En
outre cette interface nous montre le temps pris par chaque scénario ou par l’ensemble des
scénarios.
Vous trouverez ci-dessous l’interface de Karaté qui donne un ensemble d’informations
sur le test exécuté.
Figure 4.28 – Interface de Karaté
Postman
Le test via Postman permet d’envoyer des requêtes REST, SOAP ou GraphQL pour sol-
liciter nos APIs , simuler des endpoints , surveiller la performance des APIs, travailler de
manière collaborative avec les espaces de travail.
Pour chaque requête, Postman propose d’exécuter des pré requis et un script de test.
C’est dans ce dernier script qu’on va ajouter des vérifications sur la réponse obtenue pour
bien s’assurer de bon fonctionnement des APIs.
La figure suivante présente un exemple de test d’API via Postman :
Figure 4.29 – Interface de Postman
Test d’intégration
Une fois qu’une API a été développée et testée, nous la testons ensuite dans le cadre
du système global, avec Postman, en envoyant des requêtes et en comparant les réponses
avec ce qui est attendu. Cependant, ce n’est pas une bonne habitude, surtout lorsque nous
avons des centaines d’APIs à tester, C’est pourquoi nos architectes ont décidé de construire
en interne un outil qui permet d’envoyer des requêtes, recevoir des réponses, et valider ces
réponses avec les critères d’acceptation spécifiés par un Business-analyst.En effet, PILOT
simplifie le test d’une seule API dans le système et il permet de tester toutes les API sans
aucune intervention humaine à partir du moment où les tests sont déclenchés.Il offre une
interface utilisateur simplifiée, avec un bouton d’exécution pour déclencher l’exécution d’un
fichier contenant plusieurs scénarios de test. A ce niveau, la seule chose que nous devons
spécifier est l’environnement dans lequel nous voulons que ces tests soient exécutés DEV,
HF, HT ou PROD. PILOT permet de centraliser toutes les données de test dans un seul réper-
toire. De cette manière, lorsqu’un développeur ou un testeur a besoin de certaines données
pour tester son API, il n’a pas besoin de consulter tous les autres développeurs/business-
analystes pour obtenir ces informations, car il peut les trouver avec le reste des données,
dans le même répertoire git.
Figure 4.30 – Pilot
4.3.4 Déploiement
Le déploiement continu est une stratégie de développement logiciel , dans laquelle les
modifications apportées au code d’une application sont publiées automatiquement dans l’en-
vironnement de production. Cette automatisation est pilotée par une série de tests prédéfinis.
Une fois que les nouvelles mises à jour passent ces tests, le système envoie les mises à jour
directement aux utilisateurs du logiciel.
Pour mettre en œuvre ce principe dans notre usine informatique, nous utilisons des ou-
tils fournis principalement par HASHICORP, qui est un éditeur de logiciels avec un modèle
économique freemium basé à San Francisco, en Californie.
HashiCorp fournit des outils open-source et des produits commerciaux qui permettent
aux développeurs, aux opérateurs et aux professionnels de la sécurité d’approvisionner, de
sécuriser, d’exploiter et de connecter des infrastructures informatiques.
Le premier outil que nous utilisons pour atteindre ce niveau de déploiement continu est :
Bolt.
Parmi les stratégies utilisées dans les environnements de déploiement :
— Recreate : ”La version A est terminée puis la version B est déployée”. Cette straté-
gie est utilisée en DEV, HF et HT, puisque ”0 temps d’arrêt” n’est pas une obligation
et nous attendons tous la prochaine version pour exécuter notre test, nous pouvons
tous attendre pour que la prochaine ait lieu pour lancer nos tests en sachant qu’ils
sont exécutés sur la nouvelle version.
— A/B testing : ”La version B est disponible pour un sous-ensemble d’utilisateurs sous
certaines conditions”. Nous l’appelons FF Friends and Family , ces utilisateurs sont
sélectionnés par chaque agence, et ils peuvent tester la nouvelle version et nous four-
nir leurs commentaires que nous pouvons analyser avec les logs et les métriques pour
décider de rediriger tout le flux à cette version ou continuer à l’améliorer davantage,
ceci alors que le grand sous-ensemble de nos utilisateurs utilise toujours l’ancienne
version.
Figure 4.31 – A/B testing
4.3.5 Monitoring
Afin de garantir la disponibilité et la performance de leur système d’information, les en-
treprises font appel à différents outillages pour surveiller l’infrastructure, les équipements,
logiciels et processus supportant les données. Pour y répondre, il faut : s’assurer qu’aucun
dysfonctionnement technique ne perturbe le service, mesurer la performance au regard des
attentes, communiquer et prendre en charge au plus vite un dysfonctionnement. La sur-
veillance informatique, c’est-à-dire la supervision, couvre :
• La disponibilité des serveurs, réseaux, logiciels, processus, switchs, routeurs, parefeux,

onduleurs, connexions internet, bornes wifi…
• La disponibilité des ressources d’un système, telles que l’espace disque, la mémoire,
le CPU.
• L’état des équipements (postes de travail, téléphonie, imprimantes…).
• La performance, par exemple les temps de réponse d’une application, le débit réseau,
la température d’une salle.
4.4. Conclusion 103
• La fiabilité / qualité, par analyse de la disponibilité sur une période.
• La sécurité, pour prévenir des attaques, (vol de données confidentielles clients ou in-
ternes, ransomware, virus…).
Alors avoir une solution qui vous permettre de faire du monitoring est bien évidemment
obligatoire surtout dans le secteur bancaire. La solution proposé par la Difa se base princi-
palement sur trois outils : Actuator , Grafana , Kibana.
4.4 Conclusion
Dans ce chapitre, nous avons décrit la dernière étape de projet qui est la partie réalisation.
Nous avons commencé par la description des différents outils de développement utilisés
avant de présenter un aperçu sur les interfaces réalisées en utilisant notre catalogue d’APIs.
Conclusion générale et perspectives
Ce projet de fin d’études a été le fruit d’une expérience très enrichissante. En effet, ce
fut l’occasion pour moi de travailler sur un projet réel qui était une opportunité d’intégrer le
monde professionnel au sein d’un organisme aussi bien connu comme SG ABS. Notre projet
s’inscrit dans la couche bridge et permet de faciliter la communication avec le SI bancaire
tout en assurant la séparation du métier et du technique. Afin d’atteindre cet objectif, Nous
avons commencé en premier lieu par mener l’étude et l’analyse des besoins probables. La
période de stage effectuée au sein de la société SG ABS a été très bénéfique pour moi, tant
au niveau technique qu’au niveau personnel, en effet, ma présence dans cet organisme dis-
posant des équipes hautement qualifiées, m’ont offert l’opportunité de raffiner mes capacités
d’abstraction et de conception ainsi que mes méthodes de travail. Ce projet a été également
une occasion intéressante pour approfondir mes connaissances dans le domaine des nou-
velles technologies et du monde de la finance. En perspective, j’envisage de poursuivre le
projet en ajoutant plus de fonctionnalités. Par exemple, l’ajout de la possibilité de payer des
factures ,créer un compte en ligne ou encore paiement par biométrie.
104
Webographie
[1] « Site officiel du groupe société générale » consulté le 20/02/2022 et disponible sur :
https ://www.societegenerale.com/fr/accueil
[2] « Site officiel de société générale african business services » consulté le 20/02/2022
et disponible sur :
https ://societegenerale.africa/fr/societe-generale-afrique/actualites /news-details/news/
[3] « Product Owner » : https ://www.blogdumoderateur.com/role-scrum-master-product-

owner-equipe-developpement.
[4] « Proxy Product Owner » : https ://blog.myagilepartner.fr/index.php/2017/01/11/un-

proxy-product-owner.
[5] « Business Analyst » : https ://www.guide-metiers.ma/metier/business-analyst/.
[6] « Scrum Master » : https ://www.scrum.org/resources/what-is-a-scrum-master
[7] « Tech & Team Lead » : https ://herodot.com/tech-lead-and-scrum-master-a-

successful-combination.
[7] « Developpeur » : https ://www.guide-metiers.ma/metier/developpeur/
[9] « Coach Agile » : https ://jedisquad.fr/differences-entre-coach-agile-et-scrum-

master.
[10] « Le média des pros du digital » consulté le 12/05/2022 et disponible sur :

https ://www.blogdumoderateur.com/tools/confluence/
[11] « PORTAIL DES SERVICES RENATER » consulté le 12/05/2022 et disponible sur :

https ://services.renater.fr/sourcesup/nexus
[12] « À quoi sert jira » : https ://www.atlassian.com/fr/software/jira/guides/use-cases/what-

is-jira-used-for
105
106 Webographie
[13] « Swagger » : https ://fr.wikipedia.org/wiki/Swagger( logiciel)
[14] « Soap UI » : https ://fr.wikipedia.org/wiki/SoapUI

Annexes
Annexe A : Agile Scrum
Scrum Master
S’assure que l’état d’esprit Agile et les pratiques de

Scrum sont compris et bien appliqués dans le projet
et soutient le Product Owner pour s’assurer que la
Valeur maximale est délivrée. Responsabilités :
— Protège l’équipe contre les interruptions externes

— Leader au service de l’équipe, il apporte son aide là où elle est nécessaire
— Protège l’équipe, supprime les blocages et facilite la communication
— Promeut l’amélioration continue
— Permet à l’équipe d’améliorer son efficacité et la qualité des livrables en suivant
les bonnes pratiques de développement Agile
— Motive l’équipe et incarne un état d’esprit positif et constructif en plus des va-
leurs et de la culture Agile
107
108 Webographie
Extended Team
Project Management Officer
Le Project Management Officer Digital (PMO Digi-

tal) est la personne qui assiste le directeur de pro-
gramme dans le pilotage opérationnel du projet
(coûts, qualité, délais) afin de permettre l’atteinte
des Responsabilités :
— Il intervient dans la mise en place de la structure projet, dans le pilotage opé-

rationnel du projet tout en s’appuyant sur les principes de la méthode Agile
(cérémonies, calcul de la vélocité, burn down chart...), ainsi que dans le suivi
des engagements .
— Il formalise et gère le planning, le budget et le périmètre du projet, alerte le
directeur de programme sur les risques et les causes de risques détectés.
— Il participe à la définition du plan d’actions, du plan de communication, et facilite
la synergie inter équipe au sein du programme. Du fait de sa position, le PMO
est en contact avec un nombre important d’acteurs issus de toutes les familles
métier et de tous les niveaux hiérarchiques.
Coach Agile
Evangélise, forme et coache les individus, les

équipes et l’organisation dans l’adoption des va-
leurs et principes de l’agile. Il apporte son soutien
pour la mise en application des pratiques agile, fa-
cilite et anime les événements. Il accompagne l’or-
ganisation dans sa transformation agile aussi bien
sur le plan organisationnel que sur le plan humain.
Responsabilités :
— Aide l’organisation à adopter les valeurs et principes Agiles, comprendre son

état d’esprit et promouvoir les comportements Agiles
— Accompagne et inspire les équipes pluridisciplinaires dans la livraison de Pro-
duits à un rythme constant, conformément aux principes Agile
Webographie 109
— S’assure que l’équipe a de bonnes pratiques Agiles dans toutes les phases du
projet en observant, questionnant et fournissant du feedback
— Aide l’équipe à mettre en place l’amélioration continue
— Met à jour en permanence les formations et les documents de bonnes pratiques
au fur et à mesure de l’évolution de la maturité de l’organisation
— Réalise régulièrement des évaluations sur la maturité Agile des équipes et aide
à définir des plans d’actions pour s’améliorer
UX/UI Designer
Crée un parcours client détaillé et des wireframes

pour une expérience utilisateur fluide, intuitive et
innovante. Responsabilités :
— Identifie et collecte les informations issues de la recherche utilisateur et des

analyses de marché
— Challenge les bénéfices du client et de l’entreprise
— Etablit les personas et construit le parcours client
— Crée des wireframes et des maquettes efficaces
— Prototype le produit digital et illustre les fonctionnalités
— Effectue une veille permanente des tendances UX et UI

PFE Bridge

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

PFE Bridge

Transféré par

Droits d'auteur :

Formats disponibles

Rapport PFE

Enrichissement du catalogue des APIs

Réalisé par :CHQIR Samia

Encadrant interne :Mme Membres du Jury :

Année universitaire 2021-2022

Je dédie ce modeste travail

A mes chers parents,

A mes exceptionnels amis,

A mes encadrants et tous mes professeurs,

A tous ceux qui m’aiment,

À tous ceux qui ont participé de près ou de loin à l’élaboration de ce travail.

We obtained as a result a catalogue of reusable APIs ready to be consumed. It is a ge-

Keywords : API, Bridge, AFS, CBS, WSo2, SMG, REST, GraphQL.

SOCIETE GENERALE AFRICAN BUSINESS

AFS Africaine sub-sahariène

API Application Programming Interface

CBS Core Banking System

AFMO Afrique Méditerranée et Outre-mer

SMG Services Métier Génériques

EDB EXPRESSION DES BESOINS

JSON JavaScript Object Notation

JWT JSON Web Token

1.1 Logo de l’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1 Rôle des APIs Unibank dans le cadre du programme Bank Up . . . . . . . . 41

4.2 Qualité du code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

1.1 Fiche Signalétique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1 Comparaison entre Spring Boot et Node.js . . . . . . . . . . . . . . . . . . . 54

1 Contexte général du projet 15

2 Étude détaillée du projet 28

3.3.2 Domain-driven design . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4 Réalisation et mise en oeuvre 63

Conclusion générale 104

Le secteur bancaire ne cesse de se transformer. L’Open Banking (système bancaire ou-

Contexte général du projet

1.2 Le groupe SGABS

1.2.1 Présentation générale du groupe

Figure 1.1 – Logo de l’entreprise

d’une banque locale.

1.2.2 Fiche signalétique

Dénomination sociale Société Générale African Business Services

Table 1.1 – Fiche Signalétique

1.2.3 Organigramme et administration de l’entreprise

Raison d’être et objectifs

— Réaliser des solutions digitales à destination des filiales de la région AFS, 1

— Un Product Management Agile, afin de construire un produit basé sur la valeur de

Figure 1.2 – Organisation de la DiFa

Les programmes de la DiFa

UniBank permet de connecter rapidement les applications (hébergées en interne ou ex-

1.3 Présentation du projet

Dans un monde qui va contre la multidisciplinarité, vers le centre de préoccupation unique,

1.3.2 Objectifs du projet

1.4 Conduite de projet

1.4.1 Ressources humaines

Nom et prénom Rôle

1.4.2 Méthodologie de travail

Figure 1.3 – Méthode Scrum

Cette figure schématise les étapes suivantes :

Figure 1.4 – Pizza Team

Figure 1.5 – Devops

Taches Durée Début Fin

Table 1.2 – Planification du projet

Pour organiser mon projet en phases chronologiques et organisationnelles, j’ai élaboré

Un extrait de ce diagramme est présenté dans la figure ci-dessous.