Memoire Ingenieur Nwawel

UNIVERSITÉ DE YAOUNDÉ I UNIVERSITY OF YAOUNDÉ I
ECOLE NATIONALE SUPÉRIEURE NATIONAL ADVANCED SCHOOL OF

POLYTECHNIQUE ENGINEERING
DÉPARTEMENT DE GENIE INFORMATIQUE DEPARTMENT OF COMPUTER ENGINEERING
CONCEPTION ET DEVELOPPEMENT D'UNE SOLUTION

MOBILE POUR LE SUIVI DES PROCEDURES
DEMATERIALISEES DU COMMERCE EXTERIEUR.
Mémoire de fin d’études / Master of Engineering
Présenté et soutenu par :
NWAWEL A IROUME
En vue de l’obtention du :
Diplôme d’ingénieur de conception en Génie Informatique
Sous la direction de :
KOUAMOU Georges Edouard, CC.
MVEH ABIA Chantal, CC.
Jamelddine EL KAMEL, Ing.
Devant le jury composé de :
 Président: TCHUENTE Maurice, Pr.

 Encadreurs: KOUAMOU Georges Edouard, CC.
MVEH ABIA Chantal, CC.
 Examinateur: Roger NKAMBOU, Pr.
 Invité : Jamelddine EL KAMEL, Ing.
Année Académique 2013 - 2014

DEDICACES
A mes parents Mr. & Mme. IROUME,
A ma tante NDEM Marceline,
A mon oncle WELL A MOUTE Dieudonné,
A Toute ma famille.
i
Mémoire de fin d’études d’Ingénieur de Conception en Informatique à
l’Ecole Nationale Supérieure Polytechnique de Yaoundé (ENSP).
Par : NWAWEL A IROUME
REMERCIEMENTS
Ma gratitude et mes remerciements au Pr. Thomas BOUETOU BOUETOU pour son
inestimable contribution à notre formation.
Je remercie le jury :
 Le président du jury Pr. TCHUENTE Maurice pour m’avoir accordé sa disponibilité

 les encadreurs Dr. KOUAMOU Georges Edouard et Mme. MVEH ABIA Chantal pour leur
disponibilité, leurs remarques et leur encadrement.
 L’examinateur Pr. Roger NKAMBOU.
Je remercie aussi :
 Ing. Jamelddine EL KAMEL Directeur Général d’ICS Engineering pour m’avoir permis
de d’effectuer mon stage de fin de formation dans son entreprise.
 Ing. Abdoullahi FAOUZI Directeur de la DSI du GUCE pour ses conseils et suggestions.
 Ing. WATO Arnold pour ses idées, et aussi Ing. AYEFOU Gildas, Ing. KOUFANA Crépin,
Ing. OWOUNDI Edima pour m’avoir guidé durant la phase technique du projet du stage.
 YENKE Marius pour son soutien lors des blocages techniques durant mon stage, et tout
le personnel d’ICS Engineering.
Vous aussi je ne vous oublie pas :
 La promotion GI14
 Mr SIDI, Mme ASA ADO pour m’avoir soutenu lors de mes déboires.
 Mes cousins WELL NDIORO Jeremy, ANOKO A WELL Honoré.
 MASSAN Angeline.
ii
RESUME
La diffusion de contenus numériques sur des équipements portables à travers des
applications mobiles prend de l’envergure dans les milieux industriels. Que ce soit sur de
simples téléphones portables, sur des smartphones et des tablettes, pratiquement toutes les
entreprises commerciales, industrielles s’orientent vers ce nouveau modèle de diffusion, du
fait qu’elle offre de nouvelles opportunités de distribution : push. Être alerté à bon escient
afin de saisir des opportunités est une attente du consommateur mobile.
En vue de rendre plus efficaces les échanges sur la place portuaire du Cameroun, le Guichet
Unique des Opérations du Commerce Extérieur (GUCE) désire étendre sa plateforme
électronique des procédures dématérialisées pour y intégrer ces applications mobiles. Ceci
afin de permettre aux opérateurs de commerce extérieur (importateur - exportateur) de
pouvoir suivre ces procédures dématérialisées et d’être alertés.
Ce mémoire a pour objectif de concevoir et de développer une solution mobile pour le

suivi des procédures dématérialisées.
Pour y parvenir nous avons fait un état des lieux sur les procédures thématiques, les modes
de diffusion technologiques. Ce qui a permis de choisir trois canaux de notification à savoir
l’email, le SMS, la notification PUSH via Google Cloud Messaging pour Android. Pour ces trois
canaux de notification, nous avons conçu et réalisé les constituants du système à mettre en
place. Il s’agit d’une application web en JEE et une application Android. Le prototype qui en
résulte a été expérimenté.
Mots clés : Android, canaux de notification, solution mobile.
iii
ABSTRACT
Dissemination of digital content on mobile through mobile applications is becoming the
new industry standard. Whether simple mobile phones, new trends such as smartphones and
tablets, virtually all commercial, industrial and institutional tends to move towards this new
model of diffusion; because it offers new opportunities of distribution: sharing, alert, push. To
be alerted wisely to seize opportunities is usually the mobile consumer habit.
In order to make more efficient trade on the port area of Cameroon, the Single Window of
operations for Foreign Trade (GUCE) wishes to extend its electronic platform to incorporate
these mobile technologies. This will allow foreign trade operators (importer - exporter) to
follow dematerialized procedures and to be alerted. This thesis aims to design and develop a
mobile solution for monitoring these dematerialized procedures.
To achieve this we made an inventor of actual state and then we selected three notification
channels: email, SMS through Kannel, PUSH notification through Google Cloud Messaging for
Android. For these three notifications channels we designed and implemented systems: A
web application in JEE, an Android application. Our work has resulted in a prototype.
Keywords: Android, mobile solution, notification channels.
iv
SOMMAIRE
DEDICACES ..................................................................................................................................................... i
REMERCIEMENTS ........................................................................................................................................ ii
Resume ......................................................................................................................................................... iii
Abstract ......................................................................................................................................................... iv
Sommaire....................................................................................................................................................... v
Liste des figures........................................................................................................................................ vii
Liste des tableaux ...................................................................................................................................... ix
Liste des acronymes................................................................................................................................... x
INTRODUCTION GENERALE .................................................................................................................. 13
Contexte................................................................................................................................................................... 13
Problème et positionnement ........................................................................................................................... 13
Objectifs ................................................................................................................................................................... 14
Plan du mémoire .................................................................................................................................................. 14
Chapitre I: ETAT DES LIEUX ....................................................................................................... 15
I.1 Analyse Thématique.......................................................................................................................... 16

I.1.1 Circuit global de commerce extérieur ............................................................................... 16
I.1.2 La plateforme électronique e-GUCE ................................................................................... 20
I.2 Etat des lieux des technologies ..................................................................................................... 21
I.2.1 Les plateformes mobiles ......................................................................................................... 21
I.2.2 Les moyens de Notification ................................................................................................... 22
I.2.3 Les passerelles SMS .................................................................................................................. 24
Chapitre II: LA CONTRIBUTION .................................................................................................. 26
II.1 Gestion du projet ................................................................................................................................ 27

II.2 Analyse ................................................................................................................................................... 27
II.2.1 Les besoins de l’utilisateur .................................................................................................... 27
II.2.2 Vision globale de la solution.................................................................................................. 27
II.2.3 Architecture fonctionnelle de la solution ......................................................................... 27
II.2.4 Besoins fonctionnels ................................................................................................................ 29
II.2.5 Besoins non fonctionnels........................................................................................................ 29
v
II.2.6 Cas d’utilisation .......................................................................................................................... 30
II.3 Conception ............................................................................................................................................ 42
II.3.1 Application web ......................................................................................................................... 42
II.3.2 Application Android ................................................................................................................. 47
II.4 Besoins en composants .................................................................................................................... 49
II.4.1 Besoins en services web ......................................................................................................... 49
II.4.2 Composant de notification via web services................................................................... 50
Chapitre III: IMPLEMENTATION ................................................................................................. 51
III.1 Déploiement au GUCE .................................................................................................................. 52

III.2 Présentation des outils utilisées .............................................................................................. 53
III.2.1 Système de gestion de base de données....................................................................... 53
III.2.2 Outils de modélisation......................................................................................................... 53
III.2.3 Environnement de développement................................................................................ 53
III.2.4 Les tests..................................................................................................................................... 53
III.3 Les technologies utilisées ........................................................................................................... 54
III.3.1 Android ..................................................................................................................................... 54
III.3.2 Java Enterprise Edition (JEE) ........................................................................................... 56
III.4 Les Frameworks et librairies utilisées................................................................................... 58
III.5 Présentation du prototype. ........................................................................................................ 59
III.5.1 Android ..................................................................................................................................... 59
III.5.2 Application web ..................................................................................................................... 63
III.6 Faisabilité économique ................................................................................................................ 63
CONCLUSION .............................................................................................................................................. 64
Synthèse .................................................................................................................................................................. 64
Limites et Perspectives. ..................................................................................................................................... 64
BIBLIOGRAPHIE........................................................................................................................................ 65
vi
LISTE DES FIGURES
Figure 1 : Les partenaires du commerce extérieur du GUCE et taux de couverture ...................... 13
Figure 2: Circuit logistique du commerce extérieur à l'import .............................................................. 16
Figure 3: Circuit logistique du commerce extérieur à l'import .............................................................. 17
Figure 4: Les formalités de commerce extérieur à l'import .................................................................... 18
Figure 5: Les formalités de commerce extérieur à l'export ..................................................................... 19
Figure 6: Circuit global de commerce extérieur. .......................................................................................... 20
Figure 7: Plateforme de l’e-GUCE ....................................................................................................................... 21
Figure 8:Architecture fonctionnelle de la communication via e-mail ................................................. 22
Figure 9:Architecture fonctionnelle de la communication via SMS .................................................... 23
Figure 10:Architecture fonctionnelle notification push ........................................................................... 24
Figure 11:utilisation d'une passerelle SMS .................................................................................................... 24
Figure 12:Architecture fonctionnelle de la passerelle KANNEL ............................................................ 25
Figure 13:Vision globale de la solution ........................................................................................................... 27
Figure 14:Architecture fonctionnelle de la solution................................................................................... 28
Figure 15:Diagramme de cas d'utilisation de l'application web............................................................ 31
Figure 16:Diagramme de séquence de l’application web - Envoie d'une notification .................. 32
Figure 17:Diagramme de séquence de l'application web - Traitement de message...................... 32
Figure 18:Diagramme de séquence de l'application web - Réception de message ........................ 33
Figure 19:Diagramme de séquence de l'application web - Valider les enregistrements ............. 33
Figure 20:Diagramme de séquence de l'application web - Authentification .................................... 34
Figure 21:Diagramme de séquence de l'application web - transférer la demande ........................ 34
Figure 22:Diagramme de séquence de l'application web - Demande information ........................ 35
Figure 23:Diagramme de cas d'utilisation de l'application Android.................................................... 36
Figure 24:Diagramme de séquence de l'application Android - Se connecter ................................... 37
Figure 25:Diagramme de séquence de l'application Android - S'enregistrer ................................. 37
Figure 26:Diagramme de séquence de l'application Android - Souscrire au service push ......... 38
Figure 27:Diagramme de séquence de l'application Android - Lier ses informations de
notification.................................................................................................................................................................. 39
Figure 28:Diagramme de séquence de l'application Android - Ajout/Modifier profil .................. 40
Figure 29:Diagramme de séquence de l'application Android - Suivre dossier/marchandise ... 41
Figure 30:Diagramme de séquence de l'application Android - Notifier ............................................. 42
Figure 31:Architecture 3 tiers de l'application web ................................................................................... 43
Figure 32:Diagramme de classe - Communication engine ....................................................................... 43
Figure 33:Diagramme de classe - Module liaison e-GUCE........................................................................ 44
Figure 34:Diagramme de classe - Notification engine ............................................................................... 45
Figure 35:Modèle de données - Couche d'accès aux données ................................................................ 46
Figure 36:Diagramme de package de l'application web ........................................................................... 47
Figure 37:Diagramme de classe de l'application Android ....................................................................... 48
Figure 38:Diagramme de package de l'application Android ................................................................... 49
Figure 39:Schéma de définition XML - Message de notification ............................................................ 50
vii
Figure 40:Architecture de déploiment ............................................................................................................ 52
Figure 41:Architecture du système Android ................................................................................................. 54
Figure 42: Les conteneurs d'une application JEE - Conteneur web & conteneur EJB ................... 57
Figure 43:Architecture du premier prototype.............................................................................................. 59
Figure 44:Présentation prototype Android - connexion, enregistrement d'un utilisateur......... 60
Figure 45:Présentation du prototype Android - Enregistrement du chargeur................................ 60
Figure 46:Présentation prototype - Consultation manifeste - 1 ............................................................ 61
Figure 47:Présentation prototype - Consultation maniteste - 2 ............................................................ 61
Figure 48:Présentation prototype - Tracking conteneur ......................................................................... 62
Figure 49:Présentation prototype - Prévision escale................................................................................. 62
Figure 50:Présentation prototype notification de connaissement via email ................................... 63
viii
LISTE DES TABLEAUX
Tableau 1: Plateforme mobiles ........................................................................................................................... 22
Tableau 2: Les autres composants d'une application Android .............................................................. 55
Tableau 3: Distribution des versions d'Android .......................................................................................... 56
ix
LISTE DES ACRONYMES
API Application Programming Interface
AGL Atelier de Génie Logiciel
AVD Android Virtual Device
AT-FT Admission Temporaire Fiche Technique
BESC Bordereau Electronique de Suivi de Cargaison
BGFT Bureau de Gestion de Fret Terrestre
CAD Commissionnaire Agréé en Douane
CAH Certificat d’Assurance Harmonisé
CAMRAIL Cameroon Railway
CIMD Computer Interface to Message Distribution
DDM Déclaration en Détail des Marchandises
DI-E Déclaration d’Import-Export
DSI Département/Direction des Systèmes d’Information
DSM Direction du Service Matériel (devenu DDM)
EJB Enterprise Java Bean
FIMEX Fichier d’Importateur Exportateur.
GSM Global System for Mobile communication
GUCE Guichet Unique des opérations de Commerce Extérieur
HTTP HyperText Transfer Protocol
HTTPS HyperText Transfer Protocol Secure
IP Internet Protocol
ISP Internet Service Provider
JSON JavaScript Object Notation
LVI Lettre de Voiture Internationale
MINCOMMERCE Ministère du Commerce
MINFOF Ministères des Forêts et de la Faune
ONCC Office Nationale des Chargeurs du Cameroun
OS Operating System
POJO Plain Old Java Object
RPAD Redevance PAD
PAD Port Autonome de Douala
REST Representational State Transfer
RMI Remote Method Invocation
SDK Software Development Kit
SEPBC Société d’Exploitation Parcs à Bois du Cameroun
SGS Société Générale de Surveillance
SMPP Short Message Peer to Peer
SMS Short Message Service
SMSC Short Message Service Center
SOAP Simple Object Access Protocol
TCP Transport Control Protocol
x
WAP Wireless Application Protocol
USSD Unstructured Supplementary Service Data
XSD XML Schema Definition
XML eXtensible Markup Language
xi
INTRODUCTION GENERALE
Contexte
Le manque d’efficacité dans l’accomplissement des formalités liées au commerce extérieur
a incité le Gouvernement camerounais à s’engager dans le processus de dématérialisation des
procédures de commerce extérieur en se dotant d’un guichet unique : le GUCE.
Le GUCE est une entreprise parapublique dont l’objectif est la réduction des coûts et délais
de passage des marchandises au Port Autonome de Douala. Elle est dotée d’une plateforme
électronique nommée e-GUCE qui a été conçue pour apporter des améliorations significatives
dans le déroulement des formalités et procédures.
Cette plateforme interconnecte différents partenaires du commerce extérieur : banques,

douane, SGS, Services phytosanitaires, ONCC, services des changes, Trésor, PAD ; et échange
avec eux des informations relatives aux formalités dématérialisées nécessaires pour une
opération de commerce international. Ces informations dématérialisées sont d’ordre
administratif, technique, douanier et de transport.
La figure 1 ci-dessous illustre les partenaires (services) du commerce extérieur

interconnectés au GUCE et le taux d’interconnexion.
Figure 1 : Les partenaires du commerce extérieur du GUCE et taux de couverture
Problème et positionnement
Dans la chaine de processus de commerce international, l’exportateur accomplit les
formalités d’exportation puis expédie sa marchandise et transmet des documents qui y sont
liés à l’importateur ou son représentant qui, dès lors, voit un commissionnaire agrée en
douane ou un transitaire pour suivre et accomplir les procédures d’exportation liées à cette
marchandise.
13
L’Ecole Nationale Supérieure Polytechnique de Yaoundé (ENSP).
Pour les procédures déjà dématérialisées, l’importateur, l’exportateur, le CAD et le
Transitaire se connectent à la plateforme e-GUCE. Pour pouvoir accomplir des opérations
liées aux procédures (consultation, soumission de pièces jointes, etc…). Les dossiers soumis
sont traités électroniquement par les différents partenaires du GUCE et mises à jour sur la
plateforme.
Pour suivre ses dossiers (procédures), l’opérateur1 est obligé de se connecter sur cette
plateforme pour consulter les rapports associés. Il n’y a pas de système d’alerte pour
l’informer de la suite sur ses dossiers et de ses marchandises. Ainsi il ne peut pas anticiper et
entreprendre des actions appropriées dans les délais.
Objectifs
Afin de solutionner ce problème, le GUCE a émis un besoin d’une solution mobile lui
permettant de doter l’opérateur d’un outil efficace pour le suivi des traitements électroniques
de ses dossiers. Cet outil devra générer des alertes en fonction de la nature des opérations et
des décisions.
Il s’agit pour nous de proposer une architecture de cette solution en identifiants les
composants et leurs interactions, puis de la valider en implémentant une version exploitable.
Plan du mémoire
La suite du mémoire est structurée ainsi qu’il suit :
 Le Chapitre I intitulé « Etat des lieux », fait un tour d’horizon sur le circuit du
commerce extérieur pour en donner une vision globale et permettre de comprendre
les concepts du domaine et d’analyser le fonctionnement du système en place.
 Le chapitre II intitulé « La contribution », présente les spécifications et la conception
de la solution proposée.
 Le chapitre III intitulé « Implémentation », présente le prototype de la solution
conçue dans le chapitre II et les outils utilisés pour la réalisation de ce prototype. Il
illustre les résultats des tests effectués et présente aussi comment la solution s’intègre
dans l’environnement cible pour son exploitation.
1 Dans ce document il est identifié comme l’importateur ou exportateur d’une marchandise. Une autre
désignation dans ce document est le « chargeur ».
14
CHAPITRE I: ETAT DES LIEUX
15
Chapitre I: ETAT DES LIEUX
I.1 Analyse Thématique
I.1.1 Circuit global de commerce extérieur

Le commerce extérieur se matérialise par de nombreux échanges de marchandises entre
divers pays. Ces marchandises importées ou exportées suivent un itinéraire composé d’une
succession d’opérations logistiques (transport, manutention, stockage) et d’une succession
d’opérations administratives. Ceci en respectant les normes internationales
I.1.1.1. Circuit logistique

Le circuit logistique désigne l’ensemble des ressources nécessaires au transport physique
des marchandises.
Tout commence éventuellement avec la vente et la livraison d’une marchandise par une
usine de fabrication au lieu voulu par l’exportateur. L’exportateur en possession de sa
marchandise ouvre éventuellement un ordre de transit chez son transitaire et lui confie sa
marchandise et les documents relatifs à la vente de sa marchandise (Certificat Origine, fiche
technique).
Le transitaire peut alors recourir à un transporteur routier (s’il ne dispose pas de la

logistique de transport) pour assurer le transport de sa marchandise jusqu’ au consignataire
où sa marchandise va être entreposée. Le transitaire va devoir accomplir des formalités
relatives au dédouanement à l’export.
Le consignataire conteneurise (groupe avec d’autres marchandises) la marchandise. La

marchandise quitte le parc du consignataire pour être déposée au quai où l’acconier s’occupe
de sa manutention de vers le navire affrété par l’armateur. Le navire quitte le quai vers le port
de destination.
La figure 2 ci-dessous illustre le circuit logistique d’une marchandise depuis l’usine

jusqu’au port.
Figure 2: Circuit logistique du commerce extérieur à l'import
16
Arrivé au port de destination, l’acconier s’occupe du déchargement du navire. Le

consignataire entre en possession des colis parmi lesquels figure la marchandise destinée à
l’importateur.
Etant en communication avec son exportateur, l’importateur avisé sur la date d’arrivée de
sa marchandise peut se rendre chez un transitaire pour conclure un ordre de transit en lui
confiant les documents transmis par son exportateur. Le transitaire effectue les formalités de
dédouanement et d’importation pour son client.
Une fois les formalités administratives et douanière accomplies, le transitaire entre au port
accompagné d’un transporteur avec qui il aurait conclu un contrat de transport, ressort du
port en possession de la marchandise. La marchandise est alors acheminée au lieu de
l’exportateur. Ce dernier rentre alors en possession de sa marchandise.
La figure 3 présente le circuit logistique d’une marchandise à l’import depuis l’arrivée au

port de destination jusqu’à l’importateur.
Figure 3: Circuit logistique du commerce extérieur à l'import
Le passage des marchandises à travers les différents services logistiques est assuré par des
formalités et procédures.
I.1.1.2. Procédures et formalités

Ce sont des démarches obligatoires à respecter par un importateur (respectivement
exportateur) pour respectivement importer (respectivement exporter) sa marchandise. On
distingue à l’export comme à l’import des formalités administratives, des formalités de
dédouanement, des formalités d’avis et contrôle technique et des formalités de transport
maritime
A l’import
La figure qui suit présente les procédures à accomplir pendant l’importation. Ces
procédures sont matérialisées par des rectangles avec en titre la procédure à accomplir, en
bas du titre et à gauche est le partenaire auprès duquel l’importateur effectue la procédure. Le
numéro indique l’ordre d’exécution de la procédure. Les flèches indiquent l’enchaînement
entre les procédures.
17
Figure 4: Les formalités de commerce extérieur à l'import
A l’export
La figure qui suit présente les procédures à accomplir pendant l’exportation. Ces
procédures sont matérialisées par des rectangles avec en titre la procédure à accomplir, en
bas du titre et à gauche est le partenaire auprès duquel l’exportateur effectue la procédure. Le
18
numéro indique l’ordre d’exécution de la procédure. Les flèches indiquent l’enchaînement

entre les procédures.
Figure 5: Les formalités de commerce extérieur à l'export
De manière générale le circuit logistique peut être décomposé en sous-circuits, chacun avec
des formalités définies, comme le montre la figure 6.
19
Figure 6: Circuit global de commerce extérieur.
I.1.2 La plateforme électronique e-GUCE

Le Guichet Unique électronique est une plate-forme informatique qui met en relation de
manière virtuelle les différents acteurs du commerce extérieur. Elle comprend :
 Une plateforme d'échange des données électroniques dont le rôle est d'héberger et
de permettre l'exécution des procédures dématérialisées.
20
 Un portail web communautaire de services permettant aux usagers (Importateur /

Exportateur, CAD, Transitaires) d'accéder aux différents services mis en œuvre par le
GUCE au rang desquels l'exécution des procédures dématérialisées ;
 Un réseau de télécommunication dont le rôle est d'assurer l'interconnexion du e-
GUCE avec les principaux acteurs des procédures du commerce extérieur
(administrations, services techniques, banques, etc.) ;
 Un infocentre servant à la production de diverses statistiques.
Figure 7: Plateforme de l’e-GUCE
Parmi les formalités et procédures dématérialisées en production nous avons :
 Contrôle d'Identification des Véhicules Importés D'Occasion (CIVIO) ;

 Simulateur des droits et taxes en douane ;
 Certificat d'Assurance Harmonisé (CAH) ;
 Déclaration d'Importation du Ministère du Commerce ;
 Paiement Electronique ;
 Manifeste ;
 Inscription au Fichier des Importateurs et Exportateurs (FIMEX) ;
 BESC ;
 Redevance PAD ;
 Formulaire unique d'Importation des Véhicules d'Occasion (PIVO).
Pour suivre ses dossiers l’importateur ou l’exportateur se connecte sur la plateforme via le
portail communautaire avec son navigateur web pour consulter ses dossiers.
I.2 Etat des lieux des technologies
I.2.1 Les plateformes mobiles

Nous avons répertorié toutes les plateformes mobiles actuelles dans le tableau qui suit.
21
Plateformes Description
Android Plateforme Open Source, SDK gratuit. C’est l’équipement mobile le plus en
vogue aujourd’hui. On le retrouve sous forme de tablettes et smartphones.
BlackBerry C’est une plateforme beaucoup plus utilisé par le gouvernement pour son
aspect sécurité. Il n’est pas à la portée de tous.
IPhone Plateforme propriétaire. Ce sont des appareils hauts gamme et pas à la portée
de tout le monde
Windows Phone Plateforme Mobile de Microsoft. Contrairement aux logiciels sur PC, les
appareils Windows Phone ne sont pas beaucoup utilisés. La plateforme
Windows Phone est propriétaire.
J2ME C’est la plateforme java pour les téléphones limités. Une vieille technologie
qui est trop couteuse dans l’implémentation
Tableau 1: Plateforme mobiles
Android s’avère être un choix adapté à nos besoins. Car il est open source et très répandu.
I.2.2 Les moyens de Notification

I.2.2.1. Le Courier électronique
C’est un moyen de communication, où les utilisateurs s’envoient des messages
électroniques à travers internet en utilisant une suite de protocoles reposant sur le protocole
TCP/IP.
L’expéditeur envoie un message (texte éventuellement avec des fichiers joints) avec son
compte de messagerie en utilisant un client de messagerie. Le message est acheminé vers le
serveur de messagerie de son fournisseur d’accès internet (FAI), puis routé sur internet vers
le serveur de messagerie du destinataire. Le destinataire utilise son client pour interroger son
serveur de messagerie, ensuite télécharge et lit le message.
Figure 8:Architecture fonctionnelle de la communication via e-mail
La notification par email est un choix convenable car il permet la réception des messages,
et est indépendante de l’appareil utilisé. Il suffit que cet appareil intègre un client de
messagerie et puisse se connecter à internet. Le destinataire peut ainsi lire ses emails quel
que soit le lieu où il se trouve.
22
I.2.2.2. Le SMS
Le SMS (Short Message Service) est une méthode de communication mise à la disposition
des Téléphone Mobile par un opérateur de téléphone mobile. Il consiste en l’envoie des
messages courts (maximum 160 caractère) de l’expéditeur vers le destinataire à travers le
réseau téléphonique de l’opérateur.
La figure 9 ci-dessous illustre l’architecture fonctionnelle pour une communication SMS.
Figure 9:Architecture fonctionnelle de la communication via SMS
I.2.2.3. Les appels téléphoniques

Un appel téléphonique est un échange de données sonores entre un appelant et un
destinataire. L’échange ne peut se faire lorsque le destinataire accepte de décrocher le
téléphone. Ce moyen présente des inconvénients du fait que les appels téléphonique peuvent
être bruyants et parfois indésirable selon les circonstances ; de plus la fiabilité de réception
du message n’est pas toujours garantie.
I.2.2.4. Les modèles de notification sur mobile.

 L’architecture client-serveur par polling: dans ce modèle de communication le client
scrute continuellement le serveur pour s’assurer de la disponibilité des données. Pour
les télécharger ensuite. Ce modèle de notification n’est pas envisageable car elle a
beaucoup d’inconvénients pour les équipements mobiles :
o Consommation de la bande passante.
o Consommation des ressources matérielles. Déjà les appareils mobiles sont
limités en ressources.
o Consommation de batterie.
 Notification Push est un mode de communication client-serveur dans lequel le dialogue
est lancé par le serveur. Le serveur envoie des messages au serveur de notification. Et
lui laisse toute la charge de synchronisation et d’envoie chez le destinataire.
23
Figure 10:Architecture fonctionnelle notification push
I.2.3 Les passerelles SMS

Une passerelle SMS est un ensemble d’infrastructures logicielles et matérielles permettant
d’interfacer un système d’information d’une entreprise avec le réseau téléphonique d’un
l’opérateur. Cet interfaçage permet d’exposer des services d’une entreprise via le canal SMS
de l’opérateur. L’usager d’un téléphone mobile accède aux services passivement en recevant
des informations ou activement en envoyant des SMS au numéro de l’entreprise. La figure 11
est une illustration. Les éléments constitutifs sont :
1- Un ensemble d’applications chargées d’offrir des services (contenus) mobiles.

2- Un ensemble de logiciels installés sur un serveur de l’entreprise. Elle traite le message
envoyé par les applications de l’entreprise, puis les transfère au SMSC de l’opérateur
téléphonique en utilisant un canal ou protocole (SMPP, CIMD, etc…)
3- Le SMSC : c’est le système chargé de fournir des SMS aux clients de l’opérateur. Tout
SMS envoyé sur le réseau téléphonique passe impérativement par le SMSC.
4- Les clients : ce sont des périphériques mobiles connectés sur le réseau téléphonique de
l’opérateur.
1 2 3 4
Figure 11:utilisation d'une passerelle SMS
I.2.3.1. Cas de KANNEL

KANNEL est une passerelle SMS et WAP Open source et écrite en C. Elle permet d’envoyer
des messages aux entités extérieures, de recevoir des SMS ou des requêtes venant de ces
entités, puis d'envoyer des réponses après traitement sur la plateforme. La plateforme est
constituée d’un serveur linux sur lequel des paquets nécessaires sont installés, un modem
24
GSM qui permet au serveur de communiquer avec un téléphone GSM sur le réseau d’un
opérateur téléphonique.
La figure 12 illustre l’architecture fonctionnelle de la passerelle KANNEL.
Figure 12:Architecture fonctionnelle de la passerelle KANNEL
Le GUCE utilise KANNEL pour envoyer des notifications à certains partenaires. L’utilisation
de KANNEL s’avère un choix favorable pour nous pour une intégration future.
Nous avons fait une analyse thématique, pour mieux assoir notre compréhension du
domaine. Ensuite nous avons présenté les solutions potentielles qui s’offrent à nous pour la
résolution de notre problème. Les solutions retenus sont donc l’e-mail, le SMS, le PUSH pour
les notifications et Android comme la plateforme mobile de notre solution.
25
Chapitre II: LA CONTRIBUTION
CHAPITRE II: LA CONTRIBUTION
26
II.1 Gestion du projet

La gestion du projet il nous a été suggéré d’utiliser Scrum. Scrum est un Framework itératif
et incrémental reposant sur la méthode agile. Le projet a des caractéristiques qui le rendent
candidat pour être géré par Scrum : Le projet est complexe et est sujet à des changements
dans les spécifications.
II.2 Analyse
II.2.1 Les besoins de l’utilisateur

Les lignes qui suivent décrivent les besoins identifiés pour le chargeur2.
 Minimiser ses multiples déplacements relatifs à ses activités d’import et export au

niveau du port via un volet informations.
 Etre Notifié sur l’arrivée des marchandises et avoir des détails sur les coûts de
dédouanement.
 Suivre ses dossiers et son évolution. Afin de réagir rapidement aux actions à
entreprendre
 Avoir un guide éventuellement adapté pour le suivi de sa marchandise car le chargeur
actuel peut ne pas avoir une idée sur les formalités de dédouanement.
II.2.2 Vision globale de la solution
Figure 13:Vision globale de la solution
Des que de nouvelles informations relatives aux procédures concernant le chargeur sont
traitées et disponible au niveau du e-GUCE (réception manifeste, dossiers) elles sont
envoyées à l’application web ou elles sont traitées et envoyées via les canaux de notifications
choisie par le chargeur. Le chargeur peut alors éventuellement demander des informations
avec un client (Android + téléphone).
II.2.3 Architecture fonctionnelle de la solution

La figure 14 qui suit présente l’architecture fonctionnelle de la solution.
2 Personne mentionnée dans le connaissement. Le plus souvent l’importateur ou l’exportateur d’une

marchandise.
27
Figure 14:Architecture fonctionnelle de la solution
L’application web déployée sur un serveur et communique avec le GUCE par des services
web (liaison 1).
Le serveur KANNEL permet à l’application web d’envoyer des notifications à travers le

réseau GSM d’un opérateur téléphonique (liaison 6 et 7). KANNEL communique avec le
serveur d’application avec la liaison 5.
2 -3 matérialise le processus des notifications pour le cas des Smartphones Android via le
Cloud de Google (Google Cloud Messaging). La liaison 4 matérialise l’interrogation d’un
service Web (L’interrogation peut être éventuellement due à une notification.
La liaison 8 matérialise la liaison du serveur avec le PC du chargeur.
Coté chargeur, nous distinguons 3 classes d’usagers
 L’utilisateur d’un PC : Il utilise son PC et se connecte à la plateforme web à l’aide d’un

navigateur web.
 L’utilisateur d’un téléphone cellulaire : le chargeur possédant un téléphone cellulaire.
Ce dernier reçoit des notifications et il peut se peut éventuellement qu’on lui fournisse
des services basiques à travers l’envoi des SMS ou l’utilisation de l’USSD.
28
 L’utilisateur d’appareils Android : chargeur possédant un Smartphone Android sur

lequel est déployé un client qui reçoit des notifications. Le chargeur peut effectuer des
actions relatives à ces notifications.
II.2.4 Besoins fonctionnels

L’application doit permettre au chargeur de pouvoir
 visualiser la liste de ses dossiers.

 Afficher les détails de dossiers.
 Afficher la liste des marchandises, connaissements,
 Afficher les détails des marchandises.
 Notifier sur les dossiers validés
 Notifier sur les escales des navires des marchandises de l’utilisateur
 Notifier le chargeur sur l’arrivée de ses marchandises.
 Fournir un guide pour le chargeur sur l’accomplissement des procédures.
II.2.5 Besoins non fonctionnels

II.2.5.1. Interface utilisateur et facteur humain
Les interfaces entre le serveur de l’application web et les autres systèmes adjacents sont
des services web qui vont assurer la liaison et l’échange des données.
L’interface entre le système et l’utilisateur est
 Soit une application Android qui va offrir des actions à l’usager à travers des menus, les
champs, etc... pour accomplir tous ses besoins.
 Soit un cellulaire GSM qui n’offrira que des notifications GSM, et éventuellement la
consultation
 Soit un navigateur web disponible sur son pc qui lui permettra d’effectuer ses
opérations.
II.2.5.2. Considération matérielle
Le système mobile va être déployé sur le téléphone de l’usager qui est de préférence un
téléphone Android ;
L’application web sera hébergée sur un serveur d’application.
II.2.5.3. Caractéristique de performance

L’application Android sera conçue en tenant compte des capacités limitées des appareils
mobile en termes de mémoire et capacité de traitement. Une base de données locale au sein
de l’application Android devra être envisagée pour le stockage temporaire et la consultation
hors ligne des données téléchargées depuis l’application web ; ou le stockage local des
transactions effectuées depuis un smartphone ou une tablette du chargeur. Tout ceci afin
d’optimiser le trafic et assurer la robustesse du système.
29
II.2.5.4. Gestion des erreurs et conditions extrêmes

L’application web doit gérer les erreurs et doit continuer de fonctionner même pendant la
monté en charge du système.
II.2.5.5. Problème de sécurité

Vu le caractère confidentiel des données de la plateforme e-GUCE, l’application web sera
hébergée au sein des locaux du guichet unique et bénéficiera de toute la logistique de sécurité
dont cette dernière dispose.
Les utilisateurs de l’application Android devront s’authentifier auprès de l’application web.

Des mesures de sécurité devront être prises pour gérer l’accès des chargeurs appartement à
une même organisation.
Vu que les notifications Android vont passer sur le Cloud de Google, il va de soi que ce
Cloud Provider aura les notifications transmises en clair. Il est dont crucial d’utiliser des
mécanismes de cryptage et décryptage.
II.2.5.6. Environnement physique

L'application web (e-Chargers) est une application qui sera chargée de fournir des services
aux chargeurs via leur téléphone mobile. L’application web sera hébergée dans les locaux du
guichet unique sur un serveur d’application et va interagir avec le système e-GUCE par
échange de messages.
II.2.6 Cas d’utilisation

La solution est composée d’un système principal, le serveur d’application qui est le
carrefour d’interconnexion avec d’autres systèmes. Pour les deux nouveaux systèmes :
application web, applications Android une analyse va être menée selon le formalisme UML.
II.2.6.1. Application web
Acteurs
 Administrateur : c’est un agent du guichet qui va vérifier et valider les
enregistrements du chargeur.
 e-GUCE : c’est la plateforme électronique du GUCE. Il participe dans l’échange des
messages avec l’application web.
 Client chargeur : c’est le système du chargeur, le client qu’il utilise pour interagir avec
l’application web.
 Notification system : c’est un système distant de notification : dans notre cas ça peut
être une passerelle SMS, un serveur de messagerie, ou le système de notification push
d’Android.
Les cas d’utilisation

La figure ci-dessous illustre les cas d’utilisation pour l’application web. Nous allons donc
détailler chaque cas d’utilisation.
30
uc Primary Use Cases
Application Web e_Chargers
Administrateur
Valider les
enregistrement Authentification
«include»
Demande Transferer
Client chargeur Information «include» demande
e-GUCE
Reception
Message
Env oie
e-GUCE notification
«include»
«include»
Notification System
Traitement
message
Figure 15:Diagramme de cas d'utilisation de l'application web
Cas d’utilisation : Envoi notification

Acteur Notification system
Description Le système envoie une notification au chargeur sur les canaux de notification
qu’il aurait choisis.
Pré traitement message.
condition
Scenario nominal :
Acteur Système
1. Envoie une notification relative à un
message préalablement traité.
2. Envoie un acquittement.
31
sd Env oie notification
Application Web Notification

System
Notify(Message)
Figure 16:Diagramme de séquence de l’application web - Envoie d'une notification
Cas d’utilisation : Traitement message

Acteur
Description Le système traite un message et l’adapte selon les canaux de notification.
Pré Réception message
condition
Scenario nominal :
Acteur Système
1. Le système traite le message reçu de
l’e-GUCE, puis procède à la
notification
sd Traitement message
Application Web
requêteBD(Charger)
ref
Env oie notification(Message)
Figure 17:Diagramme de séquence de l'application web - Traitement de message
Cas d’utilisation : Réception message

Acteur e-GUCE
Description Le système reçoit un message de l’e-GUCE
Pré
condition
32
Scenario nominal
Acteur Système
1. Envoie Un message 2. Reçoit le message, le sauvegarde et
lance un accuse réception
3. Procède ensuite au traitement
sd Reception Message
e-GUCE Application Web
depot(Message)
ACK()
ref
Traitement message(Message)
Figure 18:Diagramme de séquence de l'application web - Réception de message
Cas d’utilisation : valider les enregistrements

Acteur Administrateur
Description L’administrateur valide le profil du chargeur sur le système après avoir
vérifié si le numéro de la carte contribuable est celle du système.
Pré
condition
Scenario nominal
Acteur Système
1. Interroge le système en recherchant 2. Retourne les informations du
l’identité du chargeur chargeur
3. Vérifie la carte contribuable et valide 4. Fait la mise à jour et retourne un
l’identité du chargeur acquittement à l’administrateur.
sd Valider les enregistrement
Administrateur Application Web
demandeProfil(Chargeur)
valide(Chargeur)
Figure 19:Diagramme de séquence de l'application web - Valider les enregistrements
33
Cas d’utilisation : Authentification

Acteur
Description L’application client du chargeur s’authentifie auprès de l’application web.
Les données d’authentification sont prélevées sur les paramètres passées
dans la requête
Pré Demande information
condition
Scenario nominal
Acteur Système
1. Authentifie le client.
sd Authentification
Module
d'authentification
Application Web
Authentifier((credentiels_chargeur)
Figure 20:Diagramme de séquence de l'application web - Authentification
Cas d’utilisation : transférer demande

Acteur e-GUCE
Description La demande de l’application client est transformée et transférée
Pré Demande information
condition
Scenario nominal
Acteur Système
1. Transfère la requête à l’e-GUCE
2. Reçoit la requête et retourne le 3. Reçoit la formater pour retourner la
résultat réponse à la demande d’information.
sd Transferer demande
Application Web e-GUCE
demandeInformation(IdDossier)
:Object
Figure 21:Diagramme de séquence de l'application web - transférer la demande
34
Cas d’utilisation : demande information

Acteur Client chargeur
Description L’application client demande des informations relatives au suivi de dossiers
et au suivi des marchandises.
Pré
condition
Scenario nominal
Acteur Système
1. Demande information sur dossier 2. Le système reçoit la requête, délègue
une authentification et un transfert de
demande, puis retourne le résultat
récolté.
sd Demande Information
Client chargeur Application Web
requête(Object)
ref
Authentification(crédentiels_chargeur)
ref
Transferer demande(Reference_Chargeur)
:InformationDemandée
Figure 22:Diagramme de séquence de l'application web - Demande information
II.2.6.2. Système Android
Acteur
Parmi les acteurs du système on compte :
 L’administrateur chargeur : le chargeur peut être une personne physique ou une

personne morale. Pour le cas d’une personne morale il faudrait. Une personne qui
puisse gérer ce profil pour assurer la confidentialité au sein de l’organisation du
chargeur. C’est lui qui communique les informations de connexion au personnel.
 Le chargeur : C’est une autre personne pour le cas où un chargeur est une personne
physique
Les cas d’utilisation

La figure 23 qui suit représente les cas d’utilisation recensé sur le système Android qui
seront détaillés à la suite.
35
uc Use Case Model
Application android
Aj outer/Modifier
profil
Administrateur chargeur S'enregistrer
«extend»
lier
informations
notifcations
«extend»
Souscrire push
Se connecter
chargeur
Suiv re Notifier
dossier/Marchandises «extend»
Figure 23:Diagramme de cas d'utilisation de l'application Android
Cas d’utilisation : se connecter

Acteur Chargeur.
Description Au premier lancement de l’application, le chargeur se connecte en utilisant
les informations que lui aurai transmis l’administrateur.
Pré
condition
Scenario nominal
Acteur Système
1. Soumet les informations de 2. Le système déclenche l’opération de
connexion. connexion à l’application web.
36
sd Se connecter
chargeur Application Application web

Android
connexion(crédentiels_chargeur)
demandeConnexion(crédentiels)
Figure 24:Diagramme de séquence de l'application Android - Se connecter
Cas d’utilisation : S’enregistrer

Acteur Administrateur chargeur.
Description Le chargeur s’enregistre saisie ses informations et déclenche l’opération
d’enregistrement sur l’application.
Pré
condition
Scenario nominal
Acteur Système
1. Soumet les informations 2. Effectue l’enregistrement sur le
d’enregistrement serveur distant hébergeant
l’application web
sd S'enregistrer

Android
Enregistrement(info_chargeurs)
demandeEnregistrement(info_chargeurs)
Figure 25:Diagramme de séquence de l'application Android - S'enregistrer
37
Cas d’utilisation : Souscrire au service push.

Acteur Service push.
Description L’application Android souscrit au service push et reçoit la configuration pour
le service PUSH.
Pré
condition
Scenario nominal
Acteur Système
1. Envoie une requête d’abonnement au
service.
2. Fourni les configurations pour 3. Reçoit et sauvegarde les paramètres.
recevoir les notifications push.
sd Souscrire au push
e-Chargers Android Service push

android
souscrire()
:id_souscription
save(paramètres)
Figure 26:Diagramme de séquence de l'application Android - Souscrire au service push
Cas d’utilisation lier information de notification
Acteur Administrateur chargeur.

Description L’administrateur chargeur ouvre la fenêtre de soumission des contacts de
notifications, sélectionne les canaux de notifications.
Pré
condition
Scenario nominal
Acteur Système
1. Soumet les contacts de notification. 2. Déclenche éventuellement
l’enregistrement au service push.
3. Déclenche l’enregistrement des
contacts et canaux de notifications au
niveau de l’application web.
38
sd lier informations notifcations
Administrateur chargeur Application Application web

Android
soumettre(ContactsNotification)
opt
ref
Souscrire au push(Id)
updateContact(id_souscription)
soumettre(ContactNotification)
Figure 27:Diagramme de séquence de l'application Android - Lier ses informations de notification
Cas d’utilisation : Ajouter/Modifier profil

Acteur Administrateur.
Description L’administrateur change les informations (numéro contribuable, nom
utilisateur, etc…).
Pré
condition
Scenario nominal
Acteur Système
1. Soumet son profil actualisé. 2. Déclenche éventuellement la liaison
des informations de notification. Puis
effectue l’actualisation du profil
auprès du serveur d’application.
39
sd Aj outer/Modifier profil

Android
miseAJourProfil(nouveau_profil)
opt
ref
lier informations notifcations(nouv eau_profil)
miseAJourProfil(profil)
Figure 28:Diagramme de séquence de l'application Android - Ajout/Modifier profil
Cas d’utilisation : suivre dossier/Marchandises

Acteur Chargeur.
Description Le chargeur ouvre son application et navigue sur les rubriques relatives au
suivi de ses dossiers au suivi de ses marchandises.
Pré
condition
Scenario nominal
Acteur Système
1. Clique sur un bouton pour afficher le 2. Affiche les catégories de dossier.
volet dossier
3. Sélectionne une catégorie 4. Affiche les dossiers
5. Sélectionne un dossier spécifique 6. Affiche les documents de ce dossier
7. Sélectionne un document 8. Retourne les détails de ce document
40
sd suiv i dossier_Android
Chargeur Application Application web

android
affiche volet dossier()
demande information()
liste dossier()
affiche catégories de dossier()
selectionner catégorie()
Afficher dossiers()
alt Recherche de dossier spécifique

recherche()
demande critère recherche()
saisie et validation critères()
recherche critère()
liste dossiers()
Selection dossier()
demande information()
liste documents()
Affiche documents()
selection document()
details document()
Figure 29:Diagramme de séquence de l'application Android - Suivre dossier/marchandise
Cas d’utilisation : Notifier

Acteur
Description L’application reçoit une notification stipulant qu’une nouvelle information est
disponible. Extrait les métadonnées puis les utilise pour demander les détails
au serveur distant hébergeant l’application web.
Pré Connexion internet
condition
Scenario nominal
Acteur Système
1. Reçoit une notification
2. Reçoit la requête et retourne le 3. Demande
résultat
41
sd Notifier
Application Service push Application web

android
envoieNotification(message)
notifier()
demande_details_dicuments()
details_documents= :Object
Figure 30:Diagramme de séquence de l'application Android - Notifier
II.3 Conception
II.3.1 Application web

L’architecture de l’application web obéit à une architecture 3 Tiers :
 La couche présentation : cette couche fournie des vues personnalisées au client. Elle
permet de présenter les données aux clients disposant d’un navigateur, et de récupérer
les données à travers les formulaires des pages web.
 La couche métier : Elle correspond à la partie fonctionnelle de l'application, celle
qui implémente la « logique », et qui décrit les opérations que l'application opère sur
les données en fonction des requêtes des utilisateurs, effectuées au travers de la
couche présentation. Cette couche comprend :
 Le Communication engine.
 Le Notification engine.
 Le module de liaison e-GUCE.
 La couche d’accès aux données : elle permet d’extraire ou de stocker les données dans
un système de gestion de base de données.
42
Figure 31:Architecture 3 tiers de l'application web
II.3.1.1. La couche métier :
Composant : communication engine

C’est le module qui est chargé de la communication avec l’application Android et la
passerelle KANNEL. Il reçoit les requêtes puis renvoie les réponses issues d’un traitement en
interne par l’application web.
class communicationEngine
FrontEnd «interface»
Class Model::
+ getContainerMovement() : void IServ ice
+ getFileTracking() : void
+ getForeCastofCall() : void
+ getManifeste() : object
+ registerCharger() : object
+ registerUser() : object
«persistingEntity»
Class Model::Entity
+ create() : void
+ delete() : void
+ fetch() : object
+ update() : void
Figure 32:Diagramme de classe - Communication engine
43
Composant liaison e-GUCE

C’est le module qui est chargé en particulier de la communication avec la plateforme du
GUCE. Il expose les interfaces qui lui permettent de recevoir les notifications provenant de la
plateforme e-GUCE et des requêtes en amont provenant du module de communication.
class liaisonGUCE
«interface»
Class Model::IServ ice
EguceClient
+ getContainerMovements() : object
+ getFileTracking() : object
+ getManifeste() : object
Webserv iceToEguce
+ leaveNotificationMessage() : void
Class Model::Entity
+ create() : void
NotificationMessage + delete() : void
+ fetch() : object
+ update() : void
Figure 33:Diagramme de classe - Module liaison e-GUCE
Le composant Notification engine

C’est le module qui est chargé d’envoyer les notifications aux trois canaux de notification :
Services push tiers Google Cloud Messaging, KANNEL, e-mail.
44
class NotificationEngine
«interface»
INotificationChannel NotificationChannelProcessor
+ FormatMessage() : void
+ handleIncomingMessage() : void
+ sendNotifcationToChannel() : void
1..*
Class Model::Entity
NotificationDispatcher
+ create() : void
+ dispatch() : void
+ delete() : void
1..* 0
+ fetch() : object
+ update() : void
Figure 34:Diagramme de classe - Notification engine
II.3.1.2. Couche accès aux données

Un utilisateur est caractérisé par (core_users). Cet utilisateur peut avoir un compte
(core_account_subscriptions). Le compte est associé à un chargeur spécifique (core_chargers).
Le compte associé à un utilisateur permet d’avoir tous les contacts téléphoniques

(core_mobile_phone), email (core_email), push (core_smartphone). Ce compte permet d’avoir
toutes les notifications reçues (core_notifications).
Des notifications sont typées par la table (core_notification_types) : par exemple, on peut
avoir des notifications des connaissements3, des notifications de suivi de dossiers
(procédures).
La figure 35 ci-dessous est le modèle de donnée de notre application web.
3 C’est un document matérialise le contrat de transport entre le donneur d’ordre et la compagnie maritime.
Dans ce document figure le port d’embarquement, le port de destination, le nom du navire, le nom et l’adresse de
l’expéditeur et du destinataire.
45
Figure 35:Modèle de données - Couche d'accès aux données
II.3.1.3. Diagramme de package

Plus haut nous avons présenté les classes de chaque module. Le diagramme qui suit
présente les packages représentant les modules et les dépendances entre ces modules. Le
46
module liaisonGUCE pour fonctionner a besoin du module AccesDonnées. Il peut

éventuellement avoir besoin des ressources ou référence du NotificationEngine pour envoyer
des notifications. Le communicationEngine pour gérer les requêtes amont provenant des
clients a besoins de la couche AccesDonnées.
La figure 36 ci-dessous présente le diagramme de package.
class WebApp Package diagram
NotificationEngine
communicationEngine
+ NotificationChannelProcessor
+ FrontEnd
+ NotificationDispatcher
+ INotificationChannel
AccesDonnées
liaisonGUCE
+ CoreAccountSubscriptions
+ EguceClient
+ CoreChargers
+ NotificationMessage
+ CoreEmails
+ WebserviceToEguce
+ CoreMobilePhones
+ CoreNotifications
+ CoreNotificationsTypes
+ CoreSmartphones
+ CoreUsers
Figure 36:Diagramme de package de l'application web
II.3.2 Application Android

La figure 37 qui suit est le diagramme de classe de l’application Android. Les composants
inhérents au système Android sont expliqués dans le chapitre III, à la section dédiée à
Android.
Une activité (Activity) peut être composée de plusieurs fragments (Fragment). Nous
fabriquons une classe spéciale ActivityClient qui est un type d’activité (Activity) pouvant
exécuter une Tache (Task). Cette tâche est une opération concrète en background. Un exemple
palpant peut être l’enregistrement d’un utilisateur, une requête de prévision d’escale ou toute
requête de service web. L’ensemble des opérations est géré par la classe RestClient. Notre
classe Task est un type de classe d’Android AsyncTask. AsyncTask est une classe d’Android
permettant de gérer les threads. Notre classe PreferenceManager pour sauvegarder les
paramètres de l’utilisateur Android.
Des classes concrètes de la classe ActivityClient sont les classes RegisterUser,

RegisterCharger, Dashboard qui sont des interfaces utilisateur respectivement pour
l’enregistrement d’un utilisateur, l’enregistrement du chargeur et la fenêtre Dashboard.
47
La classe PushServiceNotificationManager est chargée de gérer les notifications reçues par

l’application Android.
Figure 37:Diagramme de classe de l'application Android
48
class Android_package_Diagram
GUCE_extensionAndroid
+ Files
AndroidCore + Manifeste
+ Activity + MessageReference
+ ActivityClient + NotificationMessage
+ AsyncTask «use»
+ DashBoard
+ Fragment
+ PreferenceManager Communication WS android
+ PushServiceNotificationManager + RestClient
+ RegisterCharger + IRestClient
+ RegisterUser
+ Task
w ebapp_android_extension
+ CoreAccountSubscriptions
+ CoreChargers
+ CoreEmails
+ CoreMobilePhones
+ CoreNotifications
+ CoreNotificationsTypes
+ CoreSmartphones
+ CoreUsers
Figure 38:Diagramme de package de l'application Android
II.4 Besoins en composants

Vu que notre solution est dépendante de la plateforme e-GUCE actuellement en place, un
certain nombre de composants doivent être mis en place au sein de cette plateforme pour
interagir avec notre application web.
II.4.1 Besoins en services web

Des services web vont être développés par la DSI du GUCE. Des séances de travail vont être
arrêtées pour s’accorder sur les différentes entités dont on a besoin. A l’issu de ces séances
des documents détaillants les spécifications de chaque service web vont être livrés. La liste
qui suit est la liste des informations qui vont être fournie par ces services web.
1-Suivi logistique des marchandises
• Tracking de conteneurs
• Escale
• Connaissement
2-Suivi des procédures
• Etat des dossiers / GUCE.
49
II.4.2 Composant de notification via web services

Ce composant va être développé par le GUCE sera chargé d’envoyer des notifications au
service web de réception de notification du composant liaison e-GUCE de notre application
web. Il sera chargé de prendre des données du GUCE et de les formater en messages, puis
d’envoyer ces messages à l’application web.
Ce client doit pouvoir nous envoyer :
• Des notifications d’arrivée des marchandises.

• Des notifications du suivi de dossier.
La structure XSD de la figure 39 qui suit décrit la structure du message que ce composant
doit envoyer à notre application web.
Figure 39:Schéma de définition XML - Message de notification
Nous avons présenté dans ce chapitre la solution globale du système à mettre en place
et nous avons donc réalisé la conception deux systèmes à implémenter notamment
l’application web et l’application Android. Le chapitre III suivant va nous permettre de valider
cette conception à travers l’implémentation et les tests.
50
CHAPITRE III: IMPLEMENTATION
51
Chapitre III: IMPLEMENTATION
III.1 Déploiement au GUCE

Le la solution devra être déployée au GUCE suivant le diagramme de déploiement
représentée par la figure 40 qui suit.
Figure 40:Architecture de déploiment
52
III.2 Présentation des outils utilisées
III.2.1 Système de gestion de base de données

Pour le développement de la base de données de l’application web, nous avons utilisé le
SGBD MySQL dans sa version 5.0. Notre choix s’est porté sur cet outil est dû au fait qu’il est
open source, efficace et léger en particulier c’est le SGBD que nous maitrisons le mieux parmi
les autres.
III.2.2 Outils de modélisation

Durant la phase de d’analyse et spécification, nous avons utilisé deux outils :
 Enterprise Architect 7.0 pour la modélisation UML

 Altova Mission Kit 2013 : pour modéliser la définition des schémas XML (XSD) des
Messages de notification pour l’interfaçage avec l’e-GUCE
 Microsoft Office Visio 2010: pour la représentation des illustrations de certaines
figures
 WireFrame Sketecher 3.4 : pour le maquettage des interfaces utilisateurs pour
Android.
III.2.3 Environnement de développement

Le choix des environnements de développement s’est porté en fonction des choix des
technologies des plateformes à développer :
Pour le développement de l’application web e-Chargers, nous avons utilisé Netbeans 8.0.
Du fait que Netbeans est un IDE complet et intègre presque tous les plugins et outils
nécessaires au développement JEE.
Le développement de l’application Android nous a incités à choisir Eclipse. Eclipse est l’IDE
Open Source le plus communément utilisé dans le développement Android. Il intègre le plugin
ADT qui lui permet d’utiliser le SDK Android pour pouvoir développer et tester les
applications Android.
III.2.4 Les tests

Pour effectuer nos test nous avons eu recourt à un certain nombre d’outils :
 SOAPUI et Postman de Google pour effectuer les tests sur les services web à
implémenter.
 Des AVD du SDK Android et notre Téléphone HTC Desire tournant sur Android 2.3.7
pour les tests de nos applications Android.
53
III.3 Les technologies utilisées
III.3.1 Android
III.3.1.1. Architecture
Android est une pile logicielle, un ensemble de sous-systèmes logiciels nécessaires pour
fournir une solution entière pour les appareils mobiles. Cette pile comprend :
 Un système d'exploitation (noyau Linux modifié), qui offre des fonctionnalités de base
comme la gestion des processus, gestion de la mémoire, de la gestion de l'appareil
comme appareil photo, clavier, écran, etc…
 un middleware (logiciel qui connecte le système d'exploitation de bas niveau pour des
applications de haut niveau) qui est en partie basé sur Java
Le middleware comprend :
 Un Framework qui est un ensemble de classe java fournissant des services aux
applications clés et aux applications Android développées.
 Des librairies qui sont un ensemble de bibliothèques écrites en C/C++
 L’environnement d’exécution Android (Runtime), comprend la machine
virtuelle Dalvik qui est l’environnement d’exécution des programmes et une
bibliothèque de base qui permet tout comme le Framework de développer des
applications Android en utilisant JAVA.
 des applications clés qui sont des applications encastrées dans le système Android.
Elles sont écrites en JAVA.
Figure 41:Architecture du système Android
54
III.3.1.2. Composants d’une application Android :

Une application Android est composée de 4 grands composants :
 Les activités : ce sont des composants qui gèrent l’affichage de l’interface utilisateur et
l’interaction de l’utilisateur avec les éléments de cette interface utilisateur.
 Les services : ce sont des composants qui s'exécutent en arrière-plan pour effectuer
des opérations de longue durée.
 Broadcast receivers: gèrent la communication entre les applications Android et le
système d'exploitation. Ils répondent simplement à des messages diffusés provenant
d'autres applications ou du système.
 Les contents providers : ils fournissent des données d’une application à une autre à
travers des requêtes. Ces données peuvent être stockées dans le système de fichiers,
une base de données (SQLite).
 Les composants additionnels
Il existe des composants supplémentaires qui participent à la création des
composants cités plus haut.
Le tableau décrit chacun d’eux :
Composant Description
s
Fragment Un fragment est une portion de l’interface utilisateur qui peut être réutilisée
dans une activité
Les Vues Ce sont les éléments de l’interface utilisateur qui sont dessinés sur l’écran
(Views)
Les Layout Ce sont des vue hiérarchiques utilisées pour contrôler le formatage et
l’apparence des Vue
Les Intents Ce sont des messages connectant les composants ensemble
Manifeste Fichier de configuration d’une application Android
Les ressources Ce sont les éléments externes tels les images, les icones, les fichiers mp3.
Tableau 2: Les autres composants d'une application Android
Les composants d'application sont les éléments essentiels d'une application Android. Ces
composants sont faiblement couplés par le fichier AndroidManifest.xml qui décrit chaque
composante et comment ils interagissent.
III.3.1.3. Choix de version

Android depuis sa création continue de subir des mutations. Ces mutations se concrétisent
à travers des mises à jour identifiées par des numéros d’API et de nom de code. Les mises à
jour récentes intègrent de nouvelles fonctionnalités et par conséquent une puissance de
traitement élevée donc un smartphone compatible.
Le tableau 3 qui suit illustre les différentes versions d’Android et le pourcentage de

distribution.
55
Tableau 3: Distribution des versions d'Android
Pour nous assurer de la retro compatibilité nous avons ciblé l’API 10
III.3.2 Java Enterprise Edition (JEE)

III.3.2.1. Présentation
Java EE est un ensemble de spécifications pour la plateforme Java, mises en œuvre par
différents conteneurs. Les conteneurs sont des environnements d'exécution Java EE pour
fournir certains services aux composants qu'ils hébergent tels que la gestion du cycle de vie,
l'injection de dépendance, La concurrence, etc.... Ces composants utilisent des contrats bien
définis pour communiquer avec l’infrastructure Java EE et avec les autres composants. Ils
doivent être emballés de façon standard (suite à une structure définie de répertoire qui peut
être comprimé dans des fichiers d'archive) avant d'être déployés. Java EE inclus la plate-
forme Java Standard Edition (Java SE), ce qui signifie API Java SE peut être utilisé par tous les
composants Java EE.
III.3.2.2. Composants
L'environnement d'exécution Java EE définit quatre types de composants. Deux d’entre eux
nous intéressent dans le cadre de notre implémentation.
 Les composants web (Servlet, Filter, etc…) sont exécutés par les conteneurs web et
répondent aux requêtes http des clients web. les applications web supportent les
services web sur SOAP et REST.
 Les composants d'entreprise sont exécutés dans un conteneur d'EJB. Les EJB sont
composants gérés par le conteneur pour le traitement métier. Ils peuvent être
accessibles localement, ou à distance via RMI, HTTP, SOAP, REST.
III.3.2.3. Les conteneurs

JEE a 4 types de conteneurs parmi lesquels nous ne citerons que 2 qui nous intéressent
dans notre périmètre:
56
 Le conteneur web : fournit les services sous-jacents pour la gestion et l'exécution de

web composants (servlets, EJB Lite, JSP, filtres, auditeurs, des pages JSF, et des services
Web). Il est responsable de l'instanciation, initialisation, et l’invocation des servlets il
supporte le protocole HTTP ou HTTPS
 Le conteneur EJB : est responsable de la gestion de l'exécution des EJB. Il crée de
nouvelles instances d’EJB, la gestion de leur cycle de vie, et fournit des services tels que
la transaction, la sécurité, la concurrence, la distribution, le service de nommage, ou la
possibilité d’être invoquée de manière asynchrone.
La figure 42 qui suit présente ces 2 types de conteneurs ainsi que les spécifications
qu’ils supportent. Pour plus de détails sur les spécifications veuillez consulter le livre Java
EE7 mentionné en bibliographie à la fin de ce document.
Figure 42: Les conteneurs d'une application JEE - Conteneur web & conteneur EJB
III.3.2.4. Les services

Parmi les services offerts par JEE, la liste qui suit décrit sommairement les services utilisés
par notre application :
 Java Transaction API (JTA): Il permet de gérer les transactions des composants au
niveau du conteneur
 Java Persistance API (JPA): API standard pour le mapping objet-relationnel (ORM).
Avec JPQL il est possible d’interroger les données stockées dans une base de données
 Java Message Service (JMS): permet aux composants de communiquer de façon
asynchrone par envoie des messages. Nous utiliserons JMS pour envoyer des messages
à chaque composant des trois canaux de notifications.
 Java Naming and Directory Interface (JNDI): cette API, inclus dans Java SE, est utilisé
pour l'accès nommage et systèmes d'annuaire. Il permet de d’obtenir ou retrouver des
objets (source de données, EJB, les file d’attente JMS, etc…) de manière transparente.
 JavaMail: cette API permet l’envoie des mails
 Les services de sécurité: permet d’authentifier et appliquer des contrôles d'accès sur
les utilisateurs.
 Services Web: Java EE fournit un support pour SOAP et les services Web RESTful.
L'API Java pour Les services Web XML (JAX-WS), fournit le support pour les services
57
Web utilisant le protocole SOAP / HTTP. L'API Java pour les Services Web RESTful
(JAX-RS) fournit un soutien pour les services Web en utilisant le style REST.
Pour l’implémentation de l’interfaçage avec la plateforme e-GUCE nous utiliserons
REST ou SOAP.
Avec la limitation des librairies JAVA sur Android nous utiliserons REST. Ce choix va
être supporté aussi sur la plateforme KANNEL.
III.4 Les Frameworks et librairies utilisées

III.4.1.1. Application web
Cloning
Cette librairie permet de cloner des objets en profondeur. Nous avons été confrontés à une
problématique lors de la phase d’implémentation. Il était fastidieux d’ajouter des annotations
afin de pouvoir être en mesure de dupliquer un objet. Du fait de la permanente évolution de
notre application. Il fallait donc trouver une alternative qui devait nous rendre la vie facile.
Sinon nous nous retrouverions en train d’ajouter à nouveau des annotations sur des classes
régénérées.
Apache Component Client

Cette librairie nous permet l’implémenter facilement des clients pour les services web
développées en REST par la DSI du GUCE. Il n’existait pas déjà des outils JEE pour
l’implémentation de tels clients.
Google Cloud Messaging Server

Cette librairie est nécessaire vu que notre application web doit être en mesure d’envoyer
des notifications à notre application Android. Elle va permettre à notre application de pouvoir
en voyer des messages au serveur de notification PUSH de Google.
III.4.1.2. Application Android
Gson
Gson est une librairie java développée par Google pour fournir une logique plus simple
pour la sérialisation des POJO (Plain Old Java Object) en chaines de caractère JSON, et la
deserialisation des chaines de caractères en POJO. Nous l’utilisons sous Android du fait
qu’Android intègre une plateforme JAVA limité. Les annotations JAXB pour la sérialisation et
la deserialisation en XML ou JSON utilisées dans l’architecture JEE ne sont pas supportées.
L’alternative était d’assurer des échanges transparents entre Android et l’application web,
ainsi rendant flexible l’interfaçage. Pour l’implémentation, nous utilisons la version 2.2.4.
Google Cloud Messaging Client

Est une librairie tierce qui vient avec le SDK Android. Il permet de pouvoir implémenter la
notification PUSH. Pour permettre à une application de recevoir des notifications venant de
Google Cloud Messaging.
58
III.5 Présentation du prototype.

Le prototype qui résulte de la mise en œuvre de la solution consiste actuellement en une
application web e-chargers qui est encore dans l’environnement de développement pour les
tests, et le développement d’une application Android e-chargers logistic pour le suivi
logistique. En local l’application web communique déjà avec le GUCE à travers les services
web réalisés par la DSI du Guichet Unique.
Figure 43:Architecture du premier prototype
III.5.1 Android
III.5.1.1. Lancement et enregistrement
Au premier lancement de l’application l’utilisateur est appelé à entrer les paramètres
d’authentification (chargerName, companyAccessCode) qui lui sont fournis par
l’administrateur. Le compte est créé dans le cas où le chargeur est une personne morale. Dans
le cas contraire, il doit alors s’enregistrer.
59
Figure 44:Présentation prototype Android - connexion, enregistrement d'un utilisateur
Figure 45:Présentation du prototype Android - Enregistrement du chargeur
III.5.1.2. Consultation des manifestes

Une fois la phase d’enregistrement terminé. L’application démarre sur le Dashboard ou il
peut consulter ses connaissements, la prévision d’escale, etc…
60
Figure 46:Présentation prototype - Consultation manifeste - 1
Figure 47:Présentation prototype - Consultation maniteste - 2
III.5.1.3. Tracking conteneur
61
Figure 48:Présentation prototype - Tracking conteneur
III.5.1.4. Prévision escale
Figure 49:Présentation prototype - Prévision escale
62
III.5.2 Application web

Nous utilisons le simulateur en local qui envoie une notification à l’application web via un
service web. La notification est ensuite envoyée à l’adresse email au chargeur enregistré sur l
plateforme.
Figure 50:Présentation prototype notification de connaissement via email
III.6 Faisabilité économique

La solution globale permettra au GUCE de réduire d’avantages les délais de passage des
marchandises sur la place portuaire avec l’envoie des notifications. Le temps de latence, entre
la mise à jour de l’état des dossiers sur la plateforme et l’action à entreprendre, sera
considérablement réduit
63
CONCLUSION
Synthèse
L’objet de ce mémoire portait sur la conception et le développement d’une solution mobile
pour le suivi des procédures dématérialisées par les opérateurs de commerce extérieur
(importateur, exportateur). Cette solution devrait pouvoir générer des alertes (notifications).
Pour cela :
 un tour d’horizon sur le circuit du commerce extérieur avec le GUCE a été effectué pour
l’appropriation des concepts et l’identification des exigences du domaine, ensuite les
solutions mobiles sont énumérées afin d’effectuer un choix qui cadre avec nos
objectifs.
 Ensuite la conception d’une solution au problème est menée en se basant sur les choix
effectués précédemment.
 Enfin un premier prototype de la solution proposée est implémenté. Les premiers tests
dans l’environnement local sont concluants.
Durant la période de notre stage nous avons rencontré des difficultés dans le
développement. Surtout dans le volet communication d’Android ou il fallait trouver une
solution d’échange flexible avec Android et l’application web. Ces difficultés ont été
surmontées grâce à la patience et à la bonne collaboration. Cette solution est la première
véritable réalisation mobile dans le système du Guichet Unique de Commerce Extérieur; aussi
l’architecture de la plateforme est assez complexe, et il a fallu maitriser un bon nombre de
technologies JEE, Android.
Limites et Perspectives.
Le prototype, dans son état actuel, n’est pas entièrement au point, par conséquent il
nécessite des développements complémentaires et des configurations pour l’installer dans
son environnement d’exploitation. Deux canaux de notifications sont déjà intégrés. La liaison
avec l’e-GUCE se limite actuellement à l’initiation des requêtes sous forme de services web
venant de l’application web. Le module de notification est en cours de réalisation par la DSI
du GUCE.
64
BIBLIOGRAPHIE
 Antonio GONCALVES. Beginning Java EE 7. Apress 2013.

 C.T. ARRINGTON. Enterprise JAVA with UML. Wiley Publishing 2002
 Godfrey Nolan, Onur Cinar, David Truxall. Android Best Practices, Apress 2013
 Tchapo TANTE-GNANDI. Implémentation d’un portail SMS à base du logiciel KANNEL.
DUT en télécommunications 2006.
 AYEFOU WAGOUM Gildas. Couplage d’un moteur d’orchestration et d’un ESB pour la
médiation entre les acteurs de commerce extérieur.
 Le Manuel des procédures. Guichet Unique des opérations du Commerce Extérieur.
65

Memoire Ingenieur Nwawel

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Memoire Ingenieur Nwawel

Transféré par

Droits d'auteur :

Formats disponibles

UNIVERSITÉ DE YAOUNDÉ I UNIVERSITY OF YAOUNDÉ I

ECOLE NATIONALE SUPÉRIEURE NATIONAL ADVANCED SCHOOL OF

CONCEPTION ET DEVELOPPEMENT D'UNE SOLUTION

Mémoire de fin d’études / Master of Engineering

Présenté et soutenu par :

Diplôme d’ingénieur de conception en Génie Informatique

KOUAMOU Georges Edouard, CC.

MVEH ABIA Chantal, CC.

Jamelddine EL KAMEL, Ing.

Devant le jury composé de :

 Président: TCHUENTE Maurice, Pr.

Année Académique 2013 - 2014

A mes parents Mr. & Mme. IROUME,

A ma tante NDEM Marceline,

A mon oncle WELL A MOUTE Dieudonné,

 Le président du jury Pr. TCHUENTE Maurice pour m’avoir accordé sa disponibilité

Vous aussi je ne vous oublie pas :

Ce mémoire a pour objectif de concevoir et de développer une solution mobile pour le

Mots clés : Android, canaux de notification, solution mobile.

Keywords: Android, mobile solution, notification channels.

Resume ......................................................................................................................................................... iii

Liste des figures........................................................................................................................................ vii

Liste des tableaux ...................................................................................................................................... ix

Liste des acronymes................................................................................................................................... x

INTRODUCTION GENERALE .................................................................................................................. 13

I.1 Analyse Thématique.......................................................................................................................... 16

II.1 Gestion du projet ................................................................................................................................ 27

III.1 Déploiement au GUCE .................................................................................................................. 52

Cette plateforme interconnecte différents partenaires du commerce extérieur : banques,

La figure 1 ci-dessous illustre les partenaires (services) du commerce extérieur

Figure 1 : Les partenaires du commerce extérieur du GUCE et taux de couverture

I.1 Analyse Thématique

I.1.1 Circuit global de commerce extérieur

I.1.1.1. Circuit logistique

Le transitaire peut alors recourir à un transporteur routier (s’il ne dispose pas de la

Le consignataire conteneurise (groupe avec d’autres marchandises) la marchandise. La

La figure 2 ci-dessous illustre le circuit logistique d’une marchandise depuis l’usine

Figure 2: Circuit logistique du commerce extérieur à l'import

Arrivé au port de destination, l’acconier s’occupe du déchargement du navire. Le

La figure 3 présente le circuit logistique d’une marchandise à l’import depuis l’arrivée au

Figure 3: Circuit logistique du commerce extérieur à l'import

I.1.1.2. Procédures et formalités

Figure 4: Les formalités de commerce extérieur à l'import

numéro indique l’ordre d’exécution de la procédure. Les flèches indiquent l’enchaînement

Figure 5: Les formalités de commerce extérieur à l'export

Figure 6: Circuit global de commerce extérieur.

I.1.2 La plateforme électronique e-GUCE

 Un portail web communautaire de services permettant aux usagers (Importateur /

Figure 7: Plateforme de l’e-GUCE

Parmi les formalités et procédures dématérialisées en production nous avons :

 Contrôle d'Identification des Véhicules Importés D'Occasion (CIVIO) ;

I.2 Etat des lieux des technologies

I.2.1 Les plateformes mobiles

I.2.2 Les moyens de Notification

Figure 8:Architecture fonctionnelle de la communication via e-mail

La figure 9 ci-dessous illustre l’architecture fonctionnelle pour une communication SMS.

Figure 9:Architecture fonctionnelle de la communication via SMS

I.2.2.3. Les appels téléphoniques

I.2.2.4. Les modèles de notification sur mobile.

Figure 10:Architecture fonctionnelle notification push

I.2.3 Les passerelles SMS

1- Un ensemble d’applications chargées d’offrir des services (contenus) mobiles.

I.2.3.1. Cas de KANNEL

La figure 12 illustre l’architecture fonctionnelle de la passerelle KANNEL.