CONSERVATOIRE NATIONAL DES ARTS ET METIERS

ISSAE CNAM LIBAN - DEPARTEMENT INFORMATIQUE

RAPPORT FINAL DU PROJET NSY115
CONDUITE D’UN PROJET INFORMATIQUE

LES PORTEFEUILLES NUMERIQUES, UNE

MENACE CROISSANTE POUR LES BANQUES
TRADITIONNELLES

CENTRE : BEYROUTH
AUDITEUR : MOHAMED SABRA
TUTEUR : DR. AMAL KOBEISSI
JURY : DR. PASCAL FARES
DATE : JUILLET 2020
Table des matières
Introduction ..................................................................................................................................... 4
I - Etude Préalable ........................................................................................................................... 5
1. Présentation de l’entreprise ..................................................................................................... 5
1.1 Profil d’entreprise ............................................................................................................. 5
1.2 Les principales activités .................................................................................................... 6
1.3 Organigramme, volume d’activités et stratégie ................................................................ 7
2. Présentation générale du projet ............................................................................................... 8
2.1 Objectif principal .............................................................................................................. 8
2.2 Position du projet dans la société ...................................................................................... 9
2.3 Services et personnes concernés par le projet ................................................................... 9
2.4 Les résultats attendus ...................................................................................................... 10
2.5 L’organisation et le contrôle du déroulement du projet .................................................. 10
4. Etude de l’existant................................................................................................................. 11
4.1 Présentation de l’existant ................................................................................................ 11
4.2 Critique de l’existant ....................................................................................................... 13
4.3 Spécifications des besoins............................................................................................... 13
5. Scénarios ............................................................................................................................... 14
5.1 Besoins fonctionnels ....................................................................................................... 14
5.2 Contraintes non fonctionnelles ....................................................................................... 14
5.3 Scénario réalisation complète en interne : Matrice SWOT............................................. 15
5.4 Scenario réalisation complète en externe : Avantage et diminution du risque ............... 15
5.5 Méthode de développement, délai et estimation du coût présenté par TechG sal. ......... 16
II- Etude comparative ................................................................................................................... 17
1. Critères fonctionnels d’un portefeuille numérique (eWallet) ............................................... 17
2. Vue générale sur le marché: .................................................................................................. 19
3. Choix techniques ................................................................................................................... 23
3.1 Langages de développement ........................................................................................... 23
3.2 Base de données .............................................................................................................. 24
3.3 Outils de développement Java ........................................................................................ 25
3.4 Topologie du réseau existant........................................................................................... 26
3.5 Outils de modélisation et conception : Merise ou UML? ............................................... 27
3.6 Outils de prototypage ...................................................................................................... 28
3.7 Outils de génération de code ........................................................................................... 28
3.8 Outils de tests .................................................................................................................. 29
3.9 Outils de gestion de performance.................................................................................... 30
3.10 Outils de migration ....................................................................................................... 31
3.11 Méthodes et Outils de gestion de projet ........................................................................ 31
3.12 Outils de suivi financiers .............................................................................................. 32
3.13 Outils de documentation ............................................................................................... 32
III – Assurance Qualité ................................................................................................................. 33
1. Pourquoi ISO 9001 ............................................................................................................... 33
2. Définir l’objet du projet ........................................................................................................ 33
3. Définir et communiquer les politiques de la réalisation du projet ........................................ 34
4. Déployer des objectifs cohérents et mesurables ................................................................... 34

Page | 2
 5. Déterminer les processus du projet et les responsables. ....................................................... 36
6. Définir la documentation des processus ............................................................................... 37
7. Mesurer et améliorer les performances ................................................................................. 38
IV- Aspects Juridiques .................................................................................................................. 39
1. La loi Informatique applicable .............................................................................................. 39
2. Identification des données personnelles................................................................................ 39
2.1 Informations que nous pouvons recueillir ....................................................................... 39
2.2 Utilisations faites des informations ................................................................................. 39
2.3 Divulgation des informations .......................................................................................... 40
2.4 Sécurité des données : Où stockons-nous vos informations personnelles? .................... 40
2.5 Droit de l’utilisateur ........................................................................................................ 40
3. Le Contrat ............................................................................................................................. 41
3.1 Description ...................................................................................................................... 41
3.2 Contrat de création de logiciel ........................................................................................ 41
V – Cahier des Charges Fonctionnel (CdCF) ............................................................................... 44
1. Présentation générale du problème ....................................................................................... 44
1.1 Projet ............................................................................................................................... 44
1.2 Contexte .......................................................................................................................... 44
1.3 Énoncé du besoin ............................................................................................................ 44
1.4 Environnement du produit : choix techniques et équipes ............................................... 45
2. Expression fonctionnelle du besoin : aperçu général des modules ....................................... 46
2.1 Inscription au portefeuille ............................................................................................... 46
2.2 Le Tableau de bord ......................................................................................................... 46
2.3 Ajouter des fonds au portefeuille .................................................................................... 47
2.4 Demander des fonds d’un autre portefeuille ................................................................... 47
2.5 Payer à partir du portefeuille ........................................................................................... 47
2.6 Relevé de compte du portefeuille.................................................................................... 48
3. Cadre de réponse ................................................................................................................... 49
3.1 Diagramme de classe simple : Aperçu global de l’application ....................................... 49
3.2 Modélisation du module Payement ................................................................................. 50
3.3 Modélisation du module Relevé de Compte ................................................................... 56
4. Les Livrables et le planning .................................................................................................. 62
VI – Bilan et Conclusion............................................................................................................... 63
1. Le Projet ................................................................................................................................ 63
2. Etapes de réalisation ............................................................................................................. 64
3. Problèmes rencontrés ............................................................................................................ 66
4. Finance .................................................................................................................................. 67
5. Expérience de la Banque et des clients ................................................................................. 67
6. Expérience personnelle ......................................................................................................... 68
7. Evolutions et perspectives..................................................................................................... 68
ANNEXES .................................................................................................................................... 69
Annexe 1 – Diagramme de Gantt.............................................................................................. 69
Annexe 2 – Diagramme de Gantt réel v/s estimé ..................................................................... 70

Page | 3
Introduction
La vitesse de l’évolution dans l’environnement numérique dans un marché inondé par une
nouvelle génération de technologies financières non traditionnels fournies par les compagnies de
« Fintechs », a rendu difficile à nos clients, les banques, de suivre le rythme de ce changement qui
va engendrer une perte du revenu annuel de 11% à 15%1 à cause de la diminution du volume
des transactions quotidiennes traditionnelles de payements chez les banques. Les clients
milléniaux préfèrent les transactions très dynamiques et relativement simple à compléter.

L’objectif est de fournir aux banques, une solution numérique d’entreprise qui peut offrir
les mêmes services de paiement que ceux offert par les Fintechs, tout en tirant parti de leurs
investissements existants dans l'infrastructure informatique y compris leur système bancaire de
base. Cela va les permettre de limiter le nombre des clients qui utilisent d’autres services pour
payer, et par suite maintenir le volume de transactions qui produit un revenu relativement
important.

Les portefeuilles numériques (Wallets) répondent parfaitement à ce besoin. En

investissant environ 200 000 dollars2 pour créer un portefeuille numériques à ses clients, y inclus
la durée de support de 3 mois après le lancement de l’application en ligne, la Banque sera capable
en 5 à 6 mois par une transformation rapide et agile de garder leurs clients existants et même
attirer de nouveaux clients potentiels, générant ainsi un plus grand nombre de transactions, donc
un revenu additionnel qui peut atteindre 5 à 6% du revenu annuel en plus de la limitation des
pertes existantes estimées de 71 millions de dollars par banque au Liban chaque année.

1 https://thefinancialbrand.com/90936/payment-trends-banking-mobile-wallet-contactless-big-tech/

https://www.businessinsider.in/business/news/indian-banks-risk-losing-9bn-revenue-to-e-wallets-by-
2025/articleshow/71836779.cms
2 https://www.nimbleappgenie.com/blogs/ewallet-mobile-app-development-cost/

Page | 4
I - Etude Préalable
Dans cette partie, nous allons présenter l’entreprise et le projet, puis étudier et critiquer
l’existant, afin de dévoiler les exigences, toujours de point de vue de la Banque.

1. Présentation de l’entreprise
1.1 Profil d’entreprise

Avec sa gamme complète et diversifiée de services, ZigBank se classe aux premiers rangs
des banques libanaises en termes d'actifs totaux, de capitaux propres, de dépôts de clients, de prêts
et d'avances. Fondée en 1835, la Banque a été constituée sous sa forme actuelle en 1967 en tant
que société anonyme à responsabilité limitée. Les premiers actionnaires étaient des membres de la
famille Zig, ainsi que certains investisseurs libanais basés en Côte d’Ivoire. Le siège social et
l’adresse officielle de la Banque sont ZigBank Center, Pascal Al Shami Street, Hamra, 2056 8144,
P.O. Box: 11-2668, Beyrouth, Liban.

La Banque est régionale. Elle opère principalement au Liban, dans la région du moyen
orient et d’Afrique du Nord (MENA), offrant une gamme de services qui couvrent principalement
la banque commerciale, la banque d’entreprise, la banque de détail, la banque personnelle et la
banque privée, ainsi que des activités auxiliaires telles que les activités du marché des capitaux et
l'affacturage. De plus, la Banque opère en Suisse, en France, en Jordanie, en Egypte, en Arabie
Saoudite, au Qatar, à Abu Dhabi (via un bureau de représentation), en Turquie et en Irak. La
Banque possède des filiales étrangères, un réseau de 110 agences dans la région MENA, dont 13
agences en Jordanie, 44 en Egypte et 46 agences en Turquie. La Banque possède deux filiales au
Liban, deux filiales en Europe, quatre filiales dans la région MENA et une filiale en Turquie. Du
fait de cette expansion régionale, un pourcentage croissant des actifs de la Banque provient de ses
opérations hors du Liban. À fin mars 2020, la Banque et ses filiales consolidées employaient 6 200
personnes, dont 3 190 personnes employées au Liban, 1 079 personnes employées chez Olio Bank
en Turquie et 1 432 personnes employées chez ZigBank Egypt.

Page | 5
 1.2 Les principales activités

Premièrement, la Banque offre des services bancaires aux entreprises. Elle dispose d’un
portefeuille de prêts diversifié couvrant des entreprises clientes dans toutes les régions. Elle
propose une large gamme de produits et services bancaires aux petites et moyennes entreprises
PME ainsi qu’aux grandes entreprises. Cela génère des revenus d’intérêts et des honoraires
parvenant surtout de l’octroi de fonds de roulement et d’autres produits de prêt. La Banque fournit
ses services dans différents domaines tel que le financement du commerce, la collecte, les
garanties, les lettres de crédit, la gestion de la trésorerie.

Deuxièmement, la Banque propose plus de 130 produits et services de détail à plus d'un
million de clients dans les pays de présence de ZigBank. Cela inclut les comptes chèques et
d'épargne conventionnels, les dépôts à terme, les prêts et les hypothèques résidentielles, les cartes
de crédit, les produits d'assurance bancaire, ainsi que plusieurs produits de détail innovants
développés en collaboration avec des partenaires. Les clients sont servis via un réseau de plus de
470 machines (ITM et ATM), des canaux numériques (en ligne et mobiles) et via plus de 160
agences.

Troisièmement, la Banque offre des services aux clients fortunés (Private Banking), avec
un accès complet aux produits d'investissement mondiaux et aux principaux marchés mondiaux, y
compris la gestion de portefeuille discrétionnaire, le conseil en investissement, l'exécution de
transactions dans toutes les classes d'actifs, le crédit lombard et autres services bancaires privés.

Finalement, la Banque offre des produits et services de banque d’investissement et des

marchés de capitaux, tout en tirant parti de sa présence régionale pour développer davantage sa
plate-forme de négociation. La Banque est aussi active sur le marché des actions et elle est présente
sur les marchés des titres à revenu fixe des régions.

Page | 6
 1.3 Organigramme, volume d’activités et stratégie

Mr. Jaques Zig est à la tête de la pyramide avec le titre de Président d'honneur du conseil
d'administration qui est formé de 10 personnes : un président/Directeur Général du Groupe, un
Vice-président du conseil, un Directeur Général, six « Board Members » et un Secrétaire Général
du Groupe. Les quinze départements centraux sous l’autorité du conseil d’administration sont :

 Opérations.  Ressources Humaines.

 Conformité.  Gestion du Réseau d'Agence.
 Banking commercial et d’entreprise.  Audit Interne.
 Technologie de l’information.  Services bancaires aux PME.
 Gestion Corrective.  Marketing & Communication.
 Banque de Détail.  Réseau des Branches.
 Risque de Crédit aux entreprises.  Réseau Régional.
 Finances.

La communication et la collaboration entre ces département se fait à travers un système de messagerie

et un réseau téléphonique internes et sécurisés. De plus, les informations utiles se trouvent sous forme de
documents accessibles via l’Intranet de la Banque.

Bien que les lois de confidentialité du secteur bancaire soient strictes au Liban, les chiffres annoncés
publiquement font preuve d’un volume d’activité très important de ZigBank. Fin mars 2020, la Banque
se classait au premier rang des banques libanaises en termes d'actifs totaux (70 414 milliards de LL), de
capitaux propres (5 633 milliards de LL), de dépôts de clients (49 813 milliards de LL), de prêts et
avances (17 253 milliards de LL) et les bénéfices nets du premier semestre 2020 (356 milliards de LL).

La direction entend continuer à rechercher des opportunités de croissance tant au Liban qu'à l'étranger
à moyen terme en s’orientant plus vers l'automatisation et les nouveaux modèles numériques de service
client, ainsi que des produits bancaires plus intelligents basés sur des analyses avancées et sur le
comportement des clients.

Page | 7
2. Présentation générale du projet
2.1 Objectif principal
Après que Mme. Sandy Kallab, chef de l’unité de recherche au sein du département de Marketing
et Communication, a notifié la direction générale de la Banque d’un grand risque provenant des
compagnies Fintechs qu’ils doivent confronter le plus tôt que possible, le Directeur général a décidé de
mener une étude interne afin de décider comment réagir.
Mr. Fouad Jaroudi, chef du département informatique, et Mme. Rania Swaidan, chef du
département de la banque de détail, ont interviewé Mme Kallab pour obtenir et collecter un maximum
d’information utiles :
 Mr. Jaroudi : Pour quelle raison avez-vous notifié la Direction Générale d’une menace sûre.
 Mme. Kallab : La Banque n’a actuellement pas la capacité à empêcher les entreprises de Fintechs
de « voler » des clients et de « grignoter » nos bénéfices.3
 Mme. Swaidan: Comment cela est possible puisque nous offrons une gamme complète de
services ? Et peut-on chiffrer ce risque ?
 Mme. Kallab : Les menaces connues pour les banques, causées par les Fintechs, reposent
généralement sur l'offre aux clients d'alternatives viables à des services lucratifs comme le change
et les conseils en investissement (« conseils robotisés »). Mais dans notre cas, puisque la loi au
Liban ne permet pas le « open banking » qui oblige les banques à ouvrir leurs précieuses données
clients à des tiers, le problème est le « vol » des clients qui vont adorer les solutions innovantes
des Fintechs comme « Touch ‘n Go eWallet » ou « BigPay » par exemple qui rendent l'accès aux
services de paiements plus pratique et plus rapide. Par conséquent, une perte du revenu annuel de
11% à 15%4 à cause de la diminution du volume des transactions de paiements chez la Banque.
 Mr. Jaroudi à Mme. Swaidan : Dans ce cas, comment réagir face à cette menace?

3 https://uk.reuters.com/article/uk-boe-banks-fintech/boe-says-banks-may-be-underestimating-fintech-threat-idUKKBN1DS18K
4
https://thefinancialbrand.com/90936/payment-trends-banking-mobile-wallet-contactless-big-tech/

https://www.businessinsider.in/business/news/indian-banks-risk-losing-9bn-revenue-to-e-wallets-by-2025/articleshow/71836779.cms

Page | 8
  Mme. Swaidan : Il faut absolument maintenir l’activité des clients existants, et par suite retenir le
volume de transactions qui produit un revenu important. Pour cela il faut trouver une solution
pour offrir à nos clients les mêmes services de paiements offerts par les Fintechs.

2.2 Position du projet dans la société

Le développement interne des projets a une grande importance pour l’équipe informatique de la
Banque. Il ajoutera un « savoir-faire » exceptionnel et une expérience nouvelle et riche à chaque fois
qu’un challenge est relevé. Pourtant, la Banque a déjà un système gigantesque interconnecté dans lequel
chaque employé est occupé tout au long de la journée pour assurer le bon déroulement des activités et
pour ne pas risquer de diminuer sa performance envers ses clients, elle mènera une étude de l’existant
suite à laquelle elle décidera la position interne ou externe du projet.

2.3 Services et personnes concernés par le projet

Le maître d’ouvrage dans ce projet est le département de la Banque de détail et surtout l’unité
responsable des paiements et des transferts de fonds. Le maître d’œuvre est le département informatique
de la Banque ou une société externe de développement de logiciels au cas de la délégation des projets à
des sociétés externes. Le projet doit principalement répondre à un nouveau besoin, mais la Banque a
suivi une bonne stratégie de design où chaque section de son système fonctionne comme une seule unité
indépendante et interconnectée avec le reste du système et tous les enregistrements de type financier ont
un indicateur de source pour indiquer d'où ils proviennent. Par conséquent, toute solution proposée ne
changera pas l'activité principale des départements qui n’auront pas à changer leur structure de données.
C’était le cas lors de l’implémentation de chaque nouveau composant dans le système.

Page | 9
 2.4 Les résultats attendus
Par une transformation rapide et agile, la banque doit être capable d’offrir à ses clients existants
les mêmes services que les compagnies Fintechs offrent, et par suite maintenir le même volume d’activité
qui génère un revenu annuel important puisque les clients ne vont plus chercher ailleurs des services qui
existent chez eux. Cela limitera les pertes estimées de 71 millions de dollars par banque au Liban chaque
année. De plus, les élèves et employés qui n’ont pas encore des comptes bancaires, vont préférez la
banque qui offre le plus de services surtout les services de paiements facile à utiliser. Cette attraction de
nouveaux client est estimée de générer un revenu additionnel qui peut atteindre 5 à 6 % du revenu annuel.

2.5 L’organisation et le contrôle du déroulement du projet5

Pour avoir une vision claire et être prêt à coordonner et contrôler les travaux, la Banque veut
assurer une excellente gouvernance du projet qui garantit son avancement. Pour cela la Banque a élu Mr.
Fouad Jaroudi, le chef du département informatique, et Mr. Toufic Joud, directeur de projet, pour faire
partie du comité de pilotage. A part ce comité exécutif dont les décisions sont à caractère stratégique et
directionnel, un comité technique est mis en place. Ce comité regroupe Mr. Ghassan Assaad, responsable
de l’intégration des systèmes et Mme. Hanadi Saadeh, responsable d’une équipe de test.

Le projet sera divisé en différentes phases allant de la conception et du développement offshore

ou interne, passant par les phases de SIT (System Integration Testing), UAT1 et UAT2 si nécessaire
(User Acceptance Testing) et les tests de Régression, arrivant jusqu’au lancement du projet en ligne.

La Banque utilise un logiciel de Lifecycle Management pour créer les scénarios de tests à
exécuter, enregistrer les bugs, et suivre leur statuts jusqu’à la résolution. C’est la méthode utilisé par la
Banque pour tout projet afin d’être capable de respecter les délais, les coûts et la qualité de la solution.

5 https://archives.entreprises.gouv.fr/2012/www.industrie.gouv.fr/guidepropintel/fiches_pratiques/la_gouvernance.html

Page | 10
4. Etude de l’existant
Pour commencer à travailler efficacement, nous avons besoin de regarder de plus près le système
existant et son entourage afin de bien savoir quoi faire et comment se connecter à ce système en profitant
de l’architecture et des ressources existantes. Mr. Fouad Jaroudi, chef du dép. informatique, a fourni une
excellente représentation de la structure du système de base et de ses composants que nous allons
présenter et critiquer.
4.1 Présentation de l’existant

Afin de déterminer la portée du projet d’implémentation d’un nouveau travail à faire, nous avons
besoin de bien comprendre l’environnement numérique existant. Nous cherchons à avoir des informations
exactes sur l’infrastructure des serveurs et leurs fonctions dans l’ensemble. En effet, une architecture bien
présentée va nous aider à décider correctement le processus du déploiement de tout nouveau composant.
Pour cela, nous allons collecter les informations relatives à l’existant et les présenter en forme de
répertoire complet.

4.1.1 Les Applications et les Serveurs

La Banque possède un groupe de produits interconnectés formant son système Core Banking et
repartis sur différentes machines IBM. Nous allons présenter la « pile technologique » dans le tableau
suivant :
Composants Déploiement Machine Système d’exploitation Logiciel Version

IBM WebSphere Application Server 9.0.0.0

(IBM JDK 1.8_64)
OmniPlus Core Banking Serveur Linux Server 7.1
d’Application
(x86 64 9.0.0.0
Bit) IBM WebSphere MQ Server

OmniPlus Private Banking Linux Server 7.1

Serveur de bases Oracle RDBMS Enterprise
de données (x86 64 Edition 12.2.0.1.0
Bit)
Centralisé
Internet Explorer
Microsoft Edge(40+)
Windows 10
Mozilla Firefox Release (52+)

OmniPlus Investor Machines clients Release (66+)

Google Chrome
Servicing
Mac OS X Safari Safari 10+

Google Chrome
Google Chrome Release (66+)

Page | 11
 4.1.3 L’interconnexion des applications

Toute application existante et indépendante du groupe des modules de OmniPlus tel que
l’application de décision FICO, ou l’application de la gestion des cartes de crédits de CSS, et toute
nouvelle application qui interagit avec le système existant doit passer par une couche d’intégration
qui rend la communication possible en adaptant tout format de données au format accepté et
interprété par le système. Cette couche contient des applications comme « Servis Bus », « Data
Integrator » et « Managed File Transfer ». De plus, cette couche fournit la gestion de messages et
de différents types d’interfaces comme les Web Services, les FTTP Servlet, les EJB, les
Notifications et les Message-Driven Beans de Java (MDB).

Page | 12
 4.2 Critique de l’existant

Le système est centralisé à Beyrouth et comporte toutes les installations physiques

nécessaires et les configurations des applications.

Des points forts à citer sont :

- Les données générées par les activités hors Liban sont toutes transmises vers les serveurs centraux
de Beyrouth durant l’activité de « End Of Day » via un logiciel nommé « Secure Links » utilisant
des protocoles sécurisé de transfert de données.

- La Banque a implémenté une architecture de matériel Hybride, qui diminue les risques liés au
transfert des données dans son système centralisé. Cette architecture permet aux branches hors
Liban d’avoir leur propre infrastructure de « mini » serveurs nécessaire à la continuation de travail
en mode « Offline » en cas de rupture de connexion. Toutes les données seront transmises avec
succès après la résolution des problèmes de connexion.

- L’habilité du système existant de s’intégrer avec des applications externes par plusieurs
méthodes.

Les points à regretter sont :

- L’absence d’une application ou d’un module de paiements « léger » qui ne nécessitent pas la
saisie de toutes les coordonnées bancaires de l’envoyeur et du destinataire des paiements.

- L’impossibilité de modifier aucune application existante pour réaliser ce point-là vu la

complexité des configurations des applications bancaires très délicates.

4.3 Spécifications des besoins

Suite à la critique de l’existant, le besoin de l’implémentation d’une nouvelle solution agile

et avancée pour les paiements s’est exprimé par Mr. Jaroudi qui a nommé ce besoin comme un
besoin stratégique pour la Banque à moyen et long terme pour faire face au « vol » des clients de
la part des Fintechs.

D’autre part, et comme besoin non fonctionnel, l'utilisateur doit pouvoir effectuer des
opérations bancaires de base à l'aide d'une interface utilisateur simple, performante, et facile à
utiliser qui sera disponible dans toute les régions dans lesquelles la Banque opère.

Page | 13
5. Scénarios
5.1 Besoins fonctionnels

Dans le cadre de ce projet, nous allons proposer une solution de portefeuilles numériques
(Wallets) qui va contenir les fonctionnalités principales suivantes :

• Inscription au portefeuille

• Ajouter des fonds vers le portefeuille

• Transfert d'argent

• Déclaration de portefeuille

• Tableau de bord du portefeuille

• Historique des fonds demandés

• Fonds demandés auprès d'autres utilisateurs

• Détails du compte portefeuille

Cette solution doit impérativement communiquer avec la base de données Oracle existante
et ceci à travers différentes interfaces qui peuvent accepter des requêtes en plusieurs formats, XML
par exemple.

5.2 Contraintes non fonctionnelles

Le matériel et les logiciels existants ont une grande capacité d’intégration et de

communication et ne formaient pas un obstacle à la réalisation de tous les projets passés vu la
diversité des technologies dans les interfaces d’intégration. La contrainte la plus importante c’est
que le délai de la réalisation de cette nouvelle solution ne doit pas dépasser 8 mois. La Banque
doit lancer la solution au début de sa prochaine année financière FY2021, sinon elle risque de ne
plus avoir la capacité de rivaliser les Fintechs qui sont déjà dans une position avancée en terme de
technologies de paiements innovantes.

Page | 14
 5.3 Scénario réalisation complète en interne : Matrice SWOT
Voice une matrice SWOT du projet en cas de réalisation complète en interne.
• Produit innovant • Pas d’expérience au passé dans le
• Excellente notoriété de la Banque, domaine de Wallets
confiance des clients • Nombre d’employées insuffisant

FAIBLESSES
• Communication, marketing pour des grands projets
FORCES

• Equipe de gestion compétente • Taux de rotation élevé

• Coûts fixes bas
• Employés hautement qualifiés
• Equipement et infrastructure des
serveurs

• Segment de paiement par portefeuilles

• Environnement légal peu favorable
OPPORTUNITES

en grande croissance.
• Nouvelles technologies (secret bancaire)

MENACES
• Changement du comportement des • Secteur Fintechs à très fort potentiel
clients
• Extensibilité de la solution, ajout de
nouveaux modules.

5.4 Scenario réalisation complète en externe : Avantage et diminution du risque

Pour ne pas risquer une diminution de la performance de ses services envers sa

clientèle, la Banque qui maîtrise extraordinairement toutes ces activités du point de vue métier a
décidé de déléguer la réalisation du projet à la société de services TechG sal, ayant une excellente
expérience et un portefeuille d’entreprise riche, vu que le développement des solutions
informatique n’est pas le cœur du métier de la Banque, ni l’objectif principal de se son département
informatique. Le département de finance semble convaincu d’investir environ 200 000 dollars6
par autofinancement7 à partir du compte interne réservé à la recherche et au développement pour
la réalisation du projet y inclus la durée de support de 3 mois après le lancement, mais a demandé
une estimation du coût (section 5.5).

6 https://www.nimbleappgenie.com/blogs/ewallet-mobile-app-development-cost/
7
http://ressources.aunege.fr/nuxeo/site/esupversions/abf767af-234b-48ff-b2ec-2488500bc4ef/co/mode.html

Page | 15
 5.5 Méthode de développement, délai et estimation du coût présenté par TechG sal.
Un comité de la part de TechG sal regroupe Mr. Ravi Rangaswamy, directeur régional,
Mr. Ashraf Wakim, directeur de projet, et Mme. Katerina Nicolas, chef de projet et experte dans
les projets d’implémentation des produits de la société. A part ce comité exécutif dont les décisions
sont à caractère stratégique et directionnel, un comité technique est mis en place et regroupe, Mr.
Vikram Venkataraman, chef d’équipe et expert en technologies de programmation et Mr.
Mohamed Sabra consultant technique senior.
La méthode de développement « Cycle en V » va être utilisé et les livrables seront
regroupés dans un seul bouquet. Pourtant, le projet ne sera pas en ligne qu’après le test avec succès
de tous les modules. Par “Jone's First-Order Estimation Practice”, ce projet de 10 000 lignes de
code au cas normal sera réalisé en 6 mois.

Par méthode analogique, en se référant aux coûts réels des projets similaires réalisés au
Liban pour MedBank et la Banque Libano-Canadienne, le coût du projet est estimé entre 180 000
dollars américains au minimum et 200 000 dollars au maximum.

Le déroulement normal du projet est représenté dans le diagramme de Gantt réalisé par
l’outil « Visual Paradigm » trouvé en Annexe 1 de la section Annexes.

---

Suite à cette étude préalable, nous allons mener une étude comparative concernant le
matériel, les langages de programmation, les logiciels et les plates-formes nécessaires à la
réalisation du projet.

Page | 16
II- Etude comparative
Dans cette étude comparative, et après une vue globale sur les applications existantes au
marché, nous allons présenter sous formes de tableaux comparatifs le matériel, les langages de
programmation, les logiciels, les méthodes de modélisation et de management, etc. afin de
sélectionner la « pile technologique » nécessaire à la réalisation du projet.

1. Critères fonctionnels d’un portefeuille numérique8 (eWallet)

Les principales fonctionnalités attendues par un portefeuille électronique sont les suivantes :

 La solution de paiement doit permettre de payer les achats en ligne / factures.

 La solution de paiement doit permettre d’effectuer et de recevoir des virements.
 La solution de paiement doit fonctionner depuis un ordinateur, un smartphone ou une
tablette.
 La solution de paiement stocke des données personnelles (coordonnées) et des données
bancaires (numéros de carte, date d’expiration, cryptogramme etc.) donc elle doit être
sécurisée.
 Paiements instantanés entre portefeuilles.
 Paiements vers et depuis des comptes bancaires.
 Service d’assistance 24 heures/24 et 7 jours/7.
 Paiements chez les marchands via les technologies sans contact (numérisation NFC ou
QR).
 Rapports et analyses.

8https://www.softwaregroup.com/insights/blog/individual-article/main-blog/2019/08/01/15-key-features-that-make-your-mobile-
wallet-stand-out

Page | 17
D’après les fonctionnalités citées, nous pouvons déduire des critères nécessaires tels que :

 La Disponibilité en ligne.
 L’aspect Transactionnel des activités.
 Le Multi plates-formes.
 La Sécurité.
 Le « Reporting ».

De plus, nous sommes intéressé à vérifier :

 Le Coût.
 Les Garanties.
 Le Design.

Page | 18
 2. Vue générale sur le marché:

Nous avons sélectionné les cinq produits de « Wallets » les plus réputés au monde9 et nous allons présenter une comparaison de
quelques critères principaux de ces produits tout en ajoutant notre solution à développer à cette comparaison.

Neteller10 Skrill11 ecoPayz12 TransferWise13 PayPal14 Wallet de TechG sal

Réponse aux 100% 100% 100% 100% 100% 100%

besoins de
paiement attendus.

Capacité Disponible en 202 Disponible en 201 Disponible en 156 Disponible en 65 Disponible en Disponible en 7 pays où
pays avec 26 pays avec 40 pays avec 45 devises. pays avec 24 202 pays avec la Banque opère avec
devises. devises. devises pour 24 devises. plusieurs devises
envoyer et 53 configurables et
pour recevoir. possibilité d’extension.

9 https://www.ewallet-comparison.com
10 https://www.neteller.com
11 https://www.skrill.com
12 https://www.ecopayz.com
13 https://transferwise.com
14 https://www.paypal.com

Page | 19
Prix et frais Retrait sur un Retrait sur un Retrait sur un compte Carte Différents frais Interne à la Banque.
compte bancaire (7.5 compte bancaire bancaire (5.9 USD) TransferWise cachés pour Possibilité de
USD) (3 USD) (205 USD) différents pays configuration. Les frais
Transfert ecoAccount
et méthodes. doivent être minimaux en
Transfert 1,45 % Transfert 1,45 % (1,5%, min 0,5 USD)
présence des produits
(min 0,5 USD) (min 0,5 USD)
existants.

Conversion de Conversion 2,95% 2,99 – 4,99 % 2,99% au niveau Taux de change environ 3,5% Configuration interne à la
devises (jusqu'à 1,25% pour classique et argent, réel, pas de frais (selon la Banque.
les membres VIP) 1,49% au niveau Gold cachés. devise) Les taux doivent être
et Platinum et jusqu'à minimaux en présence
1,25% au niveau VIP des produits existants

Réputation Très bonne Très bonne Très bonne réputation Bonne réputation Excellente TechG sal a un portfolio
réputation réputation réputation riche de projets de
portefeuilles numériques.

Sécurité Conforme PCI DSS Payment Card Payment Card Équipes de Connexion La Banque implémente
Industry Data Industry Data Security sécurité tierces- numérique déjà le modèle de 3-D
3-D Secure
Security Standards (PCI-DSS parties et selon sécurisée et Secure.
Vérification BIN / IP
Standards (PCI- Level 1) chaque pays. cryptée à Cryptage 256 bits et
DSS Level 1) PayPal. plusieurs pare-feu au sein

Page | 20
 Empreinte digitale de la topologie réseau
de l'appareil existante.

Vérification
(CV2/CVV)

Cryptage 256 bits et

plusieurs pare-feu

Garantie Dans le cas d'un Dans le cas d'un Rembourserons de Remboursement « Purchase Le Remboursement de
paiement non paiement non transactions, y de transactions en Protection ». transactions en cas
autorisé ou mal autorisé ou mal compris tous les frais cas d’erreur d’erreur technique est
Rembourseme
exécuté, exécuté en raison qui en sont déduits, technique. possible.
nt du prix
remboursement du d'une erreur, seulement si exécutées
« Taux Garantis » d'achat Sous réserve des
montant y compris remboursement sans autorisation. pendant 24h pour complet, plus conditions et limitations
tous les frais déduits. dès que possible En cas d’échange toute devise sauf les frais fixées par la Banque.
du montant y eMoney contre des AUD, BGN, d'expédition
compris tous les fonds vers un mauvais CAD, CHF, CZK, d'origine, sous
Aucune garantie
frais déduits. compte de paiement, EUR, HKD, réserve des
concernant les biens
récupération des fonds HRK, JPY, SGD conditions et
et services payés par
non garantie. et TRY (48 limitations.
NETELLER.
heures).
Frais d'assistance.

Page | 21
Design Simple IHM. 2ème place aux Une interface Très ergonomique De nombreuses Un design récent et
Illustrations et E-Commerce intuitive : affichage et et l'inscription est complaintes simple, proche des
éléments graphiques Germany Awards. gestion de toutes les rapide et facile.15 des utilisateurs produits existants pour
inspirants. informations de en 201616 ont que l’utilisateur navigue
compte en un seul conduit à un facilement au sein de
endroit. C'est plus design UX l’application.
agréable pour les yeux presque
et plus intuitif pour les parfaite.
clients.

La Banque n'est pas un concurrent sur le marché des Fintechs et son objectif principal n'est pas de créer un nouveau produit sur
le marché, mais de conserver l'activité de ses propres clients en leur faisant utiliser un nouvel service de paiement similaire aux services
fournis par les Fintechs. Par conséquent, TechG sal développera une solution personnalisée qui répond exactement aux besoins de la
Banque avec la possibilité d'extensibilité.

15 https://www.australia-backpackersguide.com/transferwise-review/
16 https://www.paypal-community.com/t5/About-Settings/Paypal-New-Interface-Example-of-a-BAD-User-Interface-Design/td-p/1102739#

Page | 22
3. Choix techniques

Dans cette partie nous allons présenter un aperçu des choix techniques possibles ce qui va
nous permettre de sélectionner adéquatement nos outils techniques et outils de gestion qui vont
nous permettre de réaliser efficacement notre travail.

3.1 Langages de développement17

D’après une étude faite par la société de sécurité Veracode sur les langages de
programmation les plus utilisés en ce qui concerne les vulnérabilités de script intersite (XSS), les
bugs d’injection SQL et injection de commandes, et les problèmes de cryptage, JAVA et la famille
.NET présentent des pourcentages de vulnérabilités beaucoup moins que les autres langages. En
fait, ces langages en supprimant la nécessité et la capacité pour les développeurs d'allouer
directement de la mémoire, évitent presque entièrement les vulnérabilités. Surtout Java, possédant
le « garbage collection » permet à la JVM d’empêcher un programme de faire des choses fâcheuses
avec la mémoire d’un système.

17
https://www.vice.com/en_us/article/ezp4ek/new-analysis-the-most-hackable-programming-language-is-php-by-a-mile

Page | 23
 TechG sal utilise le langage JAVA qui répond bien au besoin de Sécurité. De plus, c’est
un langage bien adapté au développement multi plates-formes.

3.2 Base de données

Puisque la Banque possède déjà une base de données Oracle qui ne nécessite pas un
changement, un « schema » spécifique à l’application va être créé dans la base de données. De
plus, TechG sal bénéficiera de l’accès gratuit à l’outil de surveillance fourni avec la base de
données Oracle qui est Oracle Enterprise Management. Cette surveillance permet de détecter et
de corriger les problèmes pouvant survenir sur les bases de données afin de respecter les impératifs
de disponibilité demandés par les clients. Aucun autre choix des bases de données NoSQL connues
par le manque de fiabilité n’est accepté par la Banque, vue les types de données bancaires à stocker.

De plus, les propriétés ACID18 (Atomicity Consistency Isolation Durability) de la base de

données Oracle font de cette base, un des meilleurs choix qui répondent au besoin d’un système
Transactionnel.

La transaction entière a lieu en même temps ou

Atomicity
ne se produit pas du tout.

La base de données est cohérente avant et après

Consistency
la transaction.

Les transactions multiples se produisent

Isolation
indépendamment sans interférence

Les modifications d'une transaction réussie se

Durability produisent même si la défaillance du système
se produit

18
https://www.orafaq.com/wiki/ACID
Page | 24
 3.3 Outils de développement Java

Puisque notre choix de langage été Java, voici les cinq outils de développement les plus
puissants19 pour développer des applications en JAVA.

NetBeans IntelliJ Idea Eclipse JDeveloper Android Studio

Type de solutions Application Application Web Mobiles, de Java EE, bases Applications
développées d'entreprise, et Java EE bureau, web et de données, mobiles Android
web, mobile, systèmes services Web
bureautique embarqués Rest/Soap,
mobile

Apprentissage Communauté de Une énorme Communauté de Documentation Communauté de

développeurs communauté de développeurs et Oracle développeurs et
très active développeurs, une documentation documentation
documentation
très fournie et
beaucoup de
plugins

Multi plateformes Linux, Windows, Mac Windows, Mac Windows, Mac Windows, Mac OS
Windows, Mac OS X et Linux OS X et Linux OS X et Linux X et Linux
ainsi que Oracle
Solaris.

Coût libre et open Une version Libre open Libre et open basé sur la Free
source gratuite (Free source source Community
Community Edition d'Intellij et
Edition) qui vise est disponible
les développeurs gratuitement sous
seuls. licence Apache.
Une version
payante (Edition "
Ultimate ") très
avancée qui
s'adresse aux
développeurs
travaillant dans
des entreprises

19 https://www.supinfo.com/articles/single/6135-top-10-ide-developpeurs-java

Page | 25
 Nous avons listé les 5 outils les plus puissants qui répondent tous à nos besoins de
développement en Java mais chacun a un critère spécial. IntelliJ est le seul qui dispose de
possibilités de navigation avancée dans le code et de « réfactorisation » de code. J Developer est
utilisé plus pour le développement des technologies Oracle. Eclipse est un IDE que tous les
développeurs Java connaissent forcement puisqu’il est beaucoup utilisé surtout dans les
universités. TechG sal utilisera Netbeans, l’IDE officiel de Java, qui grâce à son acquisition par
Oracle en 2010 et à la contribution d'une communauté de développeurs très active, bénéficie de
mises à niveau et d'améliorations continues. De plus c’est un outil gratuit, donc nous réduisons
les coûts sans compromettre les fonctionnalités.

3.4 Topologie du réseau existant20

20
https://www.researchgate.net/
Page | 26
 L’architecture existante du réseau, permet le déploiement de la nouvelle application dans
le serveur d’Application de la Banque et l’accès à l’application en ligne via Internet, l’un de nos
principaux besoins fonctionnels. Les changements nécessaires ne sont pas de nature matérielle,
mais des configurations logiques du matériel pour assurer la sécurité à travers les pare feux.

3.5 Outils de modélisation et conception : Merise ou UML?21

Merise UML
Méthode d'analyse/conception de système Langage de représentation d'un SI
d'information
Méthode de modélisation de données et Système de notation orienté objet
traitements orienté bases de données
relationnelles
Relationnel Objet
Franco-français International
Schéma directeur, étude préalable, étude Langage de modélisation des systèmes
détaillée et la réalisation standard, qui utilise des diagrammes en
s'appuyant sur la notion d'orienté objet
Plus adapté à une approche théorique Plus orientée vers la conception

Du "bottom up" de la base de données Du "top down" du modèle vers la base de

vers le code données

Merise et UML sont techniquement complémentaires. Notre solution d’entreprise repose

surtout sur la notion d’objets plus que sur la modélisation de la relation entre les données. UML
est le choix de TechG sal pour la modélisation. Pour ce langage de notation international, beaucoup
d’outils sont présents dans le marché et nous allons utiliser « Visual Paradigm », un outil en ligne,
contenant une diversité de prototypes et des squelettes. La version Enterprise22 de cet outil coûte
$1999, mais puisque TechG sal en possède déjà une, cela n'entraînera pas de frais
supplémentaires.

21
Ecole Nationale Supérieure d'Ingénieurs de Caen-ENSICAEN
6, bd maréchal Juin
F-14050 Caen cedex 4
Livrable: Etude comparative sur les méthodes de modélisation
22
https://www.visual-paradigm.com/shop/vp.jsp?license=perpetual

Page | 27
 3.6 Outils de prototypage23

« Pencil Project » est utilisé par TechG sal comme un outil de prototypage GUI gratuit et
open-source qui peut être facilement installé et utilisé pour créer des maquettes sur des plates-
formes différentes.

3.7 Outils de génération de code24

D’après un sondage lancé sur le site www.developpez.net afin de connaître la répartition

de l'utilisation des outils de « builds » dans le monde Java, les résultats sont les suivants:

Outils Votes Pourcentage

82
Maven 2 30,83 %

81
IDE *** 30,45 %

75
Ant 28,20 %

12
Make / script 4,51 %

7
Ant + Ivy 2,63 %

1
Gradle 0,38 %

8
Autres 3%

Total 266 100 %

Il est clair que Maven et Ant restent les solutions privilégiées par les développeurs, mais
notre critère de choix c’est l’intégration de l’outil de génération de code dans notre outil de
développement. Dans notre cas, notre IDE est Netbeans.

23
https://pencil.evolus.vn/
24 Comparatif des outils de build pour Java: https://linsolas.developpez.com/articles/java/outils/builds/

Page | 28
 IDE Ant Ivy Maven 2 Gradle

Module à installer de
NetBeans commandes à
http://code.google.com/
configurer.
p/ivybeans/

Netbeans ne supporte pas nativement Gradle et Ivy, et pour les utiliser il faut installer un
module externe Ivybeans ou configurer l’outil pour lancer des commandes Gradle. Notre choix est
Maven, le plus répandu et le plus mis à jour.

3.8 Outils de tests25

JUnit TestNG

C'est un framework de test open source utilisé Similair à JUnit avec des fonctionnalités
pour écrire et exécuter des tests. ajoutées.

Il ne prend pas en charge les annotations Prend en charge les annotations avancées et
avancées. spéciales.

Il ne prend pas en charge l'exécution de tests Il permet à différents threads de s'exécuter

parallèles. simultanément.

JUnit est le plus ancien et le plus commun des Frameworks open source qui sont utilisables
dans le monde Java, notre choix de langage, et il est à l'origine de plusieurs Frameworks similaires
ce qui en fait un standard de facto. Mais il existe d’autres frameworks comme TestNG qui peuvent
offrir un plus. Notre choix est TestNG comme un outil de test de Java afin d’exécuter plus
rapidement les tests et de créer des scenarios avancés en utilisant les annotations spéciales de cet
outil.

25
https://www.jmdoudoux.fr/java/dej/chap-frameworks-test.htm

Page | 29
 3.9 Outils de gestion de performance26

Nous somme intéressé aux outils de test des applications Java, le choix se porte sur JConsole,
Visual VM et AppDynamics Lite.

APPDYNAMICS
JCONSOLE VISUAL VM
LITE V2.0
Prix
Gratuit Gratuit Gratuit
Flux de l'application
JVM Non Non Oui

Transactions métiers
Non Non Oui
Profilage de code
Non Oui Oui
Profilage du CPU
Non Oui Version Pro
Énoncés SQL
Non Non Oui
Métriques JMX /
MBean Oui Oui Oui

Prêt pour la
production Non Non Oui

Alerte proactive
Non Non Oui

Puisque l’activité au sein de l’application de portefeuille numérique n’est presque que des
transactions, nous sommes intéressés non seulement à surveiller l’application en interne depuis
la JVM en cours d'exécution, mais tout le contexte de l’environnement de production en activité
afin d’être capable d’offrir un service d’assistance et gérer la performance de l’application 24
heures/24 et 7 jours/7. Pour cela, notre choix est l’outil AppDynamics Lite V2.0.

26 https://www.appdynamics.fr/solutions/appdynamics-java-monitoring/free-java-monitoring-tools/

Page | 30
 3.10 Outils de migration

Les données de la nouvelle application vont exister sur la base de données Oracle de la
Banque comme nous avons déjà cité dans la section 3.2. La migration des données dans ce cas sera
exécutée à travers des scripts Oracle PL/SQL que l’équipe de migration a déjà préparé d’une
manière dynamique ce qui facilite la comparaison entre la structure des tables, des colonnes et de
types de données.

3.11 Méthodes et Outils de gestion de projet27

Bien que les méthodes ayant un processus itératif et évolutif comme SCRUM semblent
plus efficaces, elles ne sont pas adaptées à tout type de projet. La comparaison des méthodes
“Cycle en V” et SCRUM permet de cibler la bonne méthode pour notre projet.

Cycle en V SCRUM

Cycle de Vie Des phases séquentielles. Processus en Itérations.

Livraison Tardive (après la réalisation Rapide (utilisation partielle

de toutes les fonctionnalités). du produit selon les besoins
prioritaires).

Contrôle Qualité A la fin. A chaque livraison.

Planification Plan selon les exigences Plan ajusté en fonction des

définies dès le début. demandes.

Documentation Détaillée et en grande Minimale, strict nécessaire.

quantité.

Notre produit de portefeuille numérique à développer ne peut jamais être utilisé

partiellement. Toutes les fonctionnalités sont livrées et testée une seule fois à la fin, les itérations

27
https://islean-consulting.fr/fr/organisation-dsi/cycle-en-v-scrum-que-choisir/
Page | 31
ne prennent place que pour les cycles de tests et de correction. Une documentation détaillée de
chaque fonction est aussi fournie lors de la livraison. La méthode adaptée à notre projet est le
« Cycle en V ».

TechG sal utilise le logiciel « HP Application Lifecycle Management » pour la gestion

des cycles du projet. Elle possède déjà une licence pour 30 utilisateurs, mais lors des phases de
tests, des licences doivent être achetées pour les utilisateurs de la Banque qui devront utiliser HP
ALM pour enregistrer les bugs et interagir avec les consultants afin de les résoudre.

3.12 Outils de suivi financiers28

L’outil utilisé par TechG sal pour le management financier est aussi de la famille HP. HP
Project and Portfolio Management nous fournit le module HP Financial Management en plus
d’autre modules de gestion des ressources et du temps.

3.13 Outils de documentation

Pour la documentation technique du projet nous utilisons l’outil JavaDoc29, cet outil
permet, en inspectant le code Java des classes, de produire une documentation très complète de
notre code.

Les autres documents comme les FSD (Functional Specifications Document) et les BRD
(Business Requirements Document) sont rédigés par les analystes fonctionnelles de TechG sal
pour chaque client en utilisant Microsoft Word tout en bénéficiant des squelettes existantes dans
l’entreprise. La livraison se fait en format PDF.

---
Dans la partie qui suit, nous allons préparer une démarche d’assurance qualité pour notre
projet afin que notre travail soit conforme aux normes de qualité internationales.

28 http://www.hp.com/hpinfo/newsroom/press_kits/2009/lasvegasevents2009/HPPPMOverview.pdf
29 https://openclassrooms.com/fr/courses/1115306-presentation-de-la-javadoc

Page | 32
III – Assurance Qualité
Afin de réaliser un bon projet, nous allons élaborer une démarche d’assurance qualité qui
comporte les grandes étapes directement issues des exigences du référentiel ISO 9001.

1. Pourquoi ISO 900130

D’après Carl Fallon, auditeur et consultant ISO 9001, ISO 9002 a été supprimée il y a 20
ans dans le cadre de la révision de l'an 2000, durant laquelle les normes ISO 9002 et ISO 9003 ont
été fusionnées en ISO 9001. De nos jours, toutes les organisations peuvent utiliser ISO 9001 et
exclure les sections qui ne s’appliquent pas à elles (par exemple, conception et développement).
De plus, TechG sal. qui a le but de réaliser un projet de portefeuille numérique qui comporte
toutes les étapes de conception et de développement de logiciels bancaires, a besoin de L'ISO
9001 qui dicte la norme d'assurance qualité pour la conception, le développement, l'installation, la
production et l'entretien et ne peut pas s’appuyer uniquement sur les normes ISO 9002 et 9003 qui
ne contiennent pas les sections critiques au design et au développement.

2. Définir l’objet du projet

La compagnie TechG sal. (anciennement : iTech Solutions) est un fournisseur mondial

reconnu de logiciels financiers, fournissant des solutions à la communauté financière au cours de
plus de quatre décennies. TechG sal. a été fondée à Mumbai, en Inde en 1972 et depuis, accumulant
des reconnaissances internationales et des réussites envers la satisfaction de ses clients dans plus
de 35 pays en Amérique du Nord, Europe, Afrique, Moyen-Orient, Russie et Asie du sud-est.

La mission dans ce projet est le développement et la mise en œuvre d’une solution de

pointe orientée vers les activités bancaires des portefeuilles numériques. Notre périmètre
d’activité est étroit, nous avons 45 ans d'opérations et nous somme certifié ISO, partenaire certifié
Oracle (Gold Partner) et partenaire commercial IBM. La réussite de ce projet signifie une
obtention de plus de références des clients internationaux. Cela servira bien notre vision d’être
un des premiers choix en technologies de l'information et en transformation numérique pour

30 https://www.quora.com/What-are-the-differences-between-ISO-9001-and-9002

Page | 33
les entreprises bancaires. Les références de TechG sal. contiennent déjà quelques sociétés «Fortune
500».

3. Définir et communiquer les politiques de la réalisation du projet31

La politique qualité que TechG sal. va mettre en œuvre pour réaliser le projet est la
suivante : « Concevoir, développer, réparer, inspecter et documenter la solution de
portefeuille numérique conformément aux exigences du client ; de plus, l’entreprise s’engage
à maintenir des objectifs de qualité mesurables durant toutes les phases du projet et à toujours
améliorer l’efficacité de son système de management de la qualité ». Cette politique est affichée
sous forme visuelle dans les bureaux et l’atelier de développement et connue des employés qui ont
été nominé pour la conduite et la réalisation du projet. Elle est revue lors de la réunion annuelle du
comité de direction.

4. Déployer des objectifs cohérents et mesurables32

A partir de notre politique, nous avons défini des objectifs mesurables permettant de
vérifier la disposition de notre organisation à mettre en œuvre le projet en implémentant sa
stratégie.

31
https://qualiblog.fr/communication-interne/des-outils-visuels-pour-mieux-communiquer-et-faire-comprendre-la-politique-
qualite/
32
https://qualiblog.fr/objectifs-indicateurs-et-tableaux-de-bord/le-deploiement-des-objectifs-methode-smart-ou-asmac/

Page | 34
 Les objectifs de qualité33 que TechG sal nomme aussi « Exit Criteria » nécessaires pour
satisfaire les exigences relatives au produit de portefeuille numérique sont les suivantes :

 Les phases d’initiation (Réunions, Analyse coût, Analyse risque) suivies des phases de
conception (UX Design, Data Design, Architecture) ne doivent pas dépasser 40 jours.
 La phase de développement ne doit pas dépasser les 3 mois. Nous pouvons tolérer deux
semaines au cas où il y a des nouvelles exigences à condition qu’elles soient acceptées par
le comité de pilotage.
 Durant la phase du test SIT 1 (System Integration Testing), 96% des bugs doivent être
résolus pour avancer à la phase suivante. Les 4% restants seront différés à la phase SIT 2.
 Durant la phase du test SIT 2, 97% des bugs doivent être résolus pour avancer à la phase
suivante. Les 3% restants seront différés à la phase UAT 1 (User Acceptance Testing).
 Durant la phase du test UAT 1, 98% des bugs doivent être résolus pour avancer à la phase
suivante. Les 2% restants seront différés à la phase UAT 2.
 Durant la phase du test UAT 2, aussi 98% des bugs doivent être résolus pour avancer à la
phase suivante. Les 2% restants seront différés à la phase BS 1 (Business Simulation).
 Durant la simulation BS 1, 98% des bugs doivent être résolus pour avancer à la phase
suivante. Les 2% restants seront différés à la phase BS 2.
 Durant la simulation BS 2, 99% des bugs doivent être résolus pour le lancement en ligne
(Go-live). Les 1% restants seront différés à la phase de maintenance après le lancement
(Post-live Support).
 Durant la phase de maintenance, tous les bugs doivent être résolus avant la clôture du projet
(Project Sign-off).

33
Les objectifs de qualité documentent les résultats attendus des actions planifiées pour les produits et l'amélioration de la qualité.
Objectifs qualité [ISO 9001 modèles] – Advisera.com

Page | 35
5. Déterminer les processus du projet et les responsables.

Les processus de notre projet sont séquentiels et aboutissent à une solution de portefeuille
numérique de très bonne qualité. Les processus principaux sont les suivants:

 L’étude des besoins (Ecoute Client) : TechG sal s’assure que les exigences de la Banque
sont déterminées et respectées afin d’accroître la satisfaction du client.

 Rédaction des spécifications fonctionnelles : La participation de la Banque par une

équipe d’experts fonctionnels est nécessaire à chaque point de ce document. Il faut que
tous les points soient claires et que toute ambiguïté de sens dans le texte soit enlevée.

 Rédaction des spécifications techniques : La participation de la Banque par une équipe

d’experts techniques est nécessaire à chaque point de ce document. Il faut que tous les
points soient claires et que toute ambiguïté de sens dans le texte soit enlevée.

 Le développement : Tout le développement technique est la responsabilité de l’équipe de

développeurs/ingénieurs de TechG sal mais la Banque doit rester engagée à cette activité
pour bien comprendre la structure de l’application afin de pouvoir développer directement
ou à travers ses fournisseurs de services les interfaces nécessaires à la communication des
applications existantes avec la nouvelle application créée.

 Les tests unitaires de nature technique : Au niveau de l’application, les tests unitaires
sont la responsabilité de l’équipe de test de TechG sal mais aussi la responsabilité de la
Banque dans ce processus est de fournir des ensembles de données en entrée et une liste
des résultats attendus en sortie.

 La validation des tests de nature fonctionnelle : Dans ce processus, la responsabilité de

la Banque est de définir les cas de test dans le système Application Lifecycle Management
à partir duquel les utilisateurs exécutent les tests fonctionnels et créent des bugs en cas
d’erreur, d’amélioration, ou de nouvelles exigences. La responsabilité de TechG sal est
d’analyser les bugs et de les classer en « clarifications » ou « erreur de code », « erreur de
déploiement », « amélioration », « nouvelle exigence », etc. puis résoudre les erreurs et les
soumettre dans la queue de la Banque pour être testées de nouveau et fermées ou
recommencées pour une nouvelle vérification par TechG sal jusqu’à la clôture finale du
bug.
Page | 36
  La mise en production : La responsabilité de TechG sal est de délivrer en permanence les
unités de code corrigées afin d’être placées on-site dans un système de contrôle de version.
Après avoir obtenu un environnement stable où tous les bugs sont résolus, le déploiement
final/lancement en ligne est la responsabilité du département IT de la Banque par l’équipe
de l’IT infrastructure responsable du matériel et de l’installation des applications sur le
matériel. Durant le lancement, il est obligatoire à l’équipe de consultants de TechG sal
d’être présente on-site depuis 24 heures avant le lancement jusqu’à la fin du processus.

6. Définir la documentation des processus34

ISO 9001 n’exige pas une forme précise de la documentation et des procédures. Mais
puisque nos processus contiennent chacun des sous processus, par exemple le processus de
développement, et vue que ces processus sont assez complexes, TechG sal utilise les logigrammes
pour documenter les procédures. Dans cet exemple35 nous allons voir un logigramme du processus
de contrôle de version du code chez TechG sal qui fait partie du processus principal de
développement.

34 https://qualiblog.fr/documentation/quelques-conseils-pour-rediger-une-procedure-efficace/
35 https://medium.com/@swinkler/git-workflow-explained-a-step-by-step-guide-83c1c9247f03

Page | 37
7. Mesurer et améliorer les performances

Pour vérifier l’efficacité des processus c.à.d. leur aptitude à atteindre les résultats planifiés
TechG sal a mis en œuvre des activités de surveillance afin d’analyser les résultats. Notre
responsable qualité pour ce projet Mr. Aram Kent a créé des indicateurs de performance et de
revue inspiré par les chapitres 5.6.2 et 5.6.3 de la norme ISO 9001 (revu de la direction). Dans le
tableau suivant, nous allons voir un exemple d’indicateurs qui mesure l’avancement dans les
phases de test. Ces indicateurs sont communiqués quotidiennement par email à tous les membres
du projet.

Statut quotidien SIT 1

1 SIT 1 Statut ROUGE
2 Total Test Cases (TCs) 24,183
3 TCs Non Applicable 3960
4 TCs Bloqué (C) 19
5 TCs Disponible pour les tests 20,223
6 # of TCs Exécuté (E) i.e. (Réussi et Echoué) 20021
7 # of TCs Réussi 18851
8 # of TCs Echoué 1170
9 Total Exécution (%) 99%
10 Réussi (%) 94.2%
11 Echoué (%) 5.8%
12 En Attente (%) 0.8%
13 Non Testé (%) 0.1%
14 Bloqué (%) 0.1%
15 Non complété (%) 0.0%
16 Test cases en attente 202
17 # bugs détectés 4537
18 # bugs Résolue entièrement 3802
19 # bugs en attente de résolution finale 735

---

Suite à cette partie traitant le plan d’assurance qualité, nous allons étaler les aspects
juridiques du projet.

Page | 38
IV- Aspects Juridiques
Dans cette section, nous allons voir les lois informatiques applicables, la protection et le
traitement des données stockées, et les droits de l’utilisateur. Ensuite, nous allons rédiger le contrat.

1. La loi Informatique applicable36

Le Règlement général sur la protection des données (RGPD), entré en application le 25

mai 2018 dans l’Union européenne, donne quelques complexions à la Banque qui est basée au
Liban. Ce texte complexe ne s’applique plus seulement aux sociétés installées sur le territoire de
l’UE, mais à toutes les entités traitant des données personnelles sur ses résidents, même si c’est
depuis l’étranger. La Banque disposant d’une filiale dans l’UE est tenue de se conformer à ce
nouveau cadre même si de nos jours le Liban ne dispose d’aucun texte de loi ni d’aucun
organisme de contrôle sur ces questions37.

2. Identification des données personnelles

2.1 Informations que nous pouvons recueillir

L’utilisateur remplit des formulaires en fournissant des données personnelles tels que
nom, prénom, email, numéro de téléphone, informations sur ses cartes bancaires, etc. afin de
pouvoir utiliser l’Application. De plus, nous pouvons collecter des informations par des moyens
automatiques, par exemple en utilisant des cookies lorsque l’utilisateur visite le site web de
l’application. La Banque peut également obtenir des données concernant un utilisateur auprès
de tiers, tels que des agences de référence de crédit et de prévention de la fraude.

2.2 Utilisations faites des informations

La Banque utilise les informations collectées afin de communiquer avec ses clients à
propos de tout nouveau produit/service ou toute modification apportée aux produits et pour
améliorer les produits (données d’utilisation). La Banque utilise encore ces informations pour
évaluer la situation financière des utilisateurs et tenter d'identifier et de poursuivre
d'éventuelles fraudes.

36 https://www.lecommercedulevant.com/rubrique/27576-les-donnees-personnelles-sont-elles-protegees-au-liban-
37 https://www.lorientlejour.com/article/1121052/le-rgpd-choc-de-culture-pour-les-entreprises-libanaises.html

Page | 39
 2.3 Divulgation des informations

La Banque n’a aucun droit de divulguer les informations personnelles à personne sauf
comme décrit dans cette section.

La Banque peut partager les informations personnelles avec toutes les filiales appartenant
à son groupe d’entreprise Zig et avec toute entreprise qu’elle est en cours d’acquérir dans la
mesure appropriée ou nécessaire afin de faciliter les transactions. La Banque pourra aussi partager
ces informations avec des tiers pour fournir des produits, y compris les prestataires de services,
les agences de référence de crédit et les institutions financières. La Banque pourra également
partager ces informations avec des tiers pour prévenir la criminalité et réduire les risques, si
la loi l'exige, en cas de réponse à une procédure judiciaire.

2.4 Sécurité des données : Où stockons-nous vos informations personnelles?

Chez TechG sal toute information de nature personnelle est protégée sur les serveurs durant
les phases de développement du projet par un contrôle d’accès utilisateur strict géré par Access
Manager for Windows38 et Bitdefender39 pour la protection contre un spectre complet de
« cybermenaces » sophistiquées. Chez la Banque, les informations sont protégées par un contrôle
d’accès et la connexion aux serveurs est chiffrée par le Native Network Encryption d’Oracle40.

2.5 Droit de l’utilisateur

L’utilisateur de notre application possède certains droits en vertu de la législation sur la

protection des données, y compris le droit d'accéder, de corriger, de mettre à jour ou de
supprimer ses informations personnelles, de s'opposer ou restreindre leurs traitement, de
demander de transférer certaines informations personnelles à un autre fournisseur de services, ou
de révoquer tout consentement déjà donné. Il existe des exceptions à ces droits disponibles à
trouver dans l'avis de confidentialité complet de TechG sal.

38 https://www.softstack.com/accmen.html
39 https://www.bitdefender.com/business/enterprise-products/elite-security.html
40 https://oracle-base.com/articles/misc/native-network-encryption-for-database-connections

Page | 40
3. Le Contrat41
3.1 Description

Ce contrat de création de logiciel régit la relation contractuelle entre TechG sal et ZigBank
et sert de référence pour savoir les droits et obligations de chacun.

3.2 Contrat de création de logiciel

Entre les soussignés :

TECHG SAL
MUMBAI, GXR TECHNOLOGY PARK, INDE Immatriculée au registre du commerce et des sociétés
sous le numéro d'immatriculation 11267C représentée en la personne de Ravi Susarla en sa qualité de
CEO.
contact@techg.com
+91 15 52 36 47 48 45 1001
Ci-après désigné comme « le Prestataire »,
Et

ZIGBANK
PASCAL AL SHAMI STREET, HAMRA, 2056 8144, P.O. BOX: 11-2668, BEYROUTH, LIBAN
Immatriculée au registre du commerce et des sociétés sous le numéro d'immatriculation 556E
représentée en la personne de Ralph Zig en sa qualité de Directeur Général du Groupe.
contact@zigbank.com
+961 1 555 557 83
Ci-après désigné comme « le Client ».

ARTICLE 1 : Thème du contrat

Le présent contrat de création de logiciel a pour objet le développement par le Prestataire d'un
logiciel spécifique pour le compte du Client moyennant une compensation financière.

41
https://www.ooreka.fr/univers/entreprise

Page | 41
Le développement du logiciel comporte :
 La conception
 le développement
 la mise en production du logiciel.
Le logiciel a pour objectif d’offrir des services de portefeuille numérique aux clients du Client.
Le logiciel devra être produit en accords avec les exigences du Client exprimés dans le contrat.
Le logiciel aura les caractéristiques particulières mentionnées ci-après : En ligne, Multi plateformes,
Sécurisé.
ARTICLE 2 : Exécution de la prestation
Le Prestataire exécute le logiciel conformément aux clauses mentionnées à l'article 1er du présent contrat.
ARTICLE 3 : Délais
Le Prestataire TECHG SAL s'engage à livrer le logiciel avant le 7 Avril 2021. Le présent contrat produira
ses effets au jour de la signature et prendra fin à la remise définitive du logiciel.
ARTICLE 4 : Exclusion de responsabilité
En cas de retard dans l'exécution du contrat en raison d'une force majeure ou à cause de documentation ou
information rendue en retard, non conforme ou incomplète, le Prestataire ne pourra voir sa responsabilité
engagée.
ARTICLE 5 : Prix
 Le paiement du prix sera forfaitaire. En contrepartie de la livraison le Client procédera au
paiement d'une somme forfaitaire de 200 000 €. Le versement du prix s'effectuera comme suit :
 100 000 € à la signature du présent contrat ;
 40 000 € au 14 Mars 2021 à la fin de la phase de test ;
 60 000 € au jour de la livraison définitive du logiciel.
 Le paiement s'effectuera dans un délai de 40 jours à compter de la réception définitive du logiciel
par virement bancaire sur le compte IND 040 2354 5543 6723.

ARTICLE 6 : Obligations du client

Le Client s'engage à payer le prix de la prestation accomplie par le Prestataire en conformité avec les
modalités exprimées dans le présent contrat.
Le Client s'oblige à collaborer avec le Prestataire en lui fournissant tout document et toute information lui
permettant de réaliser le logiciel conformément à ses exigences.
Le Client est tenu à une obligation de confidentialité concernant les divulgations dont il a eu connaissance
dans le cadre du présent contrat.

Page | 42
ARTICLE 7 : Obligations du prestataire
Le Prestataire est tenu à une obligation de résultat. Il doit délivrer un logiciel conforme aux clauses
exprimées dans le présent contrat. Pour utilisation optimale du logiciel, le Prestataire s'oblige à guider le
Client dans le domaine informatique si nécessaire.
Le Prestataire est tenu à une obligation de confidentialité quant aux informations fournies par le Client.
ARTICLE 8 : Responsabilité du client
En l'absence d'exécution de l'obligation de collaboration, le Prestataire ne sera en aucun tenu d'exécuter sa
propre obligation et pourra engager la responsabilité contractuelle du Client. Le Prestataire pourra exercer
un recours en justice et exposer le Client devant la juridiction compétente.
ARTICLE 9 : Responsabilité du prestataire
En l'absence d'exécution de ses obligations, le Prestataire engage sa responsabilité contractuelle et s'expose
à un contentieux devant la juridiction compétente.
ARTICLE 10 : Recette
Par les jeux d'essai, les parties vérifient la conformité du logiciel aux exigences du Client.
Les jeux d'essai sont établis par le Client qui en a la responsabilité. Le Client s'oblige à délivrer des jeux
d'essais au plus tard le 12 Février 2021.
ARTICLE 11 : Propriété intellectuelle
Dès l'accomplissement du logiciel, le Prestataire s'engage à transférer au Client les droits d'exploitation,
de reproduction, de représentation, de commercialisation et d'usage. Une exploitation même partielle du
logiciel par le Prestataire est interdite.
ARTICLE 12 : Juridiction compétente et droit applicable
Le droit applicable au présent contrat est le droit libanais et le RGPD européen, ou encore GDPR, de
l'anglais General Data Protection Regulation. Les parties conviennent d'un commun accord que le
Conseil arbitral du Travail de Beyrouth aura compétence pour trancher un éventuel litige.

Fait en deux exemplaires, le 09 Juin 2020 à Beyrouth.

Signature précédée de la mention « lu et approuvé » :

Signature de Ravi Susarla Signature de Ralph Zig

Page | 43
V – Cahier des Charges Fonctionnel (CdCF)
Dans ce document nous allons présenter de manière détaillée et structurée les spécifications
des services/modules à rendre et les contraintes de notre produit de portefeuille numérique. Le plan
type de ce document est extrait de la norme NF EN 1627142.

1. Présentation générale du problème

1.1 Projet

Un marché inondé par une génération de technologies financières fournis par les Fintechs
a obligé notre client ZigBank a créer une solution de portefeuille numérique afin de limiter les
pertes engendrées par l’utilisation de ces technologies par les clients existants de la Banque. Pour
cela, la Banque cherche à maintenir le volume des transactions produisant un revenu.

1.2 Contexte

ZigBank est une banque régionale qui opère au Liban et dans la région MENA avec un
large réseau d’agences et de bureaux représentatifs et donc un volume d’activité très important
dans le secteur bancaire.

1.3 Énoncé du besoin

Les clients de la Banque ont besoin d'effectuer un paiement rapide et facile, similaire à
celui fait à partir des produits fournis par les compagnies Fintechs, à l'aide d'un appareil portable.
Connaître les coordonnées/détails bancaires du destinataire ou les saisir tout en effectuant un
paiement (ou même maintenir ces coordonnées) est accablant et prend du temps. Le paiement à
l'aide d'un numéro de contact ou d'une adresse e-mail est beaucoup plus pratique pour l'utilisateur
car il est sans tracas et ne nécessite aucune maintenance des détails de paiement.

Afin de faciliter les paiements simples et rapides pour les utilisateurs, une nouvelle
application numérique doit être introduite sous le nom de «portefeuilles». Les portefeuilles
serviront aux paiements faciles pour les destinataires en entrant simplement l'identifiant e-mail ou

42 https://www.boutique.afnor.org/standard/nf-en-16271/value-management-functional-expression-of-the-need-and-functional-
performance-specification-requirements-for-expressing-and-vali/article/669103/fa164075

Page | 44
le numéro de mobile du destinataire à l'aide d'une interface utilisateur simple. La banque peut
servir de canal supplémentaire à ses utilisateurs pour les opérations bancaires de base.

1.4 Environnement du produit : choix techniques et équipes

En utilisant le langage de programmation Java, la base de données Oracle existante chez

la Banque, et l’outil de développement NetBeans, nous allons réaliser la partie technique du projet.
Les fonctionnalités seront testées en utilisant le Framework TestNG (Junit avec des
fonctionnalités avancées) et la performance de toute l’application au sein de l’environnement sera
testée avec AppDynamics Lite v2.0.

Nous allons utiliser le « Cycle en V » comme méthode de management et délivrer un seul

bouquet de livrables en fin de projet après le succès des tests fonctionnels dont les scenarios et les
bugs seront créés et suivis dans HP Application Lifecycle Management.

Le langage de notation international UML est notre choix pour la modélisation. Celle-là
sera réalisée par l’outil en ligne « Visual Paradigm » qui contient une diversité de prototypes et
de squelettes.

La gouvernance du projet va être assurée par un comité de pilotage, un comité technique,

une équipe d’experts informatique et d’une équipe de test de la part de la Banque. De même, un
comité exécutif, un comité technique, et les équipes de développement et de test de TechG sal
garantiront l’avancement et le bon déroulement du projet de la part de l’entreprise.

Page | 45
2. Expression fonctionnelle du besoin : aperçu général des modules
2.1 Inscription au portefeuille

Pour bénéficier du portefeuille et de ses services, l'utilisateur doit s'inscrire au portefeuille.

Le lien d'enregistrement sera disponible sur le portail de la Banque afin que le nouvel utilisateur
(utilisateur potentiel) puisse également s'enregistrer et accéder au portefeuille. Un utilisateur
potentiel doit suivre le processus d'enregistrement du portefeuille qui implique quelques étapes.

Ces étapes sont la réception et la saisie d’un code de vérification envoyé au numéro de
téléphone portable de l'utilisateur saisi lors de la première étape de l'inscription, la saisie des
informations principales et les informations de connexion, et finalement l’atterrissage sur le
tableau de bord du portefeuille. Dans le cadre de cet enregistrement, l'utilisateur doit définir une
question-réponse de sécurité et accepter les termes et conditions.

2.2 Le Tableau de bord

Le tableau de bord fournit une vue simple et nette des transactions et des options
disponibles pour les clients sur le portefeuille. La facilité d'utilisation est le principe essentiel du
tableau de bord puisqu’il est orienté vers l'action et non seulement un affichage des informations
en lecture seule. Nous avons quatre sections principales :

 L’entête qui présente les options d'accéder au profil utilisateur et puis à des
fonctionnalités telles que le changement de mot de passe, les détails de connexion,
la déconnexion, etc. Elle contient aussi les alertes à l’utilisateur et le solde à la date
et l’heure de connexion.
 La section des transactions à partir de laquelle l’utilisateur accède aux transactions
standard du portefeuille (Payer, Ajouter des fonds, Demander des fonds à partir
d’un autre portefeuille).
 La section des Notifications de paiement / demande où toute demande de paiement
adressée à l'utilisateur depuis un autre portefeuille sera montrée à l'utilisateur pour
son action.
 La section liste des activités affiche les activités financières récentes effectuées par
l'utilisateur.
 La section des offres montre toutes les offres hébergées par la banque.

Page | 46
 2.3 Ajouter des fonds au portefeuille

Afin d'effectuer des transferts de fonds ou des paiements via le portefeuille, un solde doit
être disponible dans un portefeuille. Le portefeuille peut être financé à l'aide de comptes externes
comme une carte de crédit, une carte de débit et / ou en utilisant les services bancaires par Internet.

L'utilisateur a également la possibilité de demander des fonds d’un contact souhaité (sur
l'identifiant de l'e-mail ou sur le numéro de mobile).

2.4 Demander des fonds d’un autre portefeuille

Avec le portefeuille, l'utilisateur a la possibilité de demander des fonds d’un autre

portefeuille provenant d'un autre utilisateur utilisant le portefeuille (contact). L'utilisateur demande
des fonds au contact souhaité à l'aide de l'identifiant de messagerie ou du numéro de mobile du
contact. Il doit spécifier le montant du financement pour lancer la demande de fonds. Cependant,
il est nécessaire que le contact (propriétaire de l'identifiant e-mail ou du numéro de mobile) soit
inscrit aux services de portefeuille. Une notification est envoyée à la personne de contact,
concernant la demande de financement du portefeuille de l'utilisateur qui peut accorder ou refuser
la demande.

2.5 Payer à partir du portefeuille

Le paiement à partir du portefeuille est simple et rapide. L’utilisateur peut payer

directement à un autre utilisateur de portefeuille ou à un contact souhaité en utilisant l'e-mail ou le
numéro de téléphone mobile du contact. Le portefeuille identifie intelligemment si l'identifiant de
messagerie / le numéro de mobile est enregistré ou non pour les services de portefeuille. Si oui, les
fonds sont directement crédités dans le portefeuille du destinataire.

Cependant, si le destinataire n'est pas enregistré pour un portefeuille, un lien de paiement

est envoyé à l'adresse e-mail / numéro de mobile du destinataire. Afin de recevoir des fonds, le
destinataire doit s'inscrire au portefeuille dans le délai indiqué. Ne pas s'inscrire au portefeuille
dans le délai signalé ne permettra pas au destinataire de recevoir des fonds. Les fonds seront
crédités de nouveau sur le portefeuille de l'envoyeur.

Page | 47
 2.6 Relevé de compte du portefeuille

Le relevé de compte joue un rôle important pour les clients dans la gestion et le contrôle
d'un compte. Comme pour tout compte d'épargne ordinaire, les portefeuilles prennent également
en charge les relevés d'activité pour les portefeuilles. Ce relevé affiche toutes les écritures
comptables qui affectent le solde du portefeuille. Un bref résumé des dernières transactions peut
être consulté sur le tableau de bord du portefeuille.

Pourtant, il existe également une option pour afficher le relevé complet du portefeuille.
Toutes les transactions effectuées à partir du portefeuille sont affichées dans l'ordre chronologique.
L'utilisateur peut utiliser des filtres pour affiner le résultat de la recherche comme la période de
transaction, le mois en cours, le mois précèdent, le type de transaction, etc. L'utilisateur dispose
également d'une option de tri pour trier le résultat en fonction de la date de transaction ou le
montant de la transaction.

Page | 48
 3. Cadre de réponse

Dans cette partie nous allons élaborer deux grands modules de l’application pour démontrer
comment ils répondent aux besoins attendus.

3.1 Diagramme de classe simple : Aperçu global de l’application

Figure 1 - Diagramme de classe, vue globale

Ce diagramme de classes décrit la structure statique de notre application de portefeuille

numérique en montrant les classes du système, leurs attributs, leurs opérations et les relations entre
elles. L’utilisateur qui s’enregistre au service de portefeuille de la Banque a une seule adresse
associée à son compte et un ou plusieurs comptes bancaires internes de différentes devises associés
au portefeuille. L’utilisateur fait des transactions de différents types : ajouter, payer, et demander
des fonds.

Page | 49
 3.2 Modélisation du module Payement
3.2.1 Cas d’utilisation

Ce diagramme de cas d'utilisation dans sa plus simple expression est une

représentation de l'interaction du client de la Banque avec le système de portefeuille numérique.
Nous allons décrire comme exemple le scenario du cas d’utilisation Ajouter des fonds/Add funds
qui appartient au module de Payement.

Nom: Ajout des fonds.

Objectif : permet à un utilisateur de remplir du « cash » dans son portefeuille.

Acteurs : Client de la Banque.

Précondition : Le client doit préalablement exister dans le système, donc s’enregistrer

dans le système pour accéder au tableau de bord.

Scenario nominal/Description :

Page | 50
1) L’utilisateur se connecte au système informatique par navigateur web ou application
mobile.

2) Le système demande un identifiant et un mot de passe.

3) L’utilisateur fournit son identifiant et son mot de passe.

4) Le système affiche le tableau de bord; l’utilisateur est connecté au système.

5) L’utilisateur clique sur Widget Portefeuilles> Ajouter de l'argent OU Basculer le menu>

Paiements> Paiements et transferts> Transférer de l'argent> Ajouter de l'argent au
portefeuille.

6) Dans le champ « Type de transfert », l’utilisateur sélectionne l'option « Mes comptes ».

Les champs par lesquels l’utilisateur peut initier le transfert depuis son propre compte
apparaissent.

7) L’utilisateur saisi les informations requises comme le montant et le commentaire, le type

de la carte utilisée et les coordonnées associées (Credit Card/Debit Card/Internet Banking)
puis clique sur le bouton « Ajouter des fonds».

8) L'application recevra un accusé de réception du client (One Time Password) concernant

la transaction et l'argent sera crédité sur le compte portefeuille de l'utilisateur.

Scénarios alternatifs/Exceptions :

3)a) L’utilisateur s’aperçoit qu’il n’est pas connu du système; il doit s’enregistrer.

4)a) Les informations fournies sont incorrectes, le système redemande l’identifiant et le

mot de passe.

Diagramme d’activités : voir section 3.2.2

Post-condition : L’utilisateur est identifié et a crédité son compte portefeuille.

Page | 51
 3.2.2 Diagramme d’activité

Dans la phase de conception, ce diagramme d'activités est adapté à la description du cas

d'utilisation « Ajout des fonds ». Il vient illustrer la description textuelle sous forme
d’organigrammes facilement intelligibles. Les activités sont ségrégées entre les acteurs qui sont
l’utilisateur et le système.

Page | 52
 3.2.3 Diagramme de séquence

Après le QUOI représenté par le diagramme de cas d’utilisation, et le QUI représenté par
le diagramme de classes, ce diagramme de séquence montre le COMMENT. Nous voyons
comment les acteurs et les objets du système interagissent entre eux en séquence temporelle, ainsi
que les messages échangés lors de ces interactions. Les alternatives sont montrées sauf pour le
login qui est une fonctionnalité évidente.

Page | 53
 3.2.4 Diagramme d’état-transition

Dans ce diagramme d’états-transitions « comportemental » nous représentons les

transitions (flèches) entre un nombre fini d’états (rectangles) dès l’état initial représenté par un
rond noir de départ jusqu’à l’état final représenté par un rond cerclé de fin. Le diagramme décrit
les réactions du système à des évènements spécifiques comme l’enregistrement, le login, et les
actions que l’utilisateur peut faire à partir du portefeuille comme l’ajout de fonds et le payement.

Page | 54
 3.2.5 Déploiements et composants

A partir de ce diagramme, nous avons représenté une vue statique qui sert à expliquer
comment l’infrastructure physique est utilisée (serveur d’application, serveur de base de données,
postes des clients, etc.). De Plus, nous avons montré quelques composants du système, leur
répartition sur l’infrastructure physique, et leurs relations entre eux.

Page | 55
 3.3 Modélisation du module Relevé de Compte
3.3.1 Cas d’utilisation

Ce diagramme de cas d'utilisation dans sa plus simple expression est une

représentation de l'interaction du client de la Banque avec le système de portefeuille numérique.
Nous allons décrire comme exemple le scenario du cas d’utilisation « Relevé de compte ».

Nom: Relevé de compte.

Objectif : permet à un utilisateur de demander un relevé de compte à partir de son

portefeuille.

Acteurs : Client de la Banque.

Précondition : Le client doit préalablement exister dans le système, donc s’enregistrer

dans le système pour accéder au tableau de bord.

Page | 56
Scenario nominal/Description :

1) L’utilisateur se connecte au système informatique par navigateur web ou application

mobile.

2) Le système demande un identifiant et un mot de passe.

3) L’utilisateur fournit son identifiant et son mot de passe.

4) Le système affiche le tableau de bord; l’utilisateur est connecté au système.

5) L’utilisateur clique sur Wallet Dashboard > Mini Statement > Statement.

6) Le relevé de compte affiche toutes les écritures comptables qui affectent le solde du
portefeuille et l’utilisateur peut utiliser les filtres ci-dessous pour affiner les résultats de la
recherche :

Période de transaction : 10 dernières transactions / Entre une plage de dates.

Type de transaction : Transactions de débits/ Transactions de crédit/ les deux.

7) L'utilisateur utilise l'option de tri pour trier le résultat selon la date des transactions ou
leurs montants.

Scénarios alternatifs/Exceptions :

3)a) L’utilisateur s’aperçoit qu’il n’est pas connu du système; il doit s’enregistrer.

4)a) Les informations fournies sont incorrectes, le système redemande l’identifiant et le

mot de passe.

Diagramme d’activités : voir section 3.3.2

Post-condition : L’utilisateur est identifié et a reçu un relevé de son compte portefeuille.

Page | 57
 3.3.2 Diagramme d’activité

Dans la phase de conception, ce diagramme d'activités est adapté à la description du cas

d'utilisation « Relevé de compte ». Il vient illustrer la description textuelle sous forme
d’organigrammes facilement intelligibles. Les activités sont ségrégées entre les acteurs qui sont
l’utilisateur et le système.

Page | 58
 3.3.3 Diagramme de séquence

Après le QUOI représenté par le diagramme de cas d’utilisation, et le QUI représenté par
le diagramme de classes, ce diagramme de séquence montre le COMMENT. Nous voyons
comment les acteurs et les objets du système interagissent entre eux en séquence temporelle, ainsi
que les messages échangés lors de ces interactions.

Page | 59
 3.3.4 Diagramme d’état-transition

Dans ce diagramme d’états-transitions « comportemental » nous représentons les

transitions (flèches) entre un nombre fini d’états (rectangles) dès l’état initial représenté par un
rond noir de départ jusqu’à l’état final représenté par un rond cerclé de fin. Le diagramme décrit
les réactions du système à des évènements spécifiques comme l’enregistrement, le login, et les
actions que l’utilisateur peut faire à partir du portefeuille comme la demande d’un relevé de
compte.

Page | 60
 3.3.5 Déploiements et composants

A partir de ce diagramme, nous avons représenté une vue statique qui sert à expliquer
comment l’infrastructure physique est utilisée (serveur d’application, serveur d’Oracle Business
Intelligence, serveur de base de données, postes des clients, etc.). De Plus, nous avons montré
quelques composants du système, leur répartition sur l’infrastructure physique, et leurs relations
entre eux.

Page | 61
4. Les Livrables et le planning

Les livrables sont :

 Des scripts PL/SQL pour la création des modèles de données et a but de configurations
initiales.
 Des packages PL/SQL en lien avec chaque module.
 Un WAR file de l’application web.
 Un APK file pour l’application mobile.

Les différentes étapes du projet et les dates limites souhaitées sont les suivantes (voir Annexe 1):

 Etude et analyse des besoins à compléter le 05 Octobre 2020.

 Choix des technologies, conception et planification des étapes du développement
technique à compléter le 11 Novembre 2020.
 Développement à commencer le 12 Novembre 2020 et à compléter le 12 Février 2021.
 Premier déploiement de l’application le 15 Mars 2021.
 Mise en ligne par la Banque au maximum le 7 Avril 2021.

--

Pour conclure, nous allons présenter un bilan de notre travail dans lequel nous allons
récapituler le projet et ses étapes de réalisation, les problèmes rencontrés, le côté finance, le côté
personnel, et l’évolution de notre projet.

Page | 62
VI – Bilan et Conclusion
1. Le Projet

ZigBank, une banque régionale à haut volume d'activité dans le secteur bancaire s'est
retrouvée menacée par l'essor des sociétés Fintechs fournissant des technologies de paiement
simples et rapides à ses clients. Afin de conserver son volume d'activité et limiter ses pertes, la
Banque a décidé d'introduire un nouveau service de portefeuille numérique et a délégué cette
tâche à TechG sal, une société informatique expérimentée dans le domaine financier.

Ce nouveau service de portefeuille numérique, offert par une banque qui opère dans
différentes régions doit être en ligne, sécurisé, toujours disponible et ayant un design simple et
facile à utiliser.

Les modules du système doivent inclure l’enregistrement au portefeuille, l’ajout de fonds,

le paiement instantané d’un portefeuille électronique vers l’autre, la demande de fonds auprès d’un
autre portefeuille ou auprès d’un contact externe souhaité. De plus, un module de relevé de
comptes avec des critères de recherche avancés est inclus dans l’application.

Afin de réaliser un bon projet et garantir son avancement et son succès, TechG sal et
Zigbank ont fait des réunions qui ont abouti à une étude préalable détaillée du besoin de point de
vue de la Banque. Puis, suite à une étude comparative des technologies à utiliser dans les
différentes sections du projet, TechG sal a élu une pile de technologies adéquates aux besoins du
projet. Enfin, TechG sal a effectué une étude des aspects juridiques et du plan d’assurance qualité
pour assurer un projet de qualité conforme aux normes internationales qui protègent les clients,
leurs coordonnées bancaires, et toutes leurs informations personnelles.

Pour démarrer le projet, plusieurs étapes ségrégées ont été mises en place. Une étape initiale
de réunions de collecte d’exigences et d’analyse des coûts et des risques a été suivie d’une étape
de Conception des modèles de données et des interfaces utilisateurs, puis d’une phase de
développement et de tests, et enfin d’une phase d’installation et de maintenance corrective.

Page | 63
2. Etapes de réalisation

Le processus de développement de l’application de portefeuille numérique a contenu un certain

nombre d’étapes :

 Définir les besoins et les exigences du client et des utilisateurs :

Dans cette étape, une équipe de consultants fonctionnels de la part de TechG sal ont discuté
avec les « Business Owners » de la Banque et les futurs utilisateurs responsable du support et de
la maintenance afin de comprendre de quoi ont-ils besoin et quelles sont les configurations
nécessaires au système afin qu’il réponde à leur besoin.

Durant cette étape, TechG sal a défini également les demandes précises de la Banque, telles
que les temps de réponse, le respect de certaines normes graphiques, le matériel sur lequel le
logiciel devrait fonctionner, etc.

 Analyser le système :

Dans cette étape, TechG sal a détaillé davantage le fonctionnement interne du logiciel afin
d’affiner ce qui a été défini dans l’étape première.

 Concevoir le système :

Dans cette étape et après avoir sélectionné les choix techniques, TechG sal a défini les modèles
de données et les modèles des interfaces graphiques (composants du front-end).

 Programmer le logiciel :

C’était l’étape que les équipes de programmation de TechG sal attendaient le plus. Ils ont
réalisé le logiciel à l’aide des langages de programmation, du système de gestion de bases de
données et des différents autres outils sélectionnés.

 Tester le logiciel :

Dans cette étape et avant les tests fonctionnels auxquelles les équipes de test de la Banque ont
participé, les équipes de test de TechG sal ont vérifié que le logiciel fonctionne et répond aux
besoins définis en début du travail. Les tests exécutés étaient de nature technique (test unitaires) et
fonctionnelle (test d’assurance qualité pour des scénarios prédéfinis), suivi par des tests de
performance globale du logiciel (temps de réponse, nombres d’utilisateurs/capacité, etc.).

Page | 64
  Déployer :

Les premiers bouquets d’unités à délivrer étaient déployés comme scripts PL/SQL pour la
création des modèles de données sur le serveur de BD, un WAR file pour l’application web sur le
serveur d’application , un APK file pour l’application mobile que les utilisateurs peuvent
télécharger depuis le portail de la Banque, et d’autres scripts SQL a but de configurations initiales.
Suite aux déploiements, les consultants techniques de TechG sal ont réalisé des ajustements pour
bien faire fonctionner le logiciel dans l’environnement de travail des utilisateurs.

 Maintenir le système :

Dans la période qui a suivi l’installation et le lancement, quelques bugs/anomalies ont été
corrigées par des scripts que TechG sal nomme « Datapatch » pour la correction des données
incorrectes par faute de migration par exemple, et par le redéploiement des packages SQL ou des
modifications des classes Java en relation avec le fonctionnement. Ces anomalies ont été classées
comme « Critical », « Major », « Moderate », « Minor » et « Cosmetic ». Toutes les anomalies
critiques et majeures ont été corrigées en moins de 24 heures et sur place durant la période gratuite
de support.

 Formation des utilisateurs :

De la part de la Banque, le nombre des utilisateurs peut ne pas dépasser deux à trois personnes
bien expérimentées en « Troubleshooting » en utilisant les outils cités dans la section des choix
techniques et surtout en lisant attentivement les logs files dans lesquelles presque toutes les étapes
du fonctionnement et les sources des erreurs sont enregistrées. Pour cela, une formation de 3 à 5
jours pour une petite équipe de la Banque couvrant la réponse aux erreurs signalées par les clients
a été délivrée en plus des documents utiles placés dans un répertoire accessible via l’Intranet de la
Banque.

Pour les clients, la Banque a publié sur son portail un guide utilisateur très détaillé qui élabore
très clairement chaque fonction du portefeuille en utilisant un langage non technique donc
compréhensible par tous.

Page | 65
3. Problèmes rencontrés

Durant la réalisation du projet, TechG sal a rencontré plusieurs problèmes personnels,

conceptuels et évidemment des contraintes techniques. Nous allons citer quelques difficultés à titre
d’exemple.

Durant la phase de développement, un des développeurs très expérimentés de l’équipe de

TechG sal qui guidait des développeurs juniors a reçu une approbation du département de
l’immigration en Australie pour sa demande d’immigration au sein d’un programme pour les
familles qui offrait un emploi prêt à occuper et disponible pour une courte période de deux mois
seulement. Ayant commencé le développement et ayant atteint un niveau avancé dans le travail,
son départ a créé une « faille » dans l’équipe, ce qui n’été pas très facile à réparer rapidement.
TechG sal a dû introduire une nouvelle ressource expérimentée qui venait de terminer un projet
récent. Cela a engendré un délai plus ou moins important dans l’étape de développement.

Un autre problème personnel s’est élevé lorsque Mme. Hanadi Saadeh, responsable de
l’équipe de test de la Banque, a tenté par inadvertance de recruter un testeur expérimenté de TechG
sal dans son équipe, après qu’il a démontré une performance remarquable durant la phase de test,
mais elle a été informée par le département des ressources humaines de l'accord verbal entre la
Banque et TechG sal de restreindre l'emploi des ressources de l'entreprise vers la Banque et vice
versa durant toute la durée du projet.

Un problème conceptuel rencontré était la création de plusieurs classes qui ont un grand
nombre d’attributs et d’opérations identiques. Cela contredit le principe de « réutilisation du code »
/ « Code Reusability » qui est fondamental dans un environnement orienté objet. Pour cela, les
classes aux propriétés communes ont été regroupées en classes mères et sous-classes qui en
héritent.

Le problème technique le plus fréquent était le blocage de quelques scripts dans les
composants du front-end par les navigateurs, surtout Google Chrome, Brave Browser, et Opera.
Cela a nécessité des modifications au niveau des paramètres/settings des navigateurs et l’ajout de
quelques étapes dans le guide utilisateur que les clients sont encouragés à faire pour éviter les
problèmes de telle nature.

Page | 66
 Au début du projet, durant l’étude préalable, nous avons prévu un plan représenté par un
diagramme de GANTT selon lequel nous avons estimé une durée de 6 mois comme durée complète
du projet. Comme différents problèmes étaient rencontrés à différents niveaux, des retards se sont
produits. Le premier retard du côté de l'entreprise a été un retard de 3 semaines dans la phase de
développement, causé par le départ d'une ressource précieuse de TechG sal. Du côté de la Banque,
les utilisateurs n'ont pas pu atteindre leurs bureaux durant la phase de test pendant plusieurs jours
vu que des manifestations violentes et des blocages de routes avaient eu lieu à Beyrouth pour des
raisons économiques et politiques. Les employés de la banque n'étaient pas habitués à travailler à
domicile. Une lenteur dans l'exécution des tests a été constatée et l’étape de test été complétée
après 5 semaines de la date estimée. En fin du projet, la date de clôture été décalée de 2 mois (voir
Annexe 2), mais les deux parties étaient très compréhensives et ne se pointaient pas du doigt.

4. Finance

Les coûts étaient bien estimés à 200 000 dollars. Au cours de la première période de 6 mois
après la mise en service du produit, le volume d'activité était normal avec une diminution minimale
qui a affecté l'ensemble du secteur bancaire au Liban en raison des situations politiques et
financières. Mais ce qui a été remarquable, c'est le volume de profit généré par les nouveaux
clients/utilisateurs du portefeuille qui était de l'ordre de 115 000 dollars au cours de cette période,
et qui devrait doubler vers la fin de l'année, montrant donc un taux annuel de retour sur
investissement de (230000-200000) / 200000 = 15%.

5. Expérience de la Banque et des clients

La direction de la Banque était satisfaite par les premiers résultats et a créé un questionnaire
sur son portail. Les résultats du questionnaire montrent jusqu’à présent que 68% des participants
étaient « très satisfaits » par le nouvel service, 15 % étaient satisfait, 11% étaient
« indifférents/neutres » et 6 % ont répondu par « non satisfait » avec des commentaires qui
montrent que la seule raison était qu’ils ne sont pas prêts à investir du temps pour suivre les
changements et apprendre à utiliser des nouveaux produits.

Page | 67
6. Expérience personnelle

Nous avons remarqué que les employés de la Banque et les employés de TechG sal ont
tous les deux trouvé cette expérience très spéciale et différente de toute autre, car le projet a
rassemblé des personnes d’origines et de cultures différentes. La Banque a également introduit un
"jeu" de délivrance de certificats de reconnaissance aux employés de TechG sal, comme "The
Code Guru", "No Stress Certificate", "Super Expert", etc., ce qui a créé une atmosphère agréable
pendant le travail.

7. Evolutions et perspectives

D’après les données d’utilisation collectées du service de portefeuille numérique, la

Banque a noté que la tranche des 25-44 ans est celle qui utilise le plus l’application, puis la tranche
des 18-24 ans qui sont des étudiants, et enfin les plus de 55 ans qui utilisent le service mais moins
régulièrement. Pour cela, la Banque vise à ajouter de l’intelligence au système pour filtrer ou plutôt
personnaliser les offres affichées dans la section des offres du tableau de bord en fonction de l'âge
de l'utilisateur et d'autres données d'utilisation comme les devises utilisées, la fréquence de
paiement, etc.

Le système est capable de couvrir plus de devises au cas où la Banque décide d’opérer dans
un nouveau pays, et cela est fait par des configurations que l’équipe de la Banque peut réaliser
rapidement et sans recourir chaque fois à TechG sal, puisque c’est un travail de paramétrage et
non pas de développement. Cependant, la Banque vise aussi à ajouter des fonctionnalités qui
nécessitent un travail technique, tel que le paiement des factures de téléphones mobiles Alpha et
Touch, des factures d’internet Ogero, des frais scolaires et universitaires, des tickets de violation
du code de la route, et des honoraires de l’inspection mécanique annuelle des voitures au Liban,
tout cela directement à partir de l’application en un seul clic, sans saisir le numéro de mobile ou
l’adresse e-mail du récepteur et sans que le récepteur s’enregistre au service de portefeuille. Nous
discuterons aussi avec la Banque la possibilité de ne plus se limiter à la connexion Internet pour
compléter les paiements, mais aussi profiter du réseau mobile et permettre une communication par
SMS.

Des nouvelles exigences, de nouvelles analyses et des nouveaux cycles de travail attendent
TechG sal et ZigBank.

Page | 68
ANNEXES
Annexe 1 – Diagramme de Gantt

Page | 69
Annexe 2 – Diagramme de Gantt réel v/s estimé

Page | 70