Plateformes de services intégrés pour mobiles

Chapitre 4 : Spécifications détaillées de notre plateforme

Dans un contexte réseau favorable, avec une clientèle demandeuse, 2SI propose deux types de services dans sa plateforme :

I. Le service de sauvegarde de répertoire

Les terminaux mobiles stockent des données importantes telles que des contacts, des agendas ou bien des listes de tâches. Cependant ces données peuvent être perdues dès que le terminal est endommagé ou perdu. Les abonnés ont ainsi besoin de sauvegarder leurs données et de les récupérer au besoin.

1. Présentation

SOS-PIN, du nom du service à développer par 2SI, permettra d'assurer la pérennité des données personnelles. Il permettra à un abonné de stocker ses données à partir de n'importe où sur le réseau et de les récupérer au besoin. Ce service nécessitera l'installation d'une application, sur le mobile du client, chargée de communiquer avec l'application installée sur le serveur de l'autre côté du réseau.

2. L'application cliente

L'application cliente permet de lancer, au gré de l'utilisateur du mobile, le processus d'échange de données. Elle adopte différents comportements selon le mode d'échange entre le mobile et le serveur. Dans le cas d'une communication "client vers serveur" (sauvegarde), cette application est chargée de  collecter, arranger et envoyer les données situées sur le terminal.

Dans le cas d'un échange "serveur vers client" (restauration), elle est chargée de récupérer les données envoyées par le serveur, de les comparer aux données existantes et de stocker les bonnes données en évitant toute redondance.

3. L'application serveur

Elle est chargée de communiquer avec le client mobile. Selon les modes d'échanges, elle récupère les données envoyées par le mobile ou renvoie au client mobile ses données stockées auparavant. Elle est aussi chargée d'attribuer à chaque client un espace de stockage de ses données.

Au terme d'un échange de données entre le serveur et le client, la base de données cliente et l'espace de stockage réservé par le serveur à ce client sont identiques. Ce processus s'appelle la synchronisation.

Figure 22 : Architecture fonctionnelle Synchronisation

II. Le service de billetterie dématérialisée

Dans ce service, toutes les ressources seront localisées sur le réseau. Il n'est pas besoin d'installer une application sur le terminal mais ce dernier doit avoir une configuration minimale requise.

Ce service est appelé M-ticketing pour mobile-ticketing.

1. Présentation

Dans un souci de faciliter l'accès à de grands spectacles ou à certains endroits au grand public, les téléphones mobiles peuvent jouer le rôle de porte-billet électronique en lieu et place du traditionnel billet en papier.

M-ticketing consiste alors en la dématérialisation des billets de spectacles, transport, etc.

Un ticket est un billet attestant un paiement et donnant droit à un service, à l'entrée dans un établissement ou à l'accès à un moyen de transport.

Dans ce qui suit, nous considérerons le cas où le ticket donne accès à un événement. Ces événements sont regroupés par type et il existe une ou plusieurs catégories de tickets donnant accès aux différents événements d'un même type, chaque événement définissant ses propres prix par catégorie.

La dématérialisation est la transformation d'un flux de documents, ainsi que les traitements qui lui sont appliqués, en flux et traitements numériques. Elle consiste à mettre en oeuvre des moyens électroniques pour effectuer des opérations de traitement, d'échange et de stockage d'informations sans support papier. Elle n'a aucun effet sur le contenu de ces informations qui restent ce qu'elles sont indépendamment de la forme que prend leur support.

En partant du constat que le portable accompagne son propriétaire partout, il peut jouer facilement le rôle de porte-billet électronique où les billets sont affichés à l'écran sous forme de code barres comme celui figurant sur la majorité des produits en vente dans le commerce.

Après une transaction effectuée à partir d'un mobile habilité ou sur Internet, le billet est envoyé sur le terminal du client sous la forme d'un SMS-image ou d'un MMS (selon les caractéristiques du portable de l'abonné).

En se débarrassant du support papier, ce service génère plus de confort pour le client. Celui-ci peut en effet effectuer sa commande jusqu'au dernier moment (contrairement à la vente à distance de billets papier qui nécessite de s'y prendre à l'avance). De plus, il facilite le contrôle d'accès : il suffit juste de faire passer l'écran du mobile devant un lecteur code barres.

Ce service, outre qu'il est accessible à partir du web, compte s'appuyer sur le modèle existant de vente de crédit de recharge où un détaillant (le mobile habilité cité ci-haut) initie la transaction.

Figure 23 : Architecture fonctionnelle MTicket

NB : les numéros sur la figure indiquent l'ordre chronologique des actions effectuées dans ce service.

2. Identification des modules

L'identification des modules nous permettra de dégager les tâches à faire, de les planifier et de faire les choix technologiques nécessaires à leur réalisation.

2.1. Portail web pour l'achat d'un ticket

A partir de ce portail, un utilisateur pourra acheter autant de tickets qu'il le désire. Il devra renseigner les numéros de téléphone des bénéficiaires, les événements, et les catégories. Il devra en plus renseigner son numéro de carte bancaire pour le paiement. Ce portail propose, en outre, à ses visiteurs une vue globale sur l'ensemble des événements pris en compte.

2.2. Système de paiement en ligne

Dans le cas de l'achat à partir du portail web, notre application devra communiquer avec un système de paiement en ligne qui se chargera d'autoriser la transaction.

2.3. Génération du code barres

Ce module permettra de générer, de manière sécurisée, les images (codes barres 1D^17(*)) qui représentent les tickets à partir de numéros reçus en entrée. Ces numéros seront aussi générés selon un algorithme précis.

2.4. Envoi du ticket

Ce module permettra d'envoyer un SMS image ou MMS selon la compatibilité du terminal du bénéficiaire. Le MMSC de l'opérateur sera mis en contribution.

2.5. Validation du ticket

Le bénéficiaire fait passer son terminal sous un lecteur de code barres. Un dispositif léger récupère l'information (le numéro du ticket) et informe notre application que ce ticket vient d'être consommé.

Pour des raisons de mobilité et de performances, nous utilisons le Workabout Pro G2, un micro-ordinateur prenant en charge une large gamme de cartes et de modules d'extensions parmi lesquels des lecteurs de codes barres (voir image 3 ci dessous), des cartes SIM pour fonction de téléphonie, des extensions WIFI. Elle est basée sur une architecture (OS) Windows Embedded (Windows CE) ou Windows Mobile.

1

2

3

Figure 24 : Workabout PRO G2

2.6. Back office

Sous forme d'interface web, il sera composé de deux niveaux :

· Un espace pour l'administration globale du portail : c'est à ce niveau que sont gérés les événements (création, suivi, etc)

· Un espace d'administration restreinte à partir duquel un organisateur ne peut gérer que son événement

2.7. Réception d'une demande de ticket à partir du serveur d'application de l'opérateur

Lorsqu'un client désire acheter un ticket à partir d'un point de vente, le vendeur informe l'opérateur de la transaction et lui transmet toutes les informations nécessaires (événement, catégorie, numéro du destinataire) par USSD. L'opérateur, après avoir vérifié que le crédit du bénéficiaire est suffisant pour une telle transaction, informe notre application et lui transmet les paramètres.

L'USSD est un moyen de transmission d'information sur un réseau GSM, GPRS, UMTS. Il a été défini standard (standards ETSI, 3GPP [1] [2] [3]) à l'origine pour la commande de services supplémentaires spécifiques aux opérateurs. Il offre aujourd'hui en pratiques des possibilités de services beaucoup plus vastes (accès à des bouquets de services, consultation des comptes prépayés ou post payés...).

Il offre aussi une connexion orientée session, half-duplex et bi-directionnelle entre un terminal mobile et un serveur applicatif USSD. Les sessions peuvent être ouvertes à l'initiative du mobile par simple appel d'un code de service (i.e numéros courts avec des * et des #).

Exemples de codes USSD :

*100#

*100*775790221#

L'USSD utilise le canal de signalisation : il est peu gourmand en ressources réseaux et donc peu coûteux contrairement au SMS qui est du type store-and-forward et qui nécessite la présence d'un SMSC (SMS Center) dans le circuit de traitement. Il peut être assimilé à telnet alors que le SMS est assimilé au mail.

Cette technologie est entrain d'être largement acceptée comme le canal idéal de services tels que l'information par mobile, le commerce sur mobile et tout autre service qui nécessite une interaction entre le client et l'application. Comparé à l'IVR^18(*), l'USSD améliore quantitativement les temps de réponse : de 25 à 7 seconds^19(*).

Il est typiquement utilisé comme déclencheur (trigger) pour invoquer des services. C'est le cas des services de recharge de crédit ou de consultation de solde.

* ¹⁷ 1D : unidimensionnel

* ¹⁸ IVR : interactive voice request - système de réponse automatique personnalisable proposant à l'appelant une liste de services

* ¹⁹source O₂ Sicap USSD gateway : www.sicap.com/store/attachments/00038.pdf