Livre blanc Développement mobile

Livre blanc Développement mobile

• 1.
  Depuis près de25 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 quelquesmots 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 Lesenjeux 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érentstypes 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’ergonomied’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 Deplus, 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 permetla 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 eststructurant à 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 isan 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 dugroupe 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: [email protected] • Web: www.atosworldline.com