Tirelire Virtuelle


P62.
Résumé
du
projet
«
Tirelire
Virtuelle
»
Année
2009
Auteurs
Marie
Gremillot
–
Laurène
Vol
Monnot,
Maha
El
Khalidy
–
Sarah
El
Hachimi,
Pylyp
Nuzhniy
–
Sixte
de
Vergnette.
Partenaires
Les
partenaires
fondateurs
de
la
FONDATION
TELECOM.
Nous
ont
suivis
en
particulier
:
A.
BOUTIGNON
‐
SFR,
et
P.
AXUS
‐
BNP
PARIBAS.
Encadrant
G.SIMON
–
Dép.
Informatique.
Mots
clés
:
services
mobiles
innovants,
paiement
par
mobile,
paiement
en
commun
Résumé
Notre
travail
s’est
déroulé
en
deux
étapes.
Le
premier
objectif
a
été
de
concevoir
une
solution
globale
pour
un
service
de
paiement
en
commun,
en
situation
de
mobilité.
Notre
solution
prend
en
compte
des
aspects
techniques
et
architecturaux,
mais
aussi
économiques
et
juridiques.
Le
deuxième
objectif
est
la
réalisation
d’un
démonstrateur
technologique
permettant
de
tester
notre
service
pour
un
des
cas
d’usages
identifié.
1. Présentation
et
contexte
du
projet.
Notre
projet
s’inscrit
dans
le
cadre
d’une
initiative
de
la
Fondation
Telecom
:
le
projet
First.
Ce
projet
propose
à
des
étudiants
de
participer
à
un
programme
d'étude
sur
un
sujet
d'actualité
de
l'économie
et
des
usages
des
STIC.
Les
étudiants
travaillent
en
collaboration
avec
les
partenaires
fondateurs
de
la
Fondation
Telecom.
Un
premier
séminaire
de
travail
entre
étudiants
et
partenaires
nous
a
permis
d’identifier
l’objet
de
notre
étude
:
un
service
de
pot
commun
sur
mobile
(Annexe
I).
Notre
objectif
était
donc
de
proposer
une
solution
globale
à
nos
partenaires,
tout
en
respectant
les
contraintes
imposées
par
Télécom
Bretagne
concernant
la
gestion
des
projets
ingénieurs.
Notamment,
dans
l’optique
du
Forum
de
Télécom
Bretagne,
nous
avons
souhaité
approfondir
l’aspect
technique
de
la
solution
proposée
en
implémentant
notre
propre
démonstrateur.
2. Méthodologie
développée
pour
aboutir.
Afin
de
proposer
à
nos
partenaires
une
solution
pertinente
pour
le
service
considéré,
nous
avons
décidé
de
mener
des
recherches
et
des
réflexions
sur
un
large
spectre
de
thématiques.
Premièrement,
nous
avons
étudié
l’état
de
l’art
afin
de
rendre
compte
de
la
situation
concurrentielle
du
secteur
et
de
la
position
des
principaux
acteurs
du
marché
considéré.
Ensuite,
parallèlement
à
des
études
visant
à
définir
les
contraintes
juridiques
du
secteur,
et
les
modèles
économiques
envisageables,
nous
avons
listé
les
usages
se
rattachant
à
notre
service,
et
pour
chacun
d’eux,
les
contraintes
de
performance
que
devra
respecter
notre
solution.
Ceci
nous
a
permis
de
rédiger
un
cahier
des
charges
pour
notre
service,
puis
de
proposer
des
pistes
architecturelles
et
techniques
cohérentes
avec
les
aspects
économiques
et
juridiques.
Tout
au
long
de
ce
processus,
nous
avons
rencontré
nos
partenaires
lors
de
deux
visioconférences,
ce
qui
nous
a
permis
de
réajuster
nos
études
selon
leurs
conseils.
Enfin,
concernant
le
démonstrateur,
et
dans
une
démarche
de
qualité,
nous
avons
choisi
d’implémenter
un
seul
usage,
mais
faisant
appel
à
un
maximum
de
fonctionnalités
pertinentes.
3. Développement
des
différentes
tâches
et
principaux
résultats
3.1.
Solution
proposée
Acquisition
des
informations
Le
service
que
nous
étudions
n’existe
pas
encore,
et
le
marché
considéré
est
un
marché
émergeant.
Ainsi
nous
situons
nous
dans
un
contexte
d’innovation.
Les
informations
qui
nous
ont
permis
de
mener
à
bien
notre
étude,
qu’elles
soient
techniques
ou
juridiques,
sont
pour
la
plupart
extrêmement
récentes
(trois
ans
au
maximum).
Les
informations
proviennent
pour
une
partie
des
organismes
partenaires,
qui
nous
ont
fréquemment
envoyé
des
documents,
et
communiqué
des
informations
lors
de
réunions
téléphoniques
ou
de
visioconférences.
Les
autres
informations
proviennent
d’Internet.
Les
sites
visités
étaient
souvent
des
sites
d’actualité
sur
les
nouvelles
technologies.
Nous
avons
par
ailleurs
appuyé
notre
étude
sur
des
rapports
mis
en
ligne
par
de
grandes
institutions,
qu’elles
viennent
du
domaine
des
Télécoms
[1],
[2],
ou
du
domaine
économique
[3].
Résultats
Le
résultat
de
notre
étude
est
un
rapport
présentant
notre
solution
sous
tous
ses
aspects.
Au
niveau
conceptuel,
nous
pouvons
scinder
ce
rapport
en
deux
parties,
définies
par
la
nature
de
l’information
que
nous
fournissons.
La
première
partie
rassemble
les
résultats
de
nos
recherches
et
de
nos
réflexions,
tandis
que
la
deuxième
partie
rassemble
nos
propositions
quant
à
la
manière
de
déployer
le
service.
La
première
partie
est
constituée
de
l’étude
économique
et
concurrentielle,
de
l’étude
des
usages,
ainsi
que
de
l’étude
fonctionnelle
et
technique.
Cette
partie
intègre
notamment
une
analyse
de
performance
originale,
qui
a
pour
but
de
lister
les
fonctionnalités
minimales,
et
les
contraintes
de
rapidité
exigées,
afin
que
notre
service
puisse
apporter
une
véritable
valeur
ajoutée
à
l’utilisateur.
La
deuxième
partie
rassemble
l’ensemble
de
nos
propositions
concernant
le
modèle
économique
et
les
stratégies
de
lancement,
et
présente
les
deux
solutions
architecturales
devant
permettre
la
mise
en
place
du
service.
La
différence
entre
les
deux
solutions
est
l’acteur
pressenti
pour
gérer
les
comptes
nécessaires
au
paiement
en
commun.
La
première
solution
fait
appel
aux
banques,
tandis
que
la
deuxième
solution
intègre
les
opérateurs
de
téléphonie
mobile.
Concernant
la
deuxième
partie,
nous
manquons
cependant
de
précisions
sur
les
champs
des
possibles
en
matière
de
législation
bancaire.
Cette
lacune
ne
nous
permet
pas,
pour
l’instant,
de
valider
ou
d’infirmer
la
viabilité
juridique
de
nos
modèles.
3.2.
Conception
du
démonstrateur
Pour
concevoir
le
démonstrateur,
nous
avons
scindé
notre
groupe
en
trois
équipes.
Une
première
équipe
est
chargée
de
créer
un
site
internet,
qui
permettra
de
s’inscrire
à
la
plateforme
de
paiement
en
commun.
Une
deuxième
équipe
est
chargée
de
développer
le
logiciel
présent
sur
le
téléphone
mobile
(sur
l’OS
Androïd).
Une
troisième
équipe
se
charge
de
la
partie
serveur
et
gestion
de
la
base
de
donnée.
Le
démonstrateur
a
été
conçu
étape
par
étape.
Après
une
période
de
prise
en
main
des
différents
outils,
nous
avons
commencé
par
implémenter
quelques
fonctions
simples
pour
faciliter
la
synchronisation
des
différentes
équipes.
Nous
avons
ensuite
implémenté
les
autres
fonctions
plus
complexes
nécessaires
au
fonctionnement
global
de
l’application,
mais
en
essayant
de
garder
le
code
le
plus
simple
possible.
Enfin,
nous
avons
étoffé
les
différentes
fonctionnalités
afin
de
proposer
un
démonstrateur
de
qualité.
A
priori,
lors
de
la
démonstration,
les
téléphones
mobiles
seront
simulés
sur
ordinateur,
mais
il
est
possible
que
SFR
nous
prête
des
terminaux
mobiles
fonctionnant
avec
Google
Androïd.
Ce
démonstrateur
sera
présenté
lors
du
forum
de
Télécom
Bretagne
du
24‐25
juin
2009.
4. Conclusions
et
perspectives.
Le
service
de
paiement
par
pot
commun
est
aujourd’hui
possible
grâce
aux
récentes
évolutions
technologiques.
Dans
ce
contexte,
il
nous
revenait
de
définir
une
solution
globale
permettant
sa
mise
en
place.
Nous
avons
choisi
le
meilleur
compromis
possible,
en
prenant
en
compte
la
plupart
des
contraintes
environnementales
qui
s’imposent
au
service.
Malgré
cela,
ces
contraintes
évoluent
sans
cesse.
La
législation
bancaire
s’adapte
continuellement
aux
nouveaux
services,
rendant
le
déploiement
des
services
de
paiement
par
mobile
plus
aisés.
La
technologie
devient
aussi
de
plus
en
plus
mature.
Ainsi,
dans
un
contexte
futur,
une
autre
solution,
plus
performante
que
celle
présentée
ici,
car
issue
de
nouvelles
contraintes,
verra
sans
doute
le
jour.
5. Références
[1]
Mobile
Marketing
Association.
Mobile
Banking
Overwiew
[en
ligne].
[13
p.]
janvier
2009.
Format
PDF.
Disponible
sur
:
<http://www.mmaglobal.com/mbankingoverview.pdf>.
(Consulté
le
20.04.2009).
[2]
GSMA.
Pay
by
mobile.
Public
white
paper
[en
ligne].
[36p.]
novembre
2007.
Format
PDF.
Disponible
sur
:
<http://gsmworld.com/documents/gsma_pbm_white_paper_11_2007.pdf>.
(Consulté
le
15.04.2009).
[3]
OCDE.
Le
commerce
mobile.
[67
p.]
février
2007.
(Consulté
le
25/03/2009).
6. Annexe
I
:
Principe
du
paiement
par
pot
commun