rapport de stage

Développement d’une application
mobile multiplateformes pour la
gestion des opérations bancaires

Réalisé par : M. ELKECHA Brahim
Et : M. OUARRICH Said

Membres de Jury :
M. IBNELHAJ Elhassane (INPT)
M. BENSAID Hicham (INPT)
Mme. MARGHOUBI Rabia (INPT)

Juin 2013
i
Projet De Fin d’étude – ELKECHA Brahim & OUARRICH Said 2012/2013

ii

« S’il n’y avait pas d’hiver, le printemps ne serait
pas si agréable : Si nous ne goûtions pas à
l’adversité, la réussite ne serait pas tant appréciée
»

Anne Bradstreet

iii

Dédicace
A

la mémoire de mes grands parents
Puisse Dieu les accueillir dans son infinie Miséricorde

A celui qui a toujours garni mes chemins avec force et lumière…mon très cher père
A la plus belle perle du monde…ma tendre mère
A mes sœurs
Je leur souhaitant tout le succès…tout le bonheur

A
A
A

toute ma famille pour l’amour et le respect qu’ils m’ont toujours accordé
mon binôme pour le frère agréable qu’il était et qu’il restera pour moi

tous mes amis
Pour une sincérité si merveilleuse…jamais oubliable, en leur souhaitant tout le
succès…tout le bonheur

A

toute personne
Qui m'a aidé à franchir un horizon dans ma vie…

Aimablement…
ELKECHA Brahim

Je dédie ce modeste travail…

iv

À ma mère et mon père
en témoignage de leur affection,
leurs sacrifices et de leurs précieux conseils qui m’ont conduit à
la réussite dans tous ce que je fais ;
À mes sœurs et mes frères
en leur souhaitant la réussite dans leur vie,
À mon cher binôme
Pour tout ce qu’il a fait pour la réussite de ce stage
À tous mes proches
À tous ceux qui m’ont aidé afin de réaliser ce travail,
Et à tous ceux que j’aime et qui m’aiment.

Aimablement…
OUARRICH Said

Je dédie ce modeste travail…
v

Remerciements
Premièrement nous remercions Dieu source de toute connaissance.
Au terme de ce travail, nous adressons nos remerciements les plus sincères à notre encadrants M.
Elhassane IBN ELHAJ & M. Hicham BENSAID, deux enseignants chercheurs

à

L’institut

national des postes et télécommunications, pour nous avoir permis de bénéficier de leur grand
savoir dans différents sujets tout au long de notre formation à l’INPT, pour leur pédagogie, leurs
compétences, leur modestie et leur aide précieuse tout au long de ce projet même pendant les
moments les plus difficiles. Vraiment merci pour une qualité d’encadrement si sérieuse et si
consistante …

Un immense merci à M. Rachid et M. Mohamed Amine Larouji méritants tout le respect pour leurs
encouragements, et de nous avoir accueillis dans la société INFOSAT et également pour leur aide
qu’ils nous ont offerte tout au long du stage.

Nos remerciements les plus cordiaux s’adressent à notre encadreur Sakher TALIBI, ingénieur
développeur à INFOSAT, pour sa disponibilité, son aide, ses conseils précieux, ses critiques
constructives, ses explications et suggestions pertinentes ainsi que pour ses qualités humaines et
morales que nous avons toujours appréciées.

Nous ne manquerons pas l’occasion de remercier chaleureusement Mr Amine KOTNI pour son
incontestable contribution à l’accomplissement de notre projet, son caractère accueillant qui nous a
offert une ambiance très motivante et encourageante au travail, ainsi que pour sa disponibilité
extraordinaire qui nous a permis de surmonter les difficultés et autres problèmes rencontrés. Que
dieu préserve votre optimisme et votre enthousiasme.

vi

Nous remercions

toutes les personnes qui nous ont soutenus, d'une façon ou d'une autre, nous

éprouvons incessamment leur estime et amabilité, nous saluons réellement cette très haute
bienveillance que vous portez à notre égard et qui restera pour toujours une vraie image de marque
en nous.

Nous terminerons

ces remerciements en saluant vivement les membres du jury pour l’honneur

qu’ils nous ont fait en acceptant de juger notre travail.

Brahim & Said.

vii

Résumé:
Le présent document est le fruit de notre travail dans le cadre du stage de fin d'étude, pour
l’obtention du diplôme d’ingénieur d’état en télécommunications et technologies de l’information,
qui a été réalisé au sein de l'entreprise INFOSAT communications. Notre travail Consiste à étudier
les différents Framework de développement mobile hybride « multi plateformes » existants et
choisir le meilleur, et à réaliser un projet mobile E-banking permettant la gestion des opérations
bancaires.
Afin de suivre l'évolution des technologies de l'information et l’émergence du monde
mobile, notre application est conçue pour les différentes plateformes mobiles à savoir: Androïde,
IOS, BlackBerry, Windows phone, Web OS, Symbian ...
Nous avons commencé par l’élaboration d’une

étude fonctionnelle qu’on a fini par

l’élaboration d’une conception du projet, puis nous avons dressé une étude comparative des deux
meilleures solutions de développement mobile multiplateformes: Titanium et PhoneGap. Cette
étude nous a permis de déduire que phone Gap répond mieux à notre besoin. Ensuite nous avons
procédé à la réalisation de l’application.
Les principales fonctionnalités de l’ « e-Banking» sont l’authentification des membres, la
consultation des comptes et des mouvements, le virement bancaire, la demande de chéquier, la
demande de recharge, la géolocalisation, la consultation des effets, des crédits et des listes
impayées. Grâce à ces fonctionnalités l’abonné reste en contact avec son compte bancaire à
n’importe quel endroit où il se trouve et à n’importe quel instant.

viii

Abstract:
This document is the result of our work in the end study’s internship, in order to obtain
engineering degree in telecommunications and information technology, which has been done
within the company INFOSAT communications. Our mission is to study the different existing
mobile development framework hybrid "multi-platform" Existing and choose the most appropriate
one to realize our mobile project e-banking.

To follow the evolution of information technology and the emergence of the mobile world,
our application is designed for different mobile platforms namely android, iOS, BlackBerry,
Windows Phone, Web OS, Symbian...

We started with a comparative analysis between the two largely usedcross-platform mobile
development frameworks: Titanium and Phone Gap. Then we decide to use Phone Gap because it
is the most appropriate.

The main features of the "e-banking" are: authentication of members, consulting bank
accounts and movements, bank transfer, check book request, demand of charge, geolocation,
effect’s consultation, credits and unpaid list. With these features the subscriber remains in contact
with his bank account at any place where and at any time.

ix

‫ملخص:‬

‫هذا الكتاب عبارة عن ثمرة لمجهوداتنا التي بذلناها إلنجاز مشروع نهاية تكويننا‬
‫كطلبة مهندسين ،و ذلك بغية الحصول على رتبة مهندس دولة في تخصص تقنيات‬
‫المواصالت السلكية والالسلكية وتقنيات المعلومات، المهمة المطلوبة منا من طرف‬
‫شركة :”‪ “INFOSAT Communications‬كانت دراسة وتحليل وإنشاء برنامج‬
‫"البنك المحمول" وهو عبارة عن برنامج يخول لمستعمله االتصال بحسابه البنكي،‬
‫ومراقبة حسابه، وتحويل األموال، وغير ذلك من الخدمات التي يوفرها البنك العادي.‬

‫بدأنا بدراسة وتحليل المشروع، كما قمنا بمقارنة دقيقة بين تكنولوجيات البرمجة‬
‫المعلوماتية التي تستهدف جميع أنظمة االشتغال التي تستخدمها الهواتف المحمولة،‬
‫لنختار بعد ذلك ”‪ ”Phone Gap‬إلنجاز مشروعنا.‬

‫التطبيق الذي قمنا بتطويره، يمكن تثبيته على مختلف انواع الهواتف الذكية،‬
‫وبالخصوص التي تستعمل انظمة االشتغال مثل، ‪ Android‬و ‪ IOS‬و‬
‫‪BlackBerry‬و ‪ Web OS‬و ‪ Symbian‬الخ.‬

‫‪x‬‬
‫3102/2102 ‪Projet De Fin d’étude – ELKECHA Brahim & OUARRICH Said‬‬

Table des matières
Liste Des Figures............................................................................................................................................ 1
Liste Des Tableaux ........................................................................................................................................ 3
Acronymes Et Abréviations ......................................................................................................................... 4
Introduction : ................................................................................................................................................... 5
1.

Contexte Général du Projet :.................................................................................................................. 6

1.1. Présentation de l’organisme d’accueil : ................................................................................................. 7
1.1.1.

Présentation d’INFOSAT Communications : .......................................................................... 7

1.1.2.

Domaines d’intervention d’INFOSAT Communications : ...................................................... 7

1.2. Cadre général du projet :...................................................................................................................... 10
1.2.1.
1.2.2.

Objectifs du projet: ................................................................................................................... 10

1.2.3.

Fonctionnalités à mettre en place:............................................................................................ 11

1.2.4.

2.

Problématique et analyse du besoin :....................................................................................... 10

Planification du projet: ............................................................................................................. 12

Etude Fonctionnelle et Technique: ...................................................................................................... 14

2.1. Etude fonctionnelle:............................................................................................................................... 15
2.1.1.

Capture des besoins fonctionnels : ........................................................................................... 15

2.1.2.

Analyse fonctionnelle : .............................................................................................................. 15

2.1.2.1.

Diagramme des Use Cases: ............................................................................................... 15

2.1.2.2.

Descriptions des Use cases: ............................................................................................... 16

2.1.2.3.

Diagrammes de classes: ..................................................................................................... 19

2.2. Etude technique: .................................................................................................................................... 21
2.2.1.

Spécifications techniques : ........................................................................................................ 21

2.2.2.

Architecture: .............................................................................................................................. 21

2.2.2.1.

Architecture mobile:.......................................................................................................... 21

2.2.2.2.

Architecture serveur: ........................................................................................................ 21

2.2.3.

3.

Choix de technologie « Services Web » : ................................................................................. 22

Choix de Framework de développement mobile: ............................................................................... 25

3.1. Développement Hybride Vs Natif: ...................................................................................................... 26
3.1.1.

introduction: .............................................................................................................................. 26

3.1.2.

Quelle est la meilleure approche : ............................................................................................ 26

3.2.1.

Phone Gap: ................................................................................................................................. 28

3.2.2.

Titanium: .................................................................................................................................... 29

3.3. Comparaison : Titanium VS Phone Gap: ........................................................................................... 31
3.3.1.

Comparaison des plateformes supportées: .............................................................................. 31

3.3.2.

Comparaison des richesses des deux plates-formes: ............................................................. 32

3.3.2.1.

4.

Synthèse : ............................................................................................................................ 33

Mise en Œuvre du projet ...................................................................................................................... 34

4.1. Choix technologiques : .......................................................................................................................... 35
4.1.1.

Coté serveur: .............................................................................................................................. 35

4.1.2.

Coté mobile: ............................................................................................................................... 37

4.2. Architecture globale du projet : ........................................................................................................... 37
4.3. Implémentation : ................................................................................................................................... 39
4.3.1.

Authentification : ....................................................................................................................... 39

4.3.2.

Consultation des comptes : ....................................................................................................... 41

4.3.3.

Demande de recharge:............................................................................................................... 42

4.3.4.

Simulateur de crédit : ................................................................................................................ 43

4.3.5.

Effectuer un virement : ............................................................................................................. 44

4.3.6.

Demander un chéquier :............................................................................................................ 47

4.3.7.

Transférer de l’argent : ............................................................................................................. 49

4.3.8.

Les Tâches : ................................................................................................................................ 50

4.3.9.

Liste des comptes titres: ............................................................................................................ 51

4.3.10.

Consultation des effets : ............................................................................................................ 52

4.3.11.

Situation des crédits : ................................................................................................................ 56

4.3.12.

Liste des impayés : ..................................................................................................................... 57

4.3.13.

Géolocalisation :......................................................................................................................... 57

4.4. Déploiement: .......................................................................................................................................... 58
4.4.1.

Les dangers du reverse engineering:........................................................................................ 58

4.4.2.

Déploiement sur mobile: ........................................................................................................... 58

Conclusion :.................................................................................................................................................... 62
Glossaire: ........................................................................................................................................................ 63
Bibliographie : ............................................................................................................................................... 65
Webographie:................................................................................................................................................. 66
Annexe: ........................................................................................................................................................... 67

Liste Des Figures
Figure 1: Diagramme de Gantt du projet ........................................................................................................ 13
Figure 2:Diagramme des uses cases ................................................................................................................ 16
Figure 3:Diagramme de classes ....................................................................................................................... 20
Figure 4: shémat expliquant l'architecture MVC ............................................................................................. 22
Figure 5: architecture phone Gap.................................................................................................................... 29
Figure 6: Architecture titanium. ...................................................................................................................... 30
Figure 7: Architecture Grails ............................................................................................................................ 36
Figure 8: Schéma directeur du projet .............................................................................................................. 38
Figure 9: Schéma simplifié du fonctionnement de Spring Security ................................................................ 39
Figure 10: Page d’authentification .................................................................................................................. 40
Figure 11: Menu principal de l’application ...................................................................................................... 40
Figure 12: Situation des comptes d’un abonné ............................................................................................... 41
Figure 14: Demande de recharge. ................................................................................................................... 42
Figure 15: bloc de signature de la demande de recharge. .............................................................................. 43
Figure 16: Simulateur de crédit. ...................................................................................................................... 43
Figure 17: Choix du type de virement. ............................................................................................................ 44
Figure 18: Saisie d’un virement de compte à compte ..................................................................................... 44
Figure 19: Récapitulatif du virement de compte à compte. ........................................................................... 45
Figure 20: Page de succès d’un virement de compte à compte...................................................................... 45
Figure 21: Saisie d’un virement vers bénéficiaire ........................................................................................... 46
Figure 22: Récapitulatif d’un virement vers bénéficiaire ................................................................................ 46
Figure 23: Ecran de succès d’un virement vers bénéficiaire. .......................................................................... 47
Figure 24: Demande de chéquier. ................................................................................................................... 48
Figure 25: Demande de chéquier(2). ............................................................................................................... 48
Figure 26: Demande de chéquier avec succès. ............................................................................................... 49
Figure 27: Saisie d’un transfert d’argent. ........................................................................................................ 50
Figure 28: Récapitulatif d’un transfert d’argent.............................................................................................. 50
Figure 29: Liste des tâches............................................................................................................................... 51
Figure 30: Situation des comptes titre. ........................................................................................................... 51
Figure 31: Transaction titre et portefeuille titre. ............................................................................................ 52
Figure 32: Choix de type d’effet. ..................................................................................................................... 52
Figure 33: Les comptes tirés. ........................................................................................................................... 53
Figure 34: La liste des effets à payer. .............................................................................................................. 53
Figure 35: Les comptes tireurs. ....................................................................................................................... 54
Figure 36: Les effets à encaisser par compte. ................................................................................................. 54
Figure 37: Les effets à encaisser par dates d’échéance. ................................................................................. 55
Figure 38: Les effets à encaisser par compte. ................................................................................................. 55
Figure 39: Liste des dossiers. ........................................................................................................................... 56
Figure 40: Contenu d’un dossier avec liste des impayés. ................................................................................ 56
Figure 41: La liste des impayés. ....................................................................................................................... 57
Figure 42: géolocalisation. ............................................................................................................................... 58
Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013

1

Figure 43: processus du service phoneGap Build. ........................................................................................... 59
Figure 44: L'IDE Adobe Dream weaver ............................................................................................................ 59
Figure 45: fenêtre de phonegap build ............................................................................................................. 59
Figure 46: démarrage du service phonegap build. .......................................................................................... 60
Figure 47: connexion au service phonegap build ............................................................................................ 60
Figure 48: génération des fichiers exécutables. .............................................................................................. 61


2

Liste Des Tableaux
Tableau 1: Spécification techniques du projet ................................................................................................ 21
Tableau 2: Comparatif des protocoles de communication ............................................................................. 24
Tableau 3: Récapitulatif DM Natif Vs hybride ............................................................................................... 27
Tableau 5: comparaison des plateformes suportées. ..................................................................................... 32
Tableau 6: : Les APIs supportées par chaque plateformes. ............................................................................ 32


3

Acronymes Et Abréviations
A
AIR: Adobe Integrated Runtime
API : Application Programming Interface
App: Application

J
JS : Java Script
JSON: JavaScript Object Notation
JVM : Java Virtual Machine

B
BPM : Business Process Management
BSD: Berkeley software distribution

M

C

R

CSS:

D
DHTMLX: dynamic Hypertext Markup
Language

MVC : Model-View-Control

REST : REpresentational State Transfer

S

EAI : Enterprise Application Integration

SE: système d’exploitation
SOAP: Simple Object Access Protocol
SDK : Software Development Kit
SQL : Structured Query Language
SVG: Scalable Vector Graphics

G

U

E

GPS : Global Positioning System

UI: user interface
UML : Unified Modeling Language
URL: Uniform Resource Locator

H
HTML: Hypertext Markup Language
HTTP : HyperText Transfer Protocol
HTTPS : HTTP Secure

I
IDE : Integrated Development
Environment
IOS: Iphone operating system
IRC: Internet Relay Chat
IHM : Interface Homme Machine

W
WS: Web Service
W3C: The World Wide Web Consortium

X
XML : eXtensible Markup Langage


4

Introduction

Introduction :
Le mobile Banking est l'utilisation du téléphone portable pour fournir des services financiers
qui peuvent être des transactions d’argent ou des échanges d'informations entre le client et les
institutions financières. Il est basé sur l'idée d'utiliser en micro-finance un outil de communication,
téléphone portable, qui s'est très fortement répandu ces dernières années, et ceci afin de diversifier
et d'améliorer l'offre de services auprès de la clientèle actuelle.
Toutefois, le développement d’une telle application doit cibler plusieurs plateformes, quitte
à faire face au problème de la fragmentation concernant les applications mobiles et par la suite faire
limiter le nombre d'utilisateurs de l'application. C'est pour cela que le développement mobile
multiplateforme apparait.
C'est dans ce contexte qu’INFOSAT nous a confié, dans la cadre de notre projet de fin
d'étude, la mise en place d'une solution de mobile banking qui permettra d’exécuter des
fonctionnalités financières accessibles à partir du mobile.
Le présent rapport est une synthèse du travail réalisé le long de la période de notre stage. Il
est structuré selon quatre chapitres couvrants l'ensemble des axes de notre travail. Le premier
chapitre décrit l'organisme d'accueil INFOSAT, montre la problématique et l'analyse des besoins,
cite les objectifs et les fonctionnalités à mettre en place et montre la planification du projet.
Le deuxième chapitre définit l'architecture, l’étude fonctionnelle, la conception générale du
projet et la démarche que nous avons suivie.
Le troisième chapitre établit une étude comparative de deux frameworks de développement
mobile multiplateforme "TITANIUM et PHONE GAP" en termes de l'apport, la productivité, les
richesses des plateformes supportées et la gestion de déploiement. A la fin de ce chapitre nous
donnons une comparaison entre le développement hybride et le développement natif.

Au dernier chapitre nous mettons en œuvre le projet. En effet nous justifions les choix
technologiques, puis nous présentons les écrans des différentes fonctionnalités implémentées.


5

Chapitre 1

1.Contexte Général du Projet :
Dans ce chapitre, nous présenterons le contexte général du projet qui sera
décliné en deux parties : la première présentera la société d’accueil, et la
seconde décrira le contexte, la problématique, l’objectif attendu du projet ainsi
que les fonctionnalités à mettre en place et la planification du projet .


6

Chapitre 1

1.1. Présentation de l’organisme d’accueil :

1.1.1. Présentation d’INFOSAT Communications :
INFOSAT est une société de services orientés vers les nouvelles technologies qui
s’intéressent aux services des systèmes d’information, télécommunications et sécurité. Ceci
comprend des domaines aussi variés que la mise en place des solutions client/serveur,
l’administration de bases de données, le développement de logiciels et la mise en place des réseaux
informatiques et téléphoniques.
Les missions d’INFOSAT sont multiples. D’abord, INFOSAT Offre à ses clients, quelle
que soit leur localisation, des produits et des services dans le domaine des technologies de
l'information qui soient d'avant-garde et d'une juste mesure en fonction de leurs besoins et de leurs
moyens financiers. INFOSAT est venu pour être un fournisseur d'informatique reconnu comme un
leader pour la qualité de ses produits et de ses services et pour le professionnalisme de ses
ressources.
Nous citons aussi parmi les missions d’INFOSAT, la réalisation des interventions grâce à
des professionnels hautement motivés offrant une disponibilité totale envers les clients, tout en
démontrant un grand souci de la perfection et beaucoup de créativité dans les solutions qu'ils
proposent.
INFOSAT reflète une organisation où l’équipe travaille dans un climat serein et un
environnement agréable qui lui permet de s'épanouir et de jouir de toute l'autonomie souhaitable
afin de réussir et de se dépasser. INFOSAT participe à l'économie locale et régionale en étant un
groupe de professionnels présents dans les activités d'affaires, culturelles, sociales et
environnemental.

1.1.2. Domaines d’intervention d’INFOSAT Communications :
 Développement informatique :
-

Logiciels, Etudes, conception et intégration de solutions informatiques standards,
spécifiques et Open source sous les environnements Linux et Windows.


7

Chapitre 1
- Développement d’applications Web.
- Edition des logiciels notamment dans les métiers de la banque et des assurances,
- Développements spécifiques autour des technologies Web, Mobile et SMS,
INFOSAT ambitionne de se positionner comme un partenaire de référence auprès des
établissements financiers souhaitant procéder au développement et à l’intégration de progiciels
spécialisés. Leur objectif est de générer de la valeur ajoutée pour nos clients en respectant leurs
spécificités, contraintes, et exigences aussi bien sur le plan de la qualité que celui du coût.


Compétences de développement:

- Langages de programmation : Windev, VB, Delphi, Java (J2EE), C++
- Bases de données : PostgreSQL, SQL Server, Interbase/Firbird, MySQL…
- Développement mobile : iphone , Androide ,Titanium ,Phongap …
- Méthodes d'analyse et modélisation : Merise, UML.

Les prestations de service sont axées principalement autour de leurs produits, et couvrent les
volets suivants :
-

Accompagnement pour la définition et le cadrage des besoins et intégration de leurs
solutions,
Prise en charges des développements spécifiques,
Formation et conduite de changement,
Hébergement (en option) en mode SaaS de notre solution,
Maintenance et assistance post-production,

 Réseaux informatiques :

-

Etude et conception d’architectures et solutions réseaux (LAN- INTRANET-WIFI….)
Installation de serveurs LINUX /Windows Server (contrôleur de domaine, serveur de
fichiers, messagerie, site web, impression…)
Etablissement de stratégies de sécurité réseau (Proxy, Firewall, sauvegardes, antivirus…)
Travaux de câblage Ethernet (CAT5, CAT6, Fibre optique), armoires informatiques,
Antennes et Points d'accès WIFI….

 RÉSEAUX TELEPHONIQUES :

-

Travaux de câblage téléphonique (prises, moulure et accessoires…)
Equipement, configuration et installation de standards téléphoniques ainsi que la Téléphonie
IP.


8

Chapitre 1

 MAINTENANCE ET REPARATION :

-

SAV et Contrats de maintenance sur tous les produits (matériels et logiciels) fournis par
INFOSAT.
Maintenance et réparation soft et hard informatique, téléphonique et électronique.

 VENTE :

-

SYSTÈMES DE POINTAGE (Pointeuses, cartes de proximité, badges, logiciel de gestion
de présence),
LOGICIELS (LGP Gestion de pointage, antivirus, gestion pharmacie, gestion commerciale,
gestion paie),
MATERIEL ET ACCESSOIRES INFORMATIQUE (Micro-ordinateurs, Imprimantes,
Traceur, Onduleur…) ,
EQUIPEMENTS DE TELECOMUNICATION (routeurs, switchs, modems, équipements
WIFI, standards et appareils téléphoniques),
SOLUTIONS DE TÉLÉSURVEILLANCE (caméras de surveillance, caméras IP, cartes
DVR….).


9

Chapitre 1

1.2. Cadre général du projet :
1.2.1. Problématique et analyse du besoin :
Au fil des années, les concepts de temps et de distance ont perdu de leur significativité à
cause des nouvelles technologies et plus spécifiquement l’Internet et les Smartphones, qui ont
acquis une grande importance dans notre quotidien. L’un des secteurs économiques le plus touché
par ce phénomène est le secteur bancaire, en effet aujourd’hui la banque propose un nombre
croissant de services délivrés en ligne : de la simple consultation des soldes bancaires ou la
création de virements électroniques, on peut dorénavant bien gérer nos opérations boursières,
solliciter un crédit, voir même ouvrir un nouveau compte sans devoir se présenter au guichet d’une
banque. Certaines de ces activités étaient impossibles il y a quelques années.

Agissant avec lucidité et consciente des évolutions que connait son domaine, la banque X (le nom réel de la banque a été omis pour des raisons de confidentialité)- a fait appel à la société
INFOSAT Communications afin de lui développer une application de gestion des opérations
bancaires. Cette banque se veut être crédible et ne tient en aucun cas à perdre sa confiance auprès
de ses clients. L’application était déjà dotée de quelques fonctionnalités en back office sur le web
et avait besoin d’être améliorée et mise en place sur mobile, et c’est justement le but de notre
projet. L’idée sur laquelle nous nous sommes basés était d’utiliser un moyen de communication
sécurisé pour fournir des services financiers qui peuvent être des transactions financières et des
échanges d’informations entre le client et l’institution financière.

1.2.2. Objectifs du projet:
Le concept de la performance occupe une place centrale dans le processus de gestion de
toute entreprise et précisément la société « INFOSAT Communications », puisque l’objectif
principal de cette dernière est d’obtenir des résultats compatibles avec sa mission et sa
planification stratégique et opérationnelle. L’évaluation de la performance est donc une activité
omniprésente et s’avère encore plus qu’une nécessité avec tout changement technologique ou
commercial opérant au sein de la banque.
Notre application en tant que moyen de bonne gestion, doit être à la hauteur des attentes, et
de la banque, et des clients bien évidemment. Les dimensions de la performance commerciale
exigées par la banque dans le cahier des charges étaient :


10

Chapitre 1
1. L’amélioration de la qualité des services : La temporalisation de la prestation de service
permise par divers équipements et systèmes d’informations, la délocalisation, le gain de
temps, la ré-négociabilité, la flexibilité, la sécurité des transactions ainsi que l’interaction en
temps réel sont les principales améliorations de la qualité des services de la banque.
2. La réduction des coûts


Coût de traitement par le client



Coût de transaction



Coût d’administration

3. La variété de la gamme d’offres : L’adoption des nouveaux canaux de l’E-Banking ouvre de
nouvelles potentialités à la banque pour élargir sa gamme de produits et services offerts aux
clients (signature électronique, paiement en ligne,..)
4. La conquête de nouveaux marchés : Les nouveaux canaux de distribution permettent de
desservir des consommateurs à travers des zones géographiques de plus en plus éloignés.
Plus la banque adopte les canaux électroniques de distribution et de communication, plus
elle aura la possibilité de contourner les barrières géographiques, et ainsi conquérir, gérer et
fidéliser de nouveaux clients.
5. Le renforcement de la relation avec les clients : cette relation a tendance à se renforcer avec
l’utilisation de ces nouveaux canaux multiples, intégrés et disponibles en tout temps.
Pour satisfaire ces besoins et assurer les nouvelles fonctionnalités que veut s’attribuer la
banque X, un site web classique paraît une solution inévitable, mais qui doit être étendue avec
l'utilisation d'une application web mobile.

1.2.3. Fonctionnalités à mettre en place:
Les différentes fonctionnalités à mettre en place dans l’application sont :
 L’accès sécurisé aux comptes bancaires et consultation de leurs soldes.
 La réalisation des transactions et la visualisation de leurs détails.
 La réalisation de virements :
Virement de compte à compte.
Virement vers un bénéficiaire.
 Le Transfert d’argent.
 La demande de chéquier(s).

11

Chapitre 1
 La visualisation des tâches non accomplies par le client (Système de notification).
 La simulation d’un crédit.
 Le contact avec la banque et ses agences.
 Un système de géolocalisation.

1.2.4. Planification du projet:
Dans le cadre de la conduite du projet, la réalisation d’un planning à suivre tout au long du
stage de fin d’études s’impose. Ainsi, le stage a débuté le mardi 4 février 2013. Du coup, une
réunion a été tenue afin de définir le calendrier du projet.
Le planning sur lequel on s’est mis d'accord est subdivisé en cinq grandes étapes:
 La première est l’étape de documentation et d’expression des besoins.
 La seconde est l’étape des spécifications fonctionnelles et techniques.
 La troisième étape, quant à elle, traite de la conception.
 La quatrième étape définit le contexte technique.
 La dernière étape est consacrée à l’implémentation, le jeu de tests et le déploiement sur
mobile.
Le planning des étapes de déroulement du projet est présenté à la figure 1 qui représente le
diagramme de GANTT qui permet de rendre plus simple le suivi de l’avancement du projet.
Conclusion:
Après une présentation de l'organisme d'accueil. Nous avons décrit le contexte, la
problématique, les objectifs du projet, ainsi que la mission à accomplir dans notre stage. Dans la
prochaine partie nous établirons une étude comparative des framework de développement mobile.


12

Chapitre 1

Figure 1: Diagramme de Gantt du projet


13

Chapitre 2
2.Etude Fonctionnelle et Technique:
Ce chapitre sera consacré à la définition de l'architecture et la conception
générale de la solution. Il décrira aussi la démarche à suivre, et mettra en œuvre
une étude fonctionnelle du projet ainsi qu'une autre technique.


14

Chapitre 2

2.1. Etude fonctionnelle:
2.1.1. Capture des besoins fonctionnels :
L’application à réaliser est une application de gestion d’opérations bancaires, elle permet à
un abonné de réaliser toutes sortes d’opérations liées à son compte bancaire, il peut visualiser le
solde de son ou ses comptes et revoir les dernières opérations effectuées sur ces derniers. Il peut
également effectuer des virements, faire des demandes de chéquiers, ainsi que transférer de
l’argent à un particulier…, en s’étant bien évidemment authentifié pour pouvoir accéder à ces
fonctionnalités.
En plus, un abonné a la possibilité de localiser les agences les plus proches, chercher les
agences par ville et pays et connaitre la distance qui sépare son emplacement de l’agence choisie,
ainsi que tracer un itinéraire vers cette destination.
Enfin, il peut faire une simulation de crédit en choisissant le montant d’emprunt, pour ainsi
connaitre la durée de l’emprunt ou le montant mensuel à payer selon le choix.

2.1.2. Analyse fonctionnelle :
2.1.2.1. Diagramme des Use Cases:
Les cas d'utilisation permettent de recueillir, d'analyser et d'organiser les besoins, et de
recenser les grandes fonctionnalités d'un système. Il s'agit donc de la première étape UML
d'analyse d'un système. Dans cette section nous allons présenter les cas d’utilisation concernant le
module de :
 Gestion des opérations bancaires.


15

Chapitre 2

Figure 2:Diagramme des uses cases

2.1.2.2.

Descriptions des Use cases:

 Consulter un compte :
Acteur :
Abonné
Description :
L’abonné a la possibilité de consulter le solde de chacun de ses comptes, et de voir les
mouvements concernant chaque compte. Chaque mouvement est constitué des informations
suivantes :





Identifiant du mouvement
Intitulé du mouvement
Date d’exécution
Montant du mouvement


16

Chapitre 2

Effectuer un virement :
Acteur :
Abonné
Description :
Dans ce cas d’utilisation l’abonné peut effectuer un virement de compte à compte, c’est un
virement qui se fait entre les comptes du même abonné. Pour cela, il doit saisir toutes les
informations qui concernent ce type de virement, ce dernier caractérisé par :







Identifiant de ce virement
Compte à créditer
Compte à débiter
Montant du virement
Motif du virement
Date d’exécution du virement

L’abonné peut éventuellement effectuer un virement vers un bénéficiaire. Ce virement ne
concerne pas un seul abonné, mais se fait entre un abonné et un autre existant parmi les
bénéficiaires de cet abonné. Pour cela, il doit également saisir toutes les informations qui
concernent ce type de virement, qui se voit caractérisé par :







Identifiant de ce virement
Bénéficiaire
Compte à créditer
Montant du virement
Motif du virement
Date d’exécution du virement

Exceptions :
L’identifiant du virement est une valeur unique. Si cette donnée existe déjà dans le système,
une exception doit être levée.
Le montant du virement ne doit pas dépasser le plafond quotidien spécifié dans le contrat et
qui représente la somme totale de tous les montants des opérations pouvant être effectuées par les
abonnées liée à ce contrat.
La date d’exécution ne doit pas être antérieure à la date système, sinon une exception est
levée.
Dans un virement de compte à compte (même abonné), le compte à créditer doit être
différent du compte à débiter.
 Effectuer un transfert d’argent :
Acteur :
Abonné

17

Chapitre 2
Description :
L’abonné peut effectuer des transferts d’argent vers un bénéficiaire, même n’étant pas client
de la banque. Pour cela, il doit saisir toutes les informations qui concernent ce transfert, qui se voit
caractérisé par des informations concernant le compte à débiter:
 Compte à débiter
 Montant du transfert
 Motif du transfert
Ainsi que des informations sur le récepteur du transfert :








Nom et prénom du bénéficiaire
Type de la pièce d’identité (Carte national, passeport, permis, carte séjour ...)
Numéro pièce d’identité
Adresse
Ville
Pays
Téléphone principal

 Demander un chéquier :
Acteur :
Abonné
Description :
L’abonné a aussi la possibilité de faire une demande d’un carnet de chèques, soit pour luimême ou pour un autre bénéficiaire, et cela en spécifiant les informations suivantes :





Compte à débiter
Nombre de chéquiers
Type de chéquier
Moyen de remise du/des chéquier(s)

Ainsi que des informations citées précédemment sur le bénéficiaire.

 Simuler un crédit :
Acteur :
Abonné
Description :
Si l’abonné veut connaitre les détails d’une prise de crédit de cette banque, il a la
possibilité de faire une simulation de crédit. Pour cela, il fournit le montant total du prêt, ainsi que
l’une des informations suivantes :


Le montant mensuel qu’il a l’intention de payer


18

Chapitre 2


La durée au bout de laquelle il compte rembourser le prêt

Et en fonction de l’information saisie, l’autre information est calculée.

 Localiser les agences de la banque :
Acteur :
Abonné
Description :
Dans ce cas d’utilisation, l’abonné peut connaitre sa position via GPS et ainsi déterminer les
agences qui sont à proximité de lui, ou bien les rechercher par ville et par nom d’agence, ces
derniers qui sont transformés en coordonnées sur la map, pour enfin connaitre la distance qui le
sépare d’une agence.

2.1.2.3.

Diagramme de classes:

Ce diagramme regroupe les différentes classes du projet à savoir : «Compte», «
VirementVersBenificiares », «VirementCompteAcompte », «TransfertArgent », « PaysAgence »,
« Virement », « Benificiare », « Contrat », « Agent », « Demande de chequier » …, contribuant à
effectuer toutes les opérations bancaires exigées par le cahier des charges.


19

Chapitre 2

Figure 3:Diagramme de classes


20

Chapitre 2

2.2. Etude technique:
2.2.1. Spécifications techniques :
L’outil doit être en mesure de répondre à un certain nombre d’exigences techniques. Cellesci se résument dans les objectifs présentés dans le tableau suivant :
Objectif

Description

Multiplateformes

L’application doit pouvoir être accessible
depuis les deux plateformes iOS et Android.

Fluidité du déploiement

L’application doit marcher sans problèmes
dans toutes les versions antérieures du SE.

Confidentialité

Les utilisateurs du système sont identifiés par
leurs noms et leurs mots de passe.

Optimisation du temps de réponse

Aucune donnée ne doit être stockée
localement.

Sécurité des transactions

Toutes les transactions du client vers le
serveur doivent être sécurisées.

Tableau 1: Spécification techniques du projet

2.2.2. Architecture:
2.2.2.1. Architecture mobile:
Deux approches possibles lorsque l’on débute un projet d’application mobile ciblant
plusieurs plateformes :
 L’approche native: consiste à développer l’application pour chacune des plateformes.
 L’approche hybride: qui consiste à développer une Application réalisée via un site Web
optimisé pour mobile (Web Apps).
La comparaison détaillée de ces deux approches sera dans le troisième chapitre.

2.2.2.2.

Architecture serveur:

Pour la séparation des données, des traitements et de la présentation, On adopte
l’architecture MVC. Programmer en utilisant MVC sépare l’application en 3 parties principales : Le
Modèle - La Vue - Le Contrôleur:
1. Le modèle: Il représente les données et les règles métiers. C’est dans ce composant que
s’effectuent les traitements liés au cœur du métier. Les données peuvent être liées à une base
de données, des services web, etc.
2.

La vue : correspond à l’IHM. Elle présente les données et interagit avec l’utilisateur.


21

Chapitre 2
3. Le contrôleur : se charge d’intercepter les requêtes de l’utilisateur, d’appeler le modèle puis
de les rediriger vers la vue adéquate. Il ne doit faire aucun traitement. Il ne fait que de
l’interception et de la redirection.

Figure 4: shémat expliquant l'architecture MVC

2.2.3. Choix de technologie « Services Web » :
 Services Web :

Définition :
Un " Service Web" est une application logicielle à laquelle on peut accéder à distance à
partir de différents langages basés sur XML.
Un " Service Web" est identifié par un URL, comme n'importe quel site Web. Il s'exécute
sur un "Serveur d'Applications". Peu importe l'ordinateur, le système d'exploitation ou le langage
utilisés par le client. Plus simplement, C'est le fait de mettre des ressources à disposition sur Internet,
via un protocole d'échanges standardisé, pour des programmes écrits dans des langages

quelconques. Cela nécessite :


un encodage (toujours XML) ;



un transport (souvent HTTP) ;



une organisation des requêtes et des réponses.


22

Chapitre 2
La procédure de fonctionnement d'un service Web en bref est la suivante :
1. le service Web définit un format pour les requêtes et les réponses.
2. un ordinateur demandeur effectue une requête.
3. le service Web effectue une action, et renvoie la réponse à l'ordinateur demandeur.
 Argumentation du choix :
Les Services Web permettent de :


Faciliter le travail du développeur dans la mesure où le modèle d’interaction par appel de
méthodes métiers est le même que celui de l’application, et donc les services Web
permettent de faire appel aux méthodes métiers par plusieurs interfaces sans avoir à refaire
le code pour chaque interface.



Améliorer un aspect de l’interopérabilité en spécifiant le format dans lequel les informations
doivent être encodées.



Optimiser le temps d’appel au serveur puisque aucune donnée ne sera stockée localement
lors des appels distants.
 REST ou SOAP, lequel choisir ?
Après le choix des web services comme moyen de communication entre le client et le

serveur, vient le choix du protocole de communication. Lors de nos recherches, nous avons trouvé
deux protocoles qui ont suscité notre curiosité : REST et SOAP, ce qui nous a mené à faire une
étude comparative afin de faire le bon choix.
REST et SOAP sont des styles architecturaux qui permettent la transmission d’objets
distants. Ce sont eux qui autorisent les objets à invoquer des méthodes d’objets situées sur un autre
serveur.

SOAP
Vision et but de

Utiliser le web pour échanger des

l’application

objets

Type

SOAP utilise des requêtes cachées

REST
Ouvrir le web aux applications
REST utilise des requêtes HTTP et


23

Chapitre 2
d’administration

dans des fichiers XML ainsi son

donc son administration est comme

administration comme celle d’un

celle du Web

EAI
Un service SOAP se met en place
Type de
développement

comme le déploiement d'un objet.
Cela ouvre la porte à l'utilisation de
langages de programmation à
typage statique

Interopérabilité
et plateformes

Un service REST se met en place
comme une page Web. Cela ouvre
la porte à des développements
rapides, aux tests possibles avec un
simple navigateur et à l'utilisation
de langage de scripts

SOAP utilise beaucoup de normes

REST n’a besoin que d’une pile

et versions de chaque normes ce qui

HTTP pour n’importe quelle

diminue son interopérabilité

plateforme

*

Tableau 2: Comparatif des protocoles de communication

 Argumentation du choix :
REST a été la meilleure solution comme protocole de communication du fait que :
- Il est simple à mettre en place.
- Il est plus sécurisé que son concurrent lors des appels distants.
- Le choix de la solution mobile que nous avons appréhendé était plus compatible avec ce
protocole.
Conclusion:
Les parties traitées dans ce chapitre sont les plus cruciales pour tout développement. Il s'agit
de la capture des besoins fonctionnels et la phase d'analyse et de la conception, en se basant sur le
diagramme de cas d'utilisation et le diagramme de classes. On a traité aussi l'architecture et les
spécifications techniques. Les résultats de cette partie représentent la base de la réalisation
technique du projet, qu’on commencera par une étude comparative des framework de
développements existants.


24

Chapitre 3
3.Choix de Framework de développement mobile:
Cette partie dresse une étude comparative entre deux framework de
développement mobile multiplateforme à savoir phone Gap et Titanium. Elle
traite également la comparaison entre les développements natif et hybride.


25

Chapitre 3

3.1. Développement Hybride Vs Natif:
3.1.1. introduction:
Les applications natives sont des applications construites et installées sur des plates-formes
spécifiques, comme iOS ou Android, en utilisant un SDK spécifique à chacune. Par exemple, pour
l'iPhone et l’iPad d'Apple, les applications sont conçus et développées sur iOS : écrits dans Xcode
en utilisant l’Objective-C. Quand-à Android a sa propre version de Java et Windows utilise C #, et
ainsi de suite.
Parmi les inconvénients des applications natives, c’est qu’elles sont écrites pour une plateforme et ne peuvent pas être déployées sur une autre. Aussi, les développeurs ont toujours besoin
de ressources supplémentaires pour développer et maintenir chaque plate-forme, qui est toujours
coûteux, d’où le développement mobile hybride apparait.

3.1.2. Quelle est la meilleure approche :
Le meilleur choix dépend du type d'application qu’on souhaite développer. Par exemple, les
applications telles que des jeux vidéo et les applications qui contiennent des animations
favoriseraient le développement natif, alors que les applications hybrides peuvent être mieux
adaptées pour les applications d'entreprise mobiles, car ils sont multiplateformes, d’où la cible est
un marché vaste. Ci-après quelques critères qu’on a pris en considération lors du choix de notre
solution de développement.
 Complexité: Quelle est le niveau de complexité de l'application? Est-ce-que c’est
une application rapide qui accède à un service de base de données ou sur le Web pour
certaines données à afficher?
– dans notre cas une application Web mobile peut suffire. .
 Performance: Quel type de rendement est exigé par l'application, par exemple, pour
regarder en temps réel des données à partir du réseau, la performance de l’application
mobile dépend de la latence du réseau et des capacités du serveur.
-- Les deux : hybrides et natif offrent des bonnes performances.
 La connectivité et la disponibilité: Quel est le type de connectivité exigé? Est-ce
que l'application exige d’être connecter en permanence afin de récupérer les données
récentes?
- Les applications natives et hybrides peuvent être construites pour fonctionner en
ligne et même hors ligne.
 multi-plate-forme Exigences: Ce critère fait la grande différence, et seules les
applications hybrides qui supportent le développement multi-plate-formes.
 Appareil-Services d'accès: Les applications natives ou hybrides permettent
d'accéder aux services périphériques locaux, tels que la caméra, app contacts,
accéléromètre, etc.


26

Chapitre 3
 Ressources: Pour le développement natif, Le nombre de développeurs consacrer à la
construction et au développement de l’application mobile, leur niveau de
compétence aussi l’environnement de travail « ici un système d'exploitation de
chaque plate-forme, de langage de programmation bien spécifie, et des devices pour
les tests » rend le travail couteux, et si on souhaite ajouter une autre plate-forme,
donc un autre langage, une autre SDK, de nouveaux compétences.
-- Pour ce critère les applications hybrides sont les plus rentables, mais il peut y
avoir des petites différences de performances.



Autre critères:

Native

Hybrid

Graphiques

Native APIs

HTML, Canvas, SVG

Performance

Rapide

moyenne

Distribution

Appstore

Appstore

Camera

oui

oui

Notifications

oui

oui

Contacts

oui

oui

Stockage hors ligne

Secure file storage

Fichiers de système sécurisés.

Géolocalisation

oui

oui

connectivité

Online et offline

Online et offline

Development skills

ObjectiveC, Java

HTML5, CSS, Javascript

App Features

Device Access

Tableau 3: Récapitulatif DM Natif Vs hybride


27

Chapitre 3
D’après cette étude on constate que le développement hybride est globalement plus
productif. C’est une solution pour les personnes souhaitant effectuer un investissement sérieux
dans le mobile. Mais sans oublier qu’ils ne vont jamais remplacer d’une manière entière le natif.

3.2. Développement mobile multiplateformes:
Il existe plusieurs Framework de développement mobile hybride basés sur JavaScript et qui
permettent d’améliorer la productivité, on cite : PhoneGap(Apache Cordova), Appcelerator
Titanium, jQuery Mobile, Sencha Touch, DHTMLX Touch, Limes JS, JQTouch, …
Ces Framework partagent quelques caractéristiques à savoir :
 Optimisés pour les appareils tactiles : la saisie de données n’est plus restreinte à la souris
ou au clavier mais devient aussi faisable par les doigts ce qui représente un ensemble de
challenges pour le design des IU. Les plateformes de développement mobile fournissent
des éléments standards pour les interfaces graphiques et une gestion des événements en
particulier pour le développement mobile.
 Une variété de plateforme : ils supportent des appareils avec différents systèmes
d’exploitation tels que Ios et Android ce qui permet de fournir l’application à plusieurs
utilisateurs.
 Lightweight : à cause des limitations da la bande passante, ces Framework se concentrent
très fortement sur la réduction des tailles des fichiers.
 Utilisation des Standards de HTML5/CSS 3 : la plupart des équipements mobile se dote
d’un navigateur qui supporte HTML5 et CSS3, ainsi les Framework de développement
web mobile profitent des fonctionnalités disponibles dans ces spécifications de W3C.

Dans notre projet nous avons effectué une comparaison entre Appcelerator Titanium, Phone
Gap. A partir de cette étude nous avons pu établir les avantages et les inconvénients de chacune
d’elles, ce qui nous a permis choisir la plateforme qui convient pour la réalisation du projet.

3.2.1. Phone Gap:
C’est un framework open source (acheter ne par adobe le 3 octobre 2011. Ceci confirme
l’intérêt que l’on peut avoir envers cette solution. Ce Framework permet de convertir des
applications développées par le langage Java script, HTML et CSS en application native à l’aide
du service
Pour développer des applications PhoneGap, on crée des documents HTML, CSS et des
fichiers JavaScript dans un répertoire local, tout comme l'élaboration d'un site Web. Ce qui nous

28

Chapitre 3
permet de profiter de quelques outils précisément le navigateur web du bureau, sans avoir besoin
de l'ensemble des outils natifs de chaque éditeur.
La compilation et la génération des fichiers exécutables sur chacune des plateformes
ciblées : IOS, Android, Windows phone 7, BlackBerry…, se fait à l’aide de l’outil Phone Gap
Build. C’est un service qui permet la compilation du projet dans le Cloud et la génération des
APK.

Figure 5: architecture phone Gap

On peut toujours tester l’application développée soit avec l’émulateur soit avec le device,
mais bien sur après avoir téléchargé le fichier exécutable convenable, généré par le service Phone
Gap Build.
 Les avantages :







petite bibliothèque.
Accès à de nombreuses ressources matérielles.
Extensibilité.
Communauté active.
Compilation à partir du cloud.

 Les inconvénients :

 conception avec callback parfois difficile à accorder avec d'autres librairies
JavaScript.

3.2.2. Titanium:


29

Chapitre 3
C’est un Framework open source développé par Appcelerator qui vend des supports et des
formations sur Titanium. Cette solution permet de développer des applications hybrides en
utilisant JavaScript, HTML et CSS.

Titanium est basée sur deux aspects de développement mobile:



Un noyau d'APIs pour créer des applications mobile qui peuvent être installées sur
différentes plateformes.
Parfois Ils existent des APIs spécifiques pour chaque plate-forme, par exemple des
conventions pour l’interface graphique, et des fonctionnalités que les développeurs devraient
prendre en considération lors de l’élaboration d’une application.

Pour ces raisons, Titanium ne peut pas être considéré comme une solution pour coder une
seule fois, exécuter partout’ comme Phone Gap.
 Fonctionnement du Framework :

Généralement, lors de l’exécution, l’application consiste en trois éléments qui sont :

Le code source JavaScript.

La mise en œuvre des APIs Titanium dans la plate-forme spécifique.

L’interpréteur de JavaScript qui est utilisé pour évaluer le code à l’exécution.

Les composants de l’UI peuvent être organisés hiérarchiquement pour créer
des interfaces utilisateurs complexes. Les objets proxy qui représentent une interface pour
les APIs non visuelles (comme système de fichiers I / O ou accès de base de données)
s’exécutent dans le code natif, et de façon synchrone pour renvoyer un résultat JavaScript.

Figure 6: Architecture titanium.

Pour développer une application avec Titanium, le développeur doit nécessairement installer
les SDK de la plateforme ciblée par exemple Ios et Android. Cependant, même après l’installation
de ces outils, l’utilisateur interagit souvent avec l’interface de Scripting de SDK de Titanium


30

Chapitre 3
(Aujourd’hui basée sur Pyhton). Ceci peut être réalisé soit avec les commandes Titanium ou très
souvent avec Titanium Studio qui est un IDE basé sur eclipse.
En utilisant l’ensemble des outils de Titanium, le développeur peut générer un répertoire
pour le projet, qui contient la configuration et la localisation des fichiers et un répertoire qui
contient les images, ainsi que le code source JavaScript utile pour donner plus d’importance à
l’application. Le développeur n’aura pas à utiliser les fichiers HTML et CSS que s’il a l’intention
de développer une application hybride qui est à la fois native et basée sur une interface graphique
HTML. Les applications de Titanium peuvent utiliser une interface graphique hybride (web et
native) comme l’application native Facebook par exemple. L’exécution d’une application de
Titanium se fait via l’émulateur de la plate-forme ciblée.
 Les avantages :
 Application native : aspect natif & performances.
 Accès aux ressources matérielles.
 Vitesse de développement.
 Extensibilité.



Les inconvénients :
 Mauvaise documentation, manque de ressources d’apprentissage.
 IDE réclamant une connexion Internet permanente.
 Parfois de nombreuses fuites de mémoire apparaissent.
 Les SDK de chaque plateforme est nécessaire.

3.3. Comparaison : Titanium VS Phone Gap:
3.3.1. Comparaison des plateformes supportées:
On commence par la comparaison des plateformes supportées par chacun des deux FrameWorks. En pratique, les applications développées par PhoneGap peuvent être installées et
exécutées sur sept plateformes différentes « voir tableau numéro 5 ».
Concernant Titanium, le support de BlackBerry et Windows phone sont encore récents et
disponible uniquement sous Windows. A cause de l’écrasante domination de l’iPhone,
d’Android et de BlackBerry), on ciblera généralement ces 3 plateformes uniquement. Mais
quelques entreprises ciblent également les plateformes Web OS, Symbian, Bada …, Donc Phone
Gap devient une solution incontournable. Ci-après un tableau qui illustre les différentes
plateformes supportées par chacun des Framework.

Phone Gap
1234-

MAC IOS
Android
BLACKBERRY
WINDOWS PHONE

Titanium
1234-

MAC IOS
ANDROID
BLACK BERRY10.
WINDOWS PHONE.


31

Chapitre 3
5- BADA
6- SYMBIAN
7- WEB OS
Tableau 4: comparaison des plateformes suportées.

3.3.2. Comparaison des richesses des deux plates-formes:
En général il y’a pas de grande différence entre ces deux plateformes en termes des APIs
supportées. Pourtant, il y a quelques une en ce qui concerne l’aspect général de chacune.
Titanium est fonctionnellement riche et fournira une apparence plus proche du natif, ce qui
est en général l’objectif des concepteurs d’applications.
PhoneGap est généralement limité en termes de fonctionnalités, car à chaque fois on doit
concevoir les écrans comme des pages Web et non des écrans natifs. .
Ci-après un tableau récapitulatif des APIs et plugins supportés par les deux Framework :
APIs

PhoneGap

Titanium

Accéléromètre

Oui

Oui

Caméra

Oui

Oui

Media

Oui

Oui

Map

Oui

Oui

Géolocation

Oui

Oui

Facebook

Oui

Oui

Database

Oui

Oui

FileSystem

Oui

Oui

Cloud

Oui

Oui

Contacts

Oui

Oui

Notification

Oui

Oui

Network

Oui

Oui

UI

Non

Oui

Tableau 5: : Les APIs supportées par chaque plateformes.


32

Chapitre 3

3.3.2.1.

Synthèse :

L’utilisation de JavaScript devient de plus en plus large, donc il est nécessaire, pour
développer ce type d’applications, de se former profondément à JavaScript et de connaître les
design patterns et la structuration /modularisation du code de ce langage. De manière
globale, l’environnement de développement de Phonegap est mieux intégré, plus documenté ainsi
qu’il est facile à apprendre.

Conclusion:
Cette partie a apporté une vision claire sur le développement mobile multiplateforme et a
permis de faire sortir les avantages et les inconvénients des deux framework et a distingué entre le
développement hybride et les développements natifs. Cette étude est une étape préliminaire vers
l'étude technique du projet qui fera, en plus de l'étude fonctionnelle, l'objet de la prochaine partie


33

Chapitre 4

4.Mise en Œuvre du projet
Dans ce chapitre on présentera la réalisation technique des différentes
fonctionnalités du projet.


34

Chapitre 4

4.1. Choix technologiques :
Nous avons opté pour l’utilisation des technologies suivantes pour plusieurs
notamment pour bénéficier de l’expérience du cadre professionnel présent à
Communications par rapport à la partie serveur, mais également pour la simplicité
utilisation. Pour la partie mobile, nous avons effectué une étude comparative pour
déterminer l’outil que nous avons utilisé.

raisons,
Infosat
de leur
pouvoir

4.1.1. Coté serveur:

 Groovy :

Groovy est un langage de programmation orienté objet destiné à la plate-forme Java. Il
constitue une alternative au langage Java pour cette plate-forme et est inspiré de Python, Ruby et
Smalltalk. Il utilise une syntaxe très proche de Java, avec des accolades, et est directement compilé,
soit à la volée dynamiquement, soit classiquement avec un compilateur en bytecode.

 Grails :

Grails est un framework open source de développement agile d'applications web basé sur
le langage Groovy et sur le patron de conception Modèle-Vue-Contrôleur. Grails est basé sur cinq
principes fondamentaux :





Ne pas se répéter : les éléments de l'application ne doivent être qu'à un seul endroit.
L'architecture MVC et la méta programmation en Groovy rendent cela possible.
Convention plutôt que configuration : il est inutile de préciser des détails lorsqu'ils
respectent des conventions établies. Grails exploite cela en proposant des comportements
par défaut pour la plupart de ses fonctionnalités.
Architecture orientée modèle : le point d'entrée et la pierre angulaire d'un développement
Grails est la description formelle des classes représentant le domaine métier (Modèle
conceptuel de données) ainsi que de leurs dépendances. Les couches techniques sousjacentes sont générées.


35

Chapitre 4




Prototypage : Les mécanismes de scaffolding offerts par le Framework permettent de
générer automatiquement un prototype d'application "présentable" aux utilisateurs dès la
formalisation des classes de domaine.
Exploiter la puissance de la JVM : les scripts Groovy étant compilés en bytecode Java,
Grails exploite totalement la richesse et la puissance du monde Java.

 Architecture Grails :

Figure 7: Architecture Grails

 PostgreSQL :

PostgreSQL est un système de gestion de base de données relationnelle et objet (SGBDRO).
Il supporte une grande partie du standard SQL tout en offrant de nombreuses fonctionnalités
modernes :






requêtes complexes,
clés étrangères, triggers,
vues,
intégrité transactionnelle,
contrôle des versions concurrentes (MVCC ou multi version concurrency control).


36

Chapitre 4

 SpringSource Tool Suite :

Basée sur Eclipse, SpringSource Tool Suite est conçue pour développer des applications
Java reposant sur Spring.

4.1.2. Coté mobile:
Critères de choix : Etude comparative PhoneGap vs Titanium , déjà présentée dans le
troisième chapitre :

VS

4.2. Architecture globale du projet :


37

Chapitre 4

Figure 8: Schéma directeur du projet

La figure donne une idée générale sur le fonctionnement du projet, et qui est la suivante :
Le client envoie une requête sécurisée HTTPS via le protocole REST au serveur web, et
plus précisément au contrôleur où sont injectés les Web Services. Grâce à ses interactions avec les
sévices il consulte les méthodes métiers, ainsi qu’avec le domaine (qui remplace la couche modèle
dans l’architecture Grails), renvoie le résultat de la requête sous format JSON au client, celle-ci
permet de compléter les vues développées par Phone Gap.

38

Chapitre 4

4.3. Implémentation :
4.3.1. Authentification :
Une étape incontournable de la création d’application consiste en l’authentification. Afin
d’accéder aux fonctionnalités de l’application, un écran d’authentification s’offre à l’utilisateur
dès l’exécution de cette dernière. Dans cette partie, nous avons adopté le module Spring
Security. Spring Security permet de gérer l'accès aux ressources d'une application Java qui
peuvent être des pages web, mais aussi des objets de services métier. Toute ressource sollicitée
par un appelant est rendue accessible si :
- d'une part, l'appelant s'est identifié,
- d'autre part, il possède les droits nécessaires (des rôles dans le vocabulaire Spring Security)
Principe de fonctionnement de Spring Security :
Afin d’utiliser Spring Security dans Grails, on doit installer ce plugin via la console Grails,
ce dernier qui va nous aider à installer une gestion des utilisateurs, avec gestion des rôles et
filtres URL/Rôles. Les requêtes HTTP envoyées par l’utilisateur sont interceptées par un filtre de
servlet qui délègue à un Bean Spring les traitements de vérification d'accès aux pages web.

Figure 9: Schéma simplifié du fonctionnement de Spring Security

Dans notre cas, les requêtes HTTP envoyées doivent être sécurisées du fait de la
confidentialité des données lors de leur envoi par client vers le serveur et donc on utilise le
protocole de transmission HTTPS plutôt que le HTTP classique. Afin d’implémenter cette
fonctionnalité dans Grails, on doit le forcer à utiliser le protocole sécurisé HTTPS.
Ainsi, les données provenant des formulaires sont envoyées via HTTPS, donc cryptées, et
acheminées vers le serveur grâce à Spring Security qui encode les mots de passe lors de la
transmission et utilise des annotations pour sécuriser l’accès aux méthodes métiers.
L’abonné est appelé à s’authentifier en tapant son nom d’utilisation et son mot de passe, s’il
est déjà enregistré et les deux sont validés alors l’authentification sera réalisée sans aucun
problème sinon elle sera refusée.

39

Chapitre 4

Figure 10: Page d’authentification

Une fois l’abonné authentifié, il peut accéder aux quatorze fonctionnalités de l’application.

Figure 11: Menu principal de l’application


40

Chapitre 4

4.3.2. Consultation des comptes :
L’abonné peut consulter le solde de son ou ses compte(s), ainsi que les mouvements
effectués pour chaque compte.

Figure 12: Situation des comptes d’un abonné

Consultation des mouvements :
Cette fonctionnalité permet à l’abonné de consulter plusieurs informations qui concernent
la liste des mouvements effectués dans chacun de ses comptes. Parmi ces informations : l’intitulé
du mouvement, sa date de création ainsi que le montant. On a organisé l’affichage par une
pagination qui ne permet que d’afficher les mouvements dix par dix. Et chaque page correspond à
une requête HTTPS pour ne pas trop ralentir l’appel des web services.

Figure 13: Affichage des mouvements sur un compte


41

Chapitre 4

4.3.3. Demande de recharge:
L’utilisateur remplit le formulaire de demande de recharge :
-Le compte à débiter.
-Le numéro de la carte.
-Le nom du bénéficiaire.
-Le montant de recharge.
-Le motif.
-Le type de recharge : Ponctuel ou permanent.
Si le client a choisi le type de recharge permanent, alors un autre bloque s’affiche et contient les
informations suivantes :
- La périodicité.
- La date de début.
- La date de fin.

Figure 14: Demande de recharge.


42

Chapitre 4

Après avoir rempli tous les champs, l’utilisateur reçoit le bloc de récapitulation où il est
demandé de signer et confirmer la demande.

Figure 15: bloc de signature de la demande de recharge.

4.3.4. Simulateur de crédit :
L’abonné a accès au simulateur de crédit pour avoir une idée sur l’échéance ou le montant
mensuel à payer en cas d’une demande de prêt. Ces derniers sont calculés selon le taux d’intérêt
fourni, grâce à des formules connu dans le milieu bancaire..

Figure 16: Simulateur de crédit.


43

Chapitre 4

4.3.5. Effectuer un virement :
L’abonné a éventuellement la possibilité d’effectuer des virements, soit de l’un de ses
comptes à un autre, soit vers le compte d’un bénéficiaire inscrits dans le contrat.

Figure 17: Choix du type de virement.

Virement compte à compte :
L’abonné commence par le remplissage d’un formulaire contenant les informations sur le
compte à débiter, celui à créditer, le montant, le motif et la date d’exécution du virement. A noter
que la date d’exécution du virement peut être différente de la date système, mais strictement
supérieure à cette dernière bien entendu.

Figure 18: Saisie d’un virement de compte à compte


44

Chapitre 4
En cliquant sur le bouton valider, le client reçoit ensuite un récapitulatif du virement
effectué et un bouton signer pour confirmer le virement, après avoir entré son mot de passe.

Figure 19: Récapitulatif du virement de compte à compte.

Après la signature du virement, le client reçoit la confirmation de la réalisation du virement
avec succès auprès du serveur.

Figure 20: Page de succès d’un virement de compte à compte.


45

Chapitre 4
Virement vers bénéficiaire :
Tout comme le virement de compte à compte, l’abonné commence par le remplissage d’un
formulaire contenant tous les informations sur le virement, la différence qui existe est que le
compte à créditer appartient à l’un de ses bénéficiaires

Figure 21: Saisie d’un virement vers bénéficiaire

Il reçoit ensuite un récapitulatif du virement effectué afin de signer pour confirmer le virement.

Figure 22: Récapitulatif d’un virement vers bénéficiaire


46

Chapitre 4

Après avoir
virement.

signé le virement, un écran de succès s’affiche pour annoncer la fin du

Figure 23: Ecran de succès d’un virement vers bénéficiaire.

4.3.6. Demander un chéquier :
L’abonné rempli le formulaire de la demande :





Le Compte à débiter
Le nombre de chéquier(s)
Le type des chéquier(s)
Le moyen de remise du/des chéquier(s)


47

Chapitre 4

Figure 24: Demande de chéquier.

Après le remplissage du formulaire, l’abonné envoie les informations saisies au serveur en
cliquant sur le boutant « envoyer », puis une requête de réponse sera renvoyée par le serveur vers
le mobile pour afficher à l’utilisateur les informations déjà saisie, et lui donner la possibilité de
rectifier avant de signer et confirmer.

Figure 25: Demande de chéquier(2).


48

Chapitre 4

Figure 26: Demande de chéquier avec succès.

4.3.7. Transférer de l’argent :
L’abonné saisit le compte à débiter parmi ses comptes, le montant et le motif du transfert
ainsi que les informations concernant le bénéficiaire :
 Nom et prénom
 Type de la pièce d’identité
 Numéro de la pièce d’identité
 Adresse
 Ville et pays
 Téléphone


49

Chapitre 4

Figure 27: Saisie d’un transfert d’argent.

Après avoir rempli les champs et validé le formulaire le client reçoit un récapitulatif de cette
demande de transfert.

Figure 28: Récapitulatif d’un transfert d’argent.

4.3.8. Les Tâches :
L’abonné peut consulter à chaque instant les différentes tâches qu’il désire effectuer, pour
les valider en les signant, par exemple on voit dans l’imprimé d’écran suivant quelques tâches à
savoir :
« Demande de virement vers bénéficiaire », « demande d’opposition sur chèque »,
« demande de recharge d’une carte », … qui sont déjà remplis dans les champs appropriés.

50

Chapitre 4

Figure 29: Liste des tâches.

4.3.9. Liste des comptes titres:
L’abonné peu consulter la situation et toutes les informations sur son compte à savoir :
Numéro du compte, l’agence, numéro de la clé, la date d’ouverture le solde et le totale. Et d’autres
informations supplémentaires.

Figure 30: Situation des comptes titre.

La suite de la Situation des comptes :


51

Chapitre 4

Figure 31: Transaction titre et portefeuille titre.

4.3.10. Consultation des effets :
L’utilisateur ou l’abonné commence d’abord par le choix de type de l’effet à consulter.
Quatre catégories d’effets sont offertes :
-Les effets à payer.
-Les effets à encaisser par compte.
-Les effets à encaisser par date d’échéance.
-Les remises d’effets à encaisser.

Figure 32: Choix de type d’effet.


52

Chapitre 4
-Les effets à payer :
Cette fonctionnalité permet à l’abonné de recevoir une liste dans laquelle figure les comptes
tirés, le montant total et le nombre des effets.

Figure 33: Les comptes tirés.

Quand l’utilisateur clique sur un compte, le serveur lui renvoie la liste des effets à payer.
Chaque sous liste contient des informations sur le compte tiré, la date d’échéance, le nom du tireur
et le montant tiré.

Figure 34: La liste des effets à payer.

-Les effets à encaisser :
C’est le cas où le porteur de l’effet garde ce dernier dans son portefeuille jusqu'à
l’échéance puis il le présente soit à sa banque pour encaissement (effet domicilié) ou au tiré ou
bien au souscripteur pour l’encaissement.

53

Chapitre 4
Ce type d’effets regroupe deux sous catégories : les effets à encaisser par compte et les
effets à encaisser par date d’échéance.
-Les effets à encaisser par compte :
Le serveur renvoie au client dans ce cas une liste contenant des informations sur les comptes
tireurs, le montant total et le nombre des effets.

Figure 35: Les comptes tireurs.

Quand l’utilisateur clique sur un compte, le serveur lui renvoie la liste des effets à
encaisser. Chaque sous liste contient des informations sur le compte tiré, la date d’échéance, le
nom du tireur et le montant tiré.

Figure 36: Les effets à encaisser par compte.


54

Chapitre 4

-Les effets à encaisser par date d’échéance :
Au lieu que le serveur renvoie les compte tireurs comme le cas précèdent, il renvoie cette
fois les dates d’échéance, les montants totaux et les nombres des effets.

Figure 37: Les effets à encaisser par dates d’échéance.

De la même façon que pour le cas précédent, le serveur renvoie, la liste des effets à
encaisser qui ont la même date d’échéance. Les sous listes contiennent les mêmes informations.
-Les remises d’effets à encaisser :
Si l’abonné choisit cette option, il verra une liste contenant des informations sur le
numéro de remise, le nombre des effets et le montant total.

Figure 38: Les effets à encaisser par compte.


55

Chapitre 4

Dans ce cas le serveur renvoie, la liste des effets à encaisser qui ont la même date
d’échéance. Les sous listes contiennent les mêmes informations que pour le cas précédent.

4.3.11. Situation des crédits :
Pour chaque dossier de crédit, l’abonné peut consulter plusieurs informations à savoir : nom
du dossier, nom de celui qui remboursera le crédit, le statut s’il est réglé ou bien en cours, date
blocage ou date de dernier échéance ….

Figure 39: Liste des dossiers.

Figure 40: Contenu d’un dossier avec liste des impayés.


56

Chapitre 4

4.3.12. Liste des impayés :
Le client peut aussi consulter la liste de ses impayés. Ainsi, le serveur renvoie la liste des
informations suivante pour chaque lise des impayées.






La date d’échéance.
Le montant impayé.
Le montant frais impayé.
Le montant d’échéance.
Le statut.

Figure 41: La liste des impayés.

4.3.13. Géolocalisation :
La géolocalisation ou géo-référencement est un procédé permettant de positionner une
personne ou un objet (guichet dans notre cas) sur une carte à l'aide de ses coordonnées
géographiques. Ici on a utilisé les deux coordonnées la longitude et l’altitude récupérées à partir du
GPS. On a mis en œuvre la carte mappy, car la carte de Google Map touche l’union de notre cher
pays.


57

Chapitre 4

Figure 42: géolocalisation.

4.4. Déploiement:
4.4.1. Les dangers du reverse engineering:
Le reverse engineering est une technique permettant de reconstituer le code source d'une
application à partir de sa forme compilée. La possession du code source permet de connaître le
fonctionnement précis d'une application. Face aux risques liés au reverse engineering, nous nous
sommes vu contraint de choisir une technique qui permettrait de cacher le code source de
l’application, puisqu’il est facile de décoder le fichier exécutable.
Il en existe quatre :





l'obfuscation transforme le code source avant compilation de manière à le rendre illisible
pour l'être humain. (voir annexe)
le chiffrement assure la confidentialité totale du code source tant que l'algorithme de
chiffrement n'a pas été cassé et que la clé n'a pu être trouvée par force brute
l'exécution de code distant permet de ne livrer aux clients qu'une partie de l'application, les
portions sensibles sont conservées sur un serveur distant protégé sur lequel elles s'exécutent
le code natif protégé est un code compilé pour une architecture matérielle très spécifique,
rendant difficile l'utilisation d'un décompilateur adapté

4.4.2. Déploiement sur mobile:
Après avoir réalisé l’application sous forme d’un site web, il vient le tour du Framework
PhoneGap qui va s’occuper d’empaqueter le code source à l’aide de son service PhoneGap Build,
intégré dans l’outil Adobe Dreamweaver (voir l’Annexe), et ainsi de générer les fichiers
permettant le déploiement de l’application sur différentes plateformes. Le schéma de ce processus
est représenté ci-dessous.

58

Chapitre 4

Figure 43: processus du service phoneGap Build.

Les figures suivantes montrent dans l’ordre la réalisation de ce processus de manière
pratique.

Figure 44: L'IDE Adobe Dream weaver

Figure 45: fenêtre de phonegap build


59

Chapitre 4

Figure 46: démarrage du service phonegap build.

Figure 47: connexion au service phonegap build


60

Chapitre 4

Figure 48: génération des fichiers exécutables.

Conclusion:
Ce chapitre avait pour but de décrire l’environnement technique et les différentes étapes de
la réalisation du projet. En effets nous avons choisi les technologiques pour l'implémentation de
l'application et finalement nous avons présenté quelques écran décrivant les fonctionnalités de
notre application.


61

Conclusion :
En guise de conclusion, nous pouvons affirmer que le développement multiplateforme
mobile est un domaine enrichissant au niveau expérimental et qu’il est en évolution constante.

Ce stage a été pour nous l’occasion de faire le lien entre nos connaissances académiques et
le monde professionnel. Il nous a permis de développer nos compétences techniques,
d’approfondir nos connaissances théoriques et les mettre en pratique. Cette expérience a aiguisé
nos capacités d’analyse et de synthèse, et nous a permis de renforcer nos connaissances concernant
le développement mobile ainsi que le développement hybride.

Après la réalisation technique du projet avec le framework Phone Gap, nous constatons
que toutes les fonctionnalités réalisées sont fonctionnelles sur le mobile. Ce projet était une
occasion pour mieux comprendre et apprendre des notions ayant une relation avec le domaine
bancaire considéré comme l'un des domaines sensibles. Cette dernière considération nous a
excités de traiter le sujet avec précaution en termes de sécurité.

Enfin, ce stage fut une expérience très enrichissante pour nous sur les deux plans
personnels et professionnels. En effet, il a été l’occasion de découvrir le dynamisme et
l’enthousiasme qui caractérisent l’équipe d'INFOSAT. Les réunions régulières effectuées avec les
encadrants à INFOSAT nous ont permis de mettre en œuvre les concepts de gestion de projets
acquis à l'INPT.


62

Glossaire:
 A
App Store :
Plateforme de téléchargement d’applications.
Aptana :
Aptana Studio est un environnement de développement intégré orienté web, multiplate-forme et
open-source.
 D
Debugger :
Est un logiciel qui aide un développeur à analyser les bugs d'un programme.
 G
Google Play :
Plateforme de téléchargement d’applications.
 I
IBM :
International Business Machines Corporation, connue sous l’abréviation IBM, est une société
multinationale américaine présente dans les domaines du matériel informatique, du logiciel et des
services informatiques.
 L
Lotus Domino :
Lotus Domino est un produit IBM qui fournit une plateforme de gestion électronique des
documents développée en mode open source, qui inclut une messagerie électronique et des
applications de travail collaboratif.
 M
Microsoft Exchange :
Microsoft Exchange Server est un Groupware (logiciel de groupe de travail) pour serveur de
messagerie électronique créé par Microsoft, pour concurrencer Lotus Domino d'IBM.
Mobile information device profile :
Désigné par l'acronyme MIDP, est un profil J2ME utilisé par certains téléphones.
 P
Pattern :
Le mot anglais « pattern » est souvent utilisé pour désigner un modèle, une structure, un motif, un
type, etc.
Ruby On Rails:
Ruby on Rails, également appelé RoR ou Rails est un framework web libre écrit en Ruby
 S
Système multitâche :

63

Un système d'exploitation est multitâche en anglais: multi-task s’il permet d’exécuter, de façon
apparemment simultanée, plusieurs programmes informatiques. On parle également de
multiprogrammation.
 T
Tag :
Langage de balisage HTML.
 W
Widgets :
Widget est une contraction des mots window et gadget. En informatique, le mot widget recouvre
deux notions distinctes en relation avec les interfaces graphiques. Il peut alors être considéré
comme étant la contraction des termes window (fenêtre) et gadget.
 X
XCode :
Est un environnement de développement pour Mac OS X.


64

Bibliographie :
David Powers. Adobe Dreamweaver CS5.5 Studio Techniques: Designing and Developing for Mobile
with jQuery, HTML5, and CSS3.
JQuery Community Experts. JQuery Cookbook : Solutions & Examples for jQuery developpers.


65

Webographie:
PhoneGap Google Group, Getting Started Guide:
http://docs.phonegap.com/en/2.0.0/guide_getting-started_index.md.html.
Appcelerator, Titanium Studio: http://www.appcelerator.com/platform/titanium-studio
Appcelerator, Titanium Documentation: http://docs.appcelerator.com/titanium/2.1/index.html
Comparing Titanium and PhoneGap: http://developer.appcelerator.com/blog/2012/05/comparingtitanium-and-phonegap.html

GitHub, Appcelerator: http://github.com/appcelerator
GitHub, PhoneGap: http://github.com/phonegap
La rédaction journal du Net, Les outils de développement multiplateforme mobiles :
http://www.journaldunet.com/developpeur/outils/les-outils-de-developpement-multi-plateformemobile/ [publié le 03/11/2011]
http://www.wikipedia.com

KONLAMBIGUE Tyab. PhoneGap vs Appcelerator: http://fr.slideshare.net/kcresus/phonegap-vsappcelerator

PETITIT François. Applications mobiles multiplateformes: les approches PhoneGap et Titanium
Mobile : http://blog.octo.com/applications-mobiles-multi-plateformes-les-approches-phonegap-ettitanium-mobile/ [publié le 17/10/2012]
Ekito, Application mobile : web ou natif : http://www.ekito.fr/portail/application-mobile-web-ounatif

Tout JavaScript: http://www.toutjavascript.com/reference/reference.php?ref=String
http://www.w3schools.com/

jQuery Mobile: http://mobile.jquery-fr.com/index.html
Introducing JSON: http://www.json.org/
jQuery: http://www.jquery.com/


66

Annexe:
Adobe Dreamweaver:
Dreamweaver est un éditeur de site web WYSIWYG pour Microsoft Windows, et Mac
OS X créé en 1997, commercialisé par Macromedia puis Adobe Systems sous licence utilisateur
final. Dreamweaver fut l'un des premiers éditeurs HTML de type « tel affichage, tel résultat »,
mais également l'un des premiers à intégrer un gestionnaire de site (CyberStudio GoLive étant le
premier). Ces innovations l'imposèrent rapidement comme l'un des principaux éditeurs de
site web, aussi bien utilisable par le néophyte que par le professionnel.
Depuis le rachat de Nitobi Software (développeur d’Apache Cordova) par Adobe Systems
le 4 Octobre 2011, ce dernier est désormais le propriétaire de Phonegap. Suite à ça, Adobe a
intégré phoneGap dans l’outil Adobe Dreamweaver (depuis la version cs5.5).

HTML 5:

HTML5 (HyperText Markup Language 5) est la prochaine révision majeure
d'HTML (format de données conçu pour représenter les pages web). Cette version est en
développement en 2012. HTML5 spécifie deux syntaxes d'un modèle abstrait défini en termes
de DOM : HTML5et XHTML5. Le langage comprend également une couche application avec de
nombreuses API, ainsi qu'un algorithme afin de pouvoir traiter les documents à la syntaxe non
conforme. Le travail a été repris par le W3C en mars 2007 après avoir été lancé par le WHATWG
(Web Hypertext Application Technology Working Group). Les deux organisations travaillent en
parallèle sur le même document afin de maintenir une version unique de la technologie. Le W3C
vise la clôture des ajouts de fonctionnalités le 22 mai 2011 et une finalisation de la spécification
en 2014, et encourage les développeurs Web à utiliser HTML 5 dès maintenant.
HTML5 présente plusieurs changements par rapport HTML 4.X et XHTML 1.X
concernant les spécifications, le Doctype et l’encodage. De plus HTML5 a apporté de nouveaux
éléments et de nouveaux attributs.



Spécifications :
Les spécifications sont publiées par leW3C http://www.w3.org/TR/html5/.
Doctype :
Tout comme les pages HTML ou XHTML, les documents HTML5
nécessitent une déclaration Doctype indiquant la méthode standard de rendu par
le navigateur. Toutefois, pour les documents XML cette déclaration est
facultative, le navigateur l'interprétant en mode standard par défaut. Pour utiliser
la structure XML il faut préciser dans le header : « Content-Type:
application/xhtml+xml ».


67

rapport de stage

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie rapport de stage

Ähnlich wie rapport de stage (20)

rapport de stage