RapportPFE Maadani Khalil Qatab Salah-Eddine

Mémoire de Projet de Fin d’Études
Pour l’Obtention du Titre

D’Ingénieur d’État en Informatique
Option
Génie Logiciel
La Refonte de l’Application de l’Entrée en Relation

Digitale de la Banque
Sous la direction de :
M. GUERMAH Hatim (ENSIAS)
M. BEL RHITRI Mohammed (BANK AL YOUSR)
Réalisé par :
Salah-Eddine QATAB
Soutenu le 29 Septembre 2022 devant le jury :
Khalil MAADANI
Mme. EL ASRI Bouchra (Président)
M. TABII Youness (Examinateur)
M. GUERMAH Hatim (Encadrant interne)
Année universitaire : 2021-2022
‫ﻚ ﺃَﻧ ْ َ‬
‫ﺖ ﺍﻟْ َﻌ ِﻠﻴ ُﻢ ﺍﻟْ َﺤ ِﻜﻴ ُﻢ‬ ‫ﻻ َ َﻣﺎ َﻋﻠّ َ ْﻤ َﺘ َﻨﺎ ۖ ِﺇﻧ ّ َ َ‬ ‫ﻚ َ‬
‫ﻻ ِﻋ ْﻠ َﻢ ﻟَ َﻨﺎ ِﺇ ّ‬ ‫ُﺳﺒ َﺤﺎﻧَ َ‬
‫ْ‬
Dédicace
À mes très chers parents

Pour votre amour, vos encouragements, vos sacrifices et vos prières
Aucun mot ne saura exprimer mes sentiments d’amour, de respect et de
gratitude envers vous ;
À mes chers frères et sœurs

Pour tout ce que vous avez fait pour moi, Je vous souhaite une vie pleine
de bonheur et de succès ;
À mes chers cousins

Pour votre soutien, vos encouragements et votre confiance en moi ;
À mes chères amis

Pour votre gentillesse, votre compréhension, pour les beaux moments
qu’on a passé ensemble, ...bref pour votre amitié ;
À toute ma grande famille ;

À toute personne qui m’est chère ;
À tous ceux qui m’aiment ;
Un grand Merci à vous.
text Salah-Eddine
3
Remerciements
Au terme de ce travail, nous tenons à exprimer notre profonde gratitude et nos sincères
remerciements pour tous ceux qui nous ont aidés de près ou de loin pendant la durée de
notre stage.
Nous tenons également à remercier Monsieur GUERMAH Hatim, professeur à l’EN-
SIAS pour son encadrement, son enthousiasme vis-à-vis notre projet et ses encourage-
ments. Nos sincères remerciements sont à adresser à Mr. BEL RHITRI Mohammed et
Mr. RASSIF Hisham qui nous ont fait l’honneur de nous encadrer tout au long de ce tra-
vail. Nous leurs en sommes très reconnaissants pour ses fructueux conseils et précieuses
directives, et pour le grand souci qu’ils portent à l’égard de notre sujet.
Remerciements spéciaux à tout le corps professoral de l’ENSIAS, pour la formation
de qualité qu’ils nous ont prodiguée durant ces trois années. Que tous ceux et celles qui
ont contribué de près ou de loin à l’accomplissement de ce travail trouvent l’expression
de nos remerciements les plus chaleureux.
4
Résumé
l’ère du digital, les banques au même titre que les autres agents économiques se
A trouvent dans l’obligation de s’adapter aux Nouvelles Technologies de l’Infor-

mation et de la Communication. La crise sanitaire Covid-19 est venue accélérer
ce changement en incitant à l’adaptation des services dématérialisés comme moyen de
préserver l’activité dans le respect des normes sanitaires.
En effet, qu’il s’agit de la désintermédiation des opérations ou la disparition du cash,

les stratégies de digitalisation ont pour objectif de garantir l’immédiateté des opérations
dans un objectif de gain du temps et en efficacité.
Dans cette perspective, Bank AL YOUSR a misé, entre autre, sur la digitalisation du
processus de « création de compte », étant le point de départ pour l’entrée en relation
avec un client, qui donnera lieu ensuite à la consommation des différents produits offerts
par la banque (crédit, assurance, etc). Ainsi, il a été mis à la disposition des clients de
Bank AL YOUSR une solution en ligne pour la création de compte individuel. Toutefois,
cette solution présente certaines limites, notamment, l’absence de moyens de vérification
des données fournies par le client, et l’alourdissement du système bancaire de base (Core
Banking) T24 avec des comptes non vérifiés.
Notre projet consiste en une refonte de tout le processus et la mise en place une nou-
velle solution mettant en avance la vérification digitale et traitement des données d’une
pièce d’identité, l’intégration d’une solution visioconférence et le verrouillage de l’interac-
tion avec le core banking. Ceci tout en prenant en considération les règles juridiques et
sécuritaires et les visions stratégiques de la banque.
5
Nous avons fait appel durant les phases du projet à une panoplie de technologies, des
outils de développement, de tests, d’automatisation et d’intégration continue comme :
ProcessMaker, SPRING, REACT-JS, KERAS.
Mots clés : Entrée en relation, Processus, Ouverture de Compte en Ligne,Flux mé-
tier,Traitement des pièces d’identité.
Page 6
Abstract
n the digital age, banks, like other economic agents, are forced to adapt to the new
I information and communication technologies. The Covid-19 health crisis accelerated

this change by encouraging the adaptation of dematerialized services as a means of
preserving activity in accordance with health standards.
Whether it is the disintermediation of transactions or the disappearance of cash, digi-

tization strategies aim to guarantee the immediacy of transactions in order to save time
and efficiency. In this perspective, Bank AL YOUSER has, among other things, banked
on the digitalization of the “account creation” process, being the starting point for ente-
ring into a relationship with a customer, which will then lead to the consumption of the
various products offered by the bank (credit, insurance, etc.).
For example, Bank AL YOUSER’s customers have been provided with an online solution
for individual account creation. However, this solution has some limitations, including the
lack of means to verify the data provided by the customer, and the additional burden on
the T24 Core Banking system with unaudited accounts.
Our project consists of a redesign of the entire process and the implementation of a
new solution that puts forward the digital verification and data processing of an identity
document, the integration of a videoconference solution and the blocking of the interac-
tion with core banking. This while taking into account the bank’s legal and security rules
and strategic visions.
During the project phases, we used a variety of technologies, development, testing, auto-
mation and continuous integration tools such as : ProcessMaker, SPRING, REACT JS,
KERAS.
Initially in this project, we had to identify the issue then define the functional and
technical specifications. After, we’ve focused on the analysis and design parts. We’ve
developed several intermediate architectures that finally lead us to the appropriate archi-
tecture.
7
Keywords : Online Account Opening, Process, Workflow, Identity documents processing,
Customer onboarding.
Page 8
Table des figures
1.1 Fiche signalétique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1.2 analyse SWOT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.3 organigramme de l’organisme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.4 La Méthode Agile "Scrum" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.5 L’interface de Trello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.1 Processus actuel d’entrée en relation digitale de la bank . . . . . . . . . . . . 32

2.2 Etude Benchmarking des solutions digitales d’ouverture de compte sur le
marché bancaire marocain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.1 Modélisation BPMN du Flux "création de dossier d’ouverture” . . . . . . . . 45

3.2 Modélisation BPMN du Flux "Traitement d’un dossier d’ouverture” . . . . 46
3.3 Exécution de la tâche "demande de création d’espace d’adhésion" . . . . . . 48
3.4 Exécution d’évènement intermédiaire d’envoi de message . . . . . . . . . . . 48
3.5 Exécution de la tâche "vérification des données" . . . . . . . . . . . . . . . . . 48
3.6 Exécution de la tâche "choix du type de client" . . . . . . . . . . . . . . . . . 49
3.7 Exécution de la tâche "importer la pièce d’identité" . . . . . . . . . . . . . . 49
3.8 Exécution de la tâche "reconnaissance du PID" . . . . . . . . . . . . . . . . . 49
3.9 Exécution de la tâche "extraction des données" . . . . . . . . . . . . . . . . . 50
3.10 Carte de sous processus "Création du dossier d’ouverture" . . . . . . . . . . 51
3.11 Architecture fonctionnelle globale (model C4[2]) . . . . . . . . . . . . . . . . 52
3.12 Architecture fonctionnelle de l’API EER (model C4[2]) . . . . . . . . . . . . 54
3.13 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.14 Diagramme de séquence "Authentification" . . . . . . . . . . . . . . . . . . . . 58
3.15 Diagramme de séquence "Traitement d’une PID pour remplissage automa-
tique du formulaire" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.16 : Diagramme de séquence "créer un dossier d’ouverture" . . . . . . . . . . . 61
3.17 Diagramme de séquence "Traiter un dossier d’ouverture" . . . . . . . . . . . 63
3.18 Architecture d’intégration continue . . . . . . . . . . . . . . . . . . . . . . . . 65
9
TABLE DES FIGURES
4.1 Architecture technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.2 Etapes de resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.3 chargement d’images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.4 modèle de prè-traitement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.5 Flux d’augmentation de données . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.6 modèle d’augmentation des données . . . . . . . . . . . . . . . . . . . . . . . 75
4.7 exemple d’image augmentée . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.8 Bloc Résiduel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.9 versions de l’architecture ResNet et ses configurations . . . . . . . . . . . . 77
4.10 Construction du modèle avec Keras API . . . . . . . . . . . . . . . . . . . . 78
4.11 Processus d’entraînement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.12 entraînement du modèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.13 Conversion du modèle en modèle probabiliste . . . . . . . . . . . . . . . . . 80
4.14 example de prédiction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.15 Fonction de représentation graphique . . . . . . . . . . . . . . . . . . . . . . 81
4.16 Prédictions sur des images de test . . . . . . . . . . . . . . . . . . . . . . . . 82
4.17 Processus OCR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.18 Region Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.19 Affinity Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.20 l’entraînement du modèle de detection du texte . . . . . . . . . . . . . . . . . 85
4.21 Architecture CRNN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.22 l’entraînement d’extracteur du texte . . . . . . . . . . . . . . . . . . . . . . . 87
4.23 exemple d’extraction des données. . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.24 page d’inscription. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.25 test d’API "inscription". . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.26 l’envoi du mail. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.27 page login. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.28 Test d’API "se connecter" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
4.29 page demande de création dossier d’ouverture. . . . . . . . . . . . . . . . . . 91
4.30 page demande de création dossier d’ouverture. . . . . . . . . . . . . . . . . . 92
4.31 Test d’API " création d’un dossier". . . . . . . . . . . . . . . . . . . . . . . . . 92
4.32 Test d’API "obtention de toutes les agences. . . . . . . . . . . . . . . . . . . . 93
4.33 Liste des prospects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.34 Détails du dossier - informations personnelles . . . . . . . . . . . . . . . . . . 94
4.35 Détails du dossier - identification . . . . . . . . . . . . . . . . . . . . . . . . . 95
4.36 Détails du dossier - informations financières . . . . . . . . . . . . . . . . . . . 95
4.37 Détails du dossier - Agence & Offre & Rendez-vous . . . . . . . . . . . . . . 96
4.38 Test d’API "obtention des dossiers". . . . . . . . . . . . . . . . . . . . . . . . . 96
Page 10
Liste des tableaux
1.1 Equipe du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

1.2 Backlog du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.1 Scénario d’inscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.2 Scénario de création de dossier d’entrée en relation . . . . . . . . . . . . . . . 39
2.3 Scénario participer au visioconférence . . . . . . . . . . . . . . . . . . . . . . . 39
2.4 Scénario traiter dossiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.1 Description du diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . 57

3.2 Description du diagramme de séquence "Traitement d’une PID pour rem-
plissage automatique du formulaire" . . . . . . . . . . . . . . . . . . . . . . . . 60
3.3 Déscription du diagramme de séquence "créer un dossier d’ouverture" . . . 62
4.2 La liste des IDEs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

4.1 La liste des Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.3 Déscription EER API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.4 Déscription PidProcessing API . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.5 Déscriptions des endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
11
Liste des abréviations
API Application Programing Interface. 9–11, 14, 53–55, 69, 71, 72, 77, 82, 85, 89,
91–93, 96
BPMN Business Process Model and Notation. 9, 14, 44–46, 66
CIN Carte d’Identité Nationale. 43, 60, 72, 73

CNN Convolutional Neural Network. 72, 76, 83, 86
CRNN Convolutional Recurrent Neural Network. 10, 72, 85, 86
CTC Connectionist Temporal Classement. 86, 87
EER Entrée en Relation. 9, 11, 14, 53–55, 71

ERP Enterprise Ressource Planning. 98
KYC Know Your Customer. 34, 36, 40, 43, 44, 64
LSTM Long Short-Term Memory. 86
NN Neural Network. 72
OCR Optical Character Recognition. 10, 53, 60, 69, 82
PID Pièce d’Identité. 9, 11, 59, 60

PME Petites ou Moyennes Entreprises. 20
PMI Petites et Moyennes Industries. 20
ResNet Residual Neural Network. 76, 77

RNN Recurrent Neural Network. 86
SMTP Simple Mail Transfer Protocol. 90

SWOT Strength Weakness Opportunity Threat. 9, 20, 21
12
Table des matières
Résumé 5
Abstract 7
Table des figures 9
Liste des tableaux 9
Liste des abréviations 12
Introduction 15
1 Contexte général du projet 17

1.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . 18
1.1.1 Produits proposés : Mise sur l’authenticité et L’innovation . . . . . 19
1.1.2 Une politique de proximité : . . . . . . . . . . . . . . . . . . . . . . . . 20
1.1.3 Analyse de l’environnement de Bank Al Yousr : . . . . . . . . . . . . 20
1.1.4 Structure interne de Bank Al Yousr : . . . . . . . . . . . . . . . . . . . 21
1.2 Présentation generale du projet . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.2.1 Contexte general du projet . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.2.2 Problématiques : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.2.3 Objectifs et Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.3 Conduite du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.3.1 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.3.2 Membres de l’équipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.3.3 Outil de collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.3.4 Planification du project . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.4 Conclusion : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
13
TABLE DES MATIÈRES
2 Analyse des besoins 31

2.1 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.1.1 Description de la solution actuelle chez Bank ALYOUSR : . . . . . . 32
2.1.2 Etude Benchmarking : . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.2 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.2.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.2.1.1 Acteurs actifs : . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.2.1.2 Acteurs Système : . . . . . . . . . . . . . . . . . . . . . . . . 35
2.2.2 Identifications des fonctionnalitées . . . . . . . . . . . . . . . . . . . . 36
2.2.3 Diagramme de Cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . 37
2.3 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.4 Conclusion : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3 Conception 42
3.1 Processus métier d’entrée en relation digitale . . . . . . . . . . . . . . . . . . 43
3.1.1 Description textuel du processus d’entrée en relation digitale : . . . 43
3.1.2 Modélisation BPMN et exécution du processus d’entrée en relation . 44
3.1.2.1 Modélisation BPMN du processus d’entrée en relation . . . 44
3.1.2.2 Exécution du processus en utilisant ProcessMaker : . . . . 47
3.2 Architecture fonctionnelle du logiciel . . . . . . . . . . . . . . . . . . . . . . . 51
3.2.1 Architecture fonctionnelle globale . . . . . . . . . . . . . . . . . . . . . 51
3.2.2 Architecture fonctionnelle de l’API EER . . . . . . . . . . . . . . . . 53
3.3 Diagramme de classe : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.4 Diagrammes de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.4.1 Diagramme de séquence « Authentification » : . . . . . . . . . . . . . 57
3.4.2 Diagramme de séquence «Traitement d’une pièce d’identité» : . . . . 59
3.4.3 Diagramme de séquence « créer un dossier d’ouverture » : . . . . . . 61
3.4.4 Diagramme de séquence « Traiter un dossier» : . . . . . . . . . . . . 63
3.5 Intégration continue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.6 Conclusion : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4 Réalisation 67
4.1 Technologies et Outils : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.2 Réalisation du backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.2.1 Architecture technique du système : . . . . . . . . . . . . . . . . . . . 70
4.2.2 Module de traitement des pièces d’identités . . . . . . . . . . . . . . . 72
4.2.2.1 Reconnaissane des pièces d’identités . . . . . . . . . . . . . 72
4.2.2.2 Extraction des données des pièces d’identités . . . . . . . . 82
4.2.3 Module de traitement d’un dossier d’ouverture . . . . . . . . . . . . . 88
4.3 Conclusion : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Conclusion 98
Webographie 99
Page 14
Introduction
Aujourd’hui, la digitalisation est devenue maitre mot des pratiques commerciales des
entreprises. Assurer un service en ligne, développer une interactivité avec la clientèle
et bénéficier des gains de temps remarquables permettent de renforcer son poids sur le
marché, de dégager plus de rentabilité et de bénéficier des économies d’échelle. Le secteur
bancaire n’a pas échappé à ces évolutions.
A cet égard, la digitalisation des services bancaires, tout en venant faciliter la vie aux
banques et à la clientèle est devenue un déterminant de lutte concurrentielle, de diffé-
rentiation des services bancaires et de positionnement stratégique. Les premières banques
capables à intégrer les meilleures pratiques technologiques sur un marché bancaire, sont
à même capables d’attirer plus de clients.
Bank ALYOUSR, en tant que nouveau intervenant sur le marché bancaire marocain
se fixe des challenges non seulement au niveau de l’originalité du service rendu et des
produits proposés mais aussi au niveau de la manière avec laquelle ce service est commer-
cialisé.
Actuellement, Bank ALYOUSR dispose d’une solution en ligne qui permet de créer un
compte non vérifié au niveau du core banking et effectuer les premiers versements. Cette
solution ne permet ni le remplissage automatique des données à partir des pièces d’identité,
ni vérification automatique de ces dernières. De plus, l’interaction avant vérification avec
le système bancaire nuit à la qualité de ce dernier en l’alourdissant avec des comptes
abandonnés lors de la vérification. L’agent bancaire reste chargé dans un tel système de
vérifier manuellement les pièces d’identité et le client est toujours tenu de se présenter en
agence pour fournir ses pièces d’identité,
15
TABLE DES MATIÈRES
compléter les contrôles KYC et signer les contrats.
A la lumière d’une étude approfondie de l’existant et des réunions réguliers avec les
équipes SI, marketing et communication et planification stratégique de la banque, il a été
assigné à ce projet les objectifs suivants :
* Modélisation d’un nouveau processus fluide, efficace et sécurisé conformément aux
règles juridiques, de sécurité gérant le secteur bancaire ;
* Le développement de la fonctionnalité de vérification digitale et traitement des
données d’une pièce d’identité,
* Le développement d’une fonctionnalité de visioconférence permettant de boucler
le processus KYC ;
* Le Verrouillage de l’interaction avec le core banking pour ne prendre en compte
que des comptes validés.
Le présent rapport est composé de quatre chapitres : Le premier chapitre présente
le contexte général du projet, à savoir l’organisme d’accueil, le cadre général du projet,
ainsi que la méthodologie de travail suivie. Le deuxième chapitre se focalise sur la partie
analyse des besoins qui englobe une étude de l’existant ayant permis de dresser les besoins
fonctionnels et non fonctionnels du système. La modélisation du processus et des exigences,
l’organisation des étapes du projet et l’architecture du système font l’objet du troisième
chapitre. Un quatrième chapitre est dédié à la phase réalisation avec les outils choisis et
les principaux résultats obtenus.
Le mémoire se termine par une conclusion générale qui présente le bilan du travail réalisé
et ses principales perceptives.
Page 16
CHAPITRE 1
Contexte général du projet
il est particulièrement intéressant de présenter le cadre général dans lequel s’est déroulé
notre projet. A cette fin, le chapitre présent est consacré à présenter ce qui suit :
** Un aperçu sur l’organisme d’accueil : Bank Al Yousr
** Présentation du projet en expliquant les motivations et objectifs et exposant la
problématique à résoudre.
** Les méthodes, outils et moyens utilisés dans la conduite de ce projet.
17
CHAPITRE 1. CONTEXTE GÉNÉRAL DU PROJET
1.1 Présentation de l’organisme d’accueil

Bank Al Yousr est la banque participative du groupe BCP. Elle est le fruit d’un
partenariat entre la Banque Centrale Populaire, l’une des banques les plus puissantes
dans le système bancaire marocain et le groupe Guidance, expert international de la
finance participative.
Conformément à l’article 54 de la loi bancaire 103-12, Bank Al Yousr est une personne
morale agréée et habilitée à recevoir les fonds à vue et d’investissement du public, à gérer
et mettre à disposition de sa clientèle les moyens de paiement et à offrir des produits de
financement comme Mourabaha, Ijara, Moucharaka, Moudaraba, Salam et à effectuer les
opérations commerciales, financières et d’investissement conformément aux avis du comité
Charia du CSO.
Sous le slogan «BANK AL YOUSR, une autre façon de faire la banque», Bank Al
Yousr présente sur le marché bancaire marocain, des alternatives aux produits et pra-
tiques bancaires traditionnels. Avec une panoplie de produits participatifs couvrant l’en-
semble des activités bancaires, Bank Al Yousr s’adresse à l’ensemble des segments de la
clientèle qu’ils soient particuliers-locaux, Marocains Du Monde, étrangers résidents ou
non-résidents, professionnels ou entreprises.
Page 18
F IGURE 1.1 – Fiche signalétique
1.1.1 Produits proposés : Mise sur l’authenticité et L’innovation

L’offre de produits financiers participatifs de Bank Al Yousr porte, dans un premier
temps, sur des produits équivalents à ceux auxquels sont habitués les Marocains au ni-
veau des banques conventionnelles, mais la phase suivante connaîtra un déploiement du
potentiel intégral de la finance participative et de la panoplie de produits qu’elle recèle
pour financer l’économie réelle et répondre aux besoins et attentes des clients.
Les produits participatifs actuellement approuvés par le comité Charia du CSO se
présente comme suit : Il convient de souligner à cet égard que les articles 58 et 59 de la loi
bancaire 103-12 ont ouvert la voie à l’innovation financière en donnant la possibilité aux
banques participatives de proposer d’autres produits que ceux initialement agréés sous
réserve de leur conformité aux préceptes de la Charia et après validation par Bank Al-
Maghrib et approbation du Comité Charia pour la finance et du Comité des établissements
de crédit.
Bank Al Yousr vise à couvrir l’ensemble des activités de la banque universelle, à
Page 19
savoir la collecte des dépôts et la distribution de crédits. Elle proposera également des
instruments de placement et d’investissement. «Nous ne voulons surtout pas reproduire à
l’identique les produits de la banque conventionnelle. Il s’agira aussi de proposer une offre
compétitive par rapport aux produits de la finance classique» précise le DG de la BCP.
1.1.2 Une politique de proximité :

Dans un environnement à concurrence féroce, Bank Al Yousr mise sur une politique
de proximité réellement traduite par :
— la mise en place d’espaces modernes et conviviaux permettant d’accueillir et de
conseiller ses clients dans des conditions optimales,
— Un réseau de distribution dédié qui se renforce continuellement pour couvrir l’en-
semble du territoire marocain,
— Une banque digitale qui rend la banque encore plus proche et plus pratique, vous
dispensant de la contrainte de se rendre en agence,
— Un réseau d’à peu près 1400 agences et plus de 1400 Guichets Automatiques de la
Banque Populaire mis à la disposition des clients de Bank Al Yousr pour gérer en
total respect de la séparation des flux entre les deux entités.
1.1.3 Analyse de l’environnement de Bank Al Yousr :

Avec une croissance mondiale à deux chiffres, l’industrie de la banque islamique est
une potentielle opportunité pour le Maroc dont le marché est au stade embryonnaire.
Le marché de la banque islamique au Maroc est au stade de niche encours de créa-
tion avec un énorme potentiel de développement (plus de 40 % clients sont non encore
bancarisés)
La particularité des banques islamiques est certainement la conformité de ses produits,
ses processus et son mode de gestion aux principes de la charia. Une partie de l’identité
des partisans est enfin libérée avec des banques qui promouvaient le principe de partage
de profits et de pertes. Ce principe viendra encourager surtout le développement des PME
et PMI et promouvoir l’innovation entrepreneuriale.
Afin de clarifier le positionnement stratégique de Bank Al Yousr au sein du secteur
bancaire islamique, il nous est paraît judicieux d’effectuer une analyse SWOT permettant
de se rapprocher de l’environnement interne et externe dans lequel opère Bank Al Yousr.
Notre analyse SWOT se présente comme suit :
Page 20
F IGURE 1.2 – analyse SWOT
1.1.4 Structure interne de Bank Al Yousr :

La banque adopte une structure horizontale avec peu de niveaux de management
intermédiaire qui favorise le travail en autonomie et l’innovation.
L’organigramme de Bank Al Yousr est présenté comme suit :
Page 21
F IGURE 1.3 – organigramme de l’organisme
Nous avons été affectés à la division système d’information et flux, plus précisément
au sein de la direction Étude et développement qui a pour rôle de définir et mettre en
œuvre la stratégie de développement informatique pour un fonctionnement optimal du
système d’information et de communication au sein de la banque.
Avec une démarche résolument orientée client, un réseau dédié, une équipe de pro-
fessionnels et une offre compétitive, conforme et innovante, Bank Al Yousr réunit les
conditions nécessaires pour occuper un rang stratégique dans cette nouvelle finance. Par
ailleurs, une veille continue du marché permet à Bank Al Yousr de s’adapter en perma-
nence aux besoins et exigences des clients dont la satisfaction est une priorité absolue
pour la banque.
Page 22
1.2 Présentation generale du projet
1.2.1 Contexte general du projet

Notre projet s’inscrit dans le cadre de la politique de proximité assignée par Bank
Al Yousr, interprétée dans sa stratégie de digitalisation par des objectifs d’efficacité et
d’instantanéité de l’approche client et des services rendus.
Dans cette perspective, la digitalisation de deux processus clés constitue une préoccu-
pation majeure du département «Etude et développement» à savoir :
• Le processus d’ «entrée en relation».
• Le processus d’«octroi de crédits».
Nous avons été interpellé à intervenir sur le premier axe : Digitalisation du processus
d’«entrée en relation».
La digitalisation de ce processus a pour objectif d’aligner la banque avec ses concur-
rents.
L’ensemble des banques au Maroc aujourd’hui proposent des parcours d’ouverture des
comptes en ligne avec des niveaux de digitalisation qui vont de la simple préouverture de
compte à la création à 100% en ligne avec vérification à distance.
A l’heure actuelle, Bank Al Yousr mets à la disposition de ses clients une solution
en ligne qui répond partiellement à ce besoin. La solution permet de créer un compte à
distance et effectuer les premiers versements. Toutefois, la présentation du client en agence
pour vérification des pièces d’identité et signature de contrats reste nécessaire pour une
validation définitive du compte permettant l’accès aux différents services (consultation de
soldes, téléchargement de relevés, paiements, virements, opérations d’épargne, de bourse
en ligne, demandes réelles de crédits). En plus d’un manque de digitalisation complète du
processus, l’ancienne solution présente certains problèmes à savoir :
• l’application est peu interactive avec l’utilisateur,du fait ce dernier remplisse ma-
nuellement différents formulaires requis, cela peut mener à une expérience utilisa-
teur pénible.
• Absence de moyens de vérification des données fournies par le client
• La solution interagit directement avec le système bancaire de base (Core Banking)
T24 en créant des comptes sur ce dernier qui seront pas forcément validés par la
suite. Ceci nuit à la qualité du système en l’alourdissant avec des comptes irréels.
Page 23
1.2.2 Problématiques :
À l’ère du digital et face à une concurrence acharnée, et des clients de plus en plus
exigeants, l’automatisation du processus d’entrée en relation est devenue un minimum
indispensable afin de garantir une approche client efficace.
L’automatisation d’un tel processus révèle un certain nombre d’enjeux et d’exigences
à savoir :
• Répondre aux besoins généraux d’une application d’ouverture de compte en ligne-
qui sont le gain de temps, une accessibilité à tout moment, et l’élimination des
tâches administratives au profit de la commercialisation des produits,
• Assurer une attractivité commerciale par une application qui assure meilleure ex-
périence utilisateur,
• Respecter les enjeux sécuritaires et réglementaires,
• Pallier aux limites de l’ancienne application, particulièrement le manque de vérifi-
cation digitale des données.
De ce qui a précédé, notre problématique se formule comme suit : «La réalisation au
profit de Bank Al Yousr d’un processus de souscription 100 en ligne avec transmission
numérique des justificatifs et vérification instantanée pouvant accorder à la banque un
avantage concurrentiel par la qualité du code et de l’expérience utilisateur en respectant
la réglementation bancaire, le devoir de diligence des banques au sujet des clients et les
normes de sécurité en matière de manipulation de données personnelles».
1.2.3 Objectifs et Motivations

Le travail sur un projet réel déclinant de la stratégie de la structure, touchant à
plusieurs aspects de notre formation en génie logiciel, et faisant appel à plusieurs connais-
sances dans le domaine des nouvelles technologies constitue notre réelle motivation pour
ce projet.
Vu l’ampleur du projet, notre ambition au cours de ce stage était d’avancer au maxi-
mum dans les phases de réalisation de l’application au point qui permet d’exprimer notre
vision pour l’application, grâce à :
• la présentation d’une conception détaillée et conforme au besoin,
• Un avancement sur les fonctionnalités clés de l’application et celles qui constituent
notre valeur ajoutée : vérification des pièces,
Page 24
1.3 Conduite du projet
1.3.1 Méthodologie de travail

La méthodologie de travail que nous avons adoptée pour mener à bien notre mission
est la méthode agile. Notre choix est justifié par l’aspect itératif et incrémental de cette
méthode. En effet, en utilisant des sprints de durée qui varient généralement entre une à
trois semaines, nous sommes en mesure d’accélérer le développement du logiciel et béné-
ficier d’un retour rapide du client. A la fin de chaque sprint le client peut voir un aperçu
partiel de l’avancement du projet appelé incrément, en plus s’il y a des modifications, le
changement sera plus facile à intégrer dans les prochains sprints.
La figure suivante (Figure. 1.4) Illustre la méthode de gestion de projet Scrum. En
utilisant cette méthode, le développement suit une approche itérative et incrémentale.
C’est-à-dire les besoins du client sont recensés puis réparties en des groupes selon leur
niveau de difficulté et leur priorité. Chaque groupe de fonctionnalités fait objet d’un
sprint qui dure entre une à trois semaines et donne lieu à un incrément (une ou des
fonctionnalités développée(s), testée(s) et intégrée(s)).
F IGURE 1.4 – La Méthode Agile "Scrum"
1.3.2 Membres de l’équipe

Notre équipe de projet est composée de cinq personnes qui collaborent dans l’objectif
de réussir ce projet.
Page 25
Membre Nom
Chef de projet Mohammed belghitri
Product Owner Ben malk Otman
Assistant à maîtrise d’ouvrage(AMOA) El mamouni Amine
Equipe de la mise en oeuvre QATAB SALAH-EDDINE

MAADANI KHALIL
TABLE 1.1 – Equipe du projet
1.3.3 Outil de collaboration

Trello est un outil de collaboration lancé en septembre 2011, il permet aux membres
de l’équipe de travailler en ligne.
Trello organise les tâches du projet en plusieurs listes qui représentent l’avancement
de chaque tâche (Sprint Back log, Product Back log, en cour de réalisation, bloqué, à
valider, validé). La tâche est représentée dans Trello par une carte assignée à un membre
de l’équipe, et qui porte son nom.
F IGURE 1.5 – L’interface de Trello
Page 26
1.3.4 Planification du project

La phase la plus importante en avant-projet est la planification, car elle permet de
définir un ordonnancement des tâches du projet, et de donner une estimation de la charge
et de temps à consacrer à chaque tâche. Ceci afin de comparer les objectifs atteints avec les
objectifs préfixés, et pour garantir une bonne communication de l’avancement du projet.
Le tableau ci-après représente la planification prévisionnelle du projet.
Page 27
Back log Activité Date Début Date Fin Criticité

Formation 22/02/2022 28/03/2022 Forte
Sprint 0 :Formation et benchmar-
recueillir les besoins 01/03/2022 07/03/2022 Moyenne
king :
Benchmarking 08/03/2022 22/03/2022 Forte
Analyse 23/03/2022 25/03/2022 Forte
Conception 26/03/2022 28/03/2022 Moyenne
Sprint 1 :Module d’Inscription et Développement 29/03/2022 04/04/2022 Forte
authentification Test 05/04/2022 06/04/2022 Forte
Intégration 07/04/2022 08/04/2022 Moyenne
Revue de sprint 09/04/2022 10/04/2022 Faible
Analyse 11/04/2022 13/04/2022 Forte
Conception 14/04/2022 16/04/2022 Forte
Sprint 2 :Module du traitement Développement 17/04/2022 23/04/2022 Moyenne
des pièces d’identité Test 24/04/2022 25/04/2022 Faible
Analyse 01/05/2022 03/05/2022 Forte
Sprint 3 :Module de gestion des Développement 07/05/2022 11/05/2022 Forte
dossiers d’ouverture Test 11/05/2022 12/05/2022 Moyenne
Analyse 17/05/2022 19/05/2022 Forte
Sprint 4 :Intégration de la solu- Développement 23/05/2022 04/05/2022 Forte
tion visioconférence Test 05/06/2022 06/06/2022 Forte
Analyse 11/06/2022 13/06/2022 Forte
Sprint 5 : Intégration des services Développement 17/06/2022 23/06/2022 Moyenne
du Core Banking T24 Test 24/06/2022 25/06/2022 Moyenne
TABLE 1.2 – Backlog du projet
Déscription des sprints :

• Sprint 0 :Formation et benchmarking :
Page 28
les missions effectués durant sprint 0 sont :

— nous instruire sur le système d’information de la banque (Core Banking T24),
principalement, les différentes activités bancaires supportées par système, et
dans un environnement de paramétrage, nous avons pratiqué le développement
des solutions pour un usage métier spécifique.
— après avoir collecter les exigences, nous avons comparé, à l’aide d’ un bench-
marking, la solution actuelle de la banque avec celles de ses concurrents afin
d’avoir une idée sur les fonctionnalités a mettre en oeuvre, ce qui permet ainsi
d’assurer un avantage concurrentiel dans le marché.
• Sprint 1 :Service d’inscription et authentification :
conception et développement des fonctionnalités permettant la gestion des utilisa-
teurs et leurs accès aux ressources de l ’application.
• Sprint 2 :Module du traitement des pièces d’identité :la conception et dévelop-
pement d’une application permettant la reconnaissance et extraction des données
des pièces d’identité
• Sprint 3 :Module de gestion des dossiers d’ouverture :
mettre en oeuvre une application permettant d’une part au prospect de créer un
dossier d’ouverture, et d’autre part à l’agent bancaire de traiter l’ensemble des
dossiers soumis.
• Sprint 4 :Intégration de la solution visioconférence :
intégration d’une solution de visioconférence fournissant la fonctionnalité d’appel
vidéo, assurant ainsi un entretien a distance entre le prospect et l’agent dont l’ob-
jectif est de compléter en ligne le processus d’ouverture de compte
• Sprint 5 : Intégration des services du Core Banking T24 :
intégrer des services créés au niveau du Core Banking t24 qui assurent notamment :
— la récupération la liste des agences,des villes, etc.
— la création un nouveau client.
— génération et récupération des contrats d’ouverture de compte.
1.4 Conclusion :
Ce chapitre a été consacré à la présentation de l’entreprise d’accueil, Bank Al yousr,
comme il explique le cadre général du projet en mettant le point sur la problématique et
les objectifs à atteindre. Ensuite il décrit la méthodologie adoptée pour la conduite du
projet, à savoir SCRUM, et le planning du travail. Dans Le chapitre suivant, nous allons
Page 29
aborder l’étude préliminaire et fonctionnelle qui va traiter la solution sur laquelle porte
ce projet.
Page 30
CHAPITRE 2
Analyse des besoins
’étude de 1’existant est un point de passage obligé qui matérialise le premier
L contact pour la compréhension des besoins et des objectifs poursuivis ainsi que
le terrain sur lequel ils s’appliquent.
A travers cette compréhension, nous arrivons à la fin de ce chapitre à présenter une
analyse des besoins fonctionnels et non fonctionnels de notre système.
31
CHAPITRE 2. ANALYSE DES BESOINS
2.1 Etude de l’existant
2.1.1 Description de la solution actuelle chez Bank ALYOUSR :

Le processus actuel d’entrée en relation avec le client de Bank ALYOUSR se déroule
en deux étapes utilisant deux canaux différents :
* Un canal virtuel pris en charge par le client lui-même,
* Un canal direct piloté par les agents bancaires.
Le canal virtuel donne accès au client pour remplir ses informations personnelles, choisir
le type de compte souhaité, choisir un pack parmi une panoplie de packs offerts et au final
choisir l’agence et des créneaux pour un rendez-vous téléphonique qu’un agent en choisira
un selon sa convenance.
Le système actuel permet la réduction des tâches administratives réalisées par les
agents, leur permettant ainsi de se focaliser sur les tâches commerciales et le service
avant-vente qui représentent la mission principale de leur poste.
Toutefois, l’intervention humaine occupe encore une grande place dans le système ac-
tuel. L’agent doit gérer des rendez-vous avec les clients afin de s’assurer de l’identité du
porteur du compte, vérifier les pièces justificatifs et clôturer l’ouverture de compte par la
signature des contrats.
F IGURE 2.1 – Processus actuel d’entrée en relation digitale de la bank
Page 32
2.1.2 Etude Benchmarking :

Une étude comparative avec les solutions existantes chez les confrères s’impose afin
d’évaluer les avancés au niveau de la limitation de l’intervention physique de l’agent et
du client ainsi d’identifier les fonctionnalités déjà existantes et en rajouter d’autres qui
peuvent assurer un avantage concurrentiel. Notre étude Benchmarking se présente comme
suit :
F IGURE 2.2 – Etude Benchmarking des solutions digitales d’ouverture de compte sur le mar-
ché bancaire marocain.
D’après cette étude, on constate l’existence de niveaux divergents de digitalisation du

processus «ouverture de compte». Les solutions présentes sur le marché vont de la simple
application de préouverture de compte, en remplissant un formulaire simple sans même
avoir à créer un compte adhésion à la digitalisation complète du processus.
En comparaison avec la solution actuelle de Bank AL YOUSR, on peut dire que cette
dernière se positionne dans un niveau moyen par rapport aux solutions des confrères.
Elle propose les fonctionnalités basiques comme le remplissage manuel du formulaire des
données, l’importation des pièces d’identité sans être capable de les vérifier. Toutefois,
l’intervention de l’agent est toujours nécessaire afin d’assurer la vérification des identités
des clients et la validité des pièces justificatives. Le prospect a toujours l’obligation de se
Page 33
déplacer afin de compléter la procédure et signer les contrats.
D’après cette analyse, nous concluons que nous avons des exemples forts sur le marché
qu’il convient de considérer comme exemples. Afin d’atteindre le niveau de la concurrence,
notre solution doit couvrir, idéalement, l’ensemble des étapes suivantes :
* Création de compte d’adhésion,
* Choix de la catégorie du client,
* Choix de l’offre/Pack,
* Vérification de l’identité,
* Prise de photo(selfie),
* Remplissage automatique de formulaire,
* Remplissage du questionnaire KYC en ligne,
* Choix de l’agence,
* Appel visioconférence,
* Signature électronique.
Parmi les étapes qui manquent dans la solution actuelle, il a été décidé de travailler
principalement sur les suivantes :
* vérification de l’identité,
* remplissage automatique du formulaire,
* Interview en visioconférence,
Nous considérons que l’ajout de ces fonctionnalités permettra d’assurer une solution
digne de concurrencer ses similaires sur le marché et qui répond à l’essentiel de nos ob-
jectifs de réduction de l’intervention humaine et des déplacements.
Il convient de noter que le questionnaire KYC sera rempli lors de la visioconférence. En

effet, l’étape de la visioconférence reste essentielle que le questionnaire KYC soit rempli
en ligne ou pas. Dans ce sens, il s’est avéré judicieux pour l’équipe Marketing de procéder
au questionnement KYC lors de la visioconférence afin de ne pas alourdir l’expérience
client en ligne.
Page 34
La signature électronique sera traitée comme un projet à part qui sera soumis à un
sous-traitant vu les complexités techniques et le besoin d’un niveau d’expertise avancé.
Aussi, la délégation d’une telle fonctionnalité n’interféra pas avec le besoin d’appliquer la
propre vision de la banque comme dans les autres fonctionnalités.
A travers la prise de connaissance des différentes solutions présentes sur le marché,

qu’il soit chez Bank Al YOUSR ou ses confrères, nous avons pu formuler une première
vue sur les besoins fonctionnels et non fonctionnels qu’une telle solution doit remplir.
2.2 Besoins fonctionnels
2.2.1 Identification des acteurs

Un acteur représente l’abstraction d’un rôle joué par des entités externes(utilisateur,
dispositif matériel ou autres systèmes ) qui interagissent directement avec le système
étudié.
2.2.1.1 Acteurs actifs :
les acteurs qui initient l’exécution des cas d’utilisation, ces acteurs sont :
• Internaute : c’est le futur prospect qui doit s’enregistrer pour effectuer la demande
d’entrée en relation.
• Prospect : : c’est le futur client, une fois enregistré il dispose d’un espace personnel
au niveau de notre application.
• Agent : :,c’est l’acteur qui représente la banque durant les opérations de l’ouverture
de compte.
2.2.1.2 Acteurs Système :
les acteurs fournissant des fonctionnalités pour l’exécution des cas d’utilisation,ces ac-
teurs sont :
• Temenos(Le Core Banking de banque ) : est l’ensemble des composants logiciels

de base qui gèrent les services fourni par une banque à ses clients via ses branches
(réseau d’agences).
Page 35
• Application Siron :fournit aux responsables de la conformité une vue d‘ensemble

claire des mesures de mise en conformité permettant de prévenir la criminalité
financière. Les responsables de la conformité bénéficient grâce à cet outil d‘une
image précise de l‘efficacité de l‘ensemble de l‘organisation de la conformité et de
sa situation en termes de risque, et ce, pour toutes les filiales et pour tous les pays.
• OpenVidu : ce système est utilisé pour créer une session d’appel vidéo entre le
client prospect et l’agent.
2.2.2 Identifications des fonctionnalitées

• Création d’un compte d’adhesion : permet à un internaute de créer un canal en
ligne afin d’effectuer et suivre la demande d’entrée en relation.
• Choix du type du client : permet au prospect de s’identifier en tant que Personne

Particulier, Personne Fonctionnaire, Personne Morale.
• Choix du produit : ce sont les différents packs et types de comptes offerts par la
banque, ils sont proposés par le système en fonction du type client.
• importation/prendre une photo de la pièce d’identité : cette fonctionnalité a pour

but d’extraire les données relatives au prospect. elle Permet d’automatiser le rem-
plissage de la signalétique prospect.
• Modifier/valider la fiche signalétique prospect : il s’agit de permettre au prospect

de consulter le formulaire des données personnelles pré-remplie,l’éditer ou le valider.
• Choix de l’agence : il s’agit de choisir l’agence qui sera chargée de gérer ces de-
mandes d’ouverture de compte.
• La gestion rendez-vous :c’est la possibilité offerte au client pour choisir une date
de rendez-vous, et mettre à jour cette date tant que la rencontre à distance avec
l’agent n’a pas été effectuée.
• Remplissage du formulaire KYC(Know Your Customer) : Une obligation de col-

lecter et de conserver les informations concernant le bénéficiaire effectif, ainsi que
Page 36
de les communiquer à un registre central, accessible aux autorités et aux services

de renseignement financiers(parmi les données on trouve : Justificatif de domicile,
Justificatif de Revenus ), son objectif est d’éviter les soucis de conformité.
• Entretien : le système permet d’établir une visioconférence entre l’agent et le pros-

pect afin de verfier l’identité de ce dernier, mettre à jour ou compléter son dossier.
• Consultation des demandes : l’agent peut consulter les differents dossiers et les
documents associés.
2.2.3 Diagramme de Cas d’utilisation

Pour montrer les interactions entre les acteurs et notre système, nous avons réalisé le
diagramme de cas d’utilisation ci-après :
F IGURE 2.3 – Diagramme de cas d’utilisation
Déscription des cas d’utilisation :
Page 37
fonctionnalité Créer un compte d’adhésion

Acteur Internaute
Avoir un canal en ligne particulier au prospect pour recorder et suivre
Finalité
ses activités dans le process d’entrée en relation
Précondition Dispose d’un numéro de téléphone ou un Email
Postcondition création d’un compte pour accéder à son espace via un mot de passe
1. Internaute accède à la page d’accueil.
2. Remplir le formulaire.
3. Système vérifie les coordonnées.
4. Système valide les coordonnées et envoie un lien et code de

Processus Standard
confirmation à l’internaute.
5. l’internaute confirme son email et numéro de téléphone.
6. Système active le compte du nouveau prospect
1. Internaute accède à la page d’accueil.
2. l’Internaute Remplit le formulaire.
Processus Alternatif 3. le Système vérifie les coordonnées
4. le Système rejet les coordonnées (ex :email ou numéro de té-

léphone existants) et envoie un message d’erreur.
TABLE 2.1 – Scénario d’inscription
Page 38
fonctionnalité Créer un dossier d’ouverture

Acteur Prospect
Finalité postuler une demande de création du compte bancaire
1. Prospect doit être authentifié.
Précondition 2. Prospect est autorisé pour créer un dossier d’ouverture.
Postcondition un dossier d’ouverture à été bien crée
1. prospect importe sa pièce d’identité.
2. le système détecte la pièce d’identité
3. le système extrait les données de la pièce d’identité et l’af-
Processus Standard fichent dans une formulaire pré-remplie.
4. Prospect modifie ou valide la formulaire.
5. Prospect choisit une agence et un rendez-vous.
6. Système enregistre le dossier.
1. prospect importe sa pièce d’identité.
Processus Alternatif 2. le système ne détecte pas la pièce d’identité et envoie un

message d’erreur.
TABLE 2.2 – Scénario de création de dossier d’entrée en relation
fonctionnalité Participer au viséoconfrence

Acteur Prospect,Agent
Finalité Effectuer un entretien avec le prospect
1. Prospect doit être authentifié.
2. Agent doit être authentifié .

Précondition
3. Prospect non encore entretenue.
Postcondition un appel vidéo est établie entre l’agent et le prospect
1. l’agent crée une salle de visioconférence .
2. l’agent envoie l’identifiant de la salle au prospect.

Processus Standard
3. le prospect accède au visioconférence
4. l’entretien en cours de déroulement
TABLE 2.3 – Scénario participer au visioconférence
Page 39
fonctionnalité Traiter un dossier

Acteur Agent
Finalité récupérer les données de prospect et les documents associés
1. Agent est authentifié.
2. prospect est authentifié.

Précondition
3. visioconférence en cours de déroulement
Postcondition les données du prospect et les documents associés sont bien vérifiées.
1. l’agent accède le tableau de bord .
2. l’agent sélectionne le dossier du prospect qu’il l’entretient .
3. l’agent vérifie l’identité du prospect.

Processus Standard 4. l’agent remplie les données du KYC qui sont communiquées
lors de l’entretien avec le prospect.
5. le dossier est bien traité et constitue maintenant une de-

mande d’ouverture de compte bancaire.
1. l’agent décide que le dossier est incomplet .
2. l’agent demande du prospect d’envoyer les documents man-

quants.
3. l’agent mis à jour le dossier en rajoutant les documents man-

quants.
Processus alternatif
4. l’agent vérifie l’identité du prospect.
5. l’agent remplie les données du KYC qui sont communiquées

lors de l’entretien avec le prospect.
6. le dossier est bien traité et constitue maintenant une de-

mande d’ouverture de compte bancaire.
TABLE 2.4 – Scénario traiter dossiers
2.3 Besoins non fonctionnels

En plus des besoins fonctionnels, le futur système doit satisfaire d’autres besoins non
fonctionnels. En particulier, notre application doit respecter les besoins suivants :
• Navigabilité et facilité d’utilisation : L’application doit minimiser les tâches des
Page 40
clients et des agents dans chaque étape du processus, respecter les normes de l’er-
gonomie, et permettre une ouverture de compte bancaire dans les meilleurs délais.
Pour cela, le système doit offrir à ces utilisateurs une vue complète sur l’ensemble
des étapes du processus d’ouverture de compte, avec un nombre minimum de clicks
et passages entre les fenêtres, et aussi il doit réduire le nombre des champs à rem-
plir par le client dans chaque étape.
• Fiabilité : l’aptitude du notre système à assurer sa mission dans des conditions d’en-
vironnement données et pendant une durée donnée. La fiabilité caractérise ainsi la
confiance que l’utilisateur peut placer dans le service rendu par le système.
• Sécurité :Dans ce système, la fonction de sécurité qui permet de contrôler les

différents utilisateurs, et applications qui entrent en interaction avec notre système
doit être déléguée à un module d’authentification et gestion des rôles, qui respecte
les standards de sécurité, et qui sera configurable pour tenir en compte les futurs
besoins en termes de sécurité et gestion d’accès.
2.4 Conclusion :
Dans ce chapitre, nous avons étudié la solution actuelle, puis nous avons établi un
benchmarking qui nous a aidé à identifier les caractéristiques et les fonctionnalités que
le futur système doit implémenter, enfin nous avons élaboré sur ces fonctionnalités en les
divisant en besoins fonctionnels besoins non fonctionnels avec description associée pour
chacun de ses éléments
Page 41
CHAPITRE 3
Conception
a phase de conception permet de modéliser les exigences du système avant sa
L mise en œuvre et d’organiser la réalisation du projet en définissant les modules

et les étapes de la réalisation du projet. Nous adoptons dans notre travail les
diagrammes de séquences liés aux cas d’utilisation et le diagramme de classe, pour décrire
les différentes entités du système, pour mettre en œuvre l’architecture de notre système
présentée à la fin du chapitre.
42
CHAPITRE 3. CONCEPTION
3.1 Processus métier d’entrée en relation digitale
3.1.1 Description textuel du processus d’entrée en relation digitale :

• le processus est initié par le prospect par la création d’un compte d’adhésion,
• Une fois, le compte est activé, le prospect peut accéder à son espace sur lequel il
peut établir sa demande d’ouverture de compte :
* Choisir le type de client (personne morale, personnel, professionnel),
* Importer sa pièce d’identité pour que le système la vérifie (CIN pour un maro-
cain résident, une carte de séjour pour un étranger résident, un passeport pour
un étranger non résident),
• le système s’occupe d’extraire les données de la pièce et les afficher au prospect

dans un formulaire pré remplie,
• le prospect a la possibilité d’effectuer des modifications sur ces données avant de

valider,
• Ensuite, le prospect effectue son choix de l’agence qui sera chargé de traiter sa
demande,
• Il choisit un rendez-vous pour une visioconférence dans un calendrier affichant les

disponibilités déterminées par le système.
• Ainsi, un dossier d’ouverture de compte est créé contenant toutes les informations
du prospect et les documents associées,
• L’agent consulte le dossier et accepte le RDV pour effectuer un appel vidéo avec le
prospect. La visioconférence permet d’affirmer l’identité du prospect, l’entretenir
sur des préférences et besoins supplémentaires et poser des questions spécifiques
permettant de boucler le processus KYC et attribuer un score sur sa situation fi-
nancière.
• ensuite l’agent valide le dossier qui constitue maintenant une demande de création
Page 43
de compte bancaire.
• La validation de l’agent génère une communication automatique du système avec

le core banking (T24 dans notre cas) en lui transmettant les données de cette de-
mande,
• le système T24 attribue au client un compte bancaire restrictif dans un premier

temps et génère pour le prospect les documents à signer : convention du compte,fiche
client, fiche KYC.
• Une fois la signature électronique est effectuée par le client, l’agent est notifié afin
d’exécuter une deuxième validation requise pour qu’une deuxième communication
automatique avec T24 s’établisse,
• Lors de cette deuxième communication, T24 procède au stockage définitif du compte

et enlève les restrictions imposées sur ce dernier,
• Ainsi le prospect devient un nouveau client de la banque et peut consommer ses

différents produits et services
3.1.2 Modélisation BPMN et exécution du processus d’entrée en relation
3.1.2.1 Modélisation BPMN du processus d’entrée en relation
Le nouveau processus que nous visons de mettre en place envisage de nouvelles fonc-
tionnalités et un nouveau schéma d’interactions entre les participants et les activités, ce
qui impose qu’un tout nouveau modèle doit être établi.
à l’aide de l’outil ProcessMaker[1], nous avons établi une représentation BPMN de

notre processus qui illustre les activités avec les intervenants assignés et les différents
parcours pouvant être activées en fonction des règles métier.
le processus d’entrée en relation digitale peut être divisé principalement en deux sous-
processus illustrés dans les figures ci-dessous.
* Le premier représente le flux des activités qui se produit lors de la création d’un
dossier d’ouverture,
Page 44
* le second correspond au traitement du dossier,

.
F IGURE 3.1 – Modélisation BPMN du Flux "création de dossier d’ouverture”
Page 45
F IGURE 3.2 – Modélisation BPMN du Flux "Traitement d’un dossier d’ouverture”

Page 46
les diagrammes contiennent deux pistes (pools) et qui sont :
• Bank al yousr : représente l’ensemble de l’organisation et les processus qui peuvent

s’y dérouler et contient deux couloirs indiquant qu’une partie du processus métier
est exécutée par une entité ayant un rôle particulier. ces entités sont :
** Solution : désigne tous les services fournis par la solution, et implémente toute
la logique métier pour le processus d’entrée en relation digitale.
** Agent :représente l’agent bancaire qui a plusieurs tâches qui lui sont assi-
gnées,ces dernières, ne sont à l’origine, qu’un échange de données entre la solu-
tion et l’agent bancaire via des interfaces utilisateur.
• Portail web : dénote les interfaces utilisateur exposées en ligne pour tout utilisateur
souhaitant souscrire à un produit bancaire, n’importe quel visiteur peut avoir sa
voie sur cette piste, faire les différentes activités associées qui sont assurées et
controllées par la communication entre le portail web et la solution.
3.1.2.2 Exécution du processus en utilisant ProcessMaker :
Exécution du Flux création du dossier d’ouverture :

Afin de simuler l’exécution du processus nous créons un compte pour chaque participant,
ces comptes sont affectés à des activités et contiennent des informations sur ces dernières
notamment, leur état, et celles que les utilisateurs peuvent commencer dans le processus.
les comptes qui ont été créés sont :

• Admin :l’utilisateur de ce compte interagit tout au long du processus en tant que
participant qui représente la solution d’entrée en relation digitale.
notons que la solution est une implémention technique de la logique métier qui en
fait un ensemble de programmes qui seront mis en place dans les phases ultérieures
de notre projet, mais dans cette simulation ces programmes sont des tâches qui
seront gérées manuellement par l’utilisateur du compte admin
• Prospect : l’utilisateur de ce compte représente le prospect affecté à ses tâches qui
sont un échange de données entre l’admin et le prospect, l’échange se fait via un
ensemble de formulaires qui seront créés et attachés à chaque tâche à l’aide de notre
outil de modélisation
le processus commence par le remplissage du formulaire d’inscription par le prospect
comme la figure montre :
Page 47
F IGURE 3.3 – Exécution de la tâche "demande de création d’espace d’adhésion"
Une fois le formulaire soumis,un événement intermédiaire d’envoi de message va récu-

pérer les données d’inscription et déclencher l’interruption du processus au niveau pros-
pect,le faisant attendre la réponse de vérification
la transmission des messages entre differents voies se fait en executant un script fournit
par processs-maker
F IGURE 3.4 – Exécution d’évènement intermédiaire d’envoi de message
Une fois les données sont reçues, l’événement chargé de recevoir le message permettra
à l’administrateur de commencer sa première tâche qui est la vérification des données
F IGURE 3.5 – Exécution de la tâche "vérification des données"
Page 48
Si l’administrateur approuve les données de l’utilisateur prospect, ce dernier sera re-

dirigé vers la tâche suivante qui est le choix du type de client :
F IGURE 3.6 – Exécution de la tâche "choix du type de client"
puis le prospect importe sa pièce d’identité et l’envoie à l’administrateur afin de la

vérifier
F IGURE 3.7 – Exécution de la tâche "importer la pièce d’identité"
Le processus est à nouveau interrompu au niveau du prospect par un autre événement

intermédiaire qui envoie les images.
l’administrateur attend de recevoir un message qui déclenche sa prochaine tâche, qui est
maintenant disponible, lui permettant de voir les images et de prendre une décision à leur
sujet.
F IGURE 3.8 – Exécution de la tâche "reconnaissance du PID"
Page 49
Si les images correspondent à une pièce d’identité, il approuve puis il sera redirigé vers
la tâche suivante, l’impliquant d’extraire les données prospect à partir d’images
F IGURE 3.9 – Exécution de la tâche "extraction des données"
Le prospect attend sa prochaine tâche qui sera déclenchée si l’administrateur approuve

et envoie les données extraites, puis un événement de capture dans la voie du prospect
recevra les données et déclenchera l’exécution de la prochaine activité du prospect lui
permettant de modifier ces données extraites et les valider
Si la validation se produit, l’administrateur sera informé et envoie par la suite les dates
de rendez-vous disponibles, qui seront reçues dans la voie du prospect, le prospect choisit
une date et le processus se termine en informant l’agent bancaire qu’un nouveau dossier
a été enregistré.
voici la carte de processus illustrant l’exécution du processus à un moment donnée :
Page 50
F IGURE 3.10 – Carte de sous processus "Création du dossier d’ouverture"
3.2 Architecture fonctionnelle du logiciel
3.2.1 Architecture fonctionnelle globale

L’architecture fonctionnelle globale de notre système décrit l’organisation et la struc-
ture globales de ce dernier. Cette vue du système a pour objectif de clarifier son fonc-
tionnement , comment les responsabilités y sont réparties, et comment les différentes
applications (internes et externes au système) communiquent entre elles.
Page 51
F IGURE 3.11 – Architecture fonctionnelle globale (model C4[2])Page 52

Le digramme ci-dessus décrit notre système, composé de :
• Une Application Monopage côté client (Prospect App) : Cette application est
dédiée au Prospect de la banque, et lui permet d’effectuer une demande d’ouverture
de compte enligne.
• Une Application web côté serveur (Prospect Web App) : Cette Application joue
le rôle d’un serveur web, elle fournit l’application Monopage et son contenu statique
au navigateur du prospect.
• Une Application Monopage côté client (Agent App) : Cette application est dédiée
au Agent banquaire, et lui permet de gérer les dossiers des prospects ayant effectuer
une demande d’ouverture de compte.
• Une Application web côté serveur (Agent Web App) : Cette Application joue
le rôle d’un deuxième serveur web hébérgée sur le réseau local de la banque, elle
fournit l’application Monopage et son contenu statique au navigateur de l’agent.
• l’API Entrée en Relation (EER) : c’est le backend du système , mettant en dispo-
sition des services qui permettent d’une part à l’application de l’agent banquaire
d’effectuer les traitemants/operations sur les dossiers et d’autre part à l’applica-
tion du prospect d’ajouter des dossiers à la base de données afin d’être traiter par
l’agent. Cette API est ègalement une interface entre les applications du front et la
base de donnée, le système du core banking (T24) utilisé au sein de la banque, et
le serveur de stockage de fichiers.
• l’API du traitement des pièces d’identitées : mettre en disposition à l’application
Monopage du prospect deux modèles d’apprentissage automatique ; un modèle de
classification d’image, la permet de savoir si une image correspondant vraiment à
une pièce d’identité, et un modèle d’extraction du text (OCR model), pour extraire
les informations contenu dans cette dernière.
3.2.2 Architecture fonctionnelle de l’API EER

Si nous zoomons et décomposons davantage chaque conteneur, nous pouvons identifier
les principaux blocs de construction structurels et leurs interactions
Page 53
Page 54
F IGURE 3.12 – Architecture fonctionnelle de l’API EER (model C4[2])

Le digramme ci-dessus décrit l’API EER,voici les principaux couches qui la construire :
• Controllers : le module fournissant des interfaces de communication entre les ser-

vices de l’application et la vue, chacune s’occupe de recevoir des requêtres conte-
nants des données et déterminer la réponse à renvoyer à l’utilisateur.
ex :
AuthController : gère l’échange de données entre l’utilisateur final et le service
d’authentification.
• Services : le module implementant toute la logique et les règles métier ainsi que
des calculs concernant le processus d’entrée en relation, répartis en composantes
chacun s’occupe d’un traitement specifique.
ex :
Dossierservice : contenant les opérations effectuer sur les dossiers des prospects,
notamment la création d’un dossier d’ouverture et sa gestion.
• Data Access : le module fournissant les interfaces de communication entre la base

de données et les services, il contient les différentes opérations telles que la récupé-
ration et le stockage des données
ex :
UserRepository : permet au services de récupérer, stocker, mettre à jour ou sup-
primer les données d’un utilisateur de la base de données.
• Integration : permet d’intégrer les services externes, notamment ceux fournis par le
système du Core Banking et le système de stockage de fichiers, afin qu’ils puissent
être exploités par les services internes de l’application.
ex :
T24WSClient :
le client pour accéder au services web de T24, permer aux services qui y sont
connectés de d’effctuer les opérations suivants :
- récupérer les listes des villes, des agences, des nationalités, etc.
- créer un nouveau client dans la base de données de la banque.
- créer un nouveau compte banquaire.
- générer et récupérer les contrats d’ouverture de compte.
Page 55
3.3 Diagramme de classe :
F IGURE 3.13 – Diagramme de classe
Page 56
Classe Description
représente l’utilisateur de l’application et contient les in-
User formations initiales nécessaires à la création d’un espace
au niveau de l’application
L’Agent Front Office : le responsable pour la partie ouver-
Agent_CRC
ture des comptes pour les prospects.
Prospect Le client ciblé qui n’a aucun compte bancaire.
représente l’administrateur qui pour rôle de gérer les uti-
Admin
lisateurs de l’application.
Le dossier d’ouverture de compte pour un prospect, qui
Dossier englobe toutes les informations sur ce dernier, les pro-
duits choisis, les pièces justificatives.
Agence contient la liste des agences de bank Alyousr
la liste des documents demandés au moment de l’ouver-
PieceJustificatif
ture du compte
Le pack contient un produit ou plusieurs de la banque,
Pack
produits supplémentaires.
TABLE 3.1 – Description du diagramme de classe
3.4 Diagrammes de séquence

le but de l’utilisation du diagramme de séquence est de modéliser les interactions entre
les objets de notre système, ces interactions spécifient comment les messages et les données
sont échangés entre les participants.
3.4.1 Diagramme de séquence « Authentification » :

Lorsque l’utilisateur demande l’authentification en saisissant son email adresse et mot
de passe, le système récupère ses coordonnées avec le rôle associé,puis il vérifie le mot de
passe et génère « Access Token », garantissant ainsi l’accès à des ressources spécifiques en
fonction du rôle.
Page 57
F IGURE 3.14 – Diagramme de séquence "Authentification"
Page 58
3.4.2 Diagramme de séquence «Traitement d’une pièce d’identité» :
F IGURE 3.15 – Diagramme de séquence "Traitement d’une PID pour remplissage automa-
tique du formulaire"
Page 59
Acteur Description
représente le prospect actuel qui est entrain de créer un
Prospect dossier d’ouverture
Vue la couche présentation du système

principalement composé de :
1. DocExtractInfo : modele machine-learning ca-
pable d’extraire les données d’une image ou PDF.
2. DocVerify : modele machine-learning sert à recon-

Système de traitement piece naître une Pièce d’identité qui peut être, soit un
d’identité CIN, passeport, carte de résidence.
3. DocProcessing : une interface qui communique

avec la couche préesentation et qui expose l’utilité
des deux modeles.
TABLE 3.2 – Description du diagramme de séquence "Traitement d’une PID pour remplis-
sage automatique du formulaire"
Le prospect importe la pièce d’identité à travers la vue, qui la transfère au système de

traitement des PID, plus précisément au controlleur de ce dernier, qui fait appel au modèle
de reconnaissance de la PID, si la PID est reconnu, controlleur la renvoie au méthode
extractPidInfo qui s’occupe de charger le modèle OCR,lui fournir la pièce d’identité, les
données sont par suit extraits et envoyés à la couche representative afin de les afficher au
prospect dans une formulaire.
Page 60
3.4.3 Diagramme de séquence « créer un dossier d’ouverture » :
F IGURE 3.16 – : Diagramme de séquence "créer un dossier d’ouverture"
Page 61
Acteur Description
représente le prospect actuel qui est entrain de créer un
Prospect dossier d’ouverture
Vue la couche présentation du système

principalement composé de :
1. DossierService : une classe implantant les diffé-
rentes opérations concernant le traitement d’un
dossier d’ouverture.
Service de creation d’un dos-
2. DossierController : interface de communi-
sier d’ouverture
cation avec la couche représentative, elle
gère l’accès aux opérations du service selon le
rôle(Prospect,Agent).
l’objet client communiquant avec le service distant qui

T24WSClient
existe au niveau du T24
TABLE 3.3 – Déscription du diagramme de séquence "créer un dossier d’ouverture"
Page 62
3.4.4 Diagramme de séquence « Traiter un dossier» :
F IGURE 3.17 – Diagramme de séquence "Traiter un dossier d’ouverture"
L’agent initialise la connexion et crée une salle de réunion à l’aide du service OpenI-
vidu, ce dernier génère et envoie un identifiant unique à l’agent, et au prospect concerné
afin de lui permettre d’accéder à la salle de réunion.
Page 63
Lors de la visioconférence, l’agent récupère le dossier du prospect puis vérifie son identité
et les informations y contenues. Dans le cas de manque des documents justificatifs, le
prospect est invité à charger ces derniers. Par la suite, l’agent saisit les données du KYC
et modifie, si nécessaire, les informations du dossier. Le service T24 intervient dans cette
étape pour la création du compte dans le système banquaire (compte restreint), et l’envoie
des contrats au prospect pour les signées et les renvoyés à l’agent pour, finalement, valider
la demande et enlever les restrictions du compte.
Page 64
3.5 Intégration continue

L’intégration continue est une pratique issue de l’eXtreme Programming (XP). Elle
permet d’éviter les régressions qui peuvent survenir suite à des mises à jour dans le code
source de l’application.
Pour adopter cette pratique, nous avons partagé notre code source à l’aide d’un outil de
gestion de versions (git), ceci afin de détecter les modifications dans le code.
Ensuite, nous avons procédés à l’écriture des tests qui permettent la validation ou non
des modifications. Finalement, nous avons installé et configuré un serveur d’intégration
continue pour permettre l’automatisation des tests, la compilation et la génération des
rapports.
Dans la Bank alyousr, le gestionnaire de version utilisé est Git, avec GitLab CI/CD
comme serveur d’intégration continue.
F IGURE 3.18 – Architecture d’intégration continue
Dans un premier lieu, le développeur effectue un changement ou un ajout d’une fonc-

tionnalité de système, ensuite en utilisant ses propres tests unitaires, il s’assure que tout
fonctionne correctement en locale avant d’envoyer les modifications au gestionnaire de
source (git) pour faire l’intégration avec les autres modules existants.
Le serveur GitLab CI/CD offre la possibilité d’exécuter des tâches données (compilation,
tests, génération des rapports, déploiement, etc.).
Page 65
Suite à un changement dans le code. Le développeur peut effectuer une commit via son
gestionnaire de code source git locale, pour mettre à jour le répertoire partageable entre
les différents membres de l’équipe sur GitLab.
Si le fragment ne s’intègre pas correctement, c’est-à-dire le résultat de l’exécution d’une
tâche (une tâche est appelé job dans GitLab CI/CD) est négatif, dans ce cas le dévelop-
peur doit effectuer une annulation des modifications apportées, et revenir à la dernière
version stable de l’application, ceci est possible en utilisant un outil de gestion de code
source distribué tel que Git.
3.6 Conclusion :
Dans ce chapitre, nous avons commencé à l’aide de BPMNpar modéliser le nouveau
processus que nous comptions mettre en place, et nous avons simulé l’exécution des diffé-
rents flux contenus dans le processus, puis nous avons précisé l’architecture fonctionnelle
de la solution, et en utilisant le langage UML notamment, les diagrammes de classe et de
séquence, nous avons spécifié la structure interne du système et modélisé les interactions
entre ses différentes parties.
Page 66
CHAPITRE 4
Réalisation
fin de réaliser notre projet de fin d’études, nous avons utilisé une panoplie de
A technologies, des outils de développement, de tests, d’automatisation et d’inté-

gration continue. Ceci pour mettre en œuvre une application de bonne qualité
respectant des exigences fonctionnelles et non fonctionnelles du cahier de charges.
67
CHAPITRE 4. RÉALISATION
4.1 Technologies et Outils :

Pour avoir le même environnement du travail que l’équipe de transformation digitale
et afin de s’aligner avec leur vision stratégique de développement, nous avons adopté les
mêmes outils et les mêmes briques technologiques pour assurer une compatibilité avec
l’environnement existant.
IDE Description
Visual Studio code est un éditeur de code extensible dé-

veloppé par Microsoft.
Spring Tool Suite est un IDE pour développer des applica-

tions Spring. Il s’agit d’un environnement de développe-
ment basé sur Eclipse. Il fournit un environnement prêt
à l’emploi pour implémenter, exécuter, déployer et dé-
boguer l’application. Il valide notre application et fournit
des correctifs rapides pour les applications.
TABLE 4.2 – La liste des IDEs
Page 68
Technologie et Outils Description
Spring est un framework de développement en Java,

connu par ses nombreuses fonctionnalités qu’il apporte
sur plusieurs aspects : web, sécurité, batch ou encore ac-
cès aux données dans le cadre du développement d’une
application web.
React est une bibliothèque JavaScript libre développée
par Facebook depuis 2013. Il a pour but de faciliter la créa-
tion des applications monopage (Single page Application)
à travers des composants dépendant d’un état pour géné-
rer une page HTML.
Redux est une bibliothèque JavaScript libre de gestion

d’état pour les applications web basé sur JavaScript. Elle
est plus connue aujourd’hui pour son utilisation avec des
bibliothèques comme React et Angular.
Flask est un petit framework web Python léger, qui four-

nit des outils et des fonctionnalités utiles qui facilitent
la création d’applications web en Python.Flask est égale-
ment extensible et ne force pas une structure de réper-
toire particulière ou ne nécessite pas de code standard
compliqué avant de commencer.
Ecrite en Python, Keras est bibliothèque open source de
prototypage rapide de modèles de deep learning. A la
portée des débutants en IA, elle s’articule autour d’une
API de haut niveau supportant différentes librairies de
réseaux de neurones artificiels récurrents ou convolutifs,
comme Tensorflow, Microsoft Cognitive Toolkit, PlaidML
ou Theano.
bibliothèque python qui fournit des modèles OCR prêts à

l’emploi et un pipeline de formation de bout en bout pour
créer de nouveaux modèles OCR.
TABLE 4.1 – La liste des Technologies
Page 69
4.2 Réalisation du backend
4.2.1 Architecture technique du système :
Page 70
F IGURE 4.1 – Architecture technique

EER API
Couche Description
gère les demandes de toutes les fonctionnalités d’authentifi-
AuthController : (Spring
cation telles que la connexion et l’inscription, la vérification
REST Controller)
d’un e-mail déjà utilisé
responsable du traitement des requêtes spécifiques à des opé-
Couche Web UserController (Spring rations sur le compte de l’utilisateur, telles que l’obtention des
REST Controller informations de l’utilisateur actuel, la mise à jour du mot de
passe et la déconnexion.
GestionDossierController s’occupe des requêtes correspond aux opérations sur les dos-
(Spring REST Controller) siers
définit un programme pour toute tâche d’authentification, il
est composé d’un ensemble d’opérations, chacune est un trai-
AuthService (Spring Ser-
tement basé sur des règles spécifiques. ex : authentifier un
vice)
utilisateur au système, s’enregistrer et envoyer un lien de vé-
rification
c’est le composant principal du système actuel, qui implé-
Couche Métier
mente toute la logique métier que l’organisation suit pour
l’entrée en relation digitale avec le client, définissant ainsi les
DossierService (Spring
traitements qui peuvent se lancer sur les ressources de l’ap-
Service)
plication, particulierement les dosssiers. ex :la creation d’un
nouveu dossier (affecter une agence, gérer les informations de
la piece d’identité)
interfaces dans lesquelles nous déclarons toutes les re-
quêtes requises sur les tables de la base de données, elles
seront utilisées dans tous les services qui doivent trai-
Repositories (Spring Data ter des informations depuis ou vers la base de données.
JPA) : ex : UserRepository :cherche un utilisateur par son email dans
la base de données .ces interfaces communiquent directe-
ment avec hibernate qui gère le mapping objet relationnel.
le client pour accéder au services de transfert de fichiers, per-

Couche DAO/Inte- AmazonS3Client(AWS
met à l’API EER de stocker et récupérer les documents justifi-
grationr SDK for Java)
catifs contenus dans le dossier d’ouveture de compte.
l’objet client d’un service Web distant que nous avons créé et
exposé dans le Core banking T24 il intègre les différentes opé-
rations qui seront traitées au niveau du T24 telles que
** récupérer les listes des villes, des agences, des natio-
T24WSClient (Spring WS)
nalités, etc.
** créer un nouveau client dans la base de données de la
banque.
TABLE 4.3 – Déscription EER API
Page 71
PidProcessing API
Couche Description
DocProcessing
controller contient deux routes qui gèrent la requête, chacune a une méthode qui charge le mo-
Controller(Flask
dèle et lui transmet la pièce d’identité.
Application)
Modèle basé sur l’architecture CNN qui applique d’abord cer-
DocVerify (Keras CNN Mo- tains filtres à l’image d’entrée puis extrait certaines caractéris-
logique d’applica-
del) tiques qui seront utilisées pour classer si l’image correspond à
tion
cin ou passeport.
Modèle basé sur l’architecture CRNN composé de deux élé-
ments principaux, le détecteur de texte qui détecte et loca-
DocExtractInfo(Keras
lise les régions de texte d’une image, et l’extracteur de texte
CRNN Model)
reçoit la sortie du détecteur dans un format spécifique, les ex-
trait dans un fichier pouvant être manipulé par une machine
TABLE 4.4 – Déscription PidProcessing API
4.2.2 Module de traitement des pièces d’identités
4.2.2.1 Reconnaissane des pièces d’identités
L’ancienne solution présente de nombreuses insuffisances, lorsque le prospect arrive à

l’étape de vérification d’identité par exemple, il peut télécharger n’importe quelle image
sans vérification préalable, même si l’image est insignificative, ce qui implique des de-
mandes futiles.
Pour remedier à ce probleme, faciliter le processus d’ouverture de compte et minimiser
l’intervention humaine, nous allons filtrer les demandes qui ne répondent pas aux exigences
en terme d’éligibilité des documents justificatifs, pour ce faire nous implémentons un
modèle de classification d’images qui peut reconnaître si une image donnée correspond au
document requis dans les étapes de vérification de l’identité, de l’adresse et des revenus
du prospect. Il s’agit d’un système capable d’assigner correctement une catégorie (dans
notre cas, une catégorie de documents) à n’importe quelle image en entrée.
Un tel système exploite des algorithmes de Machine Learning issus de l’apprentissage
su- pervisé.
Méthode de résolution :
Le problème de classification d’images est posé formellement de la manière suivante :
• Il y a K classes d’images possibles. L’ensemble {0, 1, ..., K − 1} définit les labels des
différents classes (dans notre cas : 0 = “aucun document d’identification”, 1 =
“CIN marocaine”, 2 = “passeport”, etc)
Page 72
• Nous avons une collection de N images en entrée : {X i }i ∈{1,...,N }

• Les classes des N images sont connues à l’avance : chaque image X i est étiquetée
par un label y i ∈ {0, 1, ..., K − 1}
• Le but est de classifier correctement une nouvelle image, dont on ne connaît pas la
classe : on veut trouver la bonne étiquette y ′ de X ′
Le schéma ci-dessous illustre la méthode utilisée pour résoudre ce problème :
F IGURE 4.2 – Etapes de resolution
On a choisit de travailler avec les réseaux de neurones convolutifs, ils s’occupent eux
même des deux premières étapes. On passe alors directement à la troisième étape.
On voulait construire un classifieur qui peut reconnaîte les différents documents d’identi-
fication éligible pour ouvrir un compte bancuaire, à savoir les cartes d’identité marocaines
ou étrangères, les passeport, les titres de séjour marocains ou étrangers. Mais vu le manque
des données, on a choisit au début de construire un modèle capable de reconnaître les CINs
marocains (parcours des prospects Marocains résidents), et les passeports (parcours des
étrangers non résidents au Maroc ).
Processus de base pour la classification des images

le processus de base pour la classification des images suit souvent le flux de travail d’ap-
prentissage automatique suivant :
1. Préparer les données
2. Construire le modèle
3. Former le modèle
4. Testez le modèle
1- Préparation des données
• Charger un ensemble de données prédéfini à partir du répertoire :
On utilise des images issues du système d’entrée en relation actuelle, depuis ces
Page 73
images on crée un jeu de données qui contient 200 images colorées dans 2 catégories.
Les images montrent des documents d’identification (carte d’identité nationale et
passeport ) à basse résolution (224 par 224 pixels).
160 images sont utilisées pour former le réseau et 40 images pour évaluer la
précision avec laquelle le réseau a appris à classer les images.
Voici le code pour charger les données depuis un repertoire et créer une Dataset :
F IGURE 4.3 – chargement d’images
• Prè-traitement des données :

Avant d’alimenter les images au modèle de réseau de neurones, on les redimensionne
et met ses valeurs à l’échelle dans une plage de 0 à 1.
F IGURE 4.4 – modèle de prè-traitement
Page 74
• Augmentation des données :

Le nombre d’images qu’on a arrivé à collecter n’est pas suffisant pour former un mo-
dèle qui donnera des predictions satisfaisantes. Pour régler ce problème, on utilise la
méthode d’augmentation de données, c’est une technique permettant d’augmenter
la diversité de notre ensemble d’entraînement en appliquant des transformations
aléatoires (mais réalistes), telles que la rotation d’image, la translation horizontale,
etc.
le schéma ci-dessous montre les étapes d’augmentation des données jusqu’à l’en-
traînement du modèle :
F IGURE 4.5 – Flux d’augmentation de données
Pour implémenter l’augmentation des données avec Keras[3], on crée un modèle

dont les couches représentent les différentes transformations à effectuer sur une
image.
F IGURE 4.6 – modèle d’augmentation des données
voici un exemples d’images générées par ce modèle :
Page 75
F IGURE 4.7 – exemple d’image augmentée
2- Construction du modèle.
• Construire le modèle :
Construire le réseau de neurones nécessite de configurer les couches du modèle, puis
de compiler le modèle. Les couches extraient des représentations des données qui
y sont introduites. Dans notre cas, on travaille avec l’architecture ResNet[4], cette
architecture CNN est connue d’avoir un erreur minimal de 3.6%, Les ResNets sont
construits à partir de quelque chose appelé un bloc résiduel (Residual Block)
F IGURE 4.8 – Bloc Résiduel
Les couches de cette architecture, ainsi que ses configurations sont connus, diffé-
rentes versions utilisent un nombre variable de "Blocs Résiduels" à différents ni-
Page 76
veaux, comme indiqué dans la figure ci-dessus :
F IGURE 4.9 – versions de l’architecture ResNet et ses configurations
Le ResNet de 50 couches a la structure suivante :
• Entrée avec forme (224, 224, 3)

• 1 couche convolutif, avec 64 filtres
• 3, 4, 6, 3 blocs résiduels avec des filtres de tailles 64, 128, 256, 512, 1024 et 2048.
• Couche Average Pool avec taille de pool = 2
• Couche d’aplatissement
• Couche dense avec 2 nœuds de sortie
Il a un total de 50 couches. Nous utilisons l’activation ReLU et la BatchNormali-
zation après les couches de conversion.
pour adopter cette architecture au sein de notre modèle, on va utiliser l’API Ke-
ras[5] ResNet50 :
Page 77
F IGURE 4.10 – Construction du modèle avec Keras API
3- Former/Entraînez le modèle
voici un schéma qui montre le processus d’entraînement du réseau.
Page 78
F IGURE 4.11 – Processus d’entraînement
voici le code pour cette phase :
Page 79
F IGURE 4.12 – entraînement du modèle
4- Faire des pédictions/ Tester le modèle

Avec le modèle formé, Nous allons l’utiliser pour faire des prédictions sur certaines
images. Nous attachons d’abord une couche softmax pour convertir les sorties linéaires
du modèle ( logits) en probabilités, ce qui devrait être plus facile à interpréter
F IGURE 4.13 – Conversion du modèle en modèle probabiliste
Le modèle a prédit l’étiquette pour chaque image de l’ensemble de test. On prend

la première prediction. Une prédiction est un tableau de 2 nombres. Ils représentent la
"confiance" du modèle que l’image correspond à chacune des 2 pièces d’identités. Nous
pouvons voir quelle étiquette a la valeur de confiance la plus élevée. Ainsi, le modèle est
plus sûr que cette image est une carte d’identité nationale.
L’examen de l’étiquette du test montre que cette classification est correcte :
Page 80
F IGURE 4.14 – example de prédiction
Pour examiner l’ensemble complet des prédictions de classe, on les représente graphi-
quement en utilisant la fonction montrée dans la figure suivante :
F IGURE 4.15 – Fonction de représentation graphique
On trace plusieurs images de test avec leurs prédictions. Notez que le modèle peut se
tromper même lorsqu’il est très confiant.
Page 81
F IGURE 4.16 – Prédictions sur des images de test
4.2.2.2 Extraction des données des pièces d’identités
Dans cette partie,l’objectif est la construction d’un modèle capable de reconnaître un

text dans une image, et l’extraire dans un fichier qui peut être manipulé par la machine,un
tel processus est nommé l’OCR(la reconnaissance optique des caractères) illustré par la
figure suivante :
F IGURE 4.17 – Processus OCR.
en utilisant l’API Keras-ocr[6], nous allons concevoir une pipeline composée de deux
éléments un détecteur qui détecte les portions du texte contenus dans les différentes ré-
gions d’image.
Page 82
Génération de données synthétiques :

Les données synthétiques sont des données générées artificiellement par un algorithme et
non pas collectées à travers des interactions avec des personnes ou des interactions entre
des événements réels. de ce fait,nous définissons l’alphabet qui englobe tous les caractères
que nous voulons notre modèle puisse détecter et reconnaître, nous désignons l’alphabet
par 0-9, lettres majuscules et minuscules.
Afin de s’entraîner sur des données synthétiques,nous avons besoin d’un ensemble des
polices et arrières plan,keras-ocr comprend différentes méthodes afin de les télécharger à
partir de google fonts et wikimedia.
afin de créer des images,on a besoin des chaînes de caractères générées aléatoirement,
keras-ocr fournit une méthode simple pour cela en fonction d’alphabet qu’on a définit,
puis on divise les données arrière plans et polices en des données de formation, test
et validation, ensuite on les fournit au générateur des images qui va générer des images
avec une résolution définie et contenant du texte stylé par les polices et affiché dans les
arrières plans prédéfinies.
le générateur des images et aussi divisé en formation, validation et test en fonction de
la séparation fait sur les arrières plans et les polices.
Entraînement du détecteur et d’extracteur du text :

Réseaux neuronaux : Les réseaux neuronaux (Neural Neworks - NN) sont des modèles
basés sur la fonctionnalité du cerveau humain et offrent la flexibilité nécessaire pour mo-
déliser toute relation non linéaire entre la variable d’entrée et la variable de réponse.
Il existe différentes architectures du modèle NN, mais cette partie se concentre sur l’m-
plementations des specifiques neural network(NN) et qui sont :
• CNN : un type de réseau neuronal artificiel utilisé dans la reconnaissance et le trai-
tement d’images et spécifiquement conçu pour traiter et analyser l’imagerie visuelle.
keras-ocr implémente architecture CRAFT [7] pour entraîner le détecteur,CRAFT

adopte une architecture de réseau entièrement convolutive basée sur VGG-16 qui est es-
sentiellement l’architecture d’extraction de caractéristiques utilisée pour coder l’entrée du
réseau dans une certaine représentation de caractéristiques.
CRAFT prédit deux scores pour chaque charactere :
• Score de region : Il localise le charactere dans l’image.
Page 83
• Score d’affinité :« L’affinité » est le degré auquel une substance a tendance à se

combiner avec une autre. Ainsi, un score d’affinité fusionne les caractères en une
seule instance (un mot).
CRAFT génère deux cartes en sortie : Carte au niveau de la région et Carte d’affinité.
Comprenons ce qu’elles signifient en regardant un exemple :
Les zones où les caractères sont présents sont marquées dans la carte de la région :
F IGURE 4.18 – Region Map
Le rouge symbolise que les caractères ont une forte affinité et doivent être fusionnés
en un mot :
F IGURE 4.19 – Affinity Map
Enfin, les scores d’affinité et de région sont combinés pour donner la boîte englobante
de chaque mot. Les coordonnées sont dans l’ordre : (en haut à gauche), (en haut à droite)
(en bas à droite), (en bas à gauche), où chaque coordonnée est une paire (x, y).
Page 84
Une telle opération sera exécutée sur l’ensemble des données de formation en optimisant
les poids de l’architecture CRAFT a chaque itération jusqu’au on obtient une valeur
minimale loss qui est une valeur mesurant à quel point notre modèle se porte bien.
en s’appuyant sur l’Architecture CRAFT qu’on a décrit, l’entraînement de détecteur est
implémenté en utilisant keras ocr API comme suit,
F IGURE 4.20 – l’entraînement du modèle de detection du texte
L’entrainement d’extracteur du texte se base sur l’architecture CRNN[8] decrit par la

figure suivante :
Page 85
F IGURE 4.21 – Architecture CRNN
Voici le bref flux d’architecture :

1. L’image prétraitée donnée en entrée au CRNN architecture.
2. Cette image d’entrée est transmise à la convolution composant pour l’extraction
de caractéristiques.
3. Les cartes de caractéristiques convolutionnelles générées sont utilisées pour former
des champs récepteurs résultant en une séquence de vecteurs de caractéristiques.
4. La sortie du composant CNN est transmise en tant qu’entrée au composant RNN
pour la modélisation de séquence.
5. Les couches de RNN prédisent la distribution des étiquettes pour chaque image de
la séquence d’entités.
6. Les distributions d’étiquettes par image générées à partir du les couches LSTM
bidirectionnelles sont passées à travers le composant de transcription.
7. Ces distributions d’étiquettes sont converties en étiquettes séquences en appliquant
le Connectionist Temporal Classement (CTC).
Page 86
8. Les séquences de marqueurs obtenues sont ensuite converties dans le format de

l’étiquette requise à l’aide du décodeur CTC :
F IGURE 4.22 – l’entraînement d’extracteur du texte
On finira par tester le modèle d’Extraction des données composée du détecteur et recon-
naissance du texte qu ’on a construit
F IGURE 4.23 – exemple d’extraction des données.
Page 87
4.2.3 Module de traitement d’un dossier d’ouverture

La figure suivante illustre les différents endpoints qui traitent les requêtes et les re-
dirigent vers les services afin de déclencher des traitements dans le backend, et ainsi
renvoient la réponse à la couche de présentation.
webservices methode Endpoints

/api/auth/register
register POST
login POST /api/auth/login

checkEmailInUse GET /api/auth/checkEmailInUse/email
resetLink POST /api/auth/password/resetlink
resetPassword POST /api/auth/password/reset
creerDossier POST bayeer/api/dossier/creer
getAgences GET bayeer/api/dossier/agences
addProspectAgence POST bayeer/api/dossier/addAgence
getDossiers GET bayeer/api/dossier/getDossiers
addPieceJustif POST bayeer/api/dossier/email/documents
getDocuments GET bayeer/api/dossier/email/documents
TABLE 4.5 – Déscriptions des endpoints
La requete d’inscription venant du côté client sera traitée par un filter de Spring Secu-
rity qui est l’interface LoadbyUsername, qui prend le champ email comme argument et
exécute une requête sur la base de données, cherchant si ce champ a été utilisé par un
autre utilisateur,sinon la requete est redirigée vers endpoint, qui appelle une méthode du
AuthService, qui s’occupe de créer un nouveau canal au niveau du système , particulier
au prospect.
Page 88
F IGURE 4.24 – page d’inscription.
F IGURE 4.25 – test d’API "inscription".
Page 89
un email sera envoyée à travers un serveur SMTP à l’adresse email du visiteur qui doit
la confirmer pour que son compte soit activité.
F IGURE 4.26 – l’envoi du mail.
lorsque le prospect essaie de se connecter, le système génère un token et le renvoie au

côté client qui le stockera pour toute autre requete éventuelle.
F IGURE 4.27 – page login.
Page 90
F IGURE 4.28 – Test d’API "se connecter" .
la création du dossier est déclenchée par un requête venant vers l’endpoint, le corps
du requete contient les informations de la pièce d’identité du prospect qui sont extrait
par l’API du traitement de documents justificatifs , le contrôleur qui reçoit cette requête
invoque une méthode Dossier Service qui, premierement cherche si l’utilisateur authentifié
à déjà un dossier créé , le cas échéant,la méthode met à jour les informations associées au
dossier.
F IGURE 4.29 – page demande de création dossier d’ouverture.
Page 91
F IGURE 4.30 – page demande de création dossier d’ouverture.
F IGURE 4.31 – Test d’API " création d’un dossier".
Page 92
afin que le prospect sélectionnee une agence bancaire, le côté client envoie une requête
au système demandant la liste des agences bancaires, recevant en retour un objet json
contenant la réponse.
F IGURE 4.32 – Test d’API "obtention de toutes les agences.
Page 93
la route ci-dessous est particulière à l’agent, qui envoi à travers le côté client une
requête afin de récupérer les dossiers avec les prospects associées.
F IGURE 4.33 – Liste des prospects
F IGURE 4.34 – Détails du dossier - informations personnelles
Page 94
F IGURE 4.35 – Détails du dossier - identification
F IGURE 4.36 – Détails du dossier - informations financières
Page 95
F IGURE 4.37 – Détails du dossier - Agence & Offre & Rendez-vous
F IGURE 4.38 – Test d’API "obtention des dossiers".
Page 96
4.3 Conclusion :
Au fil de ce chapitre, l’accent est mis sur les technologies utilisées dans la réalisation
du projet ainsi que des captures d’écran de la partie front office et back office.
Page 97
Conclusion
otre stage de fin d’étude, effectué à Bank al yousr, consiste à implémenter
N une application d’entrée en relation digitale, qui doit automatiser et gérer le

processus de création du compte bancaire en ligne.
On a commencé dans un premier lieu par étudier le contexte général du projet en dé-
finissant les spécifications du besoin. En parallèle, on était en formation sur la technologie
qu’on doit utiliser pour la réalisation du projet.
Ensuite on a abordé la partie planification et répartition des tâches avec leurs priorités
en respectant la méthodologie de conduite de travail Scrum. Enfin, on a entamé la phase
d’implémentation de la solution. Ce stage m’ a donné l’ occasion de découvrir le monde
du service IT et de confronter de nouvelles techniques informatiques à savoir la plateforme
ERP T24 qui se compte mondialement parmi les leaders des logiciels bancaires .
Il nous a également offert l’opportunité d’interagir avec des consultants techniques du
département du système d’information de la banque et de participer à des réunions quo-
tidiennes, afin de mieux comprendre la culture de l’organisme, la méthode de travail, les
problèmes quotidiens et les moyens pour les résoudre. Ce stage a été bénéfique étant donné
qu’il nous a octroyé l’opportunité de mettre en application les différentes connaissances
acquises tout au long de notre cursus universitaire, ainsi que d’enrichir nos compétences
concernant différents outils et technologies. Les difficultés rencontrées durant le déroule-
ment du stage étaient principalement liées à la maîtrise de certaines technologies.
Néanmoins, grâce au suivi et à l’assistance de l’encadrant et l’équipe de système d’infor-
mation, on a pu rattraper nos besoins de formation, s’adapter facilement, affronter tous
les obstacles rencontrés et aussi expérimenter mes compétences.
98
Webographie
[1] Brian R EALE. ProcessMaker Documentation. URL : https://processmaker.gitbook.

io/processmaker/.
[2] Simon B ROWN. The C4 model for visualising software architecture. URL : https:https:
//c4model.com/.
[3] François C HOLLET. Keras data augmentation Documentation. URL : https : / / www .
tensorflow.org/tutorials/images/data_augmentation.
[4] Seung Seog Han1 Gyeong Hun Park2 Woohyung L IM 3. Deep neural networks show an
equivalent and often superior performance to dermatologists in onychomycosis diag-
nosis : Automatic construction of onychomycosis datasets by region-based convolutio-
nal deep neural network. URL : https : / / www . researchgate . net / publication /
322621180_Deep_neural_networks_show_an_equivalent_and_often_superior_
performance _ to _ dermatologists _ in _ onychomycosis _ diagnosis _ Automatic _
construction_of_onychomycosis_datasets_by_region-based_convolutional_
deep_.
[5] François C HOLLET. resnet achitecture. URL : https : / / www . tensorflow . org / api _
docs/python/tf/keras/applications/resnet50/ResNet50.
[6] Community COLLABORATION. Keras CRNN implementation. URL : https : / / keras -
ocr.readthedocs.io/en/latest/.
[7] Clova AI R ESEARCH. Character Region Awareness for Text Detection. URL : https : / /
arxiv.org/pdf/1904.01941.pdf.
[8] International Journal of I NNOVATIVE T ECHNOLOGY et Exploring E NGINEERING. Optical
Character Recognition using CRNN. URL : https://www.ijitee.org/wp- content/
uploads/papers/v9i8/H6264069820.pdf.
99

RapportPFE Maadani Khalil Qatab Salah-Eddine

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

RapportPFE Maadani Khalil Qatab Salah-Eddine

Transféré par

Droits d'auteur :

Formats disponibles

Mémoire de Projet de Fin d’Études

Pour l’Obtention du Titre

La Refonte de l’Application de l’Entrée en Relation

À mes très chers parents

À mes chers frères et sœurs

À mes chers cousins

À mes chères amis

À toute ma grande famille ;

A trouvent dans l’obligation de s’adapter aux Nouvelles Technologies de l’Infor-

En effet, qu’il s’agit de la désintermédiation des opérations ou la disparition du cash,

I information and communication technologies. The Covid-19 health crisis accelerated

Whether it is the disintermediation of transactions or the disappearance of cash, digi-

1.1 Fiche signalétique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.1 Processus actuel d’entrée en relation digitale de la bank . . . . . . . . . . . . 32

3.1 Modélisation BPMN du Flux "création de dossier d’ouverture” . . . . . . . . 45

4.1 Architecture technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

1.1 Equipe du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.1 Scénario d’inscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.1 Description du diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . 57

4.2 La liste des IDEs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

BPMN Business Process Model and Notation. 9, 14, 44–46, 66

CIN Carte d’Identité Nationale. 43, 60, 72, 73

EER Entrée en Relation. 9, 11, 14, 53–55, 71

KYC Know Your Customer. 34, 36, 40, 43, 44, 64

LSTM Long Short-Term Memory. 86

OCR Optical Character Recognition. 10, 53, 60, 69, 82

PID Pièce d’Identité. 9, 11, 59, 60

ResNet Residual Neural Network. 76, 77

SMTP Simple Mail Transfer Protocol. 90

Table des figures 9

Liste des tableaux 9

Liste des abréviations 12

1 Contexte général du projet 17

2 Analyse des besoins 31

compléter les contrôles KYC et signer les contrats.

Contexte général du projet

1.1 Présentation de l’organisme d’accueil

F IGURE 1.1 – Fiche signalétique

1.1.1 Produits proposés : Mise sur l’authenticité et L’innovation

1.1.2 Une politique de proximité :

1.1.3 Analyse de l’environnement de Bank Al Yousr :

F IGURE 1.2 – analyse SWOT

1.1.4 Structure interne de Bank Al Yousr :

F IGURE 1.3 – organigramme de l’organisme

1.2 Présentation generale du projet

1.2.1 Contexte general du projet

1.2.3 Objectifs et Motivations

1.3 Conduite du projet

1.3.1 Méthodologie de travail

F IGURE 1.4 – La Méthode Agile "Scrum"

1.3.2 Membres de l’équipe

Equipe de la mise en oeuvre QATAB SALAH-EDDINE

TABLE 1.1 – Equipe du projet

1.3.3 Outil de collaboration

F IGURE 1.5 – L’interface de Trello

1.3.4 Planification du project

Back log Activité Date Début Date Fin Criticité

TABLE 1.2 – Backlog du projet

Déscription des sprints :

les missions effectués durant sprint 0 sont :

Analyse des besoins

’étude de 1’existant est un point de passage obligé qui matérialise le premier

2.1 Etude de l’existant