Depuis près de 25 ans, Atos Worldline conçoit, développe et opère des services en ligne (Minitel, fax, serveurs vocaux, sites web, sms, sites internet mobile, rich média mobile, web 2.0, IPTV…) Concernant le mobile, les usages et les technologies ont considérablement évoluée ces dernières années. Afin de répondre à ces changements, nous avons étudié, testé, et utilisé industriellement plusieurs technologies du marché fournies par les constructeurs et les éditeurs sur les différentes plateformes mobiles. Ce livre blanc couvre les principaux points d’attention et formule des recommandations pour la conception et la mise en œuvre d’applications mobiles. Fort de cette expérience, Atos Worldline a conçu et développé son offre Worldline Padda, une solution agile rapide et industrielle pour le développement d'applications mobiles.

1. Depuis près de 25 ans, Atos Worldline conçoit, développe et opère des services en ligne (Minitel,
fax, serveurs vocaux, sites web, sms, sites internet mobile, rich média mobile, web 2.0, IPTV…).
Concernant le mobile, les usages et les technologies ont considérablement évolué ces dernières
années. Afin de répondre à ces changements, nous avons étudié, testé et utilisé industriellement
plusieurs technologies du marché fournies par les constructeurs et les éditeurs sur les différentes
plateformes mobiles.
Ce livre blanc couvre les principaux points d’attention et formule des recommandations pour la
conception et la mise en œuvre d’applications mobiles.
Fort de cette expérience, Atos Worldline a conçu et développé son offre Worldline Padda, une
solution agile rapide et industrielle pour le développement d'application mobiles.

2. Sommaire
4 En quelques mots
5 Panorama des différents types d’application mobiles
5 Pourquoi des applications mobiles embarquées ?
6 L’ergonomie d’un service mobile
7 Quels téléphones cibler ?
7 Gérer les différences d’un téléphone à l’autre
L’écran
Les textes
Les images
Le réseau
La saisie de données par l’utilisateur
Autres actions
9 Les tests
10 Déploiement
Taille de l’application
Télécharger la version appropriée au terminal
10 Mise à jour
3

3. EN QUELQUES MOTS
Les enjeux
L’année 2007 a été marquée par l’arrivée
d’une nouvelle génération de terminaux,
tels que l’iPhone ou le N95, distribués
avec des offres d’accès data illimité,
contribuant ainsi fortement et durablement
au décollage des services mobiles.
Plus de 11 millions de Français sont
aujourd’hui “mobinautes” et consomment
de façon croissante les services et contenus
associés à l’Internet mobile. 54 millions de
personnes disposent d’un téléphone mobile,
premier outil de la personnalisation de la
relation client.
Les perspectives de croissance de l’Internet
mobile en France sont donc très positives.
Dans ce contexte, comment se différencier
et développer des services innovants qui,
au delà de l’effet vitrine, soient véritablement
accessibles et utilisés par le plus grand
nombre afin de générer de nouveaux usages
et modes de consommation ?
Face à ces questions, le développement
d’applications embarquées sur les
téléphones propose une expérience ludique,
confortable et efficace en complément de
services Internet mobiles existants.
Les facteurs clés de succès
Ergonomie : prise en compte des habitudes
des utilisateurs, des limites et spécificités
des terminaux.
Ciblage des téléphones adapté au marché
visé : compromis entre les fonctionnalités
et le nombre de téléphones concernés.
Prise en compte de la diversité des
mobiles dès le lancement du projet, pour
proposer l’expérience la plus cohérente
possible, tout en profitant des capacités
propres à chaque terminal.
Réalisation des tests dès le début des
développements, dans des conditions
d’usage réel et sur un parc de mobiles
ciblés.
Déploiement de l’application facile et rapide
pour l’utilisateur.
Mises à jour automatisées en minimisant
l’impact utilisateur.
4

4. Panorama des différents types
d’applications mobiles
Un service mobile peut avoir différentes
formes :
> un site wap,
> une webapp : un site web prenant en
compte et exploitant les particularités de
quelques téléphones haut de gamme,
> un site web fonctionnant aussi offline,
> une application téléchargée sur le télé-
phone, en technologie J2ME, Symbian
ou Windows Mobile, fonctionnant en
mode connecté ou non,
> un widget,
> un composant logiciel du téléphone.
Du point de vue de l’utilisateur, la différen-
ciation entre ces différentes formes est
très limitée, voire nulle. En effet, une étude
menée par AKQA pour dotMobi en juin
2008, sur un panel représentatif de 2000
personnes, met en évidence que 50 % des
répondants ne savent pas qu'il existe des
sites mobiles optimisés pour une
utilisation sur les téléphones portables.
Ce livre blanc s’adresse plus particulièrement
aux applications mobiles embarquées. La
plupart de son contenu reste applicable
aux autres formes d’applications mobiles.
Pourquoi des applications
mobiles embarquées ?
L’Internet mobile ne permet pas d’exploiter
l’ensemble des capacités existantes des
téléphones.
Les applications embarquées permettent de
mieux utiliser les capacités des téléphones,
en termes de design, d’ergonomie, d’inter-
activité et de fonctionnalités.
Les derniers terminaux haut de gamme,
tels que l’iPhone ou le N95, intègrent des
navigateurs web puissants, aux fonction-
nalités proches d’un ordinateur de bureau,
il s’agit clairement d’un axe très prometteur
pour la réalisation de futurs services mobiles.
Cependant, ces navigateurs, réservés aux
terminaux très haut de gamme, sont
aujourd’hui malgré tout trop lents pour
traiter et afficher des pages complexes,
et ne sont pas encore adaptés pour la
réalisation d’applications riches avec une
expérience client optimisée.
Enfin, l’accès au hardware du téléphone
(NFC, carte SIM, photo…), le fonctionnement
offline et la gestion intelligente du cache
nécessitent une application mobile
embarquée.
On retrouve ici le débat “client lourd vs
client léger” qu’a connu le monde du PC,
avec la même complémentarité.
Apple avait parié au lancement de l’iPhone
sur le “tout navigateur” en ne proposant
aux développeurs d’applications que des
solutions web. Il a été contraint par les
communautés de développeurs à permettre
le développement d’applications natives.
Applications qui proposent une rapidité
d’exécution et une richesse fonctionnelle
nettement améliorée.
5
Un site wap Une webapp iPhone Un widget Nokia
Une application mobile Une application mobile de client mail Un client mail intégré
Une page web Une webapp de messagerie
instantanée
Une application de mobile TV

5. RÉUSSISSEZ VOS PROJETS
MOBILE
L’ergonomie d’un service mobile
Chaque type de service mobile implique
des attentes ou des besoins utilisateurs
spécifiques : se distraire en jouant, visualiser
un album photo, consulter l'horaire de son
TGV, lire un mail, localiser la livraison d'un
colis, choisir sa prochaine destination pour
les vacances nécessitent des interfaces
différentes.
Les interfaces des services mobiles doivent
donc être adaptées à la diversité des
terminaux selon leurs caractéristiques
d'affichage ou de contrôle. Cela est à
prendre en compte au niveau des contenus
du service, de leur design et de leur ergo-
nomie. Le but est d’assurer à l’utilisateur
efficacité, efficience, confiance, et
confort/plaisir d’utilisation.
Pour ce faire, un projet de création d’un
service mobile, comme pour tout autre
projet d’interface, nécessite d’adopter une
démarche centrée utilisateurs s’appuyant
sur :
> l’analyse des profils, besoins et objectifs
du futur service,
> une conception collaborative et itérative
basée sur des cinématiques, story boards,
maquettes,
> l’évaluation de l'interface par des
utilisateurs à différents stades du projet
(test de perception, test d'utilisabilité…).
Recommandations générales - Un seul mot : MINIMISER
1 Minimiser le volume d’informations affichées
Malgré l’amélioration des résolutions d’écrans, l’écran du mobile reste
petit, inadapté à un volume important d’informations. Celles-ci doi-
vent donc être limitées à l’essentiel et à peu de contenu par page.
2 Minimiser les textes
Pour les mêmes raisons, il est nécessaire d’adopter un style rédac-
tionnel clair, précis, concis.
3 Minimiser les actions requises
Les conditions d’utilisation en mobilité sont moins bonnes qu’avec
un PC de bureau : autre tâche simultanée, interruptions, utilisation à
une main car l'autre main est encombrée. Cela gêne l’attention, la
concentration et le confort d’utilisation. Il faut réduire l'application
sur mobile aux fonctionnalités essentielles, et limiter le nombre
d'étapes des processus.
4 Minimiser le nombre de liens
Il faut hiérarchiser les liens en fonction de leur fréquence d’utilisation :
placer en tête les liens les plus souvent utilisés.
Sur les interfaces tactiles, les liens doivent être remplacés par des
boutons assez grands et espacés pour permettre le pointage au doigt (*).
Ces boutons ne doivent pas non plus être trop grands à cause du
conflit possible entre l’action de scroll/drag & drop et celle de sélection.
Pour gagner de la place et rendre l’interface plus plaisante, il peut
être tentant de recourir aux icônes représentant un visuel plutôt qu’un
bouton texte. Cependant, contrairement aux interfaces web, les icônes
sur mobile n’ont pas d’alternative textuelle apparaissant au survol
(balise ‘ALT’). A moins d’être absolument sans ambiguïté, les icônes
doivent être systématiquement sous-titrées.
5 Minimiser les saisies
Que ce soit un clavier physique de téléphone ou un clavier virtuel, celui-ci
n’offre pas le confort du clavier alphanumérique d’un PC de bureau.
Les saisies combinant chiffres et lettres (comme les mots de passe
par exemple) sont fastidieuses sur les claviers virtuels qui sont soit
numérique soit alphabétique, comme celui de l’iPhone.
6 Minimiser les temps de chargement et les temps de réponse
Les utilisateurs ne veulent pas attendre sur un téléphone mobile.
Les résultats d’une action doivent être instantanés.
Il faut tenir compte de la faible capacité des réseaux (comparés à
l’Internet haut débit). Plus la page est lourde, plus elle contient
d’images, plus elle sera longue à charger.
Une attention particulière doit être apportée au contraste et à la
luminosité des pages.
7 Minimiser le temps d’appropriation
Se conformer aux standards d’usage des applications sur mobile.
Exemples :
> WAP : le caractère > ou < devant les liens...,
> iPhone : boutons pour naviguer comme pour agir, flèche vers la
droite pour naviguer entre les listes...
Si l’application mobile est une déclinaison d’un site web, se conformer
à celui-ci dans tout ce qui peut être commun entre les deux, comme
le choix des mots, l’enchaînement des étapes du processus, sans
chercher nécessairement à y reporter toutes les fonctionnalités.
* Selon les travaux du Studio 7.5 (Designing for Small Screens, Ava Publishing, 2005), les icônes doivent mesurer au moins 15 mm et être espacées de 5 mm.
6

6. De la conception à la mise en œuvre
Quels téléphones cibler ?
Il s’agit d’un point clé dans la réalisation
d’un projet d’application mobile. Il est
nécessaire (et difficile) de trouver le bon
compromis entre les fonctionnalités
souhaitées et le nombre de téléphones
compatibles.
La première étape consiste à identifier quels
sont les téléphones des futurs utilisateurs
du service.
Si vous avez déjà un service mobile, que
ce soit du SMS ou du wap, vous pouvez
déjà connaître les téléphones de vos
utilisateurs.
Sinon, il faudra trouver des informations
fiables de parts de marché des téléphones,
et surtout vérifier qu’ils sont bien adaptés
à votre marché. Les téléphones les plus
utilisés par des utilisateurs effectuant du
m-ticketing d’une compagnie aérienne ne
sont pas les mêmes que ceux utilisés par les
joueurs mobiles ou les votants d’émissions
de téléréalité.
La deuxième étape s’appuie sur une base
de données contenant les différentes
capacités des terminaux.Cela permet de
savoir quelles fonctionnalités peuvent être
proposées dans le service.
Gérer les différences d’un
téléphone à l’autre
Les terminaux mobiles sont ergonomique-
ment et techniquement différents d’une
marque à l’autre, voir au sein d’une même
marque. L’anticipation de ces différences
permet de mieux gérer le développement
de vos applications mobiles.
L’écran
Les écrans des téléphones varient
énormément en taille. Les différences
entre un modèle d’entrée et un modèle
haut de gamme vendus actuellement sont
comparables aux différences entre un
écran de PC actuel et un écran de la fin
des années 80 !
Afin de gérer les tailles d’écran possibles,
il est recommandé de regrouper les
téléphones en quelques familles ; et de
concevoir graphiquement votre
application pour chacune de celles ci.
Une segmentation possible est la suivante :
> 95 x 112 et supérieur : tiny
> 129 x 142 et supérieur : small
> 176 x 208 et supérieur : large
> 240 x 320 et supérieur : verylarge
> 352 x 416 et supérieur : huge
7
Évolution des tailles d’écran de PC
Tailles d’écran de téléphones existants

7. RÉUSSISSEZ VOS PROJETS
MOBILE
De plus, les téléphones affichent des barres
d’état de batterie, de couverture réseau,
etc. qui empiètent sur la zone utilisable de
l’écran. Il faut donc veiller à placer à ces
endroits des informations importantes pour
l’utilisateur.
La forme de l’écran
varie également : écran
en mode portrait, en
mode paysage. Certains
téléphones, comme le
Sony Ericsson P990i,
ont une taille qui change
suivant que le clavier
est replié ou non sur
l’écran.
Les conséquences sont au niveau des visuels
(icones, images, boutons…) qui devront
être adaptés aux différentes tailles d’écran,
mais aussi au niveau fonctionnel (moins
d’éléments de listes affichés sur une page,
découpage d’un écran d’options en deux
pages pour un petit écran…).
Dans les cas de petites différences de taille,
de l’ordre de quelques pixels, une méthode
d’adaptation à la taille des écrans peut être
d’ajouter des bordures noires sur les bords
de l’écran. Une autre est de concevoir et de
placer les ressources graphiques afin que
celles-ci s’écartent légèrement vers les bords
tout en évitant un affichage disgracieux. Ces
différences doivent être anticipées dès la
conception de l’ergonomie de l’application.
Les textes
Les polices de caractères sont différentes
d’un téléphone à l’autre. Ces différences
vont changer énormément l’aspect de votre
application mobile. Certains téléphones,
bien qu’ayant de grands écrans, ne pourront
afficher que peu de texte car les polices de
caractères sont extra larges.
De plus, les aspects gras/italique/souligné
ont parfois des rendus décevants et les
polices sont très variables d’un téléphone
à l’autre :
L’usage de polices bitmap ou vectorielles
apporte un gain non négligeable sur le
rendu final de l’application, mais impacte
la consommation mémoire et la rapidité
d’exécution de l’application.
Les images
Grâce à l’augmentation de la bande passante
et des capacités des téléphones, les
applications mobiles utilisent de plus en
plus d’images.
Une bonne optimisation de ces images
permet un téléchargement et une meilleure
réactivité de votre application mobile. Une
optimisation passe par une diminution du
nombre de couleurs (passer du true color
à une palette de 16 ou 256 couleurs) ; une
réutilisation de la même image à plusieurs
endroits de l’application ; une bonne com-
pression des images et un outil retirant les
métadatas* des images.
Il faut veiller à limiter les niveaux de
transparences, lors de la réalisation du
design graphique. Les téléphones ne
gèrent qu’un nombre limité de niveaux de
transparence.
Afin d’avoir un rendu optimum sur les télé-
phones, il est impératif de partir d’images
haute-résolution et compressées sans pertes,
et de les adapter directement à chaque
taille de téléphone. Il ne faut pas réduire
une image déjà réduite sous peine d’avoir
un rendu final très décevant par rapport
aux capacités d’affichage du téléphone.
L’adaptation doit se faire soit, a priori, par
le designer qui crée un jeu d’image par
“famille” de téléphone, soit en temps réel
par un serveur.
Il faut dans tous les cas éviter au téléphone
de redimensionner l’image en local. Cela
augmente la consommation data du télé-
phone, requiert du CPU sur le téléphone,
et n’aboutit pas à des images de qualités
optimum, à cause des algorithmes souvent
simplifiés utilisés dans les téléphones.
Le réseau
De plus en plus d’applications mobiles uti-
lisent la connectivité réseau fournie par le
téléphone pour récupérer ou envoyer des
informations depuis ou vers des serveurs.
Il y a ici trois points à vérifier :
> Les popups que le
téléphone affiche lors
d’un accès réseau.
(cf. illustration). Seule
une certification de
votre application
permet de ne pas
8
Affichage de texte sur des téléphones Motorola (à gauche)
et Sony Ericsson (à droite). Le téléphone de gauche ne
sait pas souligner les textes, et l’épaisseur des caractères
est très différente entre les deux téléphones.
*Metadata : les formats d’image png et jpeg enregistrent des informations telles que l’auteur, le copyright, la date en plus de l’image elle-même.
Avant Après Gain
109 750 octets 21 138 octets
75 %
12 480 octets 2468 octets
80 %
Image d’origine avec 10
niveaux de transparences
Image d’origine superposée
sur une image de fond
Résultat sur un téléphone
supportant 4 niveaux de
transparence
Résultat sur un téléphone
supportant 1 seul niveau de
transparence (ex samsung G600)

8. *Le T9 permet la saisie prédictive et intuitive des mots en cours de frappe pour
simplifier et accélérer la rédaction de messages courts tel que les SMS. Ainsi, il
suffit par exemple de taper les touches 7,2, 4 et 3 pour taper le mot PAGE. Le T9
nécessite un dictionnaire des mots de la langue de l’utilisateur.
De la conception à la mise en œuvre
afficher ces popups. Les téléphones
récents ne demandent confirmation de
cet accès qu’une seule fois. Malheureu-
sement, il y a encore des téléphones en
circulation qui affiche la popup à chaque
accès réseau. Cela risque de rendre
votre application mobile inutilisable et
donne une image négative du service et
de la marque associée.
> Les temps de latence d’établissement de
connexion qui peuvent varier de quelques
dixièmes de secondes à quelques
secondes. Certains téléphones coupent
la connexion réseau très rapidement et
ces temps de latence se multiplient alors.
Il faut donc concevoir votre application
mobile afin de grouper et retarder le
plus possible les accès réseau et les
effectuer en tâche de fond afin de ne pas
bloquer l’utilisateur dans l’application.
> Le bon fonctionnement de la couche
réseau : une bonne partie des téléphones
a des couches d’accès réseau boguées
ou incomplètes.
La saisie de données par l’utilisateur
Le réel problème à gérer concernant la
saisie d’information par l’utilisateur est
ergonomique. Les téléphones n’ont
généralement que des touches numériques,
voire aucune sur les téléphones à écran
tactile.
Deux types de saisie sont généralement
possibles : native et inline.
La saisie native est la
plus simple à mettre en
œuvre et permet d’utiliser
le dictionnaire T9* du
téléphone. Elle a
l’inconvénient d’ajouter
des écrans de saisie
intermédiaires, qui sont
gérés par le téléphone.
Ces écrans intermé-
diaires ne suivent pas
le look and feel de
votre application mobile et perturbent et
ralentissent l’utilisateur. L’expérience utilisa-
teur est similaire à celle des formulaires wap.
A l’inverse, la saisie
inline est peu plus
complexe à mettre
en œuvre, permet
difficilement le mode
T9. Mais elle a l’avan-
tage de se faire sans
changer d’écran. L’expérience utilisateur
est similaire à celle des formulaires web. Il
faut de plus prévoir un clavier virtuel pour
les terminaux à écran tactiles et placer
celui-ci afin de ne pas cacher la zone de
saisie.
Autres actions
Une application mobile peut aussi effectuer
des actions plus exotiques comme envoyer
un SMS, émettre un appel téléphonique ou
lancer le navigateur wap. Le comportement
précis du téléphone n’a pas été normalisé
dans ces cas là. Les téléphones se
comportent donc de manière très variée.
Par exemple, lorsque l’application veut
émettre un appel, certains téléphones vont
juste afficher une pop-up de confirmation
d’appel à l’utilisateur, alors que d’autres vont
en plus lui proposer d’effectuer l’appel en
visio, d’ajouter le numéro de téléphone aux
contacts voir d’envoyer plutôt un SMS.
Sur certains téléphones, l’application mobile
revient au premier plan après l’appel
téléphonique ; d’autres mettent l’application
en arrière plan voire l’arrêtent.
Ici encore plus qu’ailleurs, des tests sur les
téléphones cibles sont nécessaires afin de
vérifier l’expérience client de bout en bout,
pour éviter toute incompréhension de la
part de l’utilisateur.
Les tests
Pour garantir l’expérience et éviter la
déception d’une application qui ne marche
pas, iI faut tester, tester et tester votre
application mobile.
Les tests doivent avoir lieu régulièrement,
tout au long des développements.
De préférence, les tests doivent utiliser les
téléphones les plus lents, avec des tailles
d’écran variées.
Et pour cela, l’utilisation de vrais téléphones
est préférable à des émulateurs qui ont un
CPU, une bande passante et un clavier
bien meilleurs que les téléphones.
L’ergonomie de vos applications doit dès le
départ prendre en compte les téléphones à
écran tactile.
Il faut se mettre à la place de l'utilisateur,
en effectuant le parcours client de bout en
bout, sans négliger la partie téléchargement,
installation, lancement et mise à jour de
l’application.
Pour des tests à plus grande échelle, lors
de la recette par exemple, un grand nombre
de téléphones est souvent nécessaire.
L’achat de ces téléphones est long et
coûteux et leur gestion est chronophage.
Des solutions externes existent. Device-
Anywhere permet ainsi de manipuler à
distance de véritables terminaux. En
France, le PACA Mobile Center permet de
plus à ses adhérents d’accéder
physiquement à plus de 700 téléphones.
La stratégie de réalisation de ces tests doit
être adaptée au contexte du projet en
fonction de sa criticité et du budget alloué :
> Pour un projet critique, dans lequel
l’expérience utilisateur est primordiale, il
faudra impérativement, en fin de projet,
tester l’application de bout en bout sur
l’ensemble des terminaux ciblés. Ce point
9

9. RÉUSSISSEZ VOS PROJETS
MOBILE
est structurant à la fois pour les aspects
coûts, et pour les aspects planning. Ce
sera par exemple des applications pour
lesquelles il n’est pas possible d’avoir le
moindre incident ou bug, comme par
exemple un projet de paiement mobile,
ou la cinématique complète du paiement
doit être “garantie”. Dans le monde du
mobile, la seule garantie possible est de
tester de bout en bout sur le terminal
cible.
> Au contraire, pour d’autres projets
moins critiques, il sera possible de
prendre un risque supplémentaire
mesuré, en se concentrant pour les tests
de recettes sur le ou les deux terminaux
clés par famille (Série 60 V3, Sony
Ericsson JP7…). Cela nécessite une
bonne connaissance des terminaux et
de leurs “bugs standards” afin de cibler
les bonnes familles. Dans ce cas,
l’usage de méthodes de développement
industrielles, basés sur des frameworks
déjà testés et validés sur un grand
nombre de terminaux permet de
fortement diminuer la prise de risque.
Déploiement
Taille de l’application
Attention à la taille de l’application. Les
tout premiers téléphones n’acceptaient
pas les applications de plus de 128 ko.
Une limite raisonnable actuellement est
d’environ 300 ko. A titre de comparaison,
voici ci-contre les tailles de quelques
applications “classiques” du marché.
Télécharger la version appropriée au
terminal
La fragmentation des terminaux désigne la
variété des écarts visibles entre terminaux
(différences de taille d’écran, de taille de
police de caractères) ainsi que les écarts
non visibles (codes de touche, bug
d’affichage).
La gestion de ces écarts nécessite le plus
souvent d’avoir plusieurs versions
téléchargeables de l’application. Suivant
les fonctionnalités et les techniques de
développement utilisé, il peut y avoir entre
une dizaine et quelques centaines de
versions différentes, par marque ou par
modèle de téléphone.
Il faut donc que l’utilisateur télécharge la
bonne version.
Au vu des différentes pratiques actuelles, la
manière la plus appropriée de télécharger
une application est la suivante :
> Décrire l’application sur une page web
et indiquer l’URL du site wap de
téléchargement.
> Sur cette même page, proposer à
l’utilisateur de lui envoyer directement
un lien de téléchargement par SMS.
Cela nécessite un formulaire de saisie
du numéro de téléphone portable et la
capacité à envoyer des SMS push wap*.
> La page wap de téléchargement détecte
automatiquement le modèle du téléphone
et affiche une page de validation. Un lien
doit permettre à l’utilisateur de sortir du
mode de détection automatique et de
passer en sélection manuelle de son
modèle de téléphone.
En complément, il est aussi possible
d’ajouter un module sur le site Internet, dans
lequel l’utilisateur saisit son numéro de
mobile, et reçoit le lien de téléchargement
sur son mobile. Il lui suffit alors de cliquer
sur ce lien pour arriver sur le site de
téléchargement.
Mise à jour
Votre application mobile sera amenée à
évoluer. Se pose alors le problème de la
mise à jour de l’application sur les
téléphones l’ayant déjà téléchargée.
Si votre application est une application
développée de manière classique, le
moindre changement de virgule ou de
couleur nécessitera un nouveau déploiement
et l’utilisateur devra ré-installer l’application.
A l’inverse, si votre application est déve-
loppée sur la base d’un player générique,
il est possible de faire évoluer votre
application sans la relivrer. C’est un gain
de réactivité très appréciable.
Cela permet de plus de prendre en compte
les retours utilisateurs et de faire varier
rapidement le contenu ou l’ergonomie de
l’application basée sur ces retours.
Toute mise à jour de l’application se fait
ainsi de manière transparente pour
l’utilisateur qui n’a pas à réinstaller toute
son application sur son téléphone.
*SMS push wap : SMS contenant un lien vers un site wap
10
Yahoo Go 594 Ko
Gmail mobile 158 Ko
Jeu Voting
SMS
200 Ko

10. Atos Worldline is an Atos Origin Compagny www.atosworldline.com
Atos, Atos et le poisson, Atos Origin et le poisson, Atos Consulting ainsi que le poisson seul sont des marques déposées d'Atos Origin SA. - © Atos Worldline 10.2008
A propos de l’auteur
Ludovic Tant, rédacteur et coordinateur de ce livre blanc, dirige l’équipe Labs focalisée sur les marchés Télécom,
Utilities et Média au sein d’Atos Worldline.
Cette équipe constituée d’experts est dédiée à l’innovation et à l’industrialisation.
L’offre de développement d’applications mobiles Worldline Padda est issue des travaux de cette équipe.

11. Atos Worldline
Filiale du groupe Atos Origin, Atos Worldline est un acteur européen majeur
dans le traitement des échanges électroniques à grands volumes, spécialisé
dans les services de paiements électroniques, de CRM et les e-Services
(services Internet, vocaux et mobiles). Centrée sur l’innovation technologique,
Atos Worldline déploie ses solutions en mode processing ou en mode
intégration. Le 7 décembre 2006, Atos Origin a annoncé l’acquisition de
anksys et ank Card Company ( CC) pour les intégrer à Atos Worldline,
créant ainsi un leader européen des services de paiement, avec un chiffre
d’affaires pro forma 2006 combiné de 630 millions d’euros et 4.000 employés.
www.atosworldline.com
Atos Origin
Atos Origin est l’un des principaux acteurs internationaux dans les services
informatiques. Sa mission est de traduire la vision stratégique de ses clients
en résultats par une meilleure utilisation de solutions de conseil, intégration
de systèmes et infogérance. Implanté dans 40 pays à travers le monde,
Atos Origin réalise un chiffre d’affaires annuel de 5,5 milliards d’euros avec
un effectif de plus de 47 000 personnes. Atos Origin est le partenaire infor-
matique mondial des Jeux Olympiques et le Groupe compte parmi ses
clients de grands comptes internationaux dans tous les secteurs d’activité.
Atos Origin est coté sur le marché Eurolist de Paris et exerce ses activités
sous les noms d’Atos Origin, Atos Euronext Market Solutions, Atos Worldline,
Atos Consulting.
www.atosorigin.com
Atos, Atos et le poisson, Atos Origin et le poisson, Atos Consulting ainsi que le poisson seul sont des marques déposées d'Atos Origin SA. - © Atos Worldline 10.2008
Atos Worldline is an Atos Origin company
Atos Worldline • Tour Manhattan • 5-6 place de l’Iris • 92926 Paris La Défense Cedex • France
Ludovic Tant • Tel: +33 (0)3 20 60 82 09 • E-mail: ludovic.tant@atosorigin.com • Web: www.atosworldline.com