Rapport de Stage PFE - Youssef Chaachai

Mémoire de projet de fin d'études
En vue de l’obtention du diplôme d’Ingénieur

d’Etat en Réseaux et Systèmes d’Information
Sujet :
Développement et restructuration des

modules Frontend dans le domaine de la
banque digitale
Réalisé par : Sous la supervision de :

M. CHAACHAI Youssef Pr. AIRAJ Mohammed
M. TARRAQ Mohammed
M. ELOUARDI Anas
Soutenu le 28 juin 2021, devant le jury :
Pr. AIRAJ Mohammed : Professeur à la FSTG Marrakech

Pr. BENCHAREF Omar : Professeur à la FSTG Marrakech
Pr. KALOUN Soulaimane : Professeur à la FSTG Marrakech
Année Universitaire : 2020/2021

MÉMOIRE DE PROJET DE FIN D’ÉTUDES – YOUSSEF CHAACHAI 2
Dédicace
Je dédie ce travaille
A ma mère Zahra, ma raison d’être, la lanterne qui éclaire mon chemin
et m’illumine d’affection et d’amour.
A mon père Abdelaziz, en signe d’amour, et de gratitude pour tous les

soutiens et les sacrifices dont il a fait preuve à mon égard.
A ma sœur et mes chers frères,

En témoignage de mon affection fraternelle, je vous souhaite,
Oumaima, Zakaria et Ayoub, une vie pleine de bonheur et de succès
et qu’Allah, le tout puissant, vous protège et vous garde !
A tous mes proches et mes amis,
Je vous dédie ce travail en vous souhaitant un avenir éclatant et plein

de bonnes promesses.
…CHAACHAI Youssef

Remerciements
Ce travail n’aurait jamais pu se concrétiser sans l’aide et le soutien de
plusieurs personnes que je souhaite vivement remercier et à qui je
dédie ce travail.
Tout d'abord, je remercie respectueusement le directeur M. BEKKAR

Rachid pour m’avoir accepté comme stagiaire dans Adria Business &
Technology.
Je remercie M. TARRAQ Mohammed, mon encadrant au sein

d’Adria pour son accueil, sa disponibilité et le partage de son
expertise. Grâce aussi à sa confiance j'ai pu m'accomplir totalement
dans mes missions.
Mes remerciements également vont à M. AIRAJ Mohammed, mon

encadrant pédagogique au sein de la FSTG pour ses précieux conseils
et pour son excellent encadrement.
Je désire aussi remercier toute l’équipe Adria B&T, pour leur accueil
chaleureux, leur confiance, leur disponibilité malgré la charge du
travail et pour l’intérêt qu’ils ont porté à mon travail.
Finalement, je remercie tout le corps professoral et administratif de la

Faculté des Sciences et Techniques de Marrakech pour la formation
qu’ils nous ont prodigué, en particulier M. BENCHAREF Omar, le
responsable de la filière IRSI, qui n'a épargné aucun effort pour la
réussite de notre filière.

Liste des abréviations
Acronyme Signification
API Application Programming Interface
CIN Carte d’Identité Nationale
CSS Cascading Style Sheets
DOM Document Object Model
HAML HTML Abstraction Markup Language
HTML HyperText Markup Language
IDE Integrated Development Environment
IHM Interface Homme Machine
JSON JavaScript Object Notation
JSX JavaScript XML
OCR Optical Character Recognition
OpenCV Open-Source Computer Vision
PJ Pièce Jointe
SASS Syntactically Awesome Style Sheets
SDK Software Development Kit
SPA Single Page Application
UML Unified Modeling Language
XHR XMLHttpRequest
XML eXtensible Markup Language

Liste des tableaux
Tableau 1 : Fiche technique d’Adria B&T…………………………………………………………………………………………………16
Tableau 2 : Tableau illustrant la présence internationale d’Adria B&T ……………….………………………….……….18
Tableau 3 : Les rôle dans SCRUM ……………………………………………………………………….………………………….……….21
Tableau 4 : comparaison des valeurs de métriques requises avec les valeurs actuelles………………………...26
Tableau 5 : Les exigences techniques…………………………………………………………………………………………………….42
Tableau 6 : Comparaison des métriques de SonarQube avant et après l’amélioration…………………..………50

Liste des figures
Figure 1.1 : Produits et services Adria ………….…………………………………………………………………………………………17
Figure 1.2 : Principales références d’Adria …………………………………………………………………………………..…………18
Figure 1.3 : La carte de la présence internationale d’Adria ……………………………………………………………………..18
Figure 1.4 : Processus de la méthode SCRUM ……………………………………….………………………………………………..20
Figure 2.1 : Exemple du rapport de la qualité de code par SonarQube…………………………………………………..24
Figure 2.2 : Exemple des seuils de qualité requises pour un projet………………………………………………………..25
Figure 2.3 : Reconnaissance du texte dans une carte d’identité………………………………………………………….…28
Figure 2.4 : Besoins non fonctionnels…………………………………………………………………………………………………….29
Figure 3.1 : Diagramme de cas d’utilisation pour l’agent souscripteur si l’OCR est activée…………………….33
Figure 3.2 : Diagramme de cas d’utilisation pour l’agent souscripteur si l’OCR est désactivée……………….34
Figure 3.3 : Diagramme de cas d’utilisation pour l’administrateur de l’agence………………………………………35
Figure 3.4 : Diagramme de séquence : préparation de la demande de souscription avec OCR……………….36
Figure 3.5 : Diagramme de séquence : préparation de la demande de souscription sans OCR……………….37
Figure 3.6 : Diagramme de séquence : Soumission de la demande de souscription……………………………….38
Figure 3.7 : Diagramme d’activité : Processus de la demande de souscription ………………………………………39
Figure 4.1 : Architecture générale du projet frontend d’Adria……………………………………….………………………43
Figure 5.1 : Rapport de SonarQube après l’amélioration de la qualité de code………………………………………50
Figure 5.2 : Interface de souscription avant le scan de la carte nationale………………………………………………51
Figure 5.3 : Interface de souscription après le scan de la carte nationale………………………………………………52
Figure 5.4 : Formulaire de souscription après récupération des informations par OCR………………………….52
Figure 5.5 : prévisualisation des pièces jointes dans le formulaire de souscription………………………………..53
Figure 5.6 : prévisualisation d’une pièce jointe en taille réelle……………………………………………………………….53
Figure 5.7 : Interface montrant un récapitulatif de la demande avant la confirmation…………………………..54
Figure 5.8 : Interface contenant la liste des demandes de souscription rejetées……………………………………54

Table des matières
Dédicace ........................................................................................................................................................ 3
Remerciements ............................................................................................................................................. 4
Liste des abréviations.................................................................................................................................... 5
Liste des tableaux.......................................................................................................................................... 6
Liste des figures ............................................................................................................................................ 7
Résumé ....................................................................................................................................................... 11
Abstract ....................................................................................................................................................... 12
َ
‫ ُملخص‬........................................................................................................................................................... 13
Introduction générale ................................................................................................................................. 14
CHAPITRE 1 : Contexte générale du projet ........................................................................................ 15
1. Introduction ........................................................................................................................................ 16
2. Organisme d’accueil ............................................................................................................................ 16
2.1 Entreprise .................................................................................................................................... 16
2.2 Fiche technique de la société ...................................................................................................... 16
2.3 Produits et services ..................................................................................................................... 17
2.4 Principales références ................................................................................................................. 17
2.5 Présence internationale .............................................................................................................. 18
3. Rappel du sujet de stage ..................................................................................................................... 19
4. Conduite du projet .............................................................................................................................. 19
4.1 Méthodes agiles .......................................................................................................................... 19
5. Conclusion : ......................................................................................................................................... 21
CHAPITRE 2 : Analyse et spécification des besoins............................................................................. 22
1. Introduction ........................................................................................................................................ 23
2. Présentation générale du projet de stage .......................................................................................... 23
3. Étude et critique de l’existant ............................................................................................................. 24
3.1 Automatisation des tests et amélioration de la qualité de code ................................................ 24
a- Description de l’existant ............................................................................................................. 24
b- Problématique ............................................................................................................................ 25
c- Solutions envisagées ................................................................................................................... 26
3.2 La mise en œuvre du mode démo .............................................................................................. 26

b- Problématique ............................................................................................................................ 26
3.3 Intégration du système de saisie automatique des informations client .................................... 27
b- Critique de l’existant ................................................................................................................... 27
4. Spécification des besoins .................................................................................................................... 28
4.1 Besoins fonctionnels : ................................................................................................................. 28
4.2 Besoins non fonctionnels : .......................................................................................................... 29
5. Conclusion : ......................................................................................................................................... 30
CHAPITRE 3 : Conception et modélisation du projet .......................................................................... 31
1. Introduction ........................................................................................................................................ 32
2. Présentation de l’UML ........................................................................................................................ 32
3. Diagramme de cas d’utilisation :......................................................................................................... 32
3.1 Définition des acteurs ................................................................................................................. 33
3.2 Cas d’utilisation pour l’agent souscripteur ................................................................................. 33
3.3 Cas d’utilisation pour l’administrateur de l’agence .................................................................... 34
4. Diagramme de séquence : .................................................................................................................. 35
4.1 Préparation de la demande de souscription avec l’OCR............................................................. 35
4.2 Préparation de la demande de souscription sans OCR ............................................................... 36
4.3 Soumission de la demande de souscription ............................................................................... 37
5. Diagramme d’activité : ........................................................................................................................ 38
6. Conclusion : ......................................................................................................................................... 40
CHAPITRE 4 : Etude technique du projet ........................................................................................... 41
1. Introduction ........................................................................................................................................ 42
2. Besoins techniques ............................................................................................................................. 42
3. Présentation de l'architecture du projet Frontend............................................................................. 43
4. Langages et technologies de programmation .................................................................................... 44
5. Outils et technologies utilisés pour la qualité de code ....................................................................... 46
6. Outils et technologies utilisés pour la solution OCR ........................................................................... 47
7. Outils et environnement de travail ..................................................................................................... 48
8. Conclusion ........................................................................................................................................... 48

CHAPITRE 5 : Mise en œuvre ............................................................................................................ 49
1. Introduction ........................................................................................................................................ 50
2. Rapport de la qualité de code ............................................................................................................. 50
3. Aperçu des interfaces graphiques du système OCR ........................................................................... 51
4. Conclusion : ......................................................................................................................................... 55
Conclusion générale et perspectives ................................................................................................. 56
1. Résumé des objectifs achevés : .......................................................................................................... 56
2. Perspectives : ...................................................................................................................................... 56
Webographie ................................................................................................................................... 58

Résumé
Ce présent document est la synthèse de mon travail dans le cadre du stage de fin d'études, qui s’intitule
« Développement et restructuration des modules frontend dans le domaine de la banque digitale »,
pour l’obtention du diplôme d’ingénieur d’Etat en Réseaux et Systèmes d’Information (IRSI) à la Faculté
des Sciences et Techniques (FSTG) de Marrakech, Université Cadi Ayyad.
Ce stage a été effectué au sein de la société Adria Business & Technology en tant que développeur
Frontend sur une durée de quatre mois.
Le projet de stage consiste à développer des modules dans le projet Adria Standard côté Frontend, et
aussi à reconstruire certains modules et fonctionnalités qui ne répondent plus aux exigences actuelles du
marché bancaire, et cela en intégrant de nouvelles technologies comme l’OCR par exemple
(Reconnaissance Optique de Caractères). La reconstruction des modules du projet implique également la
révision et l'amélioration de l'ancien code dans le but de renforcer sa qualité.
Pour réaliser ce projet, j’ai travaillé avec une équipe de Frontend qui implémente la méthode agile de
gestion de projets Scrum, nous avons travaillé avec diverses technologies notamment la librairie ReactJS
du langage de programmation JavaScript.
Ce rapport vise donc à décrire de manière détaillée les différentes étapes qui ont permis la réalisation de
ce projet.
Mots clefs : Reconstruction, Digital Banking, Qualité de code, OCR.
Technologies : ReactJS, Redux, Webpack, SonarQube, Jest, Enzyme.

Abstract
This document presents the result of the work carried out within the end-of-studies internship project,
which is entitled "Development and restructuring of front-end modules in the field of digital banking",
to obtain the engineering diploma in Networks and Information Systems (IRSI) at the Faculty of Sciences
and Technologies (FSTG) of Marrakech, Cadi Ayyad University.
The internship was carried out within the company Adria Business & Technology as a Frontend developer
over a period of four months.
The project consists of developing modules in the Adria Standard project on the Frontend side, and also
reconstructing certain modules and functionalities that no longer meet the current requirements of the
banking market, and this by integrating new technologies such as OCR for example (Optical character
recognition). The reconstruction of the project modules also involves the revision and improvement of
the old code in order to strengthen its quality.
To realize this project, I have worked with a Frontend team that implements the agile method of project
management SCRUM, and we used various technologies including the ReactJS library of the JavaScript
programming language.
The aim of this report is therefore to describe in details the various stages that allowed us to realize this
project.
Keywords: Reconstruction, Digital Banking, Code quality, OCR.
Technologies: ReactJS, Redux, Webpack, SonarQube, Jest, Enzyme.

‫َُ‬
‫ملخص‬
‫هذا التقرير هو نتيجة العمل المنجز في إطار مشروع التخرج بعنوان "تطوير وإعادة هيكلة وحدات الواجهة األمامية في مجال الخدمات‬
‫المصرفية الرقمية"‪ ،‬من أجل الحصول على دبلوم مهندس دولة في الشبكات ونظم المعلومات بكلية العلوم والتقنيات بمراكش‪ ،‬جامعة‬
‫القاضي عياض‪.‬‬
‫تم القيام بهذا التدريب في شركة ‪ Adria Business & Technology‬كمطور للواجهة األمامية على مدى أربعة أشهر‪.‬‬
‫يهدف المشروع إلى تطوير وحدات في الواجهة األمامية من المشروع ‪ ،Adria Standard‬وكذلك إلعادة بناء بعض الوحدات والوظائف‬
‫التي لم تعد تلبي المتطلبات الحالية للسوق المصرفي‪ ،‬وذلك من خالل إدماج تقنيات جديدة مثل ‪ OCR‬على سبيل المثال (التعرف البصري‬
‫على األحرف)‪ .‬تتضمن إعادة بناء وحدات المشروع أيضًا مراجعة وتحسين الكود القديم من أجل تعزيز جودته‪.‬‬
‫لتحقيق هذا المشروع ‪ ،‬عملت مع فريق مطوري الواجهة األمامية الذي يعتمد المنهجية المرنة ‪ SCRUM‬إلدارة المشروع ‪ ،‬استخدمنا تقنيات‬
‫مختلفة بما في ذلك مكتبة ‪ ReactJS‬للغة برمجة ‪.JavaScript‬‬
‫الغرض إذا من هذا التقرير هو الوصف التفصيلي لمختلف المراحل التي مكنتنا من تنفيذ هذا المشروع‪.‬‬
‫الكلمات الداللية‪ :‬إعادة البناء ‪ ،‬الخدمات المصرفية الرقمية ‪ ،‬جودة الكود‪.OCR ،‬‬
‫التقنيات‪.Enzyme ،Jest ،SonarQube ،Webpack ،Redux ،ReactJS :‬‬
‫‪MÉMOIRE DE PROJET DE FIN D’ÉTUDES – YOUSSEF CHAACHAI‬‬ ‫‪13‬‬

Introduction générale
La tendance à l'adoption généralisée des services bancaires mobiles et en ligne augmente rapidement en
raison de COVID-19 et durera bien après la fin de la pandémie. Pour les banques, les coopératives de crédit
et les autres institutions financières, c'est une opportunité de profiter des avantages du Digital Banking et
de donner à leurs clients la possibilité d'effectuer des opérations bancaires, d'effectuer des transactions
et de transférer de l'argent comme ils le souhaitent.
Dans ce contexte, la société Adria Business & Technology offre à ses clients un large éventail de
fonctionnalités par le biais de ses application web et mobiles. Et pour préserver la progression
technologique de ses logiciels, l'entreprise cherche à adapter des solutions innovantes non seulement
pour asseoir ses spécificités, mais aussi pour se bâtir une identité propre.
L’amélioration des solutions logicielles est l'un des principaux objectifs d'Adria, par conséquent, mon
projet de stage consistait à mettre en œuvre de nouvelles idées qui feraient la différence et amélioreraient
le produit.
Ce présent rapport est composé de 5 chapitres, dans lesquels je présenterai en détail les différentes
tâches réalisées pour atteindre l'objectif du projet :
✓ Premier chapitre intitulé « Contexte général du projet » où je vais présenter l’entreprise d’accueil
et le déroulement général du projet.
✓ Deuxième chapitre intitulé « Analyse et spécification des besoins » où j’analyse les spécifications
avec une étude et critique de l’existant tout en proposant des solutions.
✓ Troisième chapitre intitulé « Conception du projet » où je présent une étude conceptuelle du

projet basée sur l’étude dans le chapitre précédant.
✓ Quatrième chapitre intitulé « Etude technique du projet » où je parle des outils techniques
utilisées pour le développement du projet.
✓ Cinquième chapitre intitulé « Mise en œuvre » où je présente des captures d’écran des interfaces
graphiques accompagné d’explications.

CHAPITRE 1 :
Contexte générale du projet
✓ Introduction
✓ Organisme d’accueil
✓ Rappel du sujet
✓ Conduite de projet
✓ Conclusion

1. Introduction
Ce premier chapitre décrit le contexte général du projet. Je vais présenter en première section de ce
chapitre l’organisme d’accueil ADRIA BUSINESS & TECHNOLOGY, puis Je rappellerais le sujet de mon
projet de stage et les objectifs à atteindre, ainsi que la démarche suivie pour mener à bien le travail.
2. Organisme d’accueil
2.1 Entreprise
ADRIA BUSINESS & TECHNOLOGY est un expert dans l’édition et

l’intégration des logiciels destinés aux banques et institutions
financières. Sa mission est d’accompagner les organisations
financières dans leurs projets de Digital Banking en leur offrant des
solutions performantes et des services à haute valeur ajoutée.
Avec une profonde compréhension du secteur bancaire, Adria crée des produits bien conçus pour aider
les banques à établir leur stratégie numérique au sein d’une structure de coûts définie et adaptée à
chaque cas d’utilisation.
2.2 Fiche technique de la société
Raison sociale ADRIA BUSINESS & TECHNOLOGY
Directeur général Rachid BEKKAR
Chiffre d’affaires 1 000 000 DHs

Société à Responsabilité Limitée à Associé Unique
Forme juridique
(SARLAU)
Secteur d’activité Informatique, Digital Banking

Shore 26 – 2e étage Casa Nearshore Park
Siege social
Casablanca, Maroc
Téléphone +212 (5) 222-73-0-73
E-mail contact@adria-bt.com
Site Web www.adria-bt.com
Tableau 1 : Fiche technique d’Adria B&T

2.3 Produits et services
Adria a pour principal objectif, assurer la qualité et l’aptitude des produits et services qu’elle offre à ses
clients, afin de satisfaire amplement les besoins exprimés ou potentiels des consommateurs. Elle expose
une variété de produits et services couvrant tous types de canaux de communication, à savoir le web et
le mobile.
o Adria banque directe Cross Canal : Il s’agit d’un produit modulaire qui se positionne sur
l’ensemble de la trajectoire commerciale et présente un espace en ligne intégré de la relation
avec le client disposant ainsi de fonctionnalités de marketing, de vente dématérialisée et
complètement en ligne, de services transactionnels, et de communication avec le client.
o Adria Mobile Branch Banking : Elle permet d’équiper les agences mobiles et les agents nomades
d’une solution qui couvre toutes les fonctionnalités d’entrée en relation, de souscription de
produits, de gestion de comptes et des services transactionnels....
o Adria Analytics : Il permet de collecter, d’analyser et visualiser l’ensemble des interactions du

client avec la banque quel que soit le canal utilisé
Figure 1.1 : Produits et services Adria
2.4 Principales références
Grâce à son potentiel inestimable, la société ADRIA a pu monopoliser 90% du marché bancaire au Maroc.
La figure ci-dessous illustre les principales références d’Adria B&T :

Figure 1.2 : Principales références d’Adria
2.5 Présence internationale
En raison de ses services de qualités, Adria a pu créer une base clientèle qui regroupe toutes les grandes
sociétés bancaires soit au Maroc ou à l’étranger. Le potentiel d'Adria l'a transformé d'une entreprise locale
à une société visant l'internationale.
ADRIA a pu acquérir la confiance de clients à l'international. Ainsi, elle a pu rapprocher ses services au
niveau Africain et Européen.
Maroc Mauritanie Burkina Italie

Faso
Egypte Cameroun Benin Gabon
Côte R.D. Congo Sénégal Togo

d'Ivoire
Belgique Inde Espagne France
Tableau 2 : Tableau illustrant la Figure 1.3 : La carte de la

présence internationale d’Adria présence internationale d’Adria

3. Rappel du sujet de stage
Mon projet de fin d’études a comme sujet de développer des modules Frontend dans les applications
Adria du Digital Banking, et aussi de restructurer certains modules qui ne répondent plus aux exigences
des client dans leurs état actuel. Ainsi, j'ai travaillé sur de nombreuses tâches dans différents projets selon
le besoin de l’équipe Frontend, je peux donc diviser ma période du stage en trois sujets :
• Automatisation des tests et amélioration de la qualité de code Frontend : Adria utilise l’outil
SonarQube pour générer un rapport indiquant la qualité du code de l’application sous différents
aspects (Couverture des test unitaires, les duplications et les faiblesses du code…). L’objectif c’est
donc, d’améliorer les métriques du rapport de SonarQube en augmentant le nombre des tests
unitaires et en éliminant les faiblesses qui apparaissent dans le code.
• Mise en œuvre d’un mode démo de l’application web Adria Banking : l’objectif est d’implémenter
une solution pour simuler toutes les fonctionnalités de l’application web Adria Standard. Ce mode
sera utilisé aussi pour tester l’application coté frontend.
• Intégration d’un système de saisie automatique des informations client : l’objectif est de mettre en
œuvre un système paramétrable qui, lorsqu'il est activé, permettra à l'agent souscripteur d'utiliser la
fonctionnalité de scan CIN dans le parcours de l’entrée en relation dans le but d’automatiser
l’acquisition des informations personnelles des nouveaux clients inscrits, tout en minimisant le risque
d’erreur et le risque de rejets.
4. Conduite du projet
La conduite de projet est une démarche qui vise à structurer et optimiser le déroulement d’un projet.
Dans ce sens, nous avons choisi comme méthodes de développement les « Méthodes Agiles ».
4.1 Méthodes agiles
Les méthodes de développement dites « méthodes agiles » offrent une approche révolutive à la façon
dont le client et l’équipe de production communiquent entre eux. Elles visent principalement à impliquer
le client dans la production du début à la fin du projet, et cela en adoptant un processus itératif et
incrémental basé sur une écoute du client, et de l’implémentation de tests tout au long du cycle de
développement.
4.1.1 La méthode SCRUM
Scrum est une « méthode agile » de gestion de projet, généralement pour le développement de logiciels.
Cette méthode de gestion, ou plutôt Framework de management de projet, a pour objectif d’améliorer la
productivité de son équipe.

Figure 1.4 : Processus de la méthode SCRUM
Cette méthode introduit des temps de travails commun qui ont pour objets d’améliorer la motivation des
participants, de synchroniser les tâches entre les membres d’équipes, de débloquer les situations difficiles
et d’accroitre le partage connaissance.
Le choix de la méthode SCRUM comme méthode de travail est des plus logique vu son importance et sa
popularité.
La méthode SCRUM nous permet de découper le projet en sprint de 2 à 4 semaines. Chaque sprint
commence par une estimation suivie d’une planification opérationnelle et se termine par un produit
livrable et une démonstration de ce qui a été achevé. Avant de démarrer un nouveau sprint, on réalise
une rétrospective durant une petite réunion de l’équipe.
4.1.2 Equipe et rôles :

La répartition des rôles dans la méthode SCRUM se fait comme suit :
Rôles Description
Product Owner - Définit les spécifications fonctionnelles.
- Établit la priorité des fonctionnalités à développer ou corriger.
- Valide les fonctionnalités développées.
- Joue le rôle du client.
Scrum Master - S’assure que les principes et les valeurs de Scrum sont respectés.
(M. TARRAQ Mohammed) - Il agit sur le processus de développement.
- Cherche à améliorer la productivité et le savoir-faire de son équipe

Equipe de - Pas de rôle spécifique (développeurs, designers, testeurs, etc.)
développement
- Tous les membres de l’équipe apportent leur savoir-faire pour
accomplir les tâches.
Tableau 3 : Les rôles dans SCRUM
4.1.3 Les réunions :

En Scrum, généralement Il y a cinq types de réunions organisées à intervalles réguliers, on parle de la mêlé
quotidienne ou Daily Scrum, Planification du sprint, revue du sprint, rétrospective du sprint et le
raffinement du Product Backlog.
Dans notre cas, nous nous sommes limités à trois réunions que nous pensions nécessaires :
- Planification du Sprint : lors de la réunion de planification de Sprint, nous déterminons les tâches
à accomplir pendant le sprint. Cette réunion avait lieu au début de chaque mois et durait une
heure.
- La mêlé quotidienne : nous avons organisé des réunions quotidiennes de durée ne dépassant pas
15 minutes. La réunion avait lieu tous les matins au cours de laquelle nous répondions à trois
questions avant de commencer à travailler, Qu'est-ce qu'on a réalisé la veille, Qu'est-ce qu'on va
accomplir aujourd'hui et quels sont les obstacles qui nous retardent.
- Revue du Sprint : L’ensemble de l’équipe de travail, y compris le Product Owner, se réunissait à

la fin de chaque semaine afin de valider ce qui a été accompli pendant le Sprint. Cette réunion
avait lieu à la fin de chaque mois et sa durée dépendait de ce que l’équipe a développé.
5. Conclusion :
Dans ce chapitre j’ai présenté l’organisme d’accueil, rappelé le sujet de stage et expliqué les méthodes
choisies pour le bon déroulement du projet. Sur la base de cette étude, je pourrais élaborer une analyse
et une spécification des besoins du projet dans le chapitre suivant.

CHAPITRE 2 :
Analyse et spécification des besoins
✓ Introduction
✓ Présentation générale du projet de stage
✓ Description et critique de l’existant
✓ Spécification des besoins
✓ Conclusion

1. Introduction
Dans ce chapitre, je vais présenter la spécification de besoins à la qualification des besoins fonctionnels
et non fonctionnels attendus du système afin de mieux comprendre le projet.
2. Présentation générale du projet de stage

Le projet rentre dans le cadre de préparation de stage de fin d'études pour l'obtention du diplôme
d’ingénieur d’Etat en Réseaux et Systèmes d’Information (IRSI) à la Faculté des Sciences et Techniques de
Marrakech. Ce projet a été effectué au sein de la société Adria Business & Technology pour une période
de quatre mois.
Le projet de stage est divisé en trois grandes parties :
Première partie : L’automatisation des tests et amélioration de la qualité de code Frontend, pour réaliser
cette tâche, j’ai travaillé avec une équipe composée de trois développeurs frontend, notre objectif était
d'écrire les tests unitaires pour augmenter le pourcentage de couverture du rapport SonarQube et
d’éliminer les faiblesses et les anomalies du code pour diminuer le nombre des "Code Smells".
Cette première partie était tellement importante pour moi, peut-être la plus importante, car elle m'a
permis d'intégrer l'équipe pour la première fois, et aussi elle m'a permis de découvrir la structure du projet
et les technologies de développement utilisées.
Deuxième partie : La mise en œuvre d’un mode démo de l’application web Adria Standard, dans cette
partie, nous avons essayé de créer un espace dans lequel les utilisateurs pourront découvrir la plateforme
sans avoir besoin d’un compte utilisateur. L'espace sera également utile pour l'équipe frontend afin de
tester les interfaces graphiques sans aucune interaction directe avec le serveur Backend, puisque celui-ci
prend plus de temps pour répondre.
Comme je l'ai dit à propos de la première tâche, cette partie m'a aussi permis d'en découvrir plus sur la
structure du projet et surtout la forme des réponses qui viennent des serveurs backend.
Troisième partie : Intégration d’un système de saisie automatique des informations client, cette tâche a
comme objectif de remplacer tous les formulaires d'informations personnelles des utilisateurs par un
système qui prend en entrée une carte d'identité (Carte nationale, passeport, …) et renvoie les
informations requises pour remplir automatiquement les champs du formulaire. Ce système doit être
paramétrable, c'est-à-dire que le propriétaire de l'application aura la possibilité d'activer/désactiver la
fonctionnalité OCR et de revenir à la manière classique (Saisie manuelle).
Le système qu’on vise à intégrer concerne principalement les applications de portefeuille bancaire où il y
a un agent chargé de créer des portefeuilles pour les clients de la banque, cet agent est notre seul acteur
ici.

3. Étude et critique de l’existant
L'étude de l'existant est une étape cruciale dans la réalisation de tout projet. Mon projet étant divisé en
trois parties principales, je présenterai dans cette section une étude concernant chacune des tâches.
3.1 Automatisation des tests et amélioration de la qualité de code

a- Description de l’existant
La qualité du code définit à quel point le code est utile et maintenable à long terme. Pour le dire plus
formellement, la qualité du code comprend un groupe d'attributs et d'exigences différents, déterminés
et hiérarchisés par l’entreprise.
Pour le cas d’Adria, l’équipe de développement frontend a intégré l'analyse de la qualité du code dans
leurs flux de travail, car de nombreux clients exigent un rapport sur la qualité du code pour s'assurer que
le produit est propre. Pour cela, Adria utilise SonarQube comme outil de gestion de la qualité du code.
La figure 2.1 illustre un ensemble des métriques relatives à la qualité du code de projet Adria Standard.
Figure 2.1 : Exemple du rapport de la qualité de code par SonarQube
Ces métriques ont été enregistrées au moment où j'ai commencé le stage, et c'était à nous (l'équipe
Frontend) de les améliorer. Mais que nous disent exactement tous ces chiffres ?
Bugs : ce sont des erreurs de codage dans le programme. Le processus de recherche de bugs s'appelle le
débogage, ça commence après la première écriture du code et se poursuit par étapes successives à
mesure que le code soit combiné avec d'autres unités du programme.

Vulnerabilities : ce sont des problèmes liés à la sécurité qui représente une porte dérobée pour les
attaquants, il s’agit d’une faille dans le code qui crée un risque potentiel de compromettre la sécurité.
Security Hotspot : ce sont des morceaux de code sensibles à la sécurité qui doivent être examinés
manuellement. Après examen, on constate qu'il n'y a pas de menace ou qu'il y a du code vulnérable qui
doit être corrigé.
Debt : ou dette technique, c’est une mesure de compromis dans la qualité du code pour compenser les
délais de livraison rapides. Comme la livraison rapide de prototypes ou de mises à jour est parfois
prioritaire sur l'optimisation du code et des performances, il est important de suivre dans quelle mesure
la qualité du code a été affectée après chaque livraison et de compenser ces compromis plus tard.
Code Smells : ils indiquent des faiblesses dans la conception qui peuvent ralentir le développement ou
augmenter le risque de bugs ou d'échecs à l'avenir.
Coverage : c’est le pourcentage de code qui est couvert par des tests automatisés.
Duplicated Blocks : c’est le nombre de blocs de code dupliqués. Un morceau de code est considéré comme
dupliqué dès qu'il y a la même séquence de 10 instructions successives quel que soit le nombre de lignes.
b- Problématique
Le problème du mauvais code est toujours difficile à résoudre dans toute organisation. La pression
incessante pour livrer plus de fonctionnalités à un rythme rapide oblige les développeurs à prendre des
raccourcis, ce qui rend le code plutôt difficile à maintenir et à étendre. Cette approche a des conséquences
graves et des coûts élevés qui seront probablement supportés par quelqu'un à l'avenir.
Pour ces raisons, les clients d’Adria ont des exigences spécifiques sur les métriques de qualité du code,
c'est ce qu'on appelle dans SonarQube "Quality Gates".
Quality Gates peuvent être définies comme un ensemble de mesures de seuil définies sur le projet, et
pour passer ces mesures, le projet doit franchir chacun des seuils définis.
La figure suivante montre un exemple des seuils définies pour un projet :
Figure 2.2 : Exemple des seuils de qualité requises pour un projet

Dans le tableau ci-dessous, je vais comparer les valeurs exigées par les clients d’Adria, avec les valeurs
réelles :
Métrique Condition de passage Valeur actuelle Quality Gate

Couverture (tests unitaires) Supérieur à 80% 25% Échoué
Lines dupliquées Inférieur à 3% 16% Échoué
Cote de maintenabilité Égale à A A Passé
Cote de fiabilité (Bugs) Égale à A C Échoué
Security Hotspots examinés Égale à 100% 100% Passé
Cote de sécurité Égale à A A Passé
Tableau 4 : comparaison des valeurs de métriques requises avec les valeurs actuelles
c- Solutions envisagées
Pour résoudre les problèmes dégagés, nous visons à :
• Écrire des tests unitaires pour tous les blocs de code et tester les différents cas d'utilisation des
interfaces graphiques afin d'améliorer le pourcentage de couverture (dépasser 80%).
• Optimiser les lignes de code dupliquées en créant des abstractions pour le code qui se répète afin
de diminuer le pourcentage de code dupliqué (moins de 3%).
• Éliminer les bugs de code pour améliorer la cote de fiabilité.
• Renforcer le code en éliminant les variables non utilisées et les traitements inutiles.
3.2 La mise en œuvre du mode démo

Dans le scénario de développement où le frontend et le backend sont séparés, il y a des avantages d'un
faible couplage et d'un développement indépendant. Cela offre beaucoup plus de flexibilité en étant
capable de déployer uniquement le frontend en production ou en utilisant le même backend pour un
frontend différent avec une pile technologique totalement différente, et c’est le cas pour le projet
standard d’Adria, le frontend est totalement isolé du backend, et les développeurs utilisent des serveurs
sur lesquels le backend est hébergé pour tester les interfaces graphiques.
b- Problématique
Généralement, les serveurs de test utilisés dans Adria ne sont pas assez performants, par conséquent, les
développeurs frontend doivent parfois attendre si longtemps une réponse du backend afin de tester une
seule interface graphique, ce qui pose un réel problème dans le temps d'avancement du projet.

Dans le développement, il y a différentes personnes qui travaillent sur le frontend et sur le backend.
L'équipe backend doit s'assurer que le contenu fourni par l'API est sain, alors que l’équipe frontend ne se
soucie pas du contenu, ils ont juste besoin des données factices dans la bonne structure.
Ces équipes n'ont donc qu'à discuter et se mettre d'accord sur les structures JSON des réponses avant de
pouvoir travailler de manière indépendante de leur côté.
Le principal avantage de travailler avec des données factices ici est l'indépendance dans laquelle l'équipe
frontend peut travailler. Peu importe si le développement du backend reste bloqué pour une raison
quelconque.
3.3 Intégration du système de saisie automatique des informations client

Dans chaque application bancaire, il y a beaucoup de formulaires de saisie de données, dans notre cas,
nous allons travailler sur des formulaires de souscription des clients pour la création des portefeuilles
bancaires (Wallets).
Le processus de création d'un portefeuille bancaire comprend le remplissage manuel d'un formulaire, les
informations utilisées pour remplir le formulaire sont copiées d’une carte d'identité fournie par le client
à l'agent en charge de la souscription.
Après avoir rempli le formulaire avec les informations nécessaires, l'agent devra scanner la carte d'identité
et la joindre à la demande afin de prouver l’identité du client.
b- Critique de l’existant
Généralement, dans les agences bancaires, les clients sont tenus de soumettre certains documents qui
pourraient être utilisés pour vérifier leur identité et obtenir des détails pertinents. Ce processus est
généralement fastidieux et prend du temps, car il se fait manuellement. Le client doit soumettre une copie
numérique des documents qu'un réviseur va examiner manuellement, identifier s'il s'agit d'une fausse
identité, extraire des informations telles que le nom, l'adresse, date de naissance etc. et les saisir dans un
formulaire de souscription.
Au cours des dernières années, nous avons assisté à une augmentation importante des outils et des
technologies qui étaient principalement conçus pour gagner du temps et minimiser les taux d'erreur.
Parmi ces technologies, il y a l'OCR.
OCR signifie "Reconnaissance optique de caractères". C’est une technologie qui reconnaît le texte dans
une image numérique. Il est couramment utilisé pour reconnaître le texte dans les documents numérisés,
mais il sert également à de nombreuses autres utilisations.

Figure 2.3 : Reconnaissance du texte dans une carte d’identité
L’OCR est la solution idéale pour notre cas puisque nous scannons la carte d'identité pour la joindre quand
même au formulaire, alors pourquoi ne pas utiliser l'image numérisée pour extraire les informations
requises et gagner du temps ?
4. Spécification des besoins
Dans cette partie je vais identifier les besoins de mon projet. Je vais mettre l’accent sur les besoins
fonctionnels ainsi que les besoins non fonctionnels.
4.1 Besoins fonctionnels :
Avant de parler du fonctionnement proprement dit du système, il est nécessaire de définir dans un
premier temps les fonctionnalités qui seront implémentées au sein du système. De ce fait nous pouvons
dire que l’agent souscripteur doit être capable de :
Si l’OCR est activé :
• Scanner la carte d’identité fournie par le client recto/verso.

• Après l'aperçu des images résultat du scan, soumettre les deux images pour recevoir les
informations demandées.
• Choisir le type de Wallet souhaité par le client (Plafond 200 DH, 5 000 DH, 20 000 DH).
• Saisir les champs supplémentaires (numéro de téléphone, E-mail, …).
• Scanner les autres pièces justificatives demandés.
• Vérifier la conformité des informations et soumettre la demande.

• Consulter la liste des demandes de souscription rejeté de la part de l’agent chargé de la révision.
• Mettre à jour les demandes qui ont été rejetées et les soumettre à nouveau.
Si l’OCR est désactivé :
• Choisir le type de Wallet souhaité par le client (Plafond 200 DH, 5 000 DH, 20 000 DH).
• Remplir le formulaire manuellement avec les informations demandées (nom, prénom, …).
• Joindre les pièces justificatives demandés, y compris la carte d'identité recto/verso.
• Vérifier informations saisies et soumettre la demande.
• Consulter la liste des demandes de souscription rejeté de la part de l’agent chargé de la révision.
• Mettre à jour les demandes qui ont été rejetées et les soumettre à nouveau.
4.2 Besoins non fonctionnels :
Il s’agit des besoins qui caractérisent le système. Ce sont des besoins en matière de performance, de type
de matériel ou le type de conception. Ces besoins peuvent concerner les contraintes d’implémentation
(langage de programmation, système d’Exploitation...)
Notre système doit d’abord satisfaire un ensemble de contraintes techniques :
• Il devrait être facile à étendre et extensible, c’est-à-dire qu’il pourra y avoir une possibilité
d’ajouter ou de modifier de nouvelles fonctionnalités et services.
• Il doit fournir une interface conviviale et intuitive.
• Il doit garantir un accès rapide à l’information.
• Il faudra aussi noter que l’application devra être hautement sécurisée car les informations ne
devront pas être accessibles à tout le monde.
• Il doit montrer une certaine résistance aux attaques externes et internes.
• Il doit être compatible avec n’importe quel système d’exploitation et format (web, tablette et
mobile).
La figure 2.4 synthétise ces besoins en un seul schéma.
Figure 2.4 : Besoins non fonctionnels

5. Conclusion :
J’ai traité dans ce chapitre la phase d’analyse et spécifications des besoins. D’abord, j’ai commencé par
une étude de l’existant, puis, j’ai défini les différents besoins fonctionnels et non fonctionnels. Le chapitre
suivant donnera une vision détaillée sur la modélisation et conception de la solution.

CHAPITRE 3 :
Conception et modélisation du projet
✓ Introduction
✓ Présentation de l’UML
✓ Diagramme de cas d’utilisation
✓ Diagramme de séquence
✓ Diagramme d’activité
✓ Conclusion

1. Introduction
Dans ce chapitre, je vais présenter une conception et une analyse basé sur l’étude faites dans le chapitre
précédant. La conception ne concernera que la tâche OCR, car les autres tâches n'ont pas d'étude
conceptuelle.
La plupart des langages sont orientés objets. Le passage de la programmation fonctionnelle à l’orienté
objet n’est pas facile. L’un de souci était d’avoir une idée globale en avance de ce qu’on doit programmer.
L'algorithmique utilisé dans la programmation fonctionnelle ne pouvait pas suffire à lui seul. Le besoin
d'avoir des méthodes ou langages pour la modélisation des langages orientés objet est nécessaire. Ainsi
plusieurs méthodes ou langages ont vu le jour. En occurrence UML qui nous a permis de faire la conception
de notre système.
De nos jours, UML2 possède treize diagrammes qui sont classés en deux catégories (dynamique et
statique). Dans ce chapitre, je vais commencer par les diagrammes de cas d'utilisation qui permettent de
donner une vue globale du système, pas seulement pour un client non avisé qui aura l'idée de sa future
application mais aussi pour le développeur qui s'en sert pour le développement des interfaces.
Puis, je vais affiner la conception en présentant la chronologie des opérations par les diagrammes des
séquences et d’activité.
2. Présentation de l’UML
En informatique UML (de l'anglais Unified Modeling Language), ou Langage de modélisation
unifié, est un langage de modélisation graphique à base de pictogrammes. Il est utilisé en
développement logiciel, et en conception orientée objet. UML est couramment utilisé dans
les projets logiciels.
UML est l'accomplissement de la fusion de précédents langages de modélisation objet : Booch, OMT,
OOSE. Principalement issu des travaux de Grady Booch, James Rumbaugh et Ivar Jacobson, UML est à
présent un standard défini par l'Object Management Group (OMG). La version actuelle du langage de
modélisation unifié est UML 2.5.1, publiée par l’OMG en décembre 2017.
3. Diagramme de cas d’utilisation :

Le diagramme de cas d’utilisation permet de déterminer les possibilités d'interférence entre le système
et les acteurs, c'est-à-dire déterminer toutes les fonctionnalités que doit fournir le système. Il permet
aussi de délimiter ce dernier.
• Chaque usage effectué par les acteurs est représenté par un cas d'utilisation.
• Chaque cas d'utilisation symbolise une fonctionnalité qui leur est offerte afin d’engendrer
le résultat attendu.
• Le diagramme de cas d'utilisation décrit l'interaction entre le système et l'acteur en
déterminant les besoins de l'utilisateur et tout ce que doit faire le système pour l'acteur.

3.1 Définition des acteurs
Un acteur est une personne, un matériel ou un logiciel qui interagit avec le système. L’analyse du présent
projet commence par une identification des acteurs agissants sur les différentes parties du système.
Les acteurs qui interagissent avec le système de reconnaissance optique de caractères sont :
• Administrateur du système ;
• Agent souscripteur ;
3.2 Cas d’utilisation pour l’agent souscripteur
Le processus de souscription admet deux scénarios possibles, soit la fonctionnalité de l’OCR est activée
ou désactivée par l’administrateur de l’agence, alors pour bien clarifier les diagrammes, je vais représenter
les deux cas dans deux diagrammes séparés.
La figure 3.1 représente le digramme de cas d’utilisation si le paramètre d’OCR est activé :
Figure 3.1 : Diagramme de cas d’utilisation pour l’agent souscripteur si l’OCR est activée

La figure 3.2 représente le digramme de cas d’utilisation si le paramètre d’OCR est désactivé :
Figure 3.2 : Diagramme de cas d’utilisation pour l’agent souscripteur si l’OCR est désactivée
En analysant les deux diagrammes, on constate que l’agent souscripteur effectue la demande de
souscription en fournissant un ensemble des informations qu’il récupère depuis la carte d’identité du
client, ainsi, il choisit le type de portefeuille souhaité par le client (plafond 200 DH, 5 000 DH ou 20 000
DH), puis, si la fonctionnalité de l’OCR est activé il n’a que scanner la carte d’identité pour remplir le
formulaire avec les informations de base (nom, prénom, date de naissance, …) et en même temps la carte
scannée sera attaché directement avec les pièce jointes. Sinon il devra remplir manuellement les champs
du formulaire, joindre les pièces justificatives demandées et soumettre la demande.
3.3 Cas d’utilisation pour l’administrateur de l’agence
La figure 3.3 représente le digramme de cas d’utilisation pour les fonctionnalités de l’administrateur :
D’après le diagramme (figure 3.3), on constate que parmi les fonctionnalités de l’administrateur, il y a
l’activation et la désactivation du paramètre de l’OCR, et la révision des demandes de souscription.
Remarque : ce diagramme montre juste les fonctionnalités de l’administrateur qui ont une relation avec
la souscription, il y a d’autres fonctionnalités qu’on ne va pas traiter car ils sont au-delà de mes tâches.

Figure 3.3 : Diagramme de cas d’utilisation pour l’administrateur de l’agence
4. Diagramme de séquence :
La description textuelle présente des inconvénients puisqu’il est difficile de montrer comment les
traitements se succèdent. Il est donc recommandé de compléter la description textuelle par un ou
plusieurs diagrammes dynamiques UML. Dans ce qui suit on va présenter les principaux diagrammes de
séquences élaborés.
4.1 Préparation de la demande de souscription avec l’OCR
Le diagramme de séquence illustré dans la figure 3.4, montre le scenario de la préparation d’une demande
de souscription avant la soumission en utilisant la fonctionnalité OCR. (J’ai divisé les scenarios pour la
lisibilité des diagrammes).
En analysant ce diagramme, on constate qu’il y a une interaction entre l’agent souscripteur et le serveur
OCR SDK par l’intermédiaire qui est l’interface homme machine (formulaire de souscription). Ainsi, après
le scan de la carte d’identité du client, l’image résultante passe par un traitement qui compris le recadrage
pour éliminer les parties vides, puis la compression afin de minimiser sa taille pour éviter la consommation
de la bande passante.
Apres la soumission des deux images (le recto et le verso de la carte), le SDK devra vérifier tout d’abord
l’existence d’une photo dans la carte, et par la suite, il va vérifier si la carte est lisible et les informations
sont claires, si toutes les conditions sont remplies, il va repérer les données et les renvoyer sous format
JSON.

Finalement le formulaire va s’affiché et se remplir avec les informations récupérées, et l'agent n'a qu'à
remplir les champs manquants pour finaliser la préparation du formulaire avant la soumission.
Figure 3.4 : Diagramme de séquence : préparation de la demande de souscription avec OCR
4.2 Préparation de la demande de souscription sans OCR
Le diagramme de séquence illustré dans la figure 3.5, montre le scenario de la préparation d’une demande
de souscription avant la soumission sans la fonctionnalité OCR.

Figure 3.5 : Diagramme de séquence : préparation de la demande de souscription sans OCR
4.3 Soumission de la demande de souscription
Le diagramme de séquence illustré dans la figure 3.6, montre le scenario de la soumission d’une demande
de souscription.
En effet, après la préparation de la demande, en passant par l’étape précédente, la demande est soumise
en 2 requêtes séparées, la première requête contient les documents justificatifs attaché, ainsi, ils seront
persistés dans la base de données en premier lieu pour récupérer leur clé primaire, cette dernière va être
retournée pour qu’elle soit utilisée dans la persistance de la souscription.
Après avoir enregistré la demande, une interface contenant un récapitulatif s'affiche pour la confirmation,
pour confirmer la demande, l’agent reçoit en SMS un code qu’il doit saisir afin de terminer l’opération.

Figure 3.6 : Diagramme de séquence : Soumission de la demande de souscription
5. Diagramme d’activité :
Ce diagramme permet de modéliser un processus interactif, global ou partiel pour un système donné
(logiciel, système d'information). Il est recommandable pour exprimer une dimension temporelle sur une
partie du modèle, à partir de diagrammes de classes ou de cas d'utilisation.
La figure 3.7 illustre un diagramme d’activité résumant le processus de la création d’une demande de
souscription par l’agent souscripteur.

OCR activé
Initial Scanner la première
face de la CIN
OCR désactivé
Scanner la deuxième
face de la CIN
Soumettre les
deux images
Erreur du serveur
CIN illisible
Succès
Choisir le type Remplir les champs Scanner d’autres

de souscription manquants pièces justificatives
Soumettre la
demande
Erreur du serveur
Succès
Final
Figure 3.7 : Diagramme d’activité : Processus de la demande de souscription

6. Conclusion :
Ce chapitre a été consacré aux différentes étapes de la conception détaillée. Du raffinement du
diagramme de cas d’utilisation, vers le diagramme d’activité et de séquence de plusieurs cas d’utilisations
pour montrer les interactions entre les acteurs et le système. Dans ce qui suit je vais décrire les différents
outils et technologies que j’ai utilisé pour la réalisation de mes tâches.

CHAPITRE 4 :
Etude technique du projet
✓ Introduction
✓ Besoins techniques
✓ Présentation de l'architecture du projet Frontend
✓ Langages et technologies de programmation
✓ Outils et technologies utilisés pour la qualité de code
✓ Outils et technologies utilisés pour la solution OCR
✓ Outils et environnement de travail
✓ Conclusion

1. Introduction
La création et la conception d'un système informatique est un processus qui implique l'utilisation de
nouvelles technologies et outils. Parmi les outils utilisés, on trouve :
- Les langages de programmation web qui permettent de créer des applications sur navigateur.
- Langage de balisage pour garantir une bonne présentation visuelle.
- Un environnement de développement (IDE) dédié à la programmation web.
- Langage de programmation coté serveur pour la création d’une interface de communication avec
ce dernier.
- Les systèmes de gestion de base de données qui répondent aux différentes opérations de
stockage et de traitement des données.
L’objectif de ce chapitre est de présenter les différents outils et technologies qu’on a utilisés lors de la
réalisation des tâches du projet.
2. Besoins techniques
La capture des besoins techniques liste les spécifications auxquelles le système doit supporter, en faisant
abstraction des besoins fonctionnels présenté précédemment.
Le système doit être conforme avec des exigences techniques présentées dans le tableau suivant :
Exigence Description
Facile à connecter L’application doit être facile à relier avec une instance client, en requittant
le logo, et les données relatives à cette instance.
Maintenable L’application doit être facile à maintenir
Disponible Être en permanence à la disposition des utilisateurs sur n’importe quelle

plateforme en minimisant le temps de répons
Sécurisée L’accès aux données doit être sécurisé à l’aide d’un mot de passe pour les
instances fermées.
Indépendante L’application ne doit pas dépendre des technologies utilisées dans le back
end.
Tableau 5 : Les exigences techniques

3. Présentation de l'architecture du projet Frontend
L'architecture d'un système décrit ses principaux composants, leurs relations et la manière dont ils
interagissent les uns avec les autres. L'architecture logicielle inclue plusieurs facteurs contributifs tels que
la stratégie commerciale, les attributs de qualité, la dynamique humaine, la conception et
l'environnement informatique.
Dans cette section, je vais présenter brièvement l'architecture du projet frontend (figure 4.1), et par la
suite, je vais définir en détails chaque outil et technologie utilisée.
Figure 4.1 : Architecture générale du projet frontend d’Adria
La figure ci-dessus représente les différentes parties qui composent le projet Frontend, chacune joue un
rôle très spécifique. Les services, les actions les réducteurs et les sélecteurs appartiennent à "Redux". Les
Template et les composants appartiennent à "React". Le conteneur est une pièce qui leur permet d'être
librement couplés ensemble. Cela permet au "Redux Store" et à la vue de pouvoir changer et grandir
indépendamment l'un de l'autre.
Définissons chaque partie individuellement afin de bien comprendre le schéma :
• Components : il s'agit d'un modèle, c'est un ensemble de code qui utilise des propriétés et peut
appeler d'autres composants et leur donner des propriétés (Props).

• Props : ils représentent les propriétés et sont utilisés pour transmettre des données d'un
composant à un autre.
• Template : il s'agit simplement d'un composant, sauf que c’est un type spécial de composant qui
fait des choses plus spécifiquement que les composants inférieurs.
• Container : Le conteneur est la partie qui relie "React" au "Redux". Autrement dit, c’est un
composant React connecté à un "Redux Store".
• Actions : Les actions sont la seule source d'informations pour Redux Store", il transporte une les
informations de l’application à stocker. Les actions sont des objets JavaScript simples qui doivent
avoir un attribut type pour indiquer le type d'action effectuée.
• Reducer : c’est une fonction qui détermine les changements d'état d'une application. Il utilise
l'action qu'il reçoit pour déterminer ce changement. Redux s'appuie fortement sur les fonctions
de réduction qui prennent l'état précédent et une action afin d'exécuter l'état suivant.
• Redux Store : c’est l'endroit où Redux stocke les données, les données sont mappées aux "Props"
que React affiche via les composants. Il s’agit d’un conteneur d'état qui contient l'état de
l'application.
4. Langages et technologies de programmation
JavaScript : souvent abrégé en JS, est un langage de programmation conforme à la

spécification ECMAScript. JavaScript est de haut niveau, souvent compilé juste à temps et
multi-paradigme. Il a une syntaxe entre accolades, un typage dynamique, une orientation
objet basée sur des prototypes et des fonctions de première classe.
Avec HTML et CSS, JavaScript est l'une des technologies de base du World Wide Web. Plus de 97% des
sites Web l'utilisent côté client pour le comportement des pages Web, incorporant souvent des
bibliothèques tierces. Tous les principaux navigateurs Web disposent d'un moteur JavaScript dédié pour
exécuter le code sur l'appareil de l'utilisateur.
En tant que langage multi-paradigmes, JavaScript prend en charge les styles de programmation
événementiels, fonctionnels et impératifs. Il dispose d'interfaces de programmation d'applications (API)
pour travailler avec du texte, des dates, des expressions régulières, des structures de données standard
et le modèle objet de document (DOM).
ReactJS : React (également connu sous le nom de React.js ou ReactJS) est une
bibliothèque JavaScript Frontend open source permettant de créer des interfaces
utilisateur ou des composants d'interface utilisateur. Il est maintenu par Facebook et une
communauté de développeurs individuels et d'entreprises. React peut servir de base au

développement d'applications monopages (SPA) ou mobiles. Cependant, React ne concerne que la gestion
de l'état et le rendu de cet état au DOM, donc la création d'applications React nécessite généralement
l'utilisation de bibliothèques supplémentaires pour le routage, ainsi que certaines fonctionnalités côté
client.
Redux : c’est une bibliothèque JavaScript open source pour la gestion de l'état de l'application.
Il est le plus souvent utilisé avec des bibliothèques telles que React ou Angular pour créer des
interfaces utilisateur. Semblable à (et inspiré par) l'architecture Flux de Facebook, il a été créé
par Dan Abramov et Andrew Clark.
Webpack : c’est un bundler de modules JavaScript open source. Il est principalement conçu
pour JavaScript, mais il peut transformer des actifs Frontend tels que HTML, CSS et des images
si les chargeurs correspondants sont inclus. Webpack prend des modules avec des
dépendances et génère des actifs statiques représentant ces modules.
Webpack prend les dépendances et génère un graphe de dépendances permettant aux développeurs Web
d'utiliser une approche modulaire à des fins de développement d'applications Web. Il peut être utilisé à
partir de la ligne de commande ou peut être configuré à l'aide d'un fichier de configuration nommé
webpack.config.js. Ce fichier est utilisé pour définir des règles, des plugins, etc., pour un projet. (Webpack
est hautement extensible via des règles qui permettent aux développeurs d'écrire des tâches
personnalisées qu'ils souhaitent effectuer lors du regroupement de fichiers.)
Remarque : Node.js est requis pour utiliser Webpack.
Babel : est un transcompilateur JavaScript gratuit et open source qui est

principalement utilisé pour convertir le code ECMAScript 2015+ (ES6+) en une
version rétro compatible de JavaScript pouvant être exécutée par des moteurs
JavaScript plus anciens. Babel est un outil populaire pour utiliser les dernières fonctionnalités du langage
de programmation JavaScript.
Les développeurs peuvent utiliser les nouvelles fonctionnalités du langage JavaScript en utilisant Babel
pour convertir leur code source en versions de JavaScript que les navigateurs Web sont capables de
traiter.
Babel fournit des polyfills pour prendre en charge les fonctionnalités qui sont totalement absentes des
environnements JavaScript. Par exemple, les méthodes statiques comme Array.from et intégrées comme
Promise ne sont disponibles que dans ES6+, mais elles peuvent être utilisées dans des environnements
plus anciens si un polyfill Babel est utilisé.

Sass : c’est un langage de script de préprocesseur qui est interprété ou compilé dans
des feuilles de style en cascade (CSS). SassScript est le langage de script lui-même.
Sass se compose de deux syntaxes. La syntaxe d'origine, appelée "syntaxe en retrait",

utilise une syntaxe similaire à Haml. Il utilise l'indentation pour séparer les blocs de
code et les caractères de nouvelle ligne pour séparer les règles. La nouvelle syntaxe, "SCSS" (Sassy CSS),
utilise une mise en forme par blocs comme celle de CSS. Il utilise des accolades pour désigner des blocs
de code et des points-virgules pour séparer les règles au sein d'un bloc. La syntaxe en retrait et les fichiers
SCSS portent traditionnellement les extensions .sass et .scss, respectivement.
I18next : c’est un Framework d'internationalisation écrit en et pour JavaScript. Il est très

populaire pour le navigateur ou tout autre environnement javascript (par exemple
Node.js, Deno).
i18next fournit :
• Connexion flexible au backend (chargement des traductions via XHR, ...)

• Mise en cache optionnelle, détection de la langue de l'utilisateur, ...
• Des pluralisations appropriées
• Contexte de traduction
• Imbrication, Remplacement variable
• Flexibilité : utilisez-le partout
• Extensibilité : par ex. sprinter
• ...
5. Outils et technologies utilisés pour la qualité de code
SonarQube : (anciennement Sonar) est une plate-forme open source développée par
SonarSource pour une inspection continue de la qualité du code afin d'effectuer des
examens automatiques avec analyse statique du code afin de détecter les bugs, les
"Code Smells" et les failles de sécurité sur plus de 20 langages de programmation.
SonarQube propose des rapports sur le code dupliqué, les normes de codage, les tests unitaires, la
couverture du code, la complexité du code, les commentaires, les bugs et les vulnérabilités de sécurité.
SonarQube peut enregistrer l'historique des métriques et fournit des graphiques d'évolution. SonarQube
fournit une analyse et une intégration entièrement automatisées avec Maven, Ant, Gradle, MSBuild et
des outils d'intégration continue (Atlassian Bamboo, Jenkins, Hudson, etc.).

Enzyme : c’est un utilitaire de test JavaScript pour React qui facilite le test de la sortie des
composants React. Il sert également à manipuler, parcourir et, à certains égards, simuler le
temps d'exécution en fonction de la sortie. L'API d'Enzyme se veut intuitive et flexible en
imitant l'API de jQuery pour la manipulation et la traversée du DOM.
Jest : c’est un Framework de test JavaScript maintenu par Facebook, conçu et construit par
Christoph Nakazawa en mettant l'accent sur la simplicité et la prise en charge des grandes
applications Web. Il fonctionne avec des projets utilisant Babel, TypeScript, Node.js, React,
Angular, Vue.js et Svelte. Jest ne nécessite pas beaucoup de configuration pour les nouveaux
utilisateurs d'un Framework de test.
ESLint : c’est un outil d'analyse de code statique pour identifier les modèles
problématiques trouvés dans le code JavaScript. Il a été créé par Nicholas C. Zakas en 2013.
Les règles dans ESLint sont configurables et des règles personnalisées peuvent être
définies et chargées. ESLint couvre à la fois les problèmes de qualité du code et de style
de codage. ESLint prend en charge les normes actuelles d'ECMAScript et la syntaxe expérimentale des
projets de normes futures. Le code utilisant JSX ou TypeScript peut également être traité lorsqu'un plugin
ou un transpiler est utilisé.
6. Outils et technologies utilisés pour la solution OCR
OpenCV est une bibliothèque de fonctions de programmation principalement destinées à la

vision par ordinateur en temps réel. Développé à l'origine par Intel, il a ensuite été soutenu
par Willow Garage puis Itseez. La bibliothèque est multiplateforme et gratuite pour une
utilisation sous la licence open source Apache 2. À partir de 2011, OpenCV propose une
accélération GPU pour les opérations en temps réel.
Asprise Scanner.js : c’est un outil qui permet à n'importe quelle page

Web d'acquérir des images à partir de scanners et de webcams TWAIN
WIA à l'aide de JavaScript dans la plupart des navigateurs de bureau
comme IE, Chrome, Firefox et plus encore. Dans de nombreux cas, l'installation d'un logiciel comme le
plug-in ActiveX n'est pas requise et l'utilisateur peut profiter d'une excellente expérience de numérisation.
Nous avons utilisé cet outil pour récupérer l’image scannée depuis le matériel (implémente) et l’utiliser
dans la solution OCR.

7. Outils et environnement de travail
IntelliJ IDEA : c’est un environnement de développement intégré (IDE) écrit en Java pour le
développement de logiciels informatiques. Il est développé par JetBrains (anciennement
connu sous le nom d'IntelliJ) et est disponible sous forme d'édition communautaire sous
licence Apache 2 et dans une édition commerciale propriétaire. Les deux peuvent être utilisés
pour le développement commercial.
Git : c’est un logiciel de suivi des modifications dans n'importe quel ensemble de fichiers,
généralement utilisé pour coordonner le travail entre les programmeurs développant en
collaboration le code source pendant le développement logiciel. Ses objectifs incluent la
vitesse, l'intégrité des données et la prise en charge des flux de travail distribués et non
linéaires (des milliers de branches parallèles s'exécutant sur différents systèmes).
Git a été créé par Linus Torvalds en 2005 pour le développement du noyau Linux, avec d'autres
développeurs de noyau contribuant à son développement initial. Depuis 2005, Junio Hamano est le
mainteneur principal. Comme avec la plupart des autres systèmes de contrôle de version distribués, et
contrairement à la plupart des systèmes client-serveur, chaque répertoire Git sur chaque ordinateur est
un référentiel à part entière avec un historique complet et des capacités complètes de suivi des versions,
indépendant de l'accès au réseau ou d'un serveur central. Git est un logiciel libre et open source distribué
sous la licence publique générale GNU version 2.
Bitbucket est un service de gestion de référentiel Git spécialement développée pour les
équipes professionnelles. Le hub central pour gérer tous les référentiels de git collabore sur
le code source et guide tout au long du cycle de développement logiciel. C'est une section
de la famille Atlassian avec des outils tels que Confluence, Jira et d'autres pour aider les
équipes techniques à explorer tout le potentiel. Le déploiement de Bitbucket se fait en trois options
différentes. Il s'agit du cloud Bitbucket, du centre de données Bitbucket et du serveur Bitbucket.
8. Conclusion
Ce chapitre a été consacré à la présentation de l'environnement de travail de notre projet. Nous avons
présenté les différentes technologies que nous avons mises en place pour réaliser notre application. Dans
le chapitre suivant, nous présentons la partie implémentation du système.

CHAPITRE 5 :
Mise en œuvre
✓ Introduction
✓ Rapport de la qualité de code
✓ Aperçu des interfaces graphiques du système OCR
✓ Conclusion

1. Introduction
Dans ce je vais aborder la façon dont j’ai mis en œuvre les différentes solutions du projet en donnant les
interfaces graphiques les plus importantes.
2. Rapport de la qualité de code

La première mission sur laquelle j'ai travaillé, aux côtés de l'équipe frontend, visait à améliorer la qualité
du code du projet Frontend, nous avons vu dans le deuxième chapitre de ce rapport (figure 2.1) que le
rapport SonarQube dépendait de certaines métriques, mais ces métriques ne répondaient pas aux valeurs
recherchées. La figure 5.1 illustre le résultat obtenu après l'ajout de tests unitaires et l'élimination de
certains bogues dans le projet.
Figure 5.1 : Rapport de SonarQube après l’amélioration de la qualité de code
Ci-dessous un tableau comparant les résultats avant et après l’amélioration :
Métrique La valeur avant La valeur après

Couverture des tests unitaires 25.8 % 84.2%
Code Smells 644 155
Bugs 7 3
Tableau 6 : Comparaison des métriques de SonarQube avant et après l’amélioration

3. Aperçu des interfaces graphiques du système OCR
La première interface, (figure 5.2) illustre la nouvelle vue de la page de souscription, dans cette interface,
nous avons mis l’accent sur l’animation qui montre à l’utilisateur comment positionner la carte d’identité
du client pour la scanner
Figure 5.2 : Interface de souscription avant le scan de la carte nationale
Afin de scanner la carte, l’agent devra positionner la carte nationale dans le scanner de la même manière
démontrée dans le GIF au centre de l’interface, puis il clique sur le bouton "Lancer scan". L’image
s’affichera par la suite dans le cadre à la droite. L’agent devra répeter cet action pour le verso de la carte
aussi.
La figure 5.3 montre la vue de la même interface après avoir scanné les deux côtés de la carte nationale :

Figure 5.3 : Interface de souscription après le scan de la carte nationale
Après avoir prévisualisé le résultat de l'analyse, l'agent le soumet pour récupérer les informations de la
CIN dans le formulaire (figure 5.4).
Figure 5.4 : Formulaire de souscription après récupération des informations par OCR.

Les deux faces de la CIN doivent être jointe à la demande pour la vérification de conformité des
informations, c’est pour cela qu’on utilise les mêmes images résultantes du scan comme des pièces
jointes, avec possibilité d’ajouter d’autres documents en cliquant sur le bouton (+).
Remarque : tant que la fonctionnalité de l’OCR est activée, l’ajout d’autres PJ devra passer par le
processus du scan aussi.
Figure 5.5 : prévisualisation des pièces jointes dans le formulaire de souscription
Nous avons aussi ajouté la possibilité d’agrandir les images pour la vérification, avec possibilité de les
télécharger. (Figure 5.6).
Figure 5.6 : prévisualisation d’une pièce jointe en taille réelle

Après avoir soumis la demande, une interface contenant un récapitulatif des informations s’affichera
pour la confirmation, (figure 5.7). Dans cette interface, l’agent peut soit annuler la demande, confirmer
la création, ou modifier les infos en cas d’erreur.
Figure 5.7 : Interface montrant un récapitulatif de la demande avant la confirmation
La figure 5.8 illustre une liste des demandes rejetées par l’agent chargé de la révision des demandes, ces
demandes devront être modifié par l’agent souscripteur selon les remarques données, et les soumettre
à nouveau.
Figure 5.8 : Interface contenant la liste des demandes de souscription rejetées

4. Conclusion :
La dernière partie était dédiée à la navigation dans la plateforme. Elle constitue le dernier volet de ce
rapport, elle a pour objectif de décrire les principales fonctionnalités implémentées suite au
développement par des captures d’écran témoignant des différentes interfaces que contient notre
plateforme.

Conclusion générale et perspectives
En un mot, ce stage a été une expérience excellente et enrichissante. Je peux conclure que j'ai beaucoup
appris de mon travail chez Adria Business & Technology. J'ai acquis de nouvelles connaissances,
compétences et rencontré beaucoup de nouvelles personnes. J'ai atteint plusieurs de mes objectifs
d’apprentissage et j'ai eu un aperçu de la pratique professionnelle.
1. Résumé des objectifs achevés :

Dans ce stage, j'ai rejoint l'entreprise en tant que stagiaire Frontend, j'ai donc intégré une équipe qui avait
beaucoup de tâches liées au projet Frontend d'Adria. J’ai donc participé à la réalisation de ces tâches en
commençant par l'amélioration de la qualité du code, où j'ai dû écrire des tests unitaires afin d'augmenter
le pourcentage de couverture, pour ce faire, j'ai utilisé certaines technologies que j'ai découvertes pour la
première fois, comme Jest, Enzyme, Eslint, ..., puis j'ai dû travailler à éliminer les Code Smells qui étaient
trop nombreuses, ce n'était pas si facile car je devais m'assurer que les modifications que je fais
n'affecteront pas le travail du programme.
La deuxième mission que j’avais pour le stage consistait à mettre en œuvre une solution démo de
l’application web d’Adria, cette solution permettrait aux développeurs Frontend de travailler sans
dépendre du serveur Backend, ce qui leur fera gagner du temps car les serveurs sont parfois en panne ou
très lents à répondre.
Pour réaliser cette solution, j'ai dû travailler avec des fichiers JSON et le stockage local du navigateur où
j'ai stocké les réponses moquées du serveur, donc lorsqu'une demande est faite à partir du projet frontal,
la réponse sera chargée à partir du fichier correspondant.
Bien que je n’aie pas travaillé avec de nouvelles technologies dans cette tâche, c'était très important pour
m'aider à comprendre la structure du projet et la forme des réponses Backend.
La troisième mission du stage a été la plus intéressante pour moi, car là où j'ai commencé à développer
de vrais modules dans le projet, la mission consistait à implémenter la technologie de reconnaissance
optique de caractères pour récupérer les informations personnelles des clients depuis la carte d’identité
nationale, et les utiliser pour créer une demande de souscription. Pour réaliser cette tâche j’ai travaillé
avec l’outil Scanner JS afin de récupérer l’image issue du scan, et OpenCV pour recadrer l’image afin de
minimiser sa taille.
2. Perspectives :
Dans chaque projet, il doit y avoir des parties qui n'ont pas été faites, soit à cause du temps,
l’indisponibilité des moyens de travail, ou pour toute autre raison possible. Mon projet n'est pas une
exception, en fait, il y a des objectifs que nous n'avons pas encore pu atteindre, mais qui seront traités
dans les plus brefs délais soit par moi, ou par quelqu'un d'autre de l'équipe Frontend.

Parmi ses objectives, je site :
• Le rapport sur la qualité du code n'a pas été complètement amélioré comme nous le souhaitions,
car il y a toujours du nouveau code écrit, ce qui signifie qu'il y aura toujours de nouvelles
duplications, bugs et vulnérabilités. De plus, certains modules n'ont pas été terminés, ce qui rend
très difficile l'amélioration à moins qu'ils ne soient terminés, et c'est pourquoi il restait des
problèmes dans le rapport (figure 5.1) jusqu'à présent.
• La solution de démonstration que nous avons implémentée ne couvre pas tous les modules du
projet, c'est pour la même raison que j'ai mentionnée précédemment, il y a toujours de nouveaux
modules et un nouveau code ajouté.

Webographie
• https://docs.sonarqube.org/latest/user-guide/concepts/
• https://www.omg.org/spec/UML/About-UML/
• https://en.wikipedia.org/wiki/React_(JavaScript_library)
• https://reactjs.org/docs/getting-started.html
• https://en.wikipedia.org/wiki/Redux_(JavaScript_library)
• https://redux.js.org/introduction/getting-started
• https://en.wikipedia.org/wiki/Babel_(transcompiler)
• https://en.wikipedia.org/wiki/Sass_(stylesheet_language)
• https://en.wikipedia.org/wiki/JavaScript
• https://en.wikipedia.org/wiki/SonarQube
• https://enzymejs.github.io/enzyme/
• https://en.wikipedia.org/wiki/Jest_(JavaScript_framework)
• https://en.wikipedia.org/wiki/ESLint
• https://en.wikipedia.org/wiki/IntelliJ_IDEA
• https://en.wikipedia.org/wiki/Git
• https://www.educba.com/what-is-bitbucket/
• https://github.com/i18next/i18next
• https://en.wikipedia.org/wiki/OpenCV
• https://asprise.com/document-scan-upload-image-browser/direct-to-server-php-asp.net-overview.html

Rapport de Stage PFE - Youssef Chaachai

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport de Stage PFE - Youssef Chaachai

Transféré par

Droits d'auteur :

Formats disponibles

Mémoire de projet de fin d'études

En vue de l’obtention du diplôme d’Ingénieur

Développement et restructuration des

Réalisé par : Sous la supervision de :

Soutenu le 28 juin 2021, devant le jury :

Pr. AIRAJ Mohammed : Professeur à la FSTG Marrakech

Année Universitaire : 2020/2021

A mon père Abdelaziz, en signe d’amour, et de gratitude pour tous les

A ma sœur et mes chers frères,

A tous mes proches et mes amis,

Je vous dédie ce travail en vous souhaitant un avenir éclatant et plein

MÉMOIRE DE PROJET DE FIN D’ÉTUDES – YOUSSEF CHAACHAI 3

Tout d'abord, je remercie respectueusement le directeur M. BEKKAR

Je remercie M. TARRAQ Mohammed, mon encadrant au sein

Mes remerciements également vont à M. AIRAJ Mohammed, mon

Finalement, je remercie tout le corps professoral et administratif de la

MÉMOIRE DE PROJET DE FIN D’ÉTUDES – YOUSSEF CHAACHAI 4

API Application Programming Interface

CIN Carte d’Identité Nationale

CSS Cascading Style Sheets

DOM Document Object Model

HAML HTML Abstraction Markup Language

HTML HyperText Markup Language

IDE Integrated Development Environment

IHM Interface Homme Machine

JSON JavaScript Object Notation

JSX JavaScript XML

OCR Optical Character Recognition

OpenCV Open-Source Computer Vision

SASS Syntactically Awesome Style Sheets

SDK Software Development Kit

SPA Single Page Application

UML Unified Modeling Language

XML eXtensible Markup Language

MÉMOIRE DE PROJET DE FIN D’ÉTUDES – YOUSSEF CHAACHAI 5

Tableau 5 : Les exigences techniques…………………………………………………………………………………………………….42

Tableau 6 : Comparaison des métriques de SonarQube avant et après l’amélioration…………………..………50

MÉMOIRE DE PROJET DE FIN D’ÉTUDES – YOUSSEF CHAACHAI 6

Figure 2.2 : Exemple des seuils de qualité requises pour un projet………………………………………………………..25

Figure 2.3 : Reconnaissance du texte dans une carte d’identité………………………………………………………….…28

Figure 2.4 : Besoins non fonctionnels…………………………………………………………………………………………………….29

Figure 3.3 : Diagramme de cas d’utilisation pour l’administrateur de l’agence………………………………………35

Figure 3.4 : Diagramme de séquence : préparation de la demande de souscription avec OCR……………….36

Figure 3.5 : Diagramme de séquence : préparation de la demande de souscription sans OCR……………….37

Figure 3.6 : Diagramme de séquence : Soumission de la demande de souscription……………………………….38

Figure 3.7 : Diagramme d’activité : Processus de la demande de souscription ………………………………………39

Figure 4.1 : Architecture générale du projet frontend d’Adria……………………………………….………………………43

Figure 5.1 : Rapport de SonarQube après l’amélioration de la qualité de code………………………………………50

Figure 5.2 : Interface de souscription avant le scan de la carte nationale………………………………………………51

Figure 5.3 : Interface de souscription après le scan de la carte nationale………………………………………………52

Figure 5.5 : prévisualisation des pièces jointes dans le formulaire de souscription………………………………..53

Figure 5.6 : prévisualisation d’une pièce jointe en taille réelle……………………………………………………………….53

Figure 5.7 : Interface montrant un récapitulatif de la demande avant la confirmation…………………………..54

Figure 5.8 : Interface contenant la liste des demandes de souscription rejetées……………………………………54

MÉMOIRE DE PROJET DE FIN D’ÉTUDES – YOUSSEF CHAACHAI 7

MÉMOIRE DE PROJET DE FIN D’ÉTUDES – YOUSSEF CHAACHAI 8

MÉMOIRE DE PROJET DE FIN D’ÉTUDES – YOUSSEF CHAACHAI 9

MÉMOIRE DE PROJET DE FIN D’ÉTUDES – YOUSSEF CHAACHAI 10

Mots clefs : Reconstruction, Digital Banking, Qualité de code, OCR.

Technologies : ReactJS, Redux, Webpack, SonarQube, Jest, Enzyme.

MÉMOIRE DE PROJET DE FIN D’ÉTUDES – YOUSSEF CHAACHAI 11

Keywords: Reconstruction, Digital Banking, Code quality, OCR.

Technologies: ReactJS, Redux, Webpack, SonarQube, Jest, Enzyme.