III.1 - Cahier des charges

III.1.1 - But général

	L' objectif principal de l'Interface Homme-Machine (IHM) développée pour l'opérateur philippin SMART 
réside dans l' administration, au sens général. L'IHM permettra aux 3 profils d'administrateurs de pouvoir 
se connecter à un serveur WEB commun quelle que soit leur position géographique (voir figure 9). Certains, 
administrateurs d'abonnés (" user administrators ") travailleront à partir des points de vente des téléphones 
mobiles de l'opérateur SMART. D'autres, administrateurs de services ("  service administrator ") gèreront 
directement les entités externes telles que les banques ou compagnies auprès desquelles les virements externes 
de l'abonné radio-mobile seront adressés… (voir figure 11) Enfin, les super-utilisateurs (" super-users ") 
auront la possibilité de gérer l'ensemble des entités intervenant dans cette architecture (abonnés, services, 
" user administrators ", " service administrators ", banques, compagnies…). 



Fig.11 - Modules intervenant dans l'architecture physique regroupant tous les services à valeur ajoutée offerts sur 
le réseau de l'opérateur philippin SMART

Le schéma précédent met en lumière les éléments présents autour de la plate-forme ASP :
	- L'opérateur GSM philippin SMART ;
	- Les banques et le serveur (" Arizona ") les reliant à la plate-forme ASP par lien TCP/IP ;
	- Le réseau fédérant les commerçant acceptant le paiement par téléphone mobile interposé. Ce réseau est relié 
à l'ASP à l'aide d'un autre serveur local (" I-Planet ") ;
	- Le Composer permettant d'effectuer des tests de l'ASP en simulant le réseau GSM, le SMSC et la carte SIM de 
l'abonné. Il s'agit d'un émulateur de téléphone mobile permettant d'observer les traces des échanges entre la carte 
SIM et la plate-forme.

Ainsi, cette IHM offre un accès universel aux 3 profils d'administrateur et devra être en relation avec l'ensemble 
des modules de l'architecture associée à la plate-forme (voir figure 12).



Fig.12 - Ensemble des modules de l'architecture liée à la plate-forme

Etant donnés les nombreux liens TCP/IP reliant ces modules, le serveur WEB lié aux IHM se présente sous la forme d'un 
CGI (Common Gateway Interface) développé en langage Perl et Javascript et dialoguant avec des processus codés en 
langage C par l'intermédiaire de sockets IP (voir annexe 5). Nous étudierons de manière plus approfondie ces processus, 
dans le paragraphe suivant, ceux-ci étant fortement liés aux fonctionnalités que devra offrir l'IHM.
 

III.1.2 - Explication détaillée des résultats attendus

	L'IHM devra offrir les fonctionnalités d'administration des services à valeur ajoutée offerts par l'opérateur 
SMART à ses abonnés. Ces services sont regroupés dans des applications qui apparaissent dans la figure 12 :

-	Le Mobile Banking : cette application permet à l'abonné mobile d'effectuer les opérations bancaires les plus 
courantes à partir de son terminal mobile GSM de façon totalement sécurisée. Cette application assure l'accès à 
plusieurs banques (au plus 3) à partir d'un même terminal mobile qui pourra les choisir ou en changer librement 
(fonction " Register Bank " déjà vue) ;
-	Le Mobile Prepaid (ou SMART Buddy) : cette application permet à l'abonné de gérer son compte prépayé qui sera 
débité lors des communications téléphoniques et l'envoi de messages courts (SM) initiés par l'abonné. Ce compte peut 
être rechargé par virement interne, carte bancaire ou carte prépayée (carte à gratter ou scratch card) ;
-	Le Mobile Wallet (ou SMART Money) : cette application permet à l'abonné de gérer son porte-monnaie électronique 
et d'accepter les transactions associées. L'abonné pourra régler ses achats via le terminal mobile et non plus la 
carte bancaire. Toutefois, seul un réseau de commerçants, équipés d'un appareil spécialisé et reliés à au serveur 
de la société IPlanet, pourront accepter ce type de transaction (voir figure 11) ;

La figure 13 suivante, illustre le fait qu'un " super user " de profil 3 accède à une plus large palette de 
fonctionnalités qu'un " user administrator " de profil 1 (voir également la Table des fonctionnalités offertes 
par un profil d'administrateur donné).

  

 
Fig. 13 - Différentes IHM auxquelles accèdent les administrateurs de profils 3 (à gauche) et 1 (à droite)

 
Nous étudierons dans la partie suivante quels choix de programmation ont été effectués pour développer l'IHM et 
comment le cahier des charges a été pris en compte ou non afin de livrer l'IHM à la fin du mois de novembre 2000.

III.2 - Compte-rendu d'activité

III.2.1 - Analyse fonctionnelle et codage d'une IHM d'administration, implémentée sur la plate-forme ASP développée 
pour l'opérateur SMART

Architecture en couches et modules de base de l'ASP

	Avant d'aborder les aspects techniques liés au développement de l'IHM, étudions les modules de base de la 
plate-forme (voir annexe 3 et 5 pour plus de détails) et voyons comment ceux-ci sont utilisés dans le cas de 
l'ASP développée dans le cadre du projet SMART. La figure 14 suivante fait apparaître trois SME (Short Message Entity) 
distincts associés chacun à une application spécifique : Mobile Banking, Mobile Wallet et Mobile Prepaid. Ces trois 
applications sont regroupées sur une même plate-forme logicielle (d'où l'acronyme ASP pour Application Services/Server 
Platform). Chaque SME est repérer par un numéro unique du point de vue du SMSC. La plate-forme peut être interconnectée 
à plusieurs SMSC (voir figure 3) et à plusieurs PLMN (Public Land Mobile Network). 

 


Fig. 14 - Couches applicatives de la plate-forme ASP (couches hautes)

La plate-forme doit gérer de nombreuses connexions (c'est pourquoi elle est également appelée passerelle) avec 
les SMSC d'une part et les fournisseurs de contenu (Arizona, IPlanet…) d'autre part. Chacune des 3 applications 
est caractérisée par un Application Controller (AC) et les sessions associées, ouvertes avec les terminaux mobiles. 
Pour un SME donné, l'ensemble des sessions est géré par un Session Controller (SC). De manière générale, un SME peut 
supporter plusieurs applications (et donc plusieurs AC) mais dans le cas de la plate-forme SMART, un SME est associé 
à un seul AC et donc à une seule application. Chaque fois qu'une communication avec un mobile est ouverte via le 
service de messages courts (SMS), un Session Handler (SH) est créé pour en maintenir le contexte. Le Session Controller 
manage, pour chaque AC du SME, l'ensemble des SH et enregistre l'état des SH (actif, en attente de réponse, bloqué) 
dans un archiveur de sessions appelé SAFF (Session Archiver Flat File). Ce genre de fichier sera interrogé par le 
service " Session Monitoring " de l' IHM afin de connaître l'état des sessions ouvertes.

	La figure précédente fait apparaître les couches hautes de la plate-forme. La figure 15 suivante, met en lumière 
les couches basses de la plate-forme. Ces couches gèrent l'interfaçage et les connexions entre la plate-forme et les 
entités externes telles que les serveurs Arizona (application " Mobile Banking"), IPlanet 
(application " Mobile Prepaid ") et les SMSC de l'opérateur SMART. Nous distinguerons 2 types d'entités externes :
-	les serveurs de contenu (CP, pour Content Provider) qui sont interfacés à la plate-forme à l'aide de processus 
démon (daemon processes). De tels processus fonctionnent continuellement et sont activés lors du démarrage de la 
plate-forme. Leur rôle principal est le formatage et la transmission des données.
-	les serveurs de messages courts (SMSC) qui sont interfacés à la plate-forme via des Media Drivers (MD) 
spécifiques. Ces processus fonctionnent également en continu et sont dévoués à un SMSC unique. Les messages 
courts transitent donc par les MD. Chaque MD met à jour son propre archiveur de messages courts, appelé MAFF 
(Message Archiver Flat File). Les MAFF seront également consultés par le service " Service Monitoring " de 
l' IHM non pas pour connaître le contenu des messages courts qu'ils véhiculent mais pour connaître l'état d'un MD.

 

Fig. 15 - Couches de communication de la plate-forme ASP (couches basses)

Remarquons qu'un SMSC est relié à un MD unique mais que les messages courts qu'il délivre peuvent être destinés à 
l'une des 3 applications (Mobile Banking, Mobile Wallet ou Mobile Prepaid). Un routage des messages courts entre le 
MD et l'application de destination doit donc être assuré. Or une application est, dans le cas de ce projet, associée 
à un SME et repérée par un numéro de SME contenu dans l'en-tête du message court. Le routage est donc possible entre 
le MD et l'application de destination et est assuré par un module appelé Router. Enfin, de nombreux processus étant 
démarrés et stoppés (chaque AC, chaque MD, chaque démon, le Router…) il convient de connaître l'état de chacun de ces 
processus, à chaque instant pour s'assurer du bon fonctionnement de la plate-forme. C'est le cas du serveur 
d'évènements (SEVENT ou Event Monitor) qui génère des messages d'alerte en fonction de l'état du système par 
traps SNMP ou e-mails aux administrateurs. Il surveille en particulier la charge du système en SH, par exemple, 
car le système est dimensionné pour un nombre de sessions simultanées (SH) donné qu'il serait regrettable de dépasser.

Architecture fonctionnelle de l'application " Mobile Banking "

	Intéressons-nous ici à l'application " Mobile Banking " et à la manière dont elle est connectée au serveur 
de contenu bancaire Arizona, au SMSC Nokia de l'opérateur SMART ainsi qu'au serveur de base de données Postgres 
(voir figure 16). De plus nous verrons avec la plate-forme de test Composer qu'il est possible de simuler un 
réseau GSM, un terminal mobile ainsi que sa carte SIM afin de développer de nouvelles applets et les tester. 
La figure suivante illustre la manière dont s'articulent, du point de vue fonctionnel, les différents modules 
intervenant :

 

Fig. 16 - Architecture fonctionnelle de l'application " Mobile Banking "
 
	Le Composer est une plate-forme de tests simulant le terminal mobile, matérialisé par sa carte SIM 
pro-active, et le réseau GSM (incluant le SMSC). Il est utilisé par les constructeurs de cartes SIM 
(Oberthur Card Systems dans le cas de Rapsodia Software) qui y développent des applications (ou applets) 
en Java Card (langage de programmation orienté objet JAVA compressé). Lors des tests, un développeur de 
Rapsodia Software (détenant la plate-forme ASP) et un développeur de Oberthur Card Systems (détenant un 
pseudo terminal mobile GSM, c'est-à-dire le Composer) vont pouvoir s'échanger des trames (enregistrées 
dans des traces) via des liaisons TCP/IP et s'assurer du bon fonctionnement du système. C'est le premier 
travail effectué au cours du stage afin de se familiariser aux différents outils d'analyse et de développement.

Le Démon Arizona assure l'interface entre l'application " Mobile Banking " et le serveur externe Arizona 
auquel il est relié via une connexion TCP/IP ou X25. Dans la spécification de l'ASP, l'AC est par définition 
l'intermédiaire exclusif entre le SH et les serveurs externes et le démon peut être considéré comme un sous-module 
de l'AC extériorisé afin de l'alléger.

Le Serveur Arizona fédère les banques auxquelles l'abonné philippin peut avoir accès. Ce serveur a pour but de 
forwarder les requêtes d'interrogation des bases de données bancaires (qui contiennent les soldes bancaires, 
dernières opérations et profils des clients entre autres). De la même manière, il retourne à l'ASP les informations 
requises. Un protocole complet décrit trames échangées entre l'ASP et les banques, mais sort malheureusement du 
cadre de ce rapport.

Le SMSC est un serveur non normalisé par les recommandations GSM émanant de l'ETSI. Si bien que chaque constructeur 
établit son propre standard. Le SMSC auquel est reliée la plate-forme est de type Nokia Artus SC5A. Les messages 
courts sont échangés à travers le réseau de signalisation sémaphore SS7. Toutefois, un serveur de message court 
étant avant tout un serveur de messagerie, la norme X.400 peut être utilisée et les messages, après reformatage 
par une passerelle, pourrons être véhiculés par le réseau de messagerie standard X400.

Le Serveur WEB est de type Apache et est installé sur la même machine que la plate-forme ASP (modèle HP avec 
système d'exploitation Unix). Toutefois, il peut être installé sur une machine indépendante. Hormis l'installation 
du serveur Apache et la récupération de l'adresse IP de la machine sur laquelle il fonctionne, seul un travail de 
configuration a été nécessaire. Il s'agissait du fichier httpd.cfg dans lequel une machine virtuelle doit être créée 
avec un port d'entrée TCP/IP différent de ceux des autres modules de l'ASP ainsi qu'un chemin vers le fichier de la 
page d'accueil (home page) du site WEB. Ce serveur est accessible par une adresse IP, un port IP et un alias du 
chemin menant à cette page d'accueil :
http://adresse_IP:port_TCP_IP/alias_du_chemin_menant_à_la_homepage/index.html
Nous verrons qu'avec l'interface CGI (Common Gateway Interface) et un mélange de langages Perl, C et Javascript, 
il est possible de formater des pages dynamiquement, d'accéder à une base de données (Postgres, par l'intermédiaire 
d'un démon) et de retourner une page WEB dynamique à l'administrateur utilisant l'IHM.

	Le Démon Admindb administre la base de données Postgres à travers l'interface d'administration (IHM) 
développée au cours de ce stage. Sur la figure précédente, il s'agit du démon de connexion entre le serveur 
WEB et Postgres. Ce processus est démarré en général juste après le serveur WEB et le serveur de base de données 
Postgres car il communique avec ces premiers au moyen des sockets IP (voir annexe 5) bien qu'il soit implémenté 
sur la même machine physique (ce n'est pas toujours le cas lorsque les applications de l'ASP gèrent un trop grand 
nombre de Session Handler car il faut alors répartir les processus sur plusieurs microprocesseurs et donc sur 
plusieurs machines). Le module Admindb a été écrit en langage C en utilisant le formalisme SQL d'accès aux bases 
de données. Il a nécessité la moitié du temps de développement de l'IHM, l'autre ayant servi à développer les 
fichiers du CGI.

	Le Serveur Postgres permet de gérer les différentes tables de la base de données de l'application 
" Mobile Banking ". Il existe une vingtaine de tables renseignant l'ASP et les administrateurs sur les abonnés 
GSM du réseau SMART, les banques avec lesquelles SMART a signé un partenariat (via Arizona), les compagnies vers 
lesquelles les abonnés peuvent effectuer leurs virements externes, les menus bancaires s'affichant sur le téléphone 
mobile… 
L' objectif principal de ce stage a donc été de développer une interface d'administration de la base de données 
Postgres rendant transparente l'utilisation des requêtes SQL à l'administrateur. Cette interface conviviale permet 
en outre, par l'utilisation d'un serveur WEB, d'accéder à la base de données quelle que soit la position géographique 
et le profil de l'administrateur. Un premier niveau de sécurisation de l'accès à cette base de données est réalisé 
par un pare-feu (firewall) qui filtre les adresses IP des stations souhaitant accéder au serveur WEB d'administration 
de la base de données. 

Architecture physique mise oeuvre pour l'application "Mobile Banking"

	Après avoir vu les aspects fonctionnels de la plate-forme ASP, observons brièvement les aspects réseaux 
associés (voir figure 17) qui nous seront bien utiles par la suite :

 

Fig. 17 - Architecture physique de la plate-forme ASP
 

III.2.2 - Déroulement concret du projet : développement, test et validation

	La figure 18 suivante permet de bien comprendre l'intérêt de l'IHM développée au cours du stage. En effet, 
supposons qu'un abonné navigue dans le menu de l'application " Mobile Banking " de son terminal mobile. La 
communication avec le Session Handler (SH) ouvert afin de gérer cette session se fait par envoi bilatéral de 
messages courts (SM). Imaginons maintenant qu'un administrateur souhaite savoir si cet abonné précisément 
utilise ou non l'application bancaire que sa banque et son opérateur lui ont proposée. Il lui suffit de se 
logger sur le site WEB associé à l'IHM et d'utiliser le service " Subscriber Monitoring " et d'enregistrer 
le numéro de téléphone mobile de l'abonné (MSISDN). Une ligne apparaît alors, après interrogation par le serveur 
WEB des fichiers d'archivage des sessions (SAFF), lui révélant que l'abonné utilise le service " Mobile Banking ". 
Il existe bien entendu de nombreux autres exemples d'utilisation de l'IHM.

 

Fig. 18 - Exemple d'architecture physique présentant à la fois l'application " MOBILE Banking " et l'IHM

	Du point de vue fonctionnel, les trois modules que constituent la Base de données Postgres, le Démon de 
connexion avec le serveur WEB et Postgres (démon admindb) et le serveur WEB, communiquent à travers les ports 
TCP/IP de la machine sur laquelle ils sont réunis (voir figure 19). Les fichiers CGI du serveur WEB sont codés 
en langage Perl et génèrent des pages HTML/Javascript. Certains de ces fichiers exécutent des scripts shell UNIX 
pour interroger les MAFF et SAFF (dans le cas de requêtes aboutissant au formatage d'une page WEB de monitoring 
des sessions par exemple). Le démon Admindb est codé en langage C et formate des requêtes SQL pour interroger la 
base de données Postgres. Durant le développement de l'IHM, une poignée de langages de programmation ont été 
utilisés par alternance, diversifiant ainsi la tâche à réaliser. Une vingtaine de requêtes d'interrogation de 
la base de données a du être développée (voir Table des requêtes/réponses échangées entre le démon Admindb et 
la database Postgres).

 

Fig. 19 - Architecture fonctionnelle et en couche de l'IHM

Le développement de ces requêtes a nécessité l'établissement d'un protocole de communication entre le démon Admindb 
et la base de données Postgres. Des trames sont alors formatées en fonction des informations à aller chercher dans 
les tables de la base de données et placées dans la socket établie entre le démon Admindb et la database.

Le déroulement d'une interrogation de la base de données Postgres par un administrateur est le suivant, dans le cas 
d'une modification de menu bancaire :
 
 

Fig. 21 - Ecran d'accueil de l'IHM

1) L'administrateur commence par se connecter à l'IHM en utilisant son navigateur (Netscape Communicator 4.7 de 
préférence). Pour cela, il enregistre l'URL suivante :

http://10.102.68.29:8090/cgi-in/main/index.cgi

Le CGI index.cgi (codé en Perl) du serveur WEB présenté par la figure 19 formate alors la page d'accueil HTML et 
l'envoie au navigateur. L'écran d'accueil ci-contre (voir figure 21) apparaît alors et propose à l'administrateur 
d'enregistrer son identifiant et son mot de passe. Le code HTML de la page WEB contient des instructions en 
Javascript pour s'assurer que les champs d'identification sont bien remplis et retourne ces 2 paramètres au serveur 
WEB.

2) Notons que le langage Perl est interprété du côté du serveur WEB. L'exécution de ce CGI génère une page 
HTML/Javascript dynamiquement et l'envoie au client. Le navigateur affiche alors la page HTML sans tenir compte 
du Javascript. Le Javascript n'est interprété côté navigateur qu'à la suite d'actions de l'administrateur sur la 
page HTML (clic du bouton valider par exemple). Les instructions Javascript sont alors déroulées et des boites 
de dialogue peuvent apparaître afin de signaler à l'administrateur un champ mal rempli. Le Javascript crée 
l' interactivité avec l'administrateur. Si les champs (identifiant d'administrateur et mot de passe) sont 
correctement renseignés, ceux-ci sont renvoyés au serveur WEB qui va les utiliser pour authentifier l'administrateur.

3) Pour cela, le CGI index.html envoie une requête d'authentification (code 01) au démon Admindb qui va interroger 
la base de données Postgres (voir figure 19). Une requête SQL est alors formatée et adressée à la database. 
Celle-ci retourne le profil de l'abonné associé à l'identifiant et au mot de passe ou un message d'erreur au démon 
Admindb (s'ils n'existent pas dans les tables ou si l'un des 2 est erroné).

4) A partir de la réponse à la requête SQL par la database, le démon prend la décision d'authentifier au non l'abonné 
et renvoie au CGI du serveur WEB soit une réponse d'échec (code 00), soit le profil de l'abonné en cas de succès 
(code 01). Dans le second cas, le CGI formate une nouvelle page WEB des services proposés par l'IHM au navigateur 
de l'administrateur (voir figure 22).

5) L'administrateur de profil 3 (tout comme celui de profil 2) est habilité à utiliser le service 
" Bank administration ". Il va donc pouvoir modifier un menu bancaire en cliquant sur ce lien hypertexte. 
Ce lien pointe vers un nouveau CGI admin.cgi responsable de ce service.

 

Fig. 22 - Menu des services proposés par l'IHM à l'administrateur de profil 3 (" super user ") 

6) Le CGI admin.cgi est exécuté du côté du serveur WEB. Ce CGI a besoin de connaître les profils de toutes 
les banques enregistrées dans la base de données avant de construire la page HTML/Javascript. Une requête de 
profils bancaires (code 05) est adressée au démon Admindb qui formule une requête SQL vers la database et 
retourne une réponse contenant les profils bancaires (code 05) au serveur WEB dont le CGI construit alors 
la page WEB et la transmet au navigateur de l'administrateur (voir figure 23).

  

Fig. 23 -Menu " Bank administration " 

7) L'administrateur choisit une banque (" IEB " dans l'exemple) pour la modifier. L'identifiant de cette 
banque est transmis par le navigateur au CGI du serveur admin.cgi WEB. Connaissant cet identifiant, le CGI 
envoie une requête de profil bancaire particulier (code 07) au démon Admindb qui interroge la database. Les 
paramètres associés à l'identifiant bancaire sont ensuite utilisés pour formater une nouvelle page HTML/Javascript, 
renvoyée aussitôt à l'administrateur (voir figure 24).

  

Fig. 24 - Modification d'un profil bancaire

8) L'administrateur peut alors enregistrer de nouvelles désignations des items du menu bancaire et les ordonner 
différemment voire en supprimer. L'impact de cette opération, une fois validée, est crucial au niveau des téléphones 
mobiles car les prochaines sessions ouvertes prendront en compte ce nouvel arrangement (voir Tableau suivant).

 

Tableau figurant une modification de menu bancaire (ordre et noms des items)

9) Si l'administrateur oublie de remplir des champs ou oublie l'item ordonné à la 5ème position, les instructions 
Javascript le lui signalent au moyen de boîtes de dialogue sans que la page WEB ne soit rechargée du serveur WEB 
vers le navigateur. Une fois que l'administrateur a validé le nouveau menu bancaire, le nouveau profil bancaire 
est transmis au CGI admin.cgi qui transmet les informations au démon Admindb par une requête 08. Le démon Admindb 
formate ensuite une requête SQL d' update des champs de la table relative au profil bancaire associé à l'identifiant 
bancaire (" IEB "). Si la mise à jour s'est bien passée, la database le signale au démon Admindb qui transmet une 
réponse d'état (code 00) au serveur WEB. Le serveur WEB renvoie la page HTML/Javascript du menu 
" Bank administration " (voir figure 23) au navigateur avec un flag tel qu'une boîte de dialogue signalera 
à l'administrateur que sa modification a bien été prise en compte.

	A l'issue de cet exemple (parmi tant d'autres), nous pouvons remarquer plusieurs choses :
-	le rôle du démon Admindb peut paraître flou étant donné que sa fonction principale est le forwarding. 
En effet, les requêtes SQL pourraient être formatées directement en langage Perl par les CGI. Cependant leur 
codage serait beaucoup trop lourd d'une part et peu évolutif au sens où si un jour la base de données migre 
de Postgres vers Oracle, tous les CGI seront à ré-écrire. D'autre part, il est possible avec la solution technique 
choisie de placer le serveur de base de données et le serveur WEB sur des machines distinctes de celle qui supporte 
la plate-forme ASP et donc le démon Admindb.
-	Le démon Admindb se voit affecter 2 ports TCP/IP, l'un est ouvert vers la database (port #2) et l'autre vers 
le serveur WEB (port #3, voir figure 19). La connexion entre le démon Admindb et le serveur WEB se fait par 
l'ouverture d'une socket IP (voir annexe 5). Un démon est par définition un processus fonctionnant continuellement 
dont le rôle est ici d' écouter le serveur WEB sur le port numéro 3 et d' interroger la database à l'aide de 
requêtes SQL.

-	La partie la plus lourde du développement de cette IHM a été le démon Admindb, purement codé en langage C, 
l'intérêt étant d'y inclure le langage SQL et de gérer les sockets IP. A contrario, la partie la plus attractive 
à développer a été l'ensemble des CGI du serveur WEB Apache qui a demandé un travail supplémentaire de configuration. 
L'intérêt du codage de CGI en Perl (ou en PHP, Python et C…) est de mélanger à la fois le langage HTML et Javascript. 
De plus cette partie possède une très grande interactivité avec le développeur au sens où ce dernier n'est pas obligé 
d'attendre une version compilée de son programme pour le voir fonctionner. Les CGI peuvent être développés et modifiés 
pas à pas en formatant et visualisant la page WEB générées par le CGI au bout de quelques lignes de code. Enfin, le 
navigateur offre un outil de débogage des instructions Javascript, appelé Console Java.


III.3 - Bilan, critique et perspectives d'évolution

III.3.1 - Bilan : panorama des autres services offerts par l'IHM SMART

	Nous n'allons pas ici détailler chaque écran de l'IHM mais les présenterons afin de découvrir d'autres services 
offerts par l'IHM tels que l'envoi de messages courts, la création de nouveaux administrateurs, la gestion et 
l'analyse des sessions ouvertes entre l'abonné mobile et les applications de la plate-forme ASP, le verrouillage 
des applications dans la carte SIM, le changement de MSISDN de l'abonné mobile…

Administration des abonnés (Subscriber menu)

 

Fig. 25 - Ecran " Subscriber Monitoring"
 
 

Fig. 26 - Ecran "Subscriber Administration"

 

Fig. 27 - Ecran "Message Sending"

 

Fig. 28 - Ecran "Incident Management"
 

Administration des services (Service menu)

 

Fig. 29 - Ecran " Service Monitoring "

 

Fig. 30 - Ecran "Sessions Monitoring"

 

Fig. 31 - Ecran "Company Administration"
 
 

Fig. 32 - Ecrans "Bank Administration" - Création d'une nouvelle banque

 

Fig. 33 - Ecran "Service Administration"

Gestion des administrateur utilisant l'IHM (Management menu)

 

Fig. 34 - Ecran " User Management "

 

Fig. 35 - Ecran " New Password "

	Après avoir dressé un panorama des services offerts par l'IHM, il est clair que de nouveaux services 
peuvent être ajoutés à cette IHM. Des services auxquels nous ne pensons pas forcément aujourd'hui mais qui 
s'imposerons par eux-mêmes dans les années à venir… La mise en place d'un nouveau service nécessite toutefois 
une charge de travail conséquente, au sens ou l'IHM n'est que la partie émergeante de l' " iceberg " qu'est la 
plate-forme ASP. Mais l'IHM nécessite d'être soignée au sens où elle demeure le seul élément " vu " par 
l'administrateur final. Nous développerons certaines de ces critiques dans le paragraphe suivant et établirons 
un bilan du stage.

III.3.2 - Critique

Aspects discutables

Après avoir mené le développement de l'IHM SMART, seul et de bout en bout, retenons tout de même certaines choses. 
Tout, d'abord, il faut à tout prie, ne pas oublier une étape essentielle lors de l'arrivée d'un stagiaire ou d'un 
employé dans une structure de développement telle qu'une start-up ou une SSII : la formation interne. Celle-ci est 
cruciale et détermine tout le travail effectué par la suite. Les premiers jours de ce stage y ont été consacrés. 
Par contre, celle-ci s'est transformée en auto-formation au cours des semaines et mois suivant, ce qui n'est pas 
problématique lorsque le stagiaire ou l'employé sait faire preuve d'autonomie mais peu le devenir dans le cas 
contraire.

Ensuite, une fois intégré à un projet, il ne faut en aucun cas commencer à développer sans définir clairement 
le travail à effectuer avec le manager du projet. Un cahier des charges ou des spécifications techniques et 
fonctionnelles décrivant tous les modules à développer sont indispensables. Les écrans de l'IHM du projet SMART 
ainsi que les protocoles de communication (format des trames) entre les différents modules auraient pu être 
définis " noir sur blanc " avant tout développement. Seulement, les deadlines, trop proches, ne nous ont pas 
laissées de répit ni de temps pour tout formaliser par écrit. Le temps ainsi gagné a peut-être été perdu par 
la suite lors de la phase de tests. Enfin, globalement ces spécifications ont été rédigées (sous forme de 
brouillons plus ou moins clairs) avant le développement.

	Après avoir abordé les aspects critiques du stage réalisé, voyons les perspectives d'évolution qui 
s'en suivent ainsi que les aspects positifs d'une telle expérience en entreprise..

Aspects positifs

	Il existe plusieurs manières d'aborder la technologie du SIM Application Toolkit, protocole de communication 
entre la carte SIM et l 'équipement radio-mobile qui la supporte. La première consiste à restreindre l'étude au 
Hardware et au protocole de communication même (voir annexe 1). C'est typiquement la manière dont le stage a été 
abordé, venant d'une formation en réseaux et télécommunications. Une autre manière est de considérer la carte SIM 
comme un élément d'une architecture client-serveur, la carte SIM étant le client et la plate-forme ASP le serveur. 
C'est typiquement l'approche conduite par un développeur de cursus d'informaticien. Une troisième manière de 
considérer le problème est l'approche Marketing, où la carte SIM (et l'abonné GSM) est associée à la demande 
et la plate-forme ASP à l'offre en nouveaux services à valeur ajoutée. La plate-forme ASP ou l'ALM, tout comme 
la carte SIMphonIC sont alors des produits. Le produit ASP s'adressant aux fournisseurs de contenu et le produit 
ALM aux opérateurs GSM. Dans les 3 cas ces approches sont complémentaires et l'une des richesses de ce stage a 
été de naviguer parmi ces trois points de vue.

	Fort de ce stage d'introduction à la technologie du SIM Application Toolkit (SAT) couplée au service de 
messages courts offerts par les réseau GSM (SMS), autorisant le transfert de données (d'une manière générale) 
et donc le dialogue entre un abonné radio-mobile et les fournisseurs de contenu (banques, serveurs de news…), 
il est intéressant de la confronter à d'autres technologies. Parallèlement à ce stage, la veille technologique 
s'est imposée d'elle-même et s'est principalement tournée vers le WAP (Wireless Application Protocole) et le 
service I-mode de la filiale japonaise DoCoMo de l'opérateur NTT. Le WAP offre certains services en commun avec 
le SAT (serveurs de news…) mais se trouve malheureusement limité par des temps de téléchargement des données 
trop longs pour rendre toute navigation aisée. Avec le SAT, les informations sont échangées avec des temps de 
transfert négligeables. De plus, le WAP ne permet absolument aucune transaction sécurisée de par sa passerelle, 
maillon faible de la chaîne de sécurisation des transactions de bout en bout (end to end). Le service I-mode, 
est un champs d'expérimentation, local au Japon, des réseaux de 3ème génération (UMTS). Il offre des services 
de diffusion de données audio et vidéo en temps réel, ainsi qu'un mode de facturation au volume et non à la 
durée que le SAT et le WAP n'offriront probablement pas (le WAP transmet tout juste des images bitmap). Par 
contre ce service repose sur une infrastructure réseau de type PHS (Personnal Handyphone System) différant 
fondamentalement du GSM (de par son débit de 64 kbit/s, à comparer aux 13 kbit/s de GSM dans le meilleur 
des cas, pour le transfert des données) et rendant toute implémentation en Europe complexe et improbable. 
Enfin, afin de standardiser le SAT et le langage de développement Java Card des applets de la carte SIM, 
un consortium d'industriels est né : le SIM Alliance. Les 3 technologies évoquées, plutôt complémentaires 
que concurrentes, sont donc à surveiller de près…

	Un des derniers aspects positifs de ce stage, outre une remarquables introduction aux services à valeur 
ajoutée des futurs réseaux de 3ème génération, est la façon dont la technologie du SAT/SMS a été abordée du 
point de vue du développement. Le développement d'un Application Controller, d'un Media Driver ou d'un 
Session Controller est chose commune dans le département développement de Rapsodia Software. Toutefois, 
il s'agit là du cœur de l'ASP (langage C et Unix) ne permettant pas de pratiquer le développement dans 
des domaines aussi variés que les IHM et bases de données. L'un des intérêts de ce stage est d'avoir 
pu aborder plusieurs domaines du développement informatique tels que l'interrogation de databases 
hétérogènes (Postgres, Oracle), le codage en C, les fichiers système UNIX, la programmation orientée 
objet avec Javascript, le Perl, le développement en équipe (outil " CVS "), les sockets IP et bien d'autres...

	Enfin, la proximité des département Développement et Marketing a fait que ce stage n'était pas articulé 
uniquement autour du développement mais également autours de la communication. Ainsi de nombreuses idées ont 
pu circuler autours de sujets tels que l'avenir du WAP, l'organisation de forums (Forum Cartes 2000 en octobre 
2000), la présentation des produits issus du développement et la façon dont ils ont été " packagés " et 
commercialisés… Du point de vue humain, ce stage s'est donc avéré très positif.

III.3.3 - Perspectives d'évolution

De nouveaux services à valeur ajoutée apparaissant chaque mois, il est clair que l'IHM SMART devra un jour ou 
l'autre en intégrer certains. Les codes sources, écrits en langage Perl, sont suffisamment modulaires et 
organisés en 2 couches (application et communication, pour formatage des trames échangées) de sorte que 
la maintenance et la portabilité de l'IHM est totale. A priori, la couche de communication écrite en Perl 
côté serveur WEB devrait migrer vers un codage en langage C de sorte que le serveur WEB et le démon Admindb 
utilisent tous les 2 une couche de communication écrite en langage C. Ainsi, l'établissement des sockets IP 
et le formatage des trames seront réalisés avec des fonctions communes.

Enfin, la plate-forme ASP intègre déjà de nouvelles fonctionnalités telles qu'une émulation de navigateur WAP 
(implémenté sous forme d' applet dans la carte SIM et prenant en compte les pages écrites en WML 1.2 mais pas 
les images), le Push (diffusion d'informations vers les téléphones mobiles en relation avec la plate-forme ASP), 
l'interface bi-fentes du téléphone mobile permettant d'y insérer une carte bancaire et permettant le Paiement par 
Carte Bancaire Mobile (PCBM)… La plate-forme ASP développée par la société Rapsodia Software est donc parfaitement 
évolutive.