Rapport Abd Fateh 2022

Dédicace
Je dédie ce travail particulièrement :

Je remercie Dieu le tout puissant pour l’aide, le courage et la patience qu’il m’a accordé tout
au long de mon cursus...
À ma chère maman pour tous les sacrifices qu’elle m’a fait et pour tout le soutien qu’elle m’a
offert tout au long de mes études.
À mon cher papa pour ses encouragements et surtout pour son soutien financier et moral.
A mes soeurs pour leur présence toujours pour me supporter et m’encourager.
À mes amis et mes collègues que j’aime tant et qui ont toujours été présents pour m’encourager.
J’espère que notre amitié durera éternellement,
À tous ceux qui m’aiment et me supportent.
Abd Elfatteh Guesmi
i
Remerciements
La réalisation d’un projet de fin d’étude ne dépend pas d’une seule personne. Par ces quelques
lignes, nous tenons à remercier toutes les personnes qui ont participé de près ou de loin au bon
déroulement de ce projet.
Nos sincères remerciements vont aussi à monsieur Sabi Trabelsi, pour l’honneur qu’il nous fait
de présider notre jury de projet fin d’étude.
Nous tenons aussi à remercier monsieur Larousi Merehben, pour nous avoir fait l’honneur
d’être le rapporteur de ce travail. Nous le remercions pour son précieux commentaires et recom-
mandations.
Nos gratitudes vont également à notre encadreur madame Fairouz Fakhfakh pour l’aide et
les conseils concernant les missions évoquées dans ce rapport, qu’elle nous a apporté lors des
différents suivis. Jamais nous n’aurons pu réaliser ce travail de projet de fin d’études sans son
soutien. Nous la remercions particulièrement pour nous avoir guidée et conseillée dans une am-
biance, toujours, formidable. Nous avons beaucoup apprécié travailler à ses côtés tant sur le plan
scientifique que sur le plan humain.
Un grand merci est également adressé à monsieur Mohamed Ali Ayachi, directeur de l’ISMAI
de Kairouan, qui n’a cessé de nous encourager durant nos deux années de Mastère.
Nous n’oublions pas non plus tous nos enseignants, à l’ISMAI de Kairouan qui ont su nous faire
aimer le domaine informatique et favoriser l’atteinte d’un niveau de connaissances techniques et
méthodologiques tel, qu’il nous a permis de mener à bien nos travaux de fin d’étude.
Finalement, Nous tenons à remercier les personnes qui m’ont soutenue, supportée, poussée à
aller de l’avant.
ii
Table des matières
Introduction générale 1
1 Étude préalable et spécification des besoins 3

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Cadre général . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.1 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4.3 Objectif du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5 Spécification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5.2 Les besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5.2.1 Les besoins fonctionnels liés au client . . . . . . . . . . . . . 11
1.5.2.2 Les besoins fonctionnels liés à l’administrateur . . . . . . . . . 12
1.5.3 Les besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 12
1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2 Analyse et conception 14
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 Choix du langage de modélisation et de méthodologie de développement . . . . . 15
2.2.1 Choix du langage de modélisation . . . . . . . . . . . . . . . . . . . . . 15
iii
2.2.2 Méthodologie de développement adoptée . . . . . . . . . . . . . . . . . 16
2.2.2.1 Cycle de vie d’un logiciel . . . . . . . . . . . . . . . . . . . . 16
2.2.2.2 Le modèle en cascade . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Diagrammes de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4 Spécification fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.1 Raffinement des cas d’utilisation du client . . . . . . . . . . . . . . . . . 21
2.4.2 Raffinement des cas d’utilisation de l’agent . . . . . . . . . . . . . . . . 28
2.4.3 Raffinement des cas d’utilisation de l’administrateur . . . . . . . . . . . 29
2.5 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.6 Les diagrammes de séquences . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.6.1 Cas d’utilisation “S’authentifier” . . . . . . . . . . . . . . . . . . . . . . 34
2.6.2 Cas d’utilisation “Voir les transactions” . . . . . . . . . . . . . . . . . . 35
2.6.3 Cas d’utilisation “Transférer de l’argent” . . . . . . . . . . . . . . . . . 36
2.6.4 Cas d’utilisation “Localiser filiale” . . . . . . . . . . . . . . . . . . . . . 37
2.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3 Réalisation 39
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2.2.1 Star UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2.2.2 MongoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.2.2.3 Postman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2.2.4 Visual Studio Code . . . . . . . . . . . . . . . . . . . . . . . 43
3.2.2.5 Laravel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.2.2.6 Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.2.2.7 Android Studio . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2.2.8 Overleaf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
iv
3.2.2.9 Le langage d’édition de document : Latex . . . . . . . . . . . 46
3.3 Les interfaces d’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.3.1 Partie web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.3.1.1 Interface “Accueil pour l’administrateur” . . . . . . . . . . . . 47
3.3.1.2 Interface “Relation clientèle” . . . . . . . . . . . . . . . . . . 47
3.3.1.3 Interface “Gestion des demandes” . . . . . . . . . . . . . . . . 48
3.3.1.4 Interface “Ajouter filiale” . . . . . . . . . . . . . . . . . . . . 49
3.3.1.5 Interface “Détail filiale” . . . . . . . . . . . . . . . . . . . . . 50
3.3.1.6 Interface ≪ Ajouter agent ≫ . . . . . . . . . . . . . . . . . . . 51
3.3.1.7 Interface “Accueil pour l’agent” . . . . . . . . . . . . . . . . . 52
3.3.1.8 Interface “Ajouter compte” . . . . . . . . . . . . . . . . . . . 53
3.3.2 Partie mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.3.2.1 Interface “Accueil” . . . . . . . . . . . . . . . . . . . . . . . 54
3.3.2.2 Interface “Espace public” . . . . . . . . . . . . . . . . . . . . 55
3.3.2.3 Interface “Simuler crédit” . . . . . . . . . . . . . . . . . . . . 56
3.3.2.4 Interface “Connexion” . . . . . . . . . . . . . . . . . . . . . . 57
3.3.2.5 Interface “Accueil Client” . . . . . . . . . . . . . . . . . . . . 58
3.3.2.6 Interface “Mes comptes” . . . . . . . . . . . . . . . . . . . . 59
3.3.2.7 Interface “Détail comptes” . . . . . . . . . . . . . . . . . . . 60
3.3.2.8 Interface “Payer facture” . . . . . . . . . . . . . . . . . . . . 61
3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Conclusion et perspectives 63
v
Table des figures
1.1 Logo de l’institut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2 Interface de Attijari Bank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Interface de Banque de Tunisie . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Interface de Chase Bank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5 Interface BNP Paribas Bank . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6 Avis des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1 Modèle en cascade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2 Diagramme de cas d’utilisation pour l’administrateur . . . . . . . . . . . . . . . 19
2.3 Diagramme de cas d’utilisation pour l’agent . . . . . . . . . . . . . . . . . . . . 20
2.4 Diagramme de cas d’utilisation pour le client . . . . . . . . . . . . . . . . . . . 20
2.5 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.6 Diagramme de séquence du cas d’utilisation “S’authentifier” . . . . . . . . . . . 34
2.7 Diagramme de séquence du cas d’utilisation “Voir les transactions” . . . . . . . . 35
2.8 Diagramme de séquence du cas d’utilisation “Transférer de l’argent” . . . . . . . 36
2.9 Diagramme de séquence du cas d’utilisation “Localiser filiale” . . . . . . . . . . 37
3.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.2 Logo de Star UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.3 Logo de Mongo DB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.4 Logo de Postman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.5 Logo de Visual Studio Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
vi
3.6 Logo de Laravel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.7 Logo de Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.8 Logo d’Android Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.9 Logo d’Overleaf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.10 Interface “Accueil pour l’administrateur” . . . . . . . . . . . . . . . . . . . . . . 47
3.11 Interface “Relation clientèle” . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.12 Interface “Gestion des demandes” . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.13 Interface “Ajouter filiale” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.14 Interface “Détail filiale” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.15 Interface “Ajouter agent” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.16 Interface “Accueil pour l’agent” . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.17 Interface “Ajouter compte” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.18 Interface “Accueil” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.19 Interface “Espace public” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.20 Interface “Simuler crédit” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.21 Interface “Connexion” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.22 Interface “Accueil Client” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.23 Interface “Mes comptes” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.24 Interface “Détail comptes” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.25 Interface “Payer facture” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
vii
Liste des tableaux
2.1 Description textuelle du cas d’utilisation ”S’authentifier” . . . . . . . . . . . . . 22

2.2 Description textuelle du cas d’utilisation”Effectuer une demande” . . . . . . . . 23
2.3 Description textuelle du cas d’utilisation ”Voir les transactions” . . . . . . . . . 24
2.4 Description textuelle du cas d’utilisation ”Transférer de l’argent” . . . . . . . . 25
2.5 Description textuelle du cas d’utilisation “Contacter l’administrateur” . . . . . . 26
2.6 Description textuelle du cas d’utilisation ”Simuler un crédit” . . . . . . . . . . . 27
2.7 Description textuelle du cas d’utilisation “Voir l’échange des devises” . . . . . . 27
2.8 Description textuelle du cas d’utilisation ”Gestion des comptes” . . . . . . . . . 28
2.9 Description textuelle du cas d’utilisation ”Gestion des clients” . . . . . . . . . . 29
2.10 Description textuelle du cas d’utilisation”Gestion des demandes” . . . . . . . . 30
2.11 Description textuelle du cas d’utilisation ”Gestion des relations clientèles” . . . 31
viii
Introduction générale
Le marché des technologies a connu une énorme évolution ces dernières années. En plus,
avec l’intégration de l’internet, il y a eu des changements sur la façon et la rapidité d’accès aux
informations. Plusieurs secteurs se sont adaptés à ce changement pour satisfaire ces nouveaux
clients. Les banques représentent l’un des secteurs qui ont un énorme nombre de clients et qui
souffrent pour répondre à leurs besoins. Ils doivent alors disposer leurs services d’une manière
plus rapide et sécurisée mais aussi à distance afin de pouvoir éviter l’encombrement dans les
agences.
Avec l’apparition des appareils mobiles, comme les smartphones et les tablettes qui ont
connu une révolution technologique, il est devenu facile pour une banque de gérer ces problèmes
en proposant une application mobile capable d’offrir des services indispensables rapidement et
à tout moment. Dans ce contexte, notre projet consiste à développer une application bancaire
mobile qui offre plusieurs fonctionnalités à l’utilisateur ainsi qu’une application web qui sert
à gérer les services clientèle. Ce rapport décrit les étapes de développement de notre projet. Il
contient trois chapitres :
Le premier chapitre sera consacré à la présentation générale du projet. En effet, nous

identifierons les problèmes existants, les critiques et les objectifs à atteindre. Par la suite, nous
présenterons les besoins fonctionnels et non fonctionnels de notre application.
1
Introduction générale
Le deuxième chapitre sera consacré à la modélisation conceptuelle de notre application.
Le dernier chapitre consiste à présenter la partie développement du système et décrire les

différentes fonctionnalités de notre application. En outre, nous présenterons les démarches tech-
niques pour la réalisation de l’application ainsi que l’environnement et les outils utilisés.
Finalement, notre rapport se clôturé par une conclusion générale et quelques perspectives que
nous visions les réaliser dans le futur.
2
C HAPITRE
1 Étude préalable et spécification des besoins
Sommaire
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Cadre général . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . 4
1.4 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.1 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4.3 Objectif du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5 Spécification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5.2 Les besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5.3 Les besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . 12
1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3
Chapitre 1. Étude préalable et spécification des besoins
1.1 Introduction
Au niveau de ce chapitre, nous allons présenter le cadre général de notre projet et une
étude préalable de ce dernier. En premier lieu, nous allons présenter l’organisme d’accueil et
une étude de l’existant. En deuxième lieu, nous allons présenter la spécification des besoins pour
notre projet.
1.2 Cadre général

Ce stage a été effectué dans le cadre d’un projet de fin d’études pour l’obtention du diplôme de
¡¡ Mastère Professionnel en Administration et Sécurité des Systèmes Informatiques et Réseaux¿¿.
Ce stage est réalisé au sein de l’institut supérieur des mathématiques appliquées et de l’informa-
tique qui nous a proposé de concevoir une application Web mobile pour Amen Bank.
1.3 Présentation de l’organisme d’accueil

L’Institut Supérieur des Mathématiques Appliquées et d’Informatique de Kairouan (IS-
MAIK) est un établissement d’enseignement supérieur, rattaché à l’université de Kairouan, sous
la tutelle du ministère de l’enseignement Supérieur et de la recherche scientifique. Depuis sa
création en 2006, l’ISMAI s’est démarqué par l’enseignement de filières d’avenir consciente du
contexte technologique fortement évolutif.
Cet institut s’est construit et se maintient grâce au dynamisme incontestable de son corps
enseignant ainsi que son corps administratif pour pouvoir offrir aux étudiants l’environnement
adéquat pour poursuivre leurs études en toute sérénité et se concentrer sur l’acquisition des
connaissances et des compétences qui leurs permettront une meilleure insertion profession-
nelle après l’obtention des diplômes. Cette offre pédagogique ne cesse d’évoluer d’année en
année dans un soucis permanent d’améliorer la qualité, le dynamisme des échanges ensei-
gnants/étudiants ou aussi l’échange avec l’administration, d’instaurer des traditions et ceci dans
un but unique : pouvoir dans un futur proche certifier les parcours pour pouvoir survivre dans un
4
contexte de plus en plus mondialisé.

Le logo de notre institut est présenté dans la figure 1.1 .
F IGURE 1.1 – Logo de l’institut
1.4 Présentation du projet

Nous décrivons dans cette section l’étude de l’existant, les critiques de l’existant ainsi que la
solution proposée.
1.4.1 Étude de l’existant
Il est indispensable avant de réaliser un projet, de bien étudier et analyser des projets simi-
laires pour bien profiter des avantages et éviter les inconvénients dans notre projet.
Toutes les descriptions sont prises de l’adresse électronique [1].
5
❖ Solutions disponibles en Tunisie

➥ Attijari Bank
Attijari Mobile présente une application facile à utiliser avec une interface accueillante et qui
offre les services suivants :
• Consultation en temps réel des soldes de vos comptes ;
• Historique de vos mouvements sur six mois ;
• Recherche multi-critères des opérations (par date, par montant) ;
• Commande de chéquier ;
• Changement de votre mot de passe ;
• Consultation des cours des principales devises ;
• Virement d’un compte au compte Attijari bank ou autre banque (optionnel).
La figure 1.2 représente l’interface de l’application mobile de Attijari Bank.
F IGURE 1.2 – Interface de Attijari Bank
6
➥ Banque de Tunisie
Aussi, Banque de Tunisie offre une application riche en fonctionnalités avec une interface convi-
viale. Parmi les services offerts, nous citons :
• Afficher les soldes et les mouvements de vos comptes en balayant simplement l’écran avec
le doigt ;
• Virer des fonds entre vos comptes ;
• Visualiser les transactions faites par vos cartes ;
• Paramétrer vos cartes internationales pour activer des achats à l’étranger en fonction de
vos voyages évitant tout risque de fraude ;
• Suivre vos chèques et visualiser leurs images ;
• Commander un chéquier ;
• Consulter votre portefeuille titres ;
• Consulter vos encours de crédits ;
• Repérer la succursale le plus proche de vous.
La figure 1.3 représente l’interface de l’application mobile de Banque de Tunisie.

❖ Solutions Mondiales
➥ Chase Mobile
Chase est une banque américaine qui offre la meilleure application bancaire à service complet
selon la magazine “Forbes”. Cette application offre un énorme nombre de fonctionnalités avec
une interface moderne est conviviale. La figure 1.4 représente l’interface de l’application mobile
de Chase Bank.
7
F IGURE 1.3 – Interface de Banque de Tunisie
F IGURE 1.4 – Interface de Chase Bank
8
➥ BNP Paribas
La banque française BNP Paribas offre une application très moderne et pleine de fonctionnalités.
La figure 1.5 représente l’interface de l’application mobile de BNP Paribas Bank.
F IGURE 1.5 – Interface BNP Paribas Bank
1.4.2 Critique de l’existant
D’après la section précédente, nous avons constaté que toutes les banques (selon un volet
national ou international) ont toujours investis dans le développement de ses applications mobiles
pour satisfaire leurs clients. Dans cette section, nous allons étudier l’application proposée par
Amen Bank ainsi que les services proposés pour bien prendre une décision technique. La figure
1.6 illustre les différents avis des différents utilisateurs de l’application de Amen Bank et les
services offerts par cette application.
D’après les avis des utilisateurs, cette application manque beaucoup de services, aussi les
interfaces sont mal fait et l’expérience utilisateur est faible. Nous allons présenter ci-dessous une
critique fonctionnel de l’application :
9
• L’authentification ne s’effectue pas dès la première fois.
• Il est impossible de faire une transaction à partir de l’application mobile.
• Il y’a une Absence de la géolocalisation.
• Il n’y a pas d’une possibilité de demander une carte bancaire ou un chéquier.
F IGURE 1.6 – Avis des utilisateurs
1.4.3 Objectif du projet
L’idée de ce projet est de réaliser une application mobile qui satisfait les besoins du client et
lui fait gagner du temps pour ne pas se présenter aux agences. Par conséquent, l’objectif consiste
à développer une application mobile conviviale et moderne qui propose plusieurs fonctionnalités
bancaires. Nous proposons aussi une application web pour la partie administrative de la gestion
des services proposés par la partie mobile.
10
1.5 Spécification
Après avoir mené une étude de l’existant dans la section précédent, nous avons pu déceler
une grande partie des problèmes que nous voulons résoudre ainsi que les améliorations que nous
pourrons apporter à la (aux) solution(s) que nous adapterons. La spécification des besoins est
une étape essentielle pour la réussite des projets. C’est dans cet esprit que tout concepteur doit
veiller à la conformité de son application aux spécifications d’utilisateur. A ce stade intervient
la spécification des besoins qui est une sorte de contrat entre le concepteur, le développeur et
les clients, évitant ainsi tout risque de malentendu et de mauvaises surprises. Dans cette section,
nous définissons les besoins fonctionnels et non fonctionnels de cette solution afin qu’elle puisse
être la plus optimale possible.
1.5.1 Identification des acteurs
• Le client : c’est l’acteur principal de notre application. Il profite de toutes les fonctionna-
lités offertes par l’application.
• L’administrateur : le rôle de cet acteur est de gérer les comptes et les clients ainsi que la
gestion des demandes et de répondre aux messages envoyés par les utilisateurs.
1.5.2 Les besoins fonctionnels
Ce sont les actions et les réactions que le système doit faire suite à une action faite par un
acteur.
1.5.2.1 Les besoins fonctionnels liés au client
Toute l’application mobile est disponible au client pour lui permettre après l’authentification
par son identificateur urique et son mot de passe d’avoir accès aux différents services offerts :
• Consulter ses informations personnelles ainsi que son compte bancaire.
• Consulter l’historique de ses transactions.
11
• Transférer de l’argent.
• Payer des factures.
• Envoyer des demandes de carte de crédit ou de carnet de chèque.
Toutefois, un utilisateur sans authentification peut aussi bénéficier de certaines fonctionnalités :
• Contacter la banque
• Voir les filiales les plus proches.
• Convertir de la devise.
1.5.2.2 Les besoins fonctionnels liés à l’administrateur
Une application web est mise à la disposition de l’administrateur pour la gestion administra-
tive de l’application mobile, pareil que le client, après l’authentification il a accès à :
• La gestion des clients ainsi que les comptes bancaires.
• La gestion des demandes effectuées par les clients.
• La gestion de la relation clientèle.
1.5.3 Les besoins non fonctionnels
Pour réussir notre projet et pour qu’il soit compatible avec ces utilisateur, il faut bien vérifier
les contraintes suivantes de l’application :
• Ergonomie : L’interface de l’application doit être simple et utilisable afin que les utili-
sateurs puissent l’exploiter sans se référer à des connaissances particulières. En d’autre
termes, notre application doit être lisible et facile à manipuler par n’importe quel utilisa-
teur.
• Sécurité : L’application devra assurer la sécurité des utilisateurs. D’où, la nécessité de

procéder à l’authentification des agents et des administrateurs tout en assurant la confiden-
tialité de leurs données.
12
• L’extensibilité : C’est-à-dire qu’il doit y avoir une possibilité d’ajouter de nouvelles fonc-
tionnalités ou de modifier celles existantes.
• Rapidité et intégrabilité dans d’autres applications : L’application devra être rapide et as-
sure que les modules seront intégrables et utilisables dans d’autres applications.
• Besoins de haute disponibilité : Il est important que notre application puisse fonctionner
sur une plateforme hautement disponible et pouvant gérer un nombre élevé de requêtes.
• Fiabilité : L’ application doit avoir une bonne qualité de contenu ainsi qu’une bonne adap-
tabilité aux différentes tailles des écrans des appareils mobiles. D’ autre part, il faut assurer
le bon fonctionnement sans erreur.
1.6 Conclusion
Dans ce chapitre, nous avons présenté d’une part la description du cadre de stage à travers
une présentation générale de l’organisme d’accueil et d’autre part l’étude et la critique de l’exis-
tant ainsi que la solution proposée. Ainsi, ce chapitre nous a permis de livrer une spécification
complète des besoins. Donc, à la fin de ce chapitre nous avons obtenu une vue globale du système
en élaborant une architecture candidate.
13
C HAPITRE
2 Analyse et conception
Sommaire
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 Choix du langage de modélisation et de méthodologie de développement . . 15
2.2.1 Choix du langage de modélisation . . . . . . . . . . . . . . . . . . . . 15
2.2.2 Méthodologie de développement adoptée . . . . . . . . . . . . . . . . 16
2.3 Diagrammes de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4 Spécification fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.1 Raffinement des cas d’utilisation du client . . . . . . . . . . . . . . . . 21
2.4.2 Raffinement des cas d’utilisation de l’agent . . . . . . . . . . . . . . . 28
2.4.3 Raffinement des cas d’utilisation de l’administrateur . . . . . . . . . . 29
2.5 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.6 Les diagrammes de séquences . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.6.1 Cas d’utilisation “S’authentifier” . . . . . . . . . . . . . . . . . . . . . 34
2.6.2 Cas d’utilisation “Voir les transactions” . . . . . . . . . . . . . . . . . 35
2.6.3 Cas d’utilisation “Transférer de l’argent” . . . . . . . . . . . . . . . . 36
2.6.4 Cas d’utilisation “Localiser filiale” . . . . . . . . . . . . . . . . . . . . 37
2.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
14
Chapitre 2. Analyse et conception
2.1 Introduction
Dans ce chapitre, nous présentons la conception de notre projet. Cette partie a comme but
de décrire le comportement de notre solution. Elle permet de modéliser les fonctionnalités de la
solution de point de vue utilisateur. Pour avoir un bon résultat, nous utilisons les diagrammes de
cas d’utilisation qui sont nécessaires dans la modélisation orientée objet.
2.2 Choix du langage de modélisation et de méthodologie de

développement
2.2.1 Choix du langage de modélisation
Le développement de tout projet informatique nécessite l’utilisation d’une méthode de

développement qui englobe, normalement, un modèle de conception et des formalismes de
notations. Face à la diversité des formalismes utilisés par les méthodes d’analyse et de concep-
tion objet, nous avons décidé d’utiliser le langage de modélisation UML (Unified Modeling
Language).
UML(Unified Modeling Langage) se définit comme un langage de modélisation graphique

et textuel destiné à comprendre et décrire des besoins, spécifier et documenter des systèmes,
concevoir des solutions et communiquer des points de vue. UML définit des standards relatifs
à la modélisation objet. UML s’articule autour de neuf diagrammes différents, chacun d’eux
étant dédié à la représentation des concepts particuliers d’un système logiciel. Par ailleurs, UML,
modélise le système suivant deux modes de représentation : l’un concerne la structure du système
pris ≪ au repos ≫, l’autre concerne sa dynamique de fonctionnement. Les deux représentations
sont nécessaires et complémentaires pour schématiser la façon dont est composé le système et
comment ses composantes fonctionnent entre elles [2].
Le mode de représentation statique ou structurel s’appuie sur les quatre dia grammes suivants :
15
• diagramme de cas d’utilisation.
• diagramme d’objet.
• diagramme de classe.
• diagramme de composants.
• diagramme de déploiement.
Le mode de représentation dynamique ou comportemental s’appuie sur les diagrammes suivants :
• diagramme de collaboration.
• diagramme de séquence.
• diagramme d’activité.
• diagramme d’état transition.
Parmi les avantages de l’UML nous pouvons citer :
• UML est un langage formel et normalisé : il permet un gain de précision et de stabilité.
• UML est un support de communication performant : il permet grâce à sa représentation

graphique, d’exprimer visuellement une solution objet, de faciliter la comparaison et
l’évolution de solution.
• Son caractère polyvalent et sa souplesse en font un langage universel.
2.2.2 Méthodologie de développement adoptée
2.2.2.1 Cycle de vie d’un logiciel
Le “cycle de vie d’un logiciel” (en anglais software life cycle), désigne toutes les étapes du
développement d’un logiciel, de sa conception à sa disparition. L’objectif d’un tel découpage est
de permettre de définir des jalons intermédiaires permettant la validation du développement lo-
giciel. C’est-à-dire la conformité du logiciel avec les besoins exprimés, la vérification du proces-
sus de développement et l’adéquation des méthodes mises en oeuvre. L’origine de ce découpage
provient du constat que les erreurs ont un coût d’autant plus élevé qu’elles sont détectées tardi-
vement dans le processus de réalisation. Le cycle de vie permet de détecter les erreurs au plus
16
tôt et ainsi de maı̂triser la qualité du logiciel, les délais de sa réalisation et les coûts associés. Il
existe différents types de cycles de développement entrant dans la réalisation d’un logiciel. Ces
cycles prennent en compte toutes les étapes de la conception d’un logiciel. Les différents cycles
de vie sont le modèle en Cascade,le modèle en V, le modèle en W et le modèle en Spirale.
2.2.2.2 Le modèle en cascade
Pour réaliser notre projet, nous avons adopté le cycle de vie en cascade. Le modèle de cycle
de vie en cascade décrit en cette succession d’étapes qui sont représentés dans ce que suit (six
étapes fondamentales), La figure 2.1 illustre les différentes étapes du modèle en cascade.
F IGURE 2.1 – Modèle en cascade
L’avantage de ce modèle est de proposer, au fur et à mesure, une démarche de réduction des
risques, en minimisant l’impact des incertitudes. L’impact d’une incertitude dans la phase de
développement étant plus faible que l’impact d’une incertitude dans les phases de conception ou
de spécifications, plus le projet avance, plus les risques diminuent.
17
2.3 Diagrammes de cas d’utilisation

Les composants principaux de ces diagrammes sont :
• Acteur : Un être humain qui interagit avec le système où chaque acteur intervient à au
moins un cas d’utilisation .
• Cas d’utilisation : Description des interactions acteur-système permettant à un acteur d’at-

teindre sont objectif.
• Association : Reliant les acteur et les cas d’utilisation.
• Extension : Utilisé pour traiter des cas particuliers de façons optionnelles. Autrement dit,
une cas d’utilisation expulsé à un autre .
• Inclusion : Ce type de relation décrit un ensemble de sous-comportements communs à plu-

sieurs tâches. C’est-à-dire, un cas d’utilisation inclut un autre où l’exécution de la première
dépend obligatoirement de la deuxième.
La figure 2.2 représente le diagramme de cas d’utilisation pour l’administrateur.
18
19
F IGURE 2.2 – Diagramme de cas d’utilisation pour l’administrateur
La figure 2.3 représente le diagramme de cas d’utilisation pour l’agent.
F IGURE 2.3 – Diagramme de cas d’utilisation pour l’agent
La figure 2.4 représente le diagramme de cas d’utilisation pour le client.
F IGURE 2.4 – Diagramme de cas d’utilisation pour le client
20
2.4 Spécification fonctionnelle

Dans cette section, nous allons citer les descriptions textuelles qui décrivent les scénarios des
différents cas d’utilisation.
2.4.1 Raffinement des cas d’utilisation du client
La description textuelle détaillée du cas d’utilisation ”S’authentifier” est présentée dans la

table 2.1.
21
TABLE 2.1 – Description textuelle du cas d’utilisation ”S’authentifier”

Sommaire d’identification
Titre S’authentifier
Permettre au client de s’authentifier pour bénéficier des services de
Résumé
l’application.
Acteur Client
Description des enchaı̂nements
•Service web disponible.
Pré-condition
•Serveur de base de données disponible.
1)Le client saisit son identificateur et son mot de passe.
2)Le client clique sur le bouton connexion.
Scénario nominal
3)Le système vérifie les données de connexion.
4)Le client accède à son compte.
Alt-1) Champs vide :le système affiche le message d’erreur
≪ veuillez remplir vos données ≫
Alt-2) Identificateur invalide : le système affiche le message d’erreur
Scénarios alternatifs ≪ vérifier que l’id soit valide ≫
Alt-3) Mot de passe invalide le système affiche le message d’erreur
≪ Mot de passe incorrecte ≫
Alt-4) Service web ou serveur de base de données indisponible : le système affiche le me
Post-condition Le client est authentifié et accède à son compte.
La description textuelle détaillée du cas d’utilisation ”Effectuer une demande” est présentée
dans la table 2.2.
22
TABLE 2.2 – Description textuelle du cas d’utilisation”Effectuer une demande”

Titre Effectuer une demande.
Permettre au client de demander une carte de crédit ou un carnet
Résumé
de chèque.
Acteur Client
• Client authentifié.
Pré-condition
• Serveur de base de données disponible.
1)Le client rempli le formulaire de la demande.
Scénario nominal 2)Le client confirme sa demande.
3)Le système enregistre la demande dans la base de donnée
Alt-1)Le client possède déjà une demande équivalente.
Scénarios alternatifs Alt-2)Service web ou le serveur de base de données indisponible : le
système affiche le message d’erreur ≪Une erreur inattendue s’est produite≫
Post-condition Le client est informé par email et attend qu’un administrateur approuve sa
demande.
La description textuelle détaillée du cas d’utilisation ”Voir les transactions” est présentée
dans la table 2.3.
23
TABLE 2.3 – Description textuelle du cas d’utilisation ”Voir les transactions”

Titre Voir les transactions.
Permettre au client de consulter l’historique des transactions de l’un de ses
Résumé
comptes.
Acteur Client
• Client adhéré à un compte.
Pré-condition
• Service web disponible.
1)Le client choisit un compte.
Scénario nominal 2)Le client accède à la page des transactions.
3)Le système affiche l’historique des transactions de ce compte.
Alt-1)Pas de transaction pour ce compte : le système affiche un message
d’erreur ≪aucune donnée n’est trouvée≫.
Scénarios alternatifs
Alt-2)Service web ou le serveur de base de données indisponible : le
système affiche le message d’erreur ≪Une erreur inattendue s’est produite≫.
Post-condition Le client voit les détails de chaque transaction sélectionnée.
La description textuelle détaillée du cas d’utilisation ”Transférer de l’argent” est présentée

dans la table 2.4.
24
TABLE 2.4 – Description textuelle du cas d’utilisation ”Transférer de l’argent”

Titre Transférer de l’argent.
Résumé Permettre au client de transférer de l’argent d’un compte à un autre.
Acteur Client
• Client adhéré à un compte.
Pré-condition
• Service web disponible.
1)Le client remplit les champs de transfert.
2)Le client entre son code secret.
Scénario nominal 3)Le client confirme l’envoi.
4)Le système vérifie les données.
5)Le système effectue la transaction.
Alt-1)L’un des champs obligatoires est vide : le système affiche un message
d’erreur ≪veuillez remplir tous les champs obligatoires≫.
Alt-2)Le montant saisi est invalide : le système affiche un message d’erreur
≪ le montant doit être plus que 0.01 ≫.
Scénarios alternatifs
Alt-3)Le solde est insuffisant : le système affiche un message d’erreur
≪ Solde insuffisant≫.
Alt-4)Le service web ou le serveur de base de données indisponible : le
système affiche le message d’erreur ≪Une erreur inattendue s’est produite≫.
Post-condition Transaction effectuée.
La description textuelle détaillée du cas d’utilisation ”Contacter l’administrateur” est

présentée dans la table 2.5.
25
TABLE 2.5 – Description textuelle du cas d’utilisation “Contacter l’administrateur”

Titre Contacter l’administrateur
Résumé Permettre à l’utilisateur de l’application de contacter l’administrateur.
Acteur Client
•Service web disponible.
Pré-condition
1)Le client remplit le formulaire.
Scénario nominal 2)Le client envoie son message.
3)Le système enregistre le message dans la base de données.
Alt-1)Le service web ou le serveur de base de données est indisponible : le
Scénario alternatif
système affiche le message d’erreur “Une erreur inattendue s’est produite”
Post-condition Le client est informé par email et attend qu’un administrateur lui répondra.
La description textuelle détaillée du cas d’utilisation ”Simuler un crédit” est présentée dans
la table 2.6.
26
TABLE 2.6 – Description textuelle du cas d’utilisation ”Simuler un crédit”

Titre Simuler un crédit.
Permettre au client de simuler une demande de crédit en impliquant
Résumé
les taxes et les impôts.
Acteur Client
Description des enchainements
Pré-condition Application lancée.
1)Le client remplit les données de simulation de son choix.
Scénario nominal
2)Le client clique sur le bouton de génération.
Post-condition Le crédit est généré.
La description textuelle détaillée du cas d’utilisation “Voir l’échange des devises” est
TABLE 2.7 – Description textuelle du cas d’utilisation “Voir l’échange des devises”
Titre Voir l’échange des devises.
Permettre à l’utilisateur de visualiser l’échange entre
Résumé
les différentes devises du monde.
Acteur Client
Pré-condition Service des devises disponible.
1)Le client saisit le montant désiré.
Scénario nominal
2)Le système convertit ce montant en plusieurs devises.
Alt-1)Service des devises indisponible : le système affiche le message
d’erreur “Une erreur inattendue s’est produite”
Post-condition Le montant saisi par le client est converti en plusieurs devises.
27
2.4.2 Raffinement des cas d’utilisation de l’agent
La description textuelle détaillée du cas d’utilisation “Gestion des comptes” est présentée
dans la table 2.8.
TABLE 2.8 – Description textuelle du cas d’utilisation ”Gestion des comptes”

Titre Gestion des comptes
Permettre à l’agent d’ajouter, modifier, supprimer ou désactiver / activé
Résumé
un compte.
Acteur Agent
Pré-condition Agent authentifié.
1)L’agent voit la liste des comptes.
Scénario nominal
2)L’agent sélectionne le compte désiré.
Alt-1)Serveur de base de données indisponible : l’agent reçoit une liste
vide.
Post-condition L’agent gère le compte sélectionné.
La description textuelle détaillée du cas d’utilisation “Gestion des clients” est présentée dans
la table 2.9.
28
TABLE 2.9 – Description textuelle du cas d’utilisation ”Gestion des clients”

Titre Gestion des clients
Résumé Permettre à l’agent d’ajouter, modifier, supprimer un client.
Acteur Agent
Pré-condition Agent authentifié.
1)L’agent voit la liste des clients.
Scénario nominal
2)L’agent sélectionne le client désiré.
vide.
Post-condition L’agent gère le client sélectionné.
2.4.3 Raffinement des cas d’utilisation de l’administrateur
La description textuelle détaillée du cas d’utilisation ”Gestion des demandes” est présentée
dans la table 2.10.
29
TABLE 2.10 – Description textuelle du cas d’utilisation”Gestion des demandes”

Titre Gestion des demandes
Permettre à l’administrateur de gérer les demandes de carte de crédit
Résumé
ou des carnets de chèque envoyé par les clients.
Acteur Administrateur
Pré-condition Administrateur authentifié.
1)L’agent voit la liste des demandes.
Scénario nominale
2)L’agent sélectionne la demande désirée.
vide.
Post-condition L’administrateur approuve ou désapprouve la demande sélectionnée.
La description textuelle détaillée du cas d’utilisation ”Gestion des relations clientèles” est
30
TABLE 2.11 – Description textuelle du cas d’utilisation ”Gestion des relations clientèles”
Titre Gestion des relations clientèles
Résumé Permettre à l’administrateur de répondre aux différents besoins des clients.
Acteur Administrateur
Pré-condition Administrateur authentifié.
1)L’agent voit la liste des sujets.
Scénario nominal 2)L’agent sélectionne le sujet désiré.
3)L’administrateur répond au sujet sélectionné.
Alt-1)Le serveur de base de données est indisponible : l’agent reçoit une
liste vide.
Post-condition Le client reçoit sa réponse par email.
2.5 Diagramme de classes

Ce diagramme est classé comme un modèle statique du système, il sert à réaliser une
modélisation des relations entre les classes du système orienté objet. La figure 2.5 représente
le diagramme de classe de notre application.
31
F IGURE 2.5 – Diagramme de classes
32
• La classe “Filiale” : cette la classe représente les informations d’une agence.
• La classe “User” :cette la classe contient les informations des différents types de per-
sonnes.
• La classe “Agent” : cette une classe hérite de la classe “User” et comporte des attributs et
des opérations supplémentaires que sa classe mère qui ont rapport avec le banquier.
• La classe “Client” : cette une classe hérite de la classe ”User” et dispose des attributs et
des opérations supplémentaires concernant le client.
• La classe “Compte” : cette la classe comporte les informations générales d’un compte.
• La classe “Vérifier-compte” : cette une classe hérite de la classe “Compte” et contient les
attributs concernant le compte courant.
• La classe “Carte-Crédit” : cette la classe représente les informations d’une carte de crédit.
• La classe “Chéquier” : cette la classe représente les informations d’un carnet de chèque.
• La classe “Transaction” : cette la classe représente une transaction.
• La classe “Contact” : cette la classe indique les informations d’un message envoyé par un
utilisateur.
• La classe “Demande” : cette la classe contient les informations d’une demande.
• La classe “Demande-CC” : cette une chasse hérite de la classe “Demande” et représente

une demande de carte de crédit.
• La classe “Demande-Chéquier” : cette une chasse hérite de la classe “Demande” et

représente une demande de carnet de chèque.
2.6 Les diagrammes de séquences

Ce diagramme représente une interaction entre le facteur et le système ainsi que les commu-
nications entre les différents composants du système.
33
2.6.1 Cas d’utilisation “S’authentifier”
La figure 2.6 représente les différentes séquences qui se produisent lorsqu’un utilisateur
appuie sur le bouton de connexion de l’interface d’authentification. Le système client va tout
d’abord faire un test sur les champs saisis, par la suite, il va demander au serveur de vérifier les
informations d’authentification afin de recevoir l’identifiant du client pour enfin pouvoir obtenir
les informations et les comptes du client.
F IGURE 2.6 – Diagramme de séquence du cas d’utilisation “S’authentifier”
34
2.6.2 Cas d’utilisation “Voir les transactions”
Lorsqu’un client veut consulter les transactions de l’un de ses comptes, il va l’ouvrir à partir
du menu de l’application et le système va directement afficher l’historique des transactions dans
l’interface de détail du compte. La figure 2.7 expose ce scénario.
F IGURE 2.7 – Diagramme de séquence du cas d’utilisation “Voir les transactions”
35
2.6.3 Cas d’utilisation “Transférer de l’argent”
Le transfert d’argent demande beaucoup de vérification comme le montre la figure 2.8. Après
avoir saisi les informations du transfert, le système client va vérifier s’il y a des champs invalides
et informe le client par un message d’erreur si c’est le cas, sinon, il va invoquer le service d’envoi
qui va tout de même vérifier le code de sécurité ainsi que la disponibilité du montant envoyé sur
le compte de l’expéditeur. Si tout est valide alors la transaction aura lieu et le client va être notifié.
Dans le cas contraire, un message d’erreur est envoyé au client.
F IGURE 2.8 – Diagramme de séquence du cas d’utilisation “Transférer de l’argent”
36
2.6.4 Cas d’utilisation “Localiser filiale”
Lorsqu’un utilisateur veut savoir où se trouve l’agence la plus proche, le système va faire
appel au service de localisation pour récupérer les coordonnées de l’utilisateur, puis avec e simple
calcul le système va afficher sur une map la position de l’utilisateur ainsi que la position de la
filiale la plus proche. Ces séquences sont représentées dans la figure 2.9.
F IGURE 2.9 – Diagramme de séquence du cas d’utilisation “Localiser filiale”
37
2.7 Conclusion
La phase de conception est la réalisation virtuelle du projet. En effet, dans ce chapitre, nous
avons présenté la conception générale et la conception détaillée. Pour se faire, nous avons uti-
lisé l’outil de modélisation UML et les méthodologies convenables qui nous ont permis de
bien définir les éléments de conception, et mieux assimiler les différents besoins relatifs à la
réalisation.
38
C HAPITRE
3 Réalisation
Sommaire
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.3 Les interfaces d’application . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.3.1 Partie web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.3.2 Partie mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
39
Chapitre 3. Réalisation
3.1 Introduction
Après avoir établi la conception du système, nous allons décrire au niveau de ce chapitre
l’architecture du projet en parlant de l’environnement matériel et logiciel. Ensuite nous allons
aborder les différentes étapes du développement. Finalement, nous allons présenter quelques
interfaces prototypes de notre application.
3.2 Environnement de travail

Cette étape est destinée à la description de l’environnement matériel et logiciel qui est utilisé
pour développer les applications (web/mobile).
3.2.1 Environnement matériel
Le matériel utilisé pour le développement de notre application est présenté dans la figure
suivante :
40
F IGURE 3.1 – Environnement matériel
3.2.2 Environnement logiciel
Cette section est dédiée à la description des logiciels utilisés lors du développement de notre
application.
3.2.2.1 Star UML
Le produit ≪ StarUML ≫ est un outil de modélisation UML (Unified Modeling Language

open source qui vient se substituer aux outils payants tels que ≪ IBM Rational Rose ≫ ou ≪ Bor-
land Together ≫. L’objet de mon étude sur les logiciels de ≪ conception – implémentation ≫,
étude portant sur l’utilisation d’un logiciel ou d’un plug-in ≪ Eclipse ≫ open source pouvant faire
de la modélisation UML ainsi que de l’implémentation Java (avec rétro-ingénierie) [3]. Le logo
officiel de Star UML est présenté dans le figure 3.2.
41
F IGURE 3.2 – Logo de Star UML
3.2.2.2 MongoDB
MongoDB (de l’anglais humongous qui peut être traduit par ≪ énorme ≫) est un système de
gestion de base de données orienté documents, répartissable sur un nombre quelconque d’ordi-
nateurs et ne nécessitant pas de schéma prédéfini des données. Il est écrit en C++. Le serveur et
les outils sont distribués sous licence SSPL, les pilotes sous licence Apache et la documentation
sous licence Creative Commons. Il fait partie de la mouvance NoSQL [4]. Le logo officiel de
MongoDB est présenté dans le figure 3.3.
F IGURE 3.3 – Logo de Mongo DB
42
3.2.2.3 Postman
Postman est l’instrument le plus incontournable du développement web, que ce soit pour du
développement PHP, Node.js, Ruby on Rails ou Python. En interagissant avec une API, Postman
sert à exécuter des appels HTTP directement depuis une interface graphique. Il permet simple-
ment choisir l’URL, la méthode HTTP (le plus souvent GET, POST, PUT, PATCH et DELETE),
les headers, les query params et dans certains cas le body de la requête [5]. Le logo officiel de
Postman est présenté dans le figure 3.4.
F IGURE 3.4 – Logo de Postman
3.2.2.4 Visual Studio Code
Visual Studio Code est un éditeur de code source qui peut être utilisé avec une variété de
langages de programmation, notamment Java, JavaScript, Go, Node.js et C++. Il est basé sur le
cadre Electron, qui est utilisé pour développer des applications Web Node.js qui s’exécutent sur
le moteur de présentation Blink [6]. Le logo officiel de Visual Studio Code est présenté dans le
figure 3.5.
43
F IGURE 3.5 – Logo de Visual Studio Code
3.2.2.5 Laravel
Laravel est un framework web open-source écrit en PHP1 respectant le principe modèle-vue-
contrôleur et entièrement développé en programmation orientée objet. Laravel est distribué sous
licence MIT, avec ses sources hébergées sur GitHub [7]. Le logo officiel de Laravel est présenté
dans le figure 3.6.
F IGURE 3.6 – Logo de Laravel
3.2.2.6 Bootstrap
Bootstrap est une collection d’outils utiles à la création du design (graphisme, animation
et interactions avec la page dans le navigateur, etc.) de sites et d’applications web. C’est un
ensemble qui contient des codes HTML et CSS, des formulaires, boutons, outils de navigation et
44
autres éléments interactifs, ainsi que des extensions JavaScript en option. C’est l’un des projets
les plus populaires sur la plate-forme de gestion de développement GitHub [8]. Le logo officiel
de Bootstrap est présenté dans le figure 3.7.
F IGURE 3.7 – Logo de Bootstrap
3.2.2.7 Android Studio
Android Studio est un environnement de développement pour développer des applications

mobiles Android. Il est basé sur IntelliJ IDEA et utilise le moteur de production Gradle. Il peut
être téléchargé sous les systèmes d’exploitation Windows, macOS, Chrome OS et Linux [9]. Le
logo officiel de Android Studio est présenté dans le figure 3.8.
F IGURE 3.8 – Logo d’Android Studio
45
3.2.2.8 Overleaf
Overleaf est une plateforme en ligne gratuite permettant d’éditer du texte en LATEX sans au-
cun téléchargement d’application. En outre, elle offre la possibilité de rédiger des documents de
manière collaborative, de proposer ses documents directement à différents éditeurs (IEEE Jour-
nal, Springer, etc.) ou plateformes d’archives ouvertes (arXiv, engrxiv, etc.) pour une éventuelle
publication [10]. Le logo officiel de Overleaf est présenté dans le figure 3.9.
F IGURE 3.9 – Logo d’Overleaf
3.2.2.9 Le langage d’édition de document : Latex
LATEX est un langage qui permet de créer des documents tout en séparant la forme du fond.
Comme pour le HTML, l’interface de rédaction est de type WYSIWYM (“what you see is what
you mean” ce que l’on voit est ce que l’on pense) : la forme du document est donc programmée
a l’aide de commandes [11].
3.3 Les interfaces d’application
3.3.1 Partie web
Dans cette partie,nous allons invoquer des imprimes écrans décrivant le travail accompli.
Nous allons présenter les interfaces qui traitent les cas d’utilisation principaux.
46
3.3.1.1 Interface “Accueil pour l’administrateur”
L’interface d’accueil pour l’administrateur est illustrée dans la figure 3.10. C’est la première
interface de l’administrateur qui représente quelques statistiques générales.
F IGURE 3.10 – Interface “Accueil pour l’administrateur”
3.3.1.2 Interface “Relation clientèle”
L’interface 3.11 présente les messages reçus par l’administrateur et l’état de chaque message.
47
F IGURE 3.11 – Interface “Relation clientèle”
3.3.1.3 Interface “Gestion des demandes”
A travers cette interface l’administrateur peut consulter et gérer les demandes des chéquiers
et des cartes de crédit comme montré la figure 3.12.
48
F IGURE 3.12 – Interface “Gestion des demandes”
3.3.1.4 Interface “Ajouter filiale”
A l’aide de l’interface 3.13 l’administrateur peut ajouter une filiale.
49
F IGURE 3.13 – Interface “Ajouter filiale”
3.3.1.5 Interface “Détail filiale”
Cette interface décrit pour l’administrateur chaque filiale et la liste des agents appartenant à
cette filiale comme illustré dans la figure 3.14.
50
F IGURE 3.14 – Interface “Détail filiale”
3.3.1.6 Interface ≪ Ajouter agent ≫
Cette interface décrit le formulaire à remplir pour l’ajout d’un agent comme illustré dans la
figure 3.15.
51
F IGURE 3.15 – Interface “Ajouter agent”
3.3.1.7 Interface “Accueil pour l’agent”
L’interface d’accueil pour l’administrateur est illustrée dans la figure 3.16. C’est la première
interface de l’agent qui représente quelques statistiques générales.
52
F IGURE 3.16 – Interface “Accueil pour l’agent”
3.3.1.8 Interface “Ajouter compte”
Cette interface décrit les étapes à suivre et le formulaire à remplir pour la création d’un
compte comme illustré dans la figure 3.17.
53
F IGURE 3.17 – Interface “Ajouter compte”
3.3.2 Partie mobile
3.3.2.1 Interface “Accueil”
L’interface d’accueil pour le client est illustrée dans la figure 3.18. Cette interface représente
la page d’accueil de notre application mobile.
54
F IGURE 3.18 – Interface “Accueil”
3.3.2.2 Interface “Espace public”
L’interface illustrée dans la figure 3.19 présente les tâches qu’un visiteur du site peut faire.
55
F IGURE 3.19 – Interface “Espace public”
3.3.2.3 Interface “Simuler crédit”
L’interface illustrée dans la figure 3.20 permet à l’utilisateur de faire une simulation de crédit.
56
F IGURE 3.20 – Interface “Simuler crédit”
3.3.2.4 Interface “Connexion”
Pour accéder à son propre interface le client doit se connecter comme illustré dans la figure
3.21.
57
F IGURE 3.21 – Interface “Connexion”
3.3.2.5 Interface “Accueil Client”
La figure 3.22 présente l’interface de la page d’accueil d’un client et les services proposés
par notre application.
58
F IGURE 3.22 – Interface “Accueil Client”
3.3.2.6 Interface “Mes comptes”
A travers cette interface le client peut consulter tous ses comptes comme montré la figure ??.
59
F IGURE 3.23 – Interface “Mes comptes”
3.3.2.7 Interface “Détail comptes”
A travers l’interface suivante le client peut consulter les détails de l’un de ses comptes (voir
figure 3.24).
60
F IGURE 3.24 – Interface “Détail comptes”
3.3.2.8 Interface “Payer facture”
A travers cette interface le client peut payer ces facture en ligne comme illustré dans la figure
??.
61
F IGURE 3.25 – Interface “Payer facture”
3.4 Conclusion
Dans ce chapitre, nous avons défini l’environnement matériel et logiciel du projet. Puis, nous
avons détaillé le travail réalisé en se basant sur des interfaces de l’application développée.
62
Conclusion et perspectives
L’objectif de notre projet était de développer une solution bancaire mobile qui propose
à la fois une application mobile aux clients d’une banque ainsi qu’une application web pour
l’administration du système.
Afin d’arriver à notre objectif, nous avons procédé d’exposer la problématique, identifier
les besoins qui ont engendré les différents objectifs de notre application et spécifier les diverses
fonctionnalités qu’elle assume. Pour réaliser la partie analyse et conception, nous avons utilisé
UML comme un langage de modélisation.
Nous avons réussi à atteindre tous les objectifs principaux et nous avons ajouté un grand nombre
de fonctionnalités secondaire comme la conversion de vises etc. Nous sommes aussi familiarisés
avec le développement mobiles et aussi avec le framework LARAVEL pour concevoir l’applica-
tion web.
Finalement, notre travail peut être amélioré par l’accomplissement de quelques tâches
supplémentaires. En effet, nous visons à ajouter à notre application des modules de Machine lear-
ning et de Deep learning pour améliorer notre application au niveau de traitement des chèques.
Ainsi, avec un simple scan d’un chèque l’utilisateur peut faire toutes les manipulations pos-
sibles. Nous proposons comme autre perspective, l’ajout de la biométrie dans notre application
(spécialement au niveau de transfert d’argent) pour renforcer la sécurité de notre application.
63
Webographie
[1] https ://play.google.com/.
[2] http ://www.iro.umontreal.ca/ dift6825/UML.htm/.
[3] http ://www.projet-plume.org/ressource/uml).
[4] https ://www.mongodb.com/.
[5] https ://practicalprogramming.fr/postman/.
[6] https ://code.visualstudio.com/.
[7] https ://kinsta.com/fr/base-de-connaissances/qu-est-ce-que-laravel/.
[8] https ://www.w3schools.com/bootstrap/bootstrap get started.asp.
[9] https ://www.android.com/.
[10] https ://paris-sorbonne.libguides.com/c.php ?g=497641p=4637541.
[11] https ://paris-sorbonne.libguides.com/c.php ?g=497641p=3446440.
64

Rapport Abd Fateh 2022

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport Abd Fateh 2022

Transféré par

Droits d'auteur :

Formats disponibles

Dédicace

Je dédie ce travail particulièrement :

Abd Elfatteh Guesmi

1 Étude préalable et spécification des besoins 3

1.1 Logo de l’institut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1 Modèle en cascade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.1 Description textuelle du cas d’utilisation ”S’authentifier” . . . . . . . . . . . . . 22

Le premier chapitre sera consacré à la présentation générale du projet. En effet, nous

Le deuxième chapitre sera consacré à la modélisation conceptuelle de notre application.

Le dernier chapitre consiste à présenter la partie développement du système et décrire les

1 Étude préalable et spécification des besoins

1.2 Cadre général . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . 4

1.4 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4.1 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.4.3 Objectif du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.5.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.5.2 Les besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.5.3 Les besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . 12

1.2 Cadre général

1.3 Présentation de l’organisme d’accueil

contexte de plus en plus mondialisé.

F IGURE 1.1 – Logo de l’institut

1.4 Présentation du projet

1.4.1 Étude de l’existant

❖ Solutions disponibles en Tunisie

• Consultation en temps réel des soldes de vos comptes ;

• Historique de vos mouvements sur six mois ;

• Recherche multi-critères des opérations (par date, par montant) ;

• Changement de votre mot de passe ;

• Consultation des cours des principales devises ;

• Virement d’un compte au compte Attijari bank ou autre banque (optionnel).

La figure 1.2 représente l’interface de l’application mobile de Attijari Bank.

F IGURE 1.2 – Interface de Attijari Bank

• Virer des fonds entre vos comptes ;

• Visualiser les transactions faites par vos cartes ;

• Suivre vos chèques et visualiser leurs images ;

• Consulter votre portefeuille titres ;

• Consulter vos encours de crédits ;

• Repérer la succursale le plus proche de vous.

La figure 1.3 représente l’interface de l’application mobile de Banque de Tunisie.

F IGURE 1.3 – Interface de Banque de Tunisie

F IGURE 1.4 – Interface de Chase Bank

F IGURE 1.5 – Interface BNP Paribas Bank

1.4.2 Critique de l’existant

• L’authentification ne s’effectue pas dès la première fois.

• Il est impossible de faire une transaction à partir de l’application mobile.

• Il y’a une Absence de la géolocalisation.

• Il n’y a pas d’une possibilité de demander une carte bancaire ou un chéquier.

F IGURE 1.6 – Avis des utilisateurs

1.4.3 Objectif du projet

1.5.1 Identification des acteurs

1.5.2 Les besoins fonctionnels

1.5.2.1 Les besoins fonctionnels liés au client

• Consulter ses informations personnelles ainsi que son compte bancaire.

• Consulter l’historique de ses transactions.

• Payer des factures.

• Envoyer des demandes de carte de crédit ou de carnet de chèque.

Toutefois, un utilisateur sans authentification peut aussi bénéficier de certaines fonctionnalités :

• Voir les filiales les plus proches.

1.5.2.2 Les besoins fonctionnels liés à l’administrateur