Conduite d'un projet informatique - Rapport Final

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

Page | 2
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 | 3
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 | 4
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 | 5
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 | 6
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 | 7
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.
 Conformité.
 Banking commercial et d’entreprise.
 Technologie de l’information.
 Gestion Corrective.
 Banque de Détail.
 Risque de Crédit aux entreprises.
 Finances.
 Ressources Humaines.
 Gestion du Réseau d'Agence.
 Audit Interne.
 Services bancaires aux PME.
 Marketing & Communication.
 Réseau des Branches.
 Réseau Régional.
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 | 8
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 | 9
 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 | 10
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 | 11
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
OmniPlus Core Banking
Centralisé
Serveur
d’Application
Linux Server 7.1
(x86 64
Bit)
IBM WebSphere Application Server
(IBM JDK 1.8_64)
9.0.0.0
IBM WebSphere MQ Server 9.0.0.0
OmniPlus Private Banking
Serveur de bases
de données
Linux Server 7.1
(x86 64
Bit)
Oracle RDBMS Enterprise
Edition 12.2.0.1.0
OmniPlus Investor
Servicing
Machines clients
Windows 10
Internet Explorer
Microsoft Edge(40+)
Mozilla Firefox Release (52+)
Mac OS X
Google Chrome Release (66+)
Safari Safari 10+
Google Chrome
Google Chrome
Release (66+)

Page | 12
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 | 13
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 | 14
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 | 15
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.
FORCES
• Produit innovant
• Excellente notoriété de la Banque,
confiance des clients
• Communication, marketing
• Equipe de gestion compétente
• Coûts fixes bas
• Employés hautement qualifiés
• Equipement et infrastructure des
serveurs
FAIBLESSES
• Pas d’expérience au passé dans le
domaine de Wallets
• Nombre d’employées insuffisant
pour des grands projets
• Taux de rotation élevé
OPPORTUNITES
• Segment de paiement par portefeuilles
en grande croissance.
• Nouvelles technologies
• Changement du comportement des
clients
• Extensibilité de la solution, ajout de
nouveaux modules.
MENACES
• Environnement légal peu favorable
(secret bancaire)
• Secteur Fintechs à très fort potentiel
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 | 16
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 | 17
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.
8
https://www.softwaregroup.com/insights/blog/individual-article/main-blog/2019/08/01/15-key-features-that-make-your-mobile-
wallet-stand-out

Page | 18
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 | 19
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
besoins de
paiement attendus.
100% 100% 100% 100% 100% 100%
Capacité Disponible en 202
pays avec 26
devises.
Disponible en 201
pays avec 40
devises.
Disponible en 156
pays avec 45 devises.
Disponible en 65
pays avec 24
devises pour
envoyer et 53
pour recevoir.
Disponible en
202 pays avec
24 devises.
Disponible en 7 pays où
la Banque opère avec
plusieurs devises
configurables et
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 | 20
Prix et frais Retrait sur un
compte bancaire (7.5
USD)
Transfert 1,45 %
(min 0,5 USD)
Retrait sur un
compte bancaire
(3 USD)
Transfert 1,45 %
(min 0,5 USD)
Retrait sur un compte
bancaire (5.9 USD)
Transfert ecoAccount
(1,5%, min 0,5 USD)
Carte
TransferWise
(205 USD)
Différents frais
cachés pour
différents pays
et méthodes.
Interne à la Banque.
Possibilité de
configuration. Les frais
doivent être minimaux en
présence des produits
existants.
Conversion de
devises
Conversion 2,95%
(jusqu'à 1,25% pour
les membres VIP)
2,99 – 4,99 % 2,99% au niveau
classique et argent,
1,49% au niveau Gold
et Platinum et jusqu'à
1,25% au niveau VIP
Taux de change
réel, pas de frais
cachés.
environ 3,5%
(selon la
devise)
Configuration interne à la
Banque.
Les taux doivent être
minimaux en présence
des produits existants
Réputation Très bonne
réputation
Très bonne
réputation
Très bonne réputation Bonne réputation Excellente
réputation
TechG sal a un portfolio
riche de projets de
portefeuilles numériques.
Sécurité Conforme PCI DSS
3-D Secure
Vérification BIN / IP
Payment Card
Industry Data
Security
Standards (PCI-
DSS Level 1)
Payment Card
Industry Data Security
Standards (PCI-DSS
Level 1)
Équipes de
sécurité tierces-
parties et selon
chaque pays.
Connexion
numérique
sécurisée et
cryptée à
PayPal.
La Banque implémente
déjà le modèle de 3-D
Secure.
Cryptage 256 bits et
plusieurs pare-feu au sein

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

Page | 22
Design Simple IHM.
Illustrations et
éléments graphiques
inspirants.
2ème place aux
E-Commerce
Germany Awards.
Une interface
intuitive : affichage et
gestion de toutes les
informations de
compte en un seul
endroit. C'est plus
agréable pour les yeux
et plus intuitif pour les
clients.
Très ergonomique
et l'inscription est
rapide et facile.15
De nombreuses
complaintes
des utilisateurs
en 201616
ont
conduit à un
design UX
presque
parfaite.
Un design récent et
simple, proche des
produits existants pour
que l’utilisateur navigue
facilement au sein de
l’application.
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 | 23
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 | 24
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.
Atomicity
La transaction entière a lieu en même temps ou
ne se produit pas du tout.
Consistency
La base de données est cohérente avant et après
la transaction.
Isolation
Les transactions multiples se produisent
indépendamment sans interférence
Durability
Les modifications d'une transaction réussie se
produisent même si la défaillance du système
se produit
18
https://www.orafaq.com/wiki/ACID

Page | 25
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
développées
Application
d'entreprise,
web, mobile,
bureautique
Application Web
et Java EE
Mobiles, de
bureau, web et
systèmes
embarqués
Java EE, bases
de données,
services Web
Rest/Soap,
mobile
Applications
mobiles Android
Apprentissage Communauté de
développeurs
très active
Une énorme
communauté de
développeurs, une
documentation
très fournie et
beaucoup de
plugins
Communauté de
développeurs et
documentation
Documentation
Oracle
Communauté de
développeurs et
documentation
Multi plateformes Linux,
Windows, Mac
ainsi que Oracle
Solaris.
Windows, Mac
OS X et Linux
Windows, Mac
OS X et Linux
Windows, Mac
OS X et Linux
Windows, Mac OS
X et Linux
Coût libre et open
source
Une version
gratuite (Free
Community
Edition) qui vise
les développeurs
seuls.
Une version
payante (Edition "
Ultimate ") très
avancée qui
s'adresse aux
développeurs
travaillant dans
des entreprises
Libre open
source
Libre et open
source
basé sur la Free
Community
Edition d'Intellij et
est disponible
gratuitement sous
licence Apache.
19
https://www.supinfo.com/articles/single/6135-top-10-ide-developpeurs-java

Page | 26
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 | 27
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 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
Merise UML
Méthode d'analyse/conception de système
d'information
Langage de représentation d'un SI
Méthode de modélisation de données et
traitements orienté bases de données
relationnelles
Système de notation orienté objet
Relationnel Objet
Franco-français International
Schéma directeur, étude préalable, étude
détaillée et la réalisation
Langage de modélisation des systèmes
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
vers le code
Du "top down" du modèle vers la base de
données

Page | 28
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
Maven 2
82
30,83 %
IDE ***
81
30,45 %
Ant
75
28,20 %
Make / script
12
4,51 %
Ant + Ivy
7
2,63 %
Gradle
1
0,38 %
Autres
8
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 | 29
IDE Ant Ivy Maven 2 Gradle
NetBeans
Module à installer de
http://code.google.com/
p/ivybeans/
commandes à
configurer.
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é
pour écrire et exécuter des tests.
Similair à JUnit avec des fonctionnalités
ajoutées.
Il ne prend pas en charge les annotations
avancées.
Prend en charge les annotations avancées et
spéciales.
Il ne prend pas en charge l'exécution de tests
parallèles.
Il permet à différents threads de s'exécuter
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 | 30
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.
JCONSOLE VISUAL VM
APPDYNAMICS
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 | 31
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
de toutes les fonctionnalités).
Rapide (utilisation partielle
du produit selon les besoins
prioritaires).
Contrôle Qualité A la fin. A chaque livraison.
Planification Plan selon les exigences
définies dès le début.
Plan ajusté en fonction des
demandes.
Documentation Détaillée et en grande
quantité.
Minimale, strict nécessaire.
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 | 32
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 | 33
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 | 34
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 | 35
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 | 36
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 | 37
 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 | 38
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 | 39
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 | 40
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 | 41
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 | 42
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 | 43
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 | 44
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 | 45
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 | 46
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 | 47
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 | 48
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 | 49
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
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.
Figure 1 - Diagramme de classe, vue globale

Page | 50
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 | 51
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 | 52
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 | 53
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 | 54
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 | 55
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 | 56
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 | 57
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 | 58
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 | 59
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 | 60
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 | 61
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 | 62
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 | 63
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 | 64
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.).

Conduite d'un projet informatique - Rapport Final

Conduite d'un projet informatique - Rapport Final

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Conduite d'un projet informatique - Rapport Final

Similaire à Conduite d'un projet informatique - Rapport Final (20)

Plus de Mohamed Sabra

Plus de Mohamed Sabra (6)

Conduite d'un projet informatique - Rapport Final