DÉDICACES

Je consacre ce modeste ouvrage en signe de respect, de profonde gratitude et de

reconnaissance à :

À mes chers parents, Hsan et Salha , pour leur amour incommensurable, leur soutien
indéfectible, ainsi que les sacrifices sans nombre qu’ils ont consentis pour m’aider à atteindre
mes objectifs. Vous êtes pour moi une source d’inspiration majeure.

À mon frère et mes sœurs bien-aimés, Yassine, Amal, Afef, Amina et Abir, pour leur
présence apaisante, leur soutien et leur amour qui m’ont soutenue et poussée tout au long de
mon parcours académique.

À mes précieux amis, Wejdenne, Arij, Reem, Malak, Ali et tous ceux qui m’ont soutenu,
pour leur soutien sans faille, leur véritable amitié et leurs encouragements constants tout au
long de mes études universitaires. Je vous souhaite un succès retentissant dans toutes vos
ambitions et projets à venir.

À moi-même, pour ma persévérance, ma résolution et l’énergie déployée tout au long de

mon parcours, j’ai réussi à franchir cette étape cruciale. Ce travail témoigne de mon
engagement et de ma détermination à réussir.

À vous tous, qui m’avez soutenue et inspirée, je dédie ce travail.

Yasmine Sassi

Fseg Nabeul Page i

 REMERCIEMENT

Au terme de ce travail, j’ai l’honneur d’adresser mes sincères remerciements à

toutes les personnes qui ont participé à la réussite du stage de fin d’études et

plus particulièrement les personnes que je cite ci-dessous,

Je tiens à remercier mes encadrants, Mme. Dalila Trad et Mme. Maroua

Mimouni pour leur présence, leurs critiques et les conseils avisés qu’ils m’ont

prodigués tout au long du chemin de ce stage.

En particulier, je tiens à remercier tous les membres de l’équipe "STB" pour

l’ambiance très conviviale, serviable qu’ils m’ont procuré.

Enfin, j’en profite pour remercier les membres du jury, en espérant qu’ils

trouveront dans ce rapport les qualités de clarté et de motivation qu’ils

attendent.

Fseg Nabeul Page ii

 TABLE DES MATIÈRES

LISTE DES FIGURES v

LISTE DES TABLEAUX vi

LISTE DES ABRÉVIATIONS vii

INTRODUCTION GÉNÉRALE 1

1 Cadre général du projet 2

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . 3
1.2.2 Fiche signalétique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.3 Organigramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1 Description de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5 Méthodologie du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5.1 Etude Comparative . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5.2 Choix de méthodologie : Méthode SCRUM . . . . . . . . . . . . . . . 11
1.6 Technologie de développement . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.6.1 Architecture utilisée . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.6.1.1 Architecture MVC (Model-View-Controller) . . . . . . . . 12
1.6.1.2 Architecture REST API . . . . . . . . . . . . . . . . . . . . 13
1.6.2 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.6.2.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . 14
1.6.2.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . 15
1.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Fseg Nabeul Page iii

TABLE DES MATIÈRES

2 Chapitre 2 : Analyse et spécification des besoins 19

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.1 Les besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.2 Les besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . 22
2.3 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4 Elaboration du backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.5 diagramme de cas d’utilisation général . . . . . . . . . . . . . . . . . . . . . . 26
2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3 Chapitre 3 : Release 1 28
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

NETOGRAPHIE 29

Fseg Nabeul Page iv

 LISTE DES FIGURES

1.1 logo STB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Vue extérieure de la STB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 organigramme de la STB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Logo Amazon Marketplace . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5 Méthode Traditionnelle VS Méthode Agile [3] . . . . . . . . . . . . . . . . . . 10
1.6 Processus Scrum [5] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.7 L’architecture MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.8 L’architecture REST API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.9 Logo de Visual Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.10 Logo d’Angular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.11 Logo de SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.12 Logo de Swagger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.13 Logo de Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.14 Logo de Draw.io . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.1 Diagramme de cas d’utilisation général . . . . . . . . . . . . . . . . . . . . . 26

Fseg Nabeul Page v

 LISTE DES TABLEAUX

2.1 Cas d’utilisation par acteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.2 Backlog Produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Fseg Nabeul Page vi

 LISTE DES ABRÉVIATIONS

Fseg Nabeul Page vii

 INTRODUCTION GÉNÉRALE

Le développement des technologies bancaires et la numérisation des services financiers ont

profondément transformé la manière dont les entreprises gèrent les modes de paiement de leurs
employés.
Les plateformes de gestion des cartes bancaires jouent un rôle crucial en offrant une solution
centralisée pour la distribution, l’administration et l’utilisation sécurisées des cartes, tout en
simplifiant les procédures administratives des grandes entreprises.
Ce modèle ne se limite pas à la simple production de cartes, mais met l’accent sur des fonctions
sophistiquées comme le rechargement, la gestion des limites et la consultation des transactions,
qui ont un impact direct sur l’efficacité opérationnelle et le satisfaction des utilisateurs.
De plus, la gestion des cartes bancaires exige une infrastructure solide et sécurisée, intégrant
des systèmes d’authentification et de permission pour se protéger contre les fraudes et les accès
non autorisés. Cela garantit une expérience utilisateur sans interruption et assure la protection
des données financières.
Dans ce contexte, la STB nous a offert l’opportunité de participer à l’élargissement de la
plateforme DigiCorps en créant une fonctionnalité innovante pour la gestion des cartes bancaires
des employés. L’objectif de ce projet est de faciliter la distribution, le rechargement et l’administration
des cartes, tout en incorporant des alertes en direct pour optimiser l’expérience de l’utilisateur.
Le présent rapport se focalise sur la description des différentes phases de la réalisation de ce
projet. Il a pour but de situer le cadre général du projet, de présenter les outils et technologies
utilisés.

• Le premier chapitre, intitulé « Étude préalable », présente l’organisme d’accueil et

introduit le cadre général du projet.

Fseg Nabeul Page 1

INTRODUCTION GÉNÉRALE

• Le deuxième intitulé « Analyse et spécification des besoins », aborde les spécifications

fonctionnelles et non fonctionnelles de notre projet et l’étude des différents diagrammes
des cas d’utilisation de système en se basant sur la méthodologie UML.

• Pour le troisième chapitre, nous allons consacrer un segment à une analyse conceptuelle
de notre plateforme qui inclura la méthodologie de gestion de projet, le diagramme de
classes, ainsi que les diagrammes de séquences. Cette recherche détaillera minutieusement
toutes les phases de la conception.

• Enfin, dans le quatrième chapitre, nous détaillerons l’environnement de travail en

abordant la phase de réalisation et la description des étapes de mise en œuvre de la
nouvelle fonctionnalité sur la plateforme DigiCorps, tout en présentant ses diverses
interfaces.

Fseg Nabeul Page 1

Chapitre

1
Cadre général du projet

Sommaire
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . 3
1.2.2 Fiche signalétique . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.3 Organigramme . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1 Description de l’existant . . . . . . . . . . . . . . . . . . . . . 7
1.3.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5 Méthodologie du projet . . . . . . . . . . . . . . . . . . . . . . . 9
1.5.1 Etude Comparative . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5.2 Choix de méthodologie : Méthode SCRUM . . . . . . . . . . . 11
1.6 Technologie de développement . . . . . . . . . . . . . . . . . . . 11
1.6.1 Architecture utilisée . . . . . . . . . . . . . . . . . . . . . . . . 12
1.6.2 Environnement de travail . . . . . . . . . . . . . . . . . . . . . 14
1.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
CADRE GÉNÉRAL DU PROJET

1.1 Introduction

Ce travail a été réalisé au siège de la Société Tunisienne de Banque en Tunisie. Nous y traitons
de l’élaboration de nouvelles fonctionnalités pour améliorer le contrôle des cartes bancaires des
employés dans les grandes sociétés. Dans ce premier chapitre, nous présenterons l’organisme
d’accueil , le contexte global de notre projet, en exposant la problématique et la solution proposée
pour y répondre .

1.2 Organisme d’accueil

1.2.1 Présentation de l’organisme d’accueil

La Société Tunisienne de Banque (STB) est un établissement bancaire public tunisien, créé en
1957. Elle est la première banque tunisienne, et elle a pour mission essentielle de contribuer au
développement économique et social du pays, de promouvoir les entreprises dans les diverses
activités économiques et de fournir des services bancaires de qualité à sa clientèle [1].

Créée en 1957, La Société Tunisienne de Banque, suite à la fusion de deux banques : la

Banque de l’Agriculture et la Banque Commerciale de Tunisie. Au fil des années, la STB a
connu une croissance rapide, élargissant ses activités et son réseau de succursales à travers le
pays.
En 1961, elle a commencé à opérer dans le domaine des échanges internationaux
En 1976, elle a créé la filiale STB Leasing pour offrir des services de leasing et de location
financière
En 1997, la STB a été partiellement privatiste, avec l’introduction de 20Elle a acquis la Banque
Franco-Tunisienne en l’an 2000 et a établi la STB Bank Algérie en 2010.
La STB est aujourd’hui l’une des banques les plus importantes en Tunisie, avec plus de 200
agences réparties à travers le pays et disposant de filiales dans plusieurs nations de l’Afrique
du Nord. Elle offre toute la gamme de produits et services financiers aux particuliers, aux

Fseg Nabeul Page 3

CADRE GÉNÉRAL DU PROJET

entreprises et aux institutions publiques.

La figure 1.1 présente le logo officiel de la STB.

images/Logo_STB.jpg

F IGURE 1.1 – logo STB

1.2.2 Fiche signalétique

• Raison sociale : Société Tunisienne de Banque

• Date de constitution : 18 Janvier 1957

• Forme juridique : Société anonyme

• Capital : 776,875 millions de dinars (2022)

• Nombre d’employés : Plus de 5 000 (2021)

• Siège social : Rue Hédi Nouira – 1001 Tunis – Tunisie

• Email : [email protected]

• Site web : www.stb.com.tn [2]

La figure 1.2 présente la Vue extérieure de la STB.

Fseg Nabeul Page 4

CADRE GÉNÉRAL DU PROJET

images/vue_externe_stb.jpg

F IGURE 1.2 – Vue extérieure de la STB

1.2.3 Organigramme

La STB, étant une banque historique et l’une des principales institutions financières du pays,
présente une structure organisationnelle particulièrement développée. Dans ce cadre, nous avons
réalisé notre stage dans le département Système d’Information et Développement Digital.

Fseg Nabeul Page 5

CADRE GÉNÉRAL DU PROJET

La figure 1.3 représente l’organigramme de la STB.

images/pppp.png

F IGURE 1.3 – organigramme de la STB

1.3 Etude de l’existant

C’est une phase cruciale dans un projet, impliquant l’analyse de l’état actuel avant d’implémenter
des améliorations ou de présenter une nouvelle solution.

Fseg Nabeul Page 6

CADRE GÉNÉRAL DU PROJET

1.3.1 Description de l’existant

Dans les grandes entreprises , Les processus traditionnels utilisées pour la paie et la gestion
des salaires sont souvent source de difficultés , ce qui a un impact négatif sur les employeurs et
les employés . Chaque mois, Les employeurs responsables du versement des salaires, doivent
gérer un grand nombre de transactions salariales , ce qui exige un contrôle strict des paiements
et de la conformité des sommes versées . Dans ce contexte actuel, de nombreuses entreprises
utilisent des opérations manuelles pour la gestion de la paie. Cela implique l’envoi d’un fichier
bancaire au partenaire financier, qui gère les comptes de chaque employé pour le versement des
salaires. Ensuite, les employés doivent aller en agence pour retirer leurs fonds. Autrement, une
autre méthode est de distribuer les salaires en espèces sous enveloppe. Ces approches, comme
l’utilisation de systèmes classiques, demandent une intervention humaine à chaque étape du
processus .
Dans ce contexte, une question cruciale se pose : De quelle manière la STB peut-elle offrir
une solution efficace pour répondre aux besoins des grandes entreprises Face aux défis
actuels de la gestion des salaires et des cartes bancaires ?

1.3.2 Critique de l’existant

Les méthodes classiques destinées à la paie et l’administration salariale engendrent un grand

nombre d’inconvénients à différents égards . Au nombre des inconvénients de ces méthodes , il
est possible de citer :

Pour les entreprises :

• Une pesante charge administrative provient de la difficulté de la gestion manuelle avec ses
coûts excessifs.

• L’absence de contrôle , des falsifications internes/externes et les calculs incorrects , crée un

environnement convenable risques d’erreurs et de fraudes.

• La réputation et la productivité touchées en conséquence de la perturbation des opérations.

Fseg Nabeul Page 7

CADRE GÉNÉRAL DU PROJET

Pour les employés :

• L’ambiguïté financière causée par les retards et le manque de suivie des dépenses.

• Vol ou perte des cheques contenant les salaires.

• Les déplacements en agence les files d’attente entraînent une perte de temps considérable.

1.4 Solution proposée

Afin de surmonter les faiblesses précédemment mentionnées , Nous suggérons d’implémenter

de nouvelles fonctionnalités sur la plateforme Digicorps, personnalisées pour les besoins spécifiques
des grandes entreprises .

Grâce à cette solution , nous facilitons et informatisons la gestion des paiements, tout en
offrant une visibilité et une sécurité accrues .
À l’aide de cette plateforme , l’administrateur de l’entreprise a l’occasion de requérir des cartes
bancaires pour ses employés sans aucune difficulté , ce qui centralise le processus et élimine les
problèmes administratifs associées aux opérations manuelles.
Une fois les cartes sont obtenues , l’administrateur peut facilement effectuer les salaires sur la
plateforme , grâce à deux profils distincts : un profil initial pour la recharge des cartes et un
profil de validation, qui renforce la sécurité .
De plus, La plateforme permet d’administrer les cartes offrant leur blocage ou déblocage selon
les besoins et chaque opération de recharge de salaire sur la carte l’employé est immédiatement
notifié . Cette nouvelle fonctionnalité Encourage la transparence , consolidant la confiance entre
l’organisation et les salariés.
En fin de compte , l’automatisation des processus autorise d’acquérir du temps , réduire les
fautes et améliorer la productivité.

Fseg Nabeul Page 8

CADRE GÉNÉRAL DU PROJET

images/Amazon-Logo (1).png

F IGURE 1.4 – Logo Amazon Marketplace

1.5 Méthodologie du projet

Avant de commencer le développement d’un projet, il faut d’abord choisir la méthodologie

de travail de ce projet, car c’est une étape cruciale , nous pouvons utiliser soit une des méthodes
classiques linéaires (cycle en V ou cascade), soit une des méthodes itératives comme (spirale
ou incrémentale), soit encore une méthode itérative incrémentale, qui est la méthode agile.

1.5.1 Etude Comparative

La figure 1.4 représente une comparaison entre les méthodologies classiques et la méthodologie
agile.

Fseg Nabeul Page 9

CADRE GÉNÉRAL DU PROJET

images/comparaison.png

F IGURE 1.5 – Méthode Traditionnelle VS Méthode Agile [3]

Les méthodes agiles seront plus utilisées pour les gros projets car elles offrent une meilleure
adaptabilité, visibilité et gestion des risques. Elles pourraient tout aussi bien être utilisées pour
les projets où il n’y pas de documentations détaillées, le client peut alors voir l’évolution du
projet et l’adapter selon ses besoins. En revanche, les méthodes classiques seront plus utilisées
si vous avez une idée très précise de votre projet avec un cahier des charges et planning très
détaillé où vous avez anticipé tous les risques possibles [4].

Fseg Nabeul Page 10

CADRE GÉNÉRAL DU PROJET

1.5.2 Choix de méthodologie : Méthode SCRUM

Après avoir comparé les méthodologies classiques et la méthode agile dans la section 1.6.1,
nous constatons que la méthode agile offre plusieurs avantages tels qu’une flexibilité accrue, une
meilleure satisfaction client et une transparence totale. Ces caractéristiques sont particulièrement
adaptées à notre projet. C’est pourquoi nous choisissons la méthodologie agile pour développer
notre projet et atteindre nos objectifs.
La figure 1.5 représente le processus Scrum

images/processusScrum.png

F IGURE 1.6 – Processus Scrum [5]

1.6 Technologie de développement

Nous avons utilisé divers outils logiciels et matériels pour mener à bien le développement
de notre application.

Fseg Nabeul Page 11

CADRE GÉNÉRAL DU PROJET

1.6.1 Architecture utilisée

1.6.1.1 Architecture MVC (Model-View-Controller)

Le but de MVC est justement de séparer la logique du code en trois parties que l’on retrouve
dans des fichiers distincts.

• Modèle : cette partie gère ce qu’on appelle la logique métier. Elle comprend notamment la
gestion des données qui sont stockées, mais aussi tout le code qui prend des décisions autour
de ces données.

• Vue : cette partie se concentre sur l’affichage. Elle ne fait presque aucun calcul et se contente
de récupérer des variables pour savoir ce qu’elle doit afficher.

• Contrôleur : cette partie gère les échanges avec l’utilisateur. C’est en quelque sorte l’intermédiaire
entre l’utilisateur, le modèle et la vue. Le contrôleur va recevoir des requêtes de l’utilisateur
[6].

La figure 1.6 représente l’architecture MVC

images/MVC.png

F IGURE 1.7 – L’architecture MVC

Fseg Nabeul Page 12

CADRE GÉNÉRAL DU PROJET

1.6.1.2 Architecture REST API

L’architecture REST (Representational State Transfer) ou RESTful est un style d’architecture

permettant de construire des applications (Web, Intranet, Web Service). Il s’agit d’un ensemble
de conventions et de bonnes pratiques à respecter et non d’une technologie à part entière.
L’architecture REST utilise les spécifications originelles du protocole HTTP, plutôt que de
réinventer une surcouche (comme le font SOAP ou XML-RPC par exemple).

• Règle n°1 : l’URI comme identifiant des ressources

• Règle n°2 : les verbes HTTP comme identifiant des opérations

• Règle n°3 : les réponses HTTP comme représentation des ressources

• Règle n°4 : les liens comme relation entre ressources

• Règle n°5 : un paramètre comme jeton d’authentification [7]

La figure 1.7 représente l’architecture REST API

images/APIrest.png

F IGURE 1.8 – L’architecture REST API

Fseg Nabeul Page 13

CADRE GÉNÉRAL DU PROJET

1.6.2 Environnement de travail

Nous sommes conscients de l’importance de l’environnement de travail dans le développement

d’une application.
Cette partie se divise en deux aspects : le premier concerne l’environnement matériel et le
second l’environnement logiciel.

1.6.2.1 Environnement matériel

Lors du développement de notre projet, nous avons utilisé :

Un ordinateur ayant les caractéristiques suivantes :

• Modèle : ACER

• Mémoire RAM installée : 8 GO

• Processeur : Intel Core I5

• Système d’exploitation : Windows 10 professionnel 64 bits

• Disque Dur : Disque SSD 512 Go

Fseg Nabeul Page 14

CADRE GÉNÉRAL DU PROJET

1.6.2.2 Environnement logiciel

Lors du développement de notre projet, nous avons utilisé les logiciels suivants :

• Visual Studio

IDE le plus complet pour les développeurs .NET et C++ sur Windows. Entièrement rempli d’un
bon ensemble d’outils et de fonctionnalités permettant d’élever et d’améliorer chaque étape du
développement de logiciels [8].

La figure 1.8 représente le logo de Visual Studio

images/vs.png

F IGURE 1.9 – Logo de Visual Studio

• Angular

Angular est un framework de développement web open source géré par Google. Il vous permet
de créer des applications web dynamiques en utilisant HTML, CSS et JavaScript [9].

La figure 1.9 représente le logo d’Angular

images/angular.jpg

F IGURE 1.10 – Logo d’Angular

Fseg Nabeul Page 15

CADRE GÉNÉRAL DU PROJET

• SQL Server

Microsoft SQL Server est un système de gestion de base de données relationnelle (SGBDR).
Les applications et les outils se connectent à une instance ou une base de données SQL Server
[10].

La figure 1.10 représente le logo de SQL Server

images/sql.png

F IGURE 1.11 – Logo de SQL Server

• Swagger

Swagger c’est un ensemble d’outils pour aider les développeurs dans la conception, le build,
la documentation et la consommation d’API [11].

La figure 1.11 représente le logo de Swagger

images/SWAGGER.png

F IGURE 1.12 – Logo de Swagger

Fseg Nabeul Page 16

CADRE GÉNÉRAL DU PROJET

• Git

Git est un outil de développement qui aide une équipe de développeurs à gérer les changements
apportés au code source au fil du temps [12].

La figure 1.12 représente le logo de Git

images/gitttt-logo.png

F IGURE 1.13 – Logo de Git

• Draw.io

Draw.io est une application gratuite en ligne, accessible via son navigateur (protocole https) qui
permet de dessiner des diagrammes ou des organigrammes. Cet outil vous propose de concevoir
toutes sortes de diagrammes, de dessins vectoriels, de les enregistrer puis de les exporter [13].

La figure 1.13 représente le logo de Draw.io

images/DDRAW.png

F IGURE 1.14 – Logo de Draw.io

Fseg Nabeul Page 17

CADRE GÉNÉRAL DU PROJET

1.7 Conclusion

Dans ce chapitre , nous avons tenté contextualiser le projet , présenter la Société tunisienne
de banque (STB) et l’étude de l’existant et la solution envisagée .
Le chapitre suivant , Nous procéderons à une spécification les différents besoins.

Fseg Nabeul Page 18

Chapitre

2
Chapitre 2 : Analyse et spécification
des besoins

Sommaire
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . 20
2.2.1 Les besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . 20
2.2.2 Les besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . 22
2.3 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . 23
2.4 Elaboration du backlog produit . . . . . . . . . . . . . . . . . . 24
2.5 diagramme de cas d’utilisation général . . . . . . . . . . . . . . 26
2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Fseg Nabeul Page 19

CHAPITRE 2 : ANALYSE ET SPÉCIFICATION DES BESOINS

2.1 Introduction

Ce chapitre vise à approfondir la compréhension de notre projet en explorant en détail les

besoins fonctionnels et non fonctionnels, afin de répondre au mieux aux attentes du client.
Nous identifierons ensuite les acteurs impliqués, élaborerons le backlog produit et présenterons
le diagramme de cas d’utilisation général.

2.2 Spécification des besoins

Avant le démarrage du projet, la réussite des objectifs fixés repose sur une définition et une
planification attentives des besoins. Pour cette raison, nous avons tenu des réunions de travail
avec notre Product Owner. Grâce à ces interactions, ont amélioré notre appréhension du projet,
ont trouvé les informations nécessaires et ont spécifié clairement les besoins fonctionnels et non
fonctionnels dans le but de garantir un développement optimal.

Ci-après, une exposition détaillée des besoins fonctionnels et non fonctionnels.

2.2.1 Les besoins fonctionnels

- Authentification :

• L’administrateur de société ou le validateur ou chargé bancaire doit entrer son identifiant et

son mot de passe pour se connecter à son espace.

- La gestion des demandes de cartes :

• L’administrateur de la société a la possibilité de solliciter des cartes bancaires pour ses

employés, de consulter l’état de ces demandes et de supprimer une demande en cours.

- Demande un lot de carte :

• L’administrateur a la possibilité de demander un lot de cartes qui contient les informations

nécessaires sur les porteurs de carte.

Fseg Nabeul Page 20

CHAPITRE 2 : ANALYSE ET SPÉCIFICATION DES BESOINS

- Recharge les cartes :

• L’administrateur a la possibilité de recharger les cartes par le montant selon leurs besoins
au moment où il le souhaite.

- Validation de recharge :

• Le validateur doit valider chaque recharge effectuée par l’administrateur afin de permettre
son traitement.

- Blocage de carte :

• L’administrateur a la possibilité de bloquer une carte pour une période selon ses besoins.

- Opposition de la carte :

• L’administrateur a la possibilité de mettre une carte en opposition en cas de besoin de la

bloquer définitivement.

- Opposition de la carte :

• L’administrateur a la possibilité de mettre une carte en opposition en cas de besoin de la

bloquer définitivement.

- Renouvellement de carte :

• L’administrateur a la possibilité d’affecter une carte déjà utilisée à un nouveau porteur de

carte.

- Consultation des transactions par carte :

• L’administrateur a la possibilité de consulter toutes les transactions par carte.

- Modification de plafond de carte :

• L’administrateur a la possibilité de demander à la banque de modifier le plafond d’une carte.

- Consultation des demandes :

• Le chargé bancaire a la possibilité de consulter toutes les demandes effectuées par différents
clients.

- Validation des demandes :

• Le chargé bancaire a la possibilité de valider la demande si la banque peut satisfaire cette

demande.

Fseg Nabeul Page 21

CHAPITRE 2 : ANALYSE ET SPÉCIFICATION DES BESOINS

- Notification aux porteurs de cartes :

• Une fois le rechargement effectué correctement, les porteurs de carte doivent être notifiés.

- notificatinner les porteurs cartes :

• Le chargé bancaire a la possibilité de rejeter la demande d’un client.

2.2.2 Les besoins non fonctionnels

- Scalabilité :

• Les performances de l’application doit être performante et évolutive même en cas de forte
charge

- Sécurité :

• Protection des données sensibles via d’authentification robustes

- Simplicité d’utilisation :

• L’utilisateur accède facilement grâce à des interfaces pratiques pour une navigation fluide

Fseg Nabeul Page 22

CHAPITRE 2 : ANALYSE ET SPÉCIFICATION DES BESOINS

2.3 Identification des acteurs

Un acteur représente un rôle d’un utilisateur qui interagit avec le système que vous modélisez.
L’utilisateur peut être un utilisateur humain, une organisation, une machine ou un autre système
externe [14].

Pour que notre système fonctionne correctement, il requiert deux utilisateurs ayant chacun
un rôle distinct.

Le tableau 2.1 présente les acteurs de notre projet.

Acteurs Cas d’utilisation

Administrateur client - Autentifier

- Demander un lot de cartes
- Recharger une carte
- Débloquer une carte
- Bloquer une carte
- Mettre une carte en opposition
- Renouveler une carte
- Consulter l’historique des transactions par carte
- Modifier les plafonds des cartes

Validateur - Valider les demandes de recharges de cartes

Chargé bancaire - Consulter demande

- Valider demande
- Rejeter demande de carte

TABLE 2.1 – Cas d’utilisation par acteur

Fseg Nabeul Page 23

CHAPITRE 2 : ANALYSE ET SPÉCIFICATION DES BESOINS

2.4 Elaboration du backlog produit

Le tableau 2.2 présente le backlog de notre projet.

ID Fonctionnalités ID Scénario Priorité

1 Authentification 1.1 - En tant qu’administrateur client Elevée

ou Validateur ou Chargé bancaire je
dois m’authentifier.

2 Gérer les damandes 2.1 - En tant qu’administrateur client je Elevée

souhaite demander un lot de cartes
2.2 - En tant qu’administrateur client, Elevée
Je souhaite consulter l’état de la
demande et la supprimer si elle est
restée en cours
2.3 - En tant qu’administrateur Elevée
client, je souhaite demander le
renouvellement d’une carte
2.4 - En tant que chargé bancaire, je Elevée
souhaite consulter les demandes de
cartes
2.5 - En tant que chargé bancaire je Elevée
souhaite valider une demande de
carte
2.6 - En tant que chargé bancaire je Elevée
souhaite rejeter une demande de
carte

Fseg Nabeul Page 24

CHAPITRE 2 : ANALYSE ET SPÉCIFICATION DES BESOINS

3 Gérer les cartes 3.1 - En tant qu’administrateur client, je Elevée

souhaite charger les cartes
3.2 - En tant qu’administrateur client, je Elevée
souhaite bloquer une carte
3.3 - En tant qu’administrateur client, je Elevée
souhaite débloquer une carte
3.4 - En tant qu’administrateur client, je Elevée
souhaite débloquer une carte
3.5 - En tant qu’administrateur client, je Elevée
souhaite Consulter l’historique des
transactions par carte
3.6 - En tant que validateur , je souhaite Elevée
valider les recharges

4 Notifications 4.1 - En tant que porteur carte , je Elevée

souhaite recevoir une notification
lorsque la recharge est validée sur
ma carte

TABLE 2.2 – Backlog Produit

Fseg Nabeul Page 25

CHAPITRE 2 : ANALYSE ET SPÉCIFICATION DES BESOINS

2.5 diagramme de cas d’utilisation général

La figure 2.1 représente le diagramme de cas d’utilisation général de notre projet

images/DDDD.drawio.png

F IGURE 2.1 – Diagramme de cas d’utilisation général

2.6 Conclusion

Dans ce chapitre, nous avons identifié les besoins fonctionnels et non fonctionnels du système.
Nous avons également défini clairement chaque acteur et ses besoins spécifiques. De plus,

Fseg Nabeul Page 26

CHAPITRE 2 : ANALYSE ET SPÉCIFICATION DES BESOINS

nous avons élaboré le backlog produit et, pour finir, nous avons présenté le diagramme de cas
d’utilisation global de notre système . Dans le chapitre suivant, nous nous concentrerons sur
l’organisation des sprints et détaillerons chaque sprint .

Fseg Nabeul Page 27

Chapitre

3
Chapitre 3 : Release 1

Sommaire
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
CHAPITRE 3 : RELEASE 1

3.1 Introduction

Fseg Nabeul Page 29

 BIBLIOGRAPHIE

[1] Présentation de l’organisme d’accueil Consulté le 1 mars 2025. url :

http ://fr.tunisie.gov.tn/annuaireAdministration/556/11-soci

[2] Fiche signalétique Consulté le 1 mars 2025. url :

https ://www.stb.com.tn/fr/communication-financiere/rapports-annuels/

[3] Figure Méthode Traditionnelle VS Méthode Agile Consulté le 6 mars 2025. url :
https ://www.appvizer.fr/magazine/operations/gestion-de-projet/methode-classique-gestion-de-projet

[4] Etude Comparative Consulté le 6 mars 2025. url :

https ://www.linkedin.com/pulse/la-gestion-de-projet-methodes-classiques-vs-agiles-christ

[5] Figure processus Scrum Consulté le 6 mars 2025. url :

https ://www.cfi.ch/scrum-une-methode-de-developpement-agile/

[6] Architecture MVC Consulté le 6 mars 2025. url :

https ://openclassrooms.com/fr/courses/4670706-adoptez-une-architecture-mvc-en-php/7847928-decouvre

[7] Architecture REST API Consulté le 7 mars 2025. url :

https ://www.nicolashachet.com/blog/developpement-php/larchitecture-rest-expliquee-en-5-regles/

[8] Visual Studio : Consulté le 10 mars 2025. url :

https ://visualstudio.microsoft.com/fr/

[9] Angular : Consulté le 10 mars 2025. url :

https ://bility.fr/definition-angular/

[10] SQL Server : Consulté le 10 mars 2025. url :

https ://learn.microsoft.com/fr-fr/sql/sql-server/what-is-sql-server ?view=sql-server-ver16

[11] Swagger : Consulté le 10 mars 2025. url :

https ://www.itroom.fr/swagger-le-framework-pour-vos-api/

Fseg Nabeul Page 30

BIBLIOGRAPHIE

[12] Git : Consulté le 10 mars 2025. url :

https : https ://www.next-decision.fr/wiki/qu-est-ce-que-git

[13] Draw.io : Consulté le 10 mars 2025. url :

https ://site.ac-martinique.fr/

[14] Identification des acteurs : Consulté le 28 mars 2025. url :

https ://www.ibm.com/docs/fr/dmrt/9.5.0 ?topic=diagrams-use-case

Fseg Nabeul Page 31