SIB Mobile

DGBF : PORTAIL D’ACCES ET
APPLICATIONS MOBILES
Portail mobile E-budget
Auteur : DTI (Direction des traitements informatiques)

DGBF : PORTAIL D’ACCES ET APPLICATIONS MOBILES Décembre 2018 – Janvier 2019
Avant-propos
Ce présent rapport présente les résultats de travaux d’étude relatifs à un sujet qui
épouse d’une part l’ère du temps en terme de technologie mobiles et d’autre part s’aligne
étroitement sur les politiques publiques nationales de gouvernance électronique ou
encore administration numérique ou système dématérialisé, si particulièrement portées
par le gouvernement dans sa vision de faire de la côte d’ivoire un état émergeant.
Quel en est le thème ? Quel est l’objectif poursuivi ? Comment sera structuré le document
de restitution ?
 Sujet
Mise en place d’une plateforme budgétaire mobile.
 Objectif
- Rendre plus accessible et en temps réel l’information budgétaire via le
mobile ;
- Progresser dans la réalisation de la mission du gouvernement :
Gouvernance électronique ou administration numérique
 Structure du rapport
1ère partie : PRESENTATION DU CADRE DU PROJET
Présente du cadre du projet d’étude.
2ème partie : ETUDE ET ANALYSE
Présente les résultats des études d’analyse
3ème partie : CONCEPTION
Présente les résultats des études de conception
4ème partie : REALISATION
Présente Le produit réalisé
1|Page
Table des matières

Table des figures et diagrammes.................................................................................................... 4
Liste des Tableaux ........................................................................................................................... 5
Glossaire des Acronymes ................................................................................................................ 6
Définitions et concepts ................................................................................................................... 6
INTRODUCTION ............................................................................................................................... 7
I. PRESENTATION DU CADRE DU PROJET D’ETUDE ................................................................... 8
I.1 Contexte .......................................................................................................................... 8
I.2 Enjeux et Problématique ................................................................................................ 8
I.3 Objectifs et résultats attendus ....................................................................................... 8
II. ETUDE ET ANALYSE ................................................................................................................. 9
II.1 Le système existant au niveau de l’accès aux services offerts aux usagers .................. 9
II.2 Analyse diagnostique du système existant .................................................................. 10
II.3 Approche de réponse : Les technologies mobiles........................................................ 10
II.3.1 Statistiques sur leurs usages .................................................................................. 11
II.3.2 Les Systèmes d’exploitation mobiles et applications mobiles .............................. 12
II.4 Solutions proposées ...................................................................................................... 12
II.4.1 Spécification fonctionnelle .................................................................................... 13
II.4.2 Spécification non fonctionnelle ............................................................................. 13
III. CONCEPTION DE NOTRE SOLUTION ................................................................................. 16
III.1 Méthode et approche adoptées : UP/UML .................................................................. 16
III.2 Le Portail mobile : Interface d’accès aux services grand publique.............................. 17
III.3 La plateforme de Notification et back-end .................................................................. 23
III.3.1 Etat de l’art de la notification mobile .................................................................... 23
III.3.2 Principe de fonctionnement et architecture technique ........................................ 24
III.4 Architecture cible de la plateforme de notification .................................................... 26
III.4.1 L’architecture globale de la plateforme : Client-serveur 3 tiers ............................ 26
IV.1.1 Serveur d’application web d’envoi ........................................................................ 28
IV.1.2 Serveur de base de données.................................................................................. 28
IV.1.3 L’application mobile : Application mobile native .................................................. 28
IV.2 Les modèles conceptuels de l’application : les diagrammes UML de notre système . 29
IV.2.1 Diagramme des cas d’utilisation (Comportement)................................................ 30
IV.2.2 Description textuelle du cas d’utilisation .............................................................. 32
IV.2.3 Diagramme de séquence / cas d’utilisation (Interaction) ..................................... 38
IV.2.4 Diagramme de classe (Vue statique) .................................................................... 42
2|Page
IV.3 Prototypage et choix des outils et de développement................................................ 43

IV.3.1 Prototype d’interface graphique (Maquettes d’écran) ......................................... 43
IV.3.2 Outils de développement et technologies :........................................................... 45
V. REALISATION ......................................................................................................................... 51
V.1 Infrastructures matérielles & réseau de mise en production ..................................... 51
V.2 Diagramme des composants applicatifs ...................................................................... 51
V.3 Présentation des IHM réalisé ....................................................................................... 52
V.4 Déploiement.................................................................................................................. 52
CONCLUSION ................................................................................................................................. 53
VI. SOURCES ET BIBLIOGRAPHIES .......................................................................................... 54
VII. LES ANNEXES ..................................................................................................................... 55
VII.1 Annexe 1 ........................................................................................................................ 55
VII.2 Annexe 2 ........................................................................................................................ 55
3|Page
Table des figures et diagrammes

Réf. Légende page
Figure I.1 17
Figure I.2 19
Figure I.3 21
Diagramme II.1 23
Figure II.2 Statistique mobile en Afrique sub-saharienne (Source GSM 32
Association)
Figure II.3 Répartition du trafic web par media (Source rapport Digital 33
2017)
Figure II.4 Part de marché OS mobile (Source 35
http://gs.statcounter.com)
Figure II.5 Part de marché du téléchargement d’application (Source 35
https://fr.statista.com)
Figure II.6 Plateforme de notification mobile 40
Diagramme II.7 Diagramme des cas d’utilisation globale
Figure III.1 Architecture standard système de notification push mobile 44
Figure III.2 Illustration du processus UP 47
Figure III.3 Architecture globale plateforme de notification mobile 48
Figure III.4 Architecture simpliste plateforme de notification mobile 48
Figure III.5 Check-list pour le choix d’une technologie 49
Diagramme III.1 Digramme des cas d’utilisation 51
Diagramme III.2 Digramme de séquence cas « S’inscrire » 59
Diagramme III.3 Digramme de séquence cas « S’authentifier » 60
Diagramme III.4 Digramme de séquence cas « S’abonner » 60
Diagramme III.5 Digramme de séquence cas « Envoyer message » 61
Diagramme III.6 Digramme de séquence cas « Créer compte utilisateur » 61
Diagramme III.7 Digramme de classe 62
Figure III.6 Format de donnés JSON 67
Figure III.7 Maquette d’écran front-end page « Accueil » 63
Figure III.8 Maquette d’écran front-end page « Créer notification » 64
Figure III.9 Maquette d’écran front-end page « Envoyer notification » 65
Diagramme IV.1 Digramme de composant 69
Diagramme IV.2 Diagramme de déploiement
4|Page
Liste des Tableaux

Réf. Légende page
Tableau II.1 Tableau des acteurs et des rôles 23
Tableau II.2 Tableau récapitulatif des systèmes de notification 24
Tableau II.3 Cas d’étude sur le sujet des TIC et leur impact 29
Tableau II.4 Cas de plateformes digitales mobiles à succès 31
Tableau II.5 Tableau des besoins non fonctionnels 40
Tableau II.6 Tableau des acteurs et des rôles du système cible 41
Tableau III.1 Tableau récapitulatif des spécifications techniques des 45
notifications mobile
Tableau III.2 Tableau des acteurs et des rôles 50
Tableau III.3 Liste des cas d’utilisation
Tableau III.4 Description Textuelle du cas d’utilisation <S’inscrire> 51
Tableau III.5 Description Textuelle du cas d’utilisation <S’authentifier>
Tableau III.6 Description Textuelle du cas d’utilisation <S’abonner au 53
service>
Tableau III.7 Description Textuelle du cas d’utilisation <Se désabonner au 54
service>
Tableau III.8 Description Textuelle du cas d’utilisation <Ouvrir un 54
message>
Tableau III.9 Description Textuelle du cas d’utilisation < Formater un 54
message >
Tableau III.10 Description Textuelle du cas d’utilisation < Programmer 55
l’envoi un message >
Tableau III.11 Description Textuelle du cas d’utilisation < Envoyer un 55
message >
Tableau III.12 Description Textuelle du cas d’utilisation < Créer groupe 56
utilisateur >
Tableau III.13 Description Textuelle du cas d’utilisation < Supprimer
compte utilisateur >
Tableau III.14 Description Textuelle du cas d’utilisation < Autoriser 57
système à se connecter >
Tableau III.15 Description Textuelle du cas d’utilisation < Déconnecter 58
Système >
5|Page
Glossaire des Acronymes

Sigle Définition
DGBF Direction Générale du Budget et des Finances
DTI Direction des Traitements Informatiques
SI Système d’Information
SIB Système d’information Budgétaire
TIC Technologie de l’Information et de la Communication
GSMA GSM Association
UIT Union Internationale des Télécommunication
Définitions et concepts
Domaine Technologie de l’information et de la communication

Progressive Web Apps Une progressive web app (PWA, applications web
progressives en français) est une application web qui
consiste en des pages ou des sites web, et qui
peuvent apparaître à l'utilisateur de la même manière
que les applications natives ou les applications
mobiles. Ce type d'applications tente de combiner les
fonctionnalités offertes par la plupart
les navigateurs modernes avec les avantages de
l'expérience offerte par les appareils mobile2,3.
Application native Une application mobile est un logiciel
applicatif développé pour un appareil électronique
mobile, tel qu'un assistant personnel, un téléphone
portable, un smartphone, un baladeur numérique,
une tablette tactile, ou encore
certains ordinateurs fonctionnant avec le système
d'exploitation Windows Phone ou Chrome OS.
Elles sont pour la plupart distribuées depuis
des plateformes de téléchargement (parfois elles-
mêmes contrôlées par les fabricants de smartphones)
telles que l'App Store (plateforme d'Apple), le Google
play (plateforme de Google / Android), ou encore
le Microsoft Store(plateforme
de Microsoft pour Windows 10 Mobile)
Notification push Sur un mobile, une notification push est un message

d'alerte reçu via une application que l'on peut ouvrir,
supprimer, autoriser ou bloquer.
6|Page
INTRODUCTION
La convergence des technologies numériques (TIC) parvenues à une certaine
maturité a indéniablement bouleversée le mode de vie dans la société : la manière de
communiquer, d’interagir, de consommer, de travailler, de diriger…on parle société de
l’information, ou encore société hyper connectée. En effet, ces technologies (Internet,
Mobile, etc..) et leur usage ont rapidement été adoptés, voir même adoubés par les
populations sur la planète plus que n’importe quelle autre technologie avant elles. En
témoignent les quelques chiffres internet 2018 sur les utilisateurs : 4,12 milliards
d’internautes, soit 54% de la population mondiale (+8% entre juillet 2017 et juillet 2018) -
Le nombre d'utilisateurs de smartphones passera de 3,4 à 6,3 milliards de personnes en
2021. Cette révolution numérique impacte évidemment tout l’environnement sociaux-
économique ; Et impose donc à chaque agent de l’écosystème un effort d’adaptation à
divers degrés au risque de se mettre en isolement. En d’autres termes « S’adapter pour
assurer sa survie ». A cet effet, la Banque Mondiale, dans son rapport annuel de 2016, «
Digital Dividends », a considéré la question de l’intégration des technologies mobiles, au
plan mondial et leurs enjeux. Le rapport souligne en particulier l’apport de celles-ci en
termes de levier favorisant l’inclusion, la transparence, l’efficacité, l’innovation et la
création d’économie substantielle entre autres du fait du potentiel de production de
biens informationnels. En d’autres terme, une intelligente intégration de ces technologies
au sein des organisations permet d’accroitre la productivité, d’améliorer l’offre de service
et la qualité de service, de réduire les coûts, d’optimiser les processus d’affaire, d’offrir
des outils d’interaction facile d’accès, qui rapproche l’usager du fournisseur de
service…etc. Dans ces conditions, les Etats, garant des politiques publiques, avait tout
intérêt se mettre à niveau afin de tirer parti du potentiel et des opportunités offerts par
ces technologies. L’élaboration, la mise en œuvre de ces politiques et stratégies
nationales de transformation numérique ont donné lieu à plusieurs appellation ou
concept : e-Administration, e-gouvernement, Gouvernance électronique, Etat-
plateforme.
C’est dans cette dynamique de modernisation et d’innovation que s’inscrit la
volonté de La Direction générale du budget et des finances (DGBF) de proposer des
plateformes numériques interactives mobiles à ces usagers, qui améliorent grandement
les échanges. Il faut souligner que ce n’est pas un projet isolé. Elle fait d’ailleurs partie du
vaste projet de refonte que mène la DGBF et qui vise à mettre en cohérence d’une part
son système d’information et les nouveaux textes et d’autres parts, moderniser
progressivement les outils électroniques du SIB.
7|Page
I. PRESENTATION DU CADRE DU PROJET D’ETUDE

I.1 Contexte
Les technologies mobiles ont incontestablement investi tous les milieux de notre
société actuelle. Nous somme à l’ère du mobile ; en effet le mobile est aujourd’hui le
media le plus utilisé dans l’accès à l’information. De fait, ce n’est quasiment plus une
option mais une exigence, et même une norme de communication et de collaboration à
laquelle tous autant que nous soyons citoyen, entreprise privée, administration publique
nous devons nous conformer pour éviter les risques d’isolement. Et la DGBF l’a bien
comprise, en conduisant des chantiers de modernisation du SIB afin de prendre en
compte cette nouvelle exigence : la mobilité des agents et des usagers. Les gains en
termes de flexibilité, de réactivité, et de qualité de service sont indéniables et partant,
de rapprochement d’avec usagers. C’est dans cette dynamique que s’inscrit le projet
« Mise en place d’une plateforme budgétaire mobile » ; Projet qui fait l’objet de notre
présente étude, et qui devrait aboutir à la mise en place d’un portail budgétaire mobile.
I.2 Enjeux et Problématique
L’accès aux services grand publics pris dans le contexte actuel d’ère de la mobilité
soulève un certains nombres de questions :
- Comment permettre aux agents et aux usagers d’accéder à des services
d’information de façon plus sûre (sécurité et confidentialité des messages), en
temps réel et en tout lieu, sans qu’ils aient à nécessairement effectuer des
déplacements ?
- En quoi et comment le recourt aux technologies mobiles et internet est
susceptible de soutenir et accroitre l’efficience du processus de communication et
l’offre de services numériques au sein de notre organisation ?
C’est bien entendu à cette problématique que notre étude devra apporter des
réponses au cours de ce projet.
I.3 Objectifs et résultats attendus

 Objectif principal
Rendre plus accessible et en temps réel l’information budgétaire en
réduisant le plus possible les déplacements et les accès physiques pour
les besoins de communication et de partage d’information.
 Objectifs spécifiques
- Accroitre l’efficacité de son fonctionnement interne en prenant en
compte l’exigence de mobilité des agents ;
- Améliorer la relation avec les citoyens et les entreprises, usagers des
services de la DGBF, par la mise en place de solution mobile interactive
en ligne ;
 Résultats attendus
8|Page
Mise en place d’une plateforme budgétaire mobile permettant aux

usagers d’accéder aux services publics et délivrant les notifications
d’information via le mobile.
II. ETUDE ET ANALYSE

II.1 Le système existant au niveau de l’accès aux services offerts aux usagers
Il faut rappeler que le partage d’information pris dans le cadre budgétaire, consiste
bien entendu à transmettre des informations d’une certaines natures (budgétaire-
économique ou professionnelle) à des agents et/ou aux usagers des services de la DGBF.
A titre récapitulatif, ce tableau présente les informations notifiées aux différentes
catégories de destinataire et les moyens utilisés :
 Tableau informations notifiées
Destinataires Informations notifiées Moyens utilisés

Agents - DGBF - Mise en place du - Courrier
- Contrôleur budget de la gestion N électronique
budgétaire - Notification ouverture - Notification
- Contrôleur financier SIGFIP intégré aux
- DAF - Notification fermeture applications
- Chargé d’étude SIGFIP métiers (SIGFIP,
- Notification des SIGBUD)
autorisations de crédit - Téléphone
- Les différentes lois de - Courrier
finance et actes physique
Usagers - Opérateurs - Marché publique - Magazine et revu

économiques - Vote du budget DGBF
- Les fonctionnaires (montant) - Site web
- Les partenaires - Situation d’exécution - Les média
financiers du budget - Courrier
- Les autres services - Bulletin de salaire physique
de l’administration - Virement des salaires
- Autres citoyens - Situation des mandats
Tableau II.1 Tableau récapitulatif des informations notifiées

 Moyens mis en œuvre pour délivrer le service d’information
- Au niveau des procédures
Les informations sont notifiées suivant des procédures bien établis, et encadrés
par des règles de gestion des accès aux ressources du SI à cet effet. L’ensemble de ces
règles et principes de contrôle et de gestion des identités et des accès (GIA) sont
consignées dans les guides référentiels suivants :
 La gestion des habilitations (réf. Guide de procédure de la DGBF) ;
9|Page
 Politique de sécurité (réf. Guide PAQ, Charte informatique).
- Au niveau des supports ou canaux

Nous avons essentiellement recensé les moyens de communication / notification
suivantes :
 Le courrier physique ou postal ;

 Le courrier électronique ou e-mail ;
 Le téléphone ;
 Les notifications des applications métier ;
 Le site web de la DGBF ;
 Les magazines et revus.
II.2 Analyse diagnostique du système existant
Le tableau « II.1 Tableau récapitulatif des informations notifiées » met en relief un

recours à divers techniques et technologies de communication essentiellement fixe et
de façon hétérogène. De plus, La composante mobile d’un système d’accès à
l’information qui concentre de nos jours la plus grande part du trafic voix/data des
communications est absente de la nôtre. Ceci prive de fait, le système de flexibilité et
d’agilité dans un contexte fortement marqué par les usages des technologies mobiles
tant chez les usagers que les agents.
Au regard et à l’analyse des moyens de communication mis en œuvre, nous
résumons l’essentiel des faiblesses comme suite :
- Absence crucial de la composante mobile du système de communication /
notification alors que le mobile concentre 75 % du trafic des
communications (Source étude du Cabinet Gatner) ;
- Système hétérogène qui ne permet pas l’obtention d’un système
standardisé de communication / notification unifié (UC&C). toute chose
qui n’offre pas de possibilité de gouvernance transversale du système et
une maîtrise des coûts de la communication
- Manque de convergence fixe-mobile permettant une flexibilité et une
agilité du système.
Sur la base de ce diagnostique, la mise en place d’une plateforme d’information
mobile s’impose de façon cruciale pour apporter une réponse à ces problèmes identifiés.
II.3 Approche de réponse : Les technologies mobiles
L’usage de ces outils mobiles transforme profondément les rapports traditionnels au
temps et à l’espace qu’entretiennent les individus dans le contexte du travail et en dehors.
Les technologies mobiles dotent les individus de capacités d’ubiquité en ce sens que ces
derniers peuvent exercer leurs activités professionnelles potentiellement n’importe
quand, n’importe où. Les avantages ainsi offertes par les technologies mobiles sont mis
10 | P a g e
en avant pour justifier l’adoption et le déploiement de ces outils dans le contexte du

travail : une amélioration des capacités de communication, de coordination et de
collaboration; une possibilité renforcée d’interaction avec les clients, une meilleure
réactivité.
II.3.1 Statistiques sur leurs usages
Le téléphone et autres terminaux mobiles de troisième génération connaissent
un succès sans précèdent auprès des populations supplantant dans l’usage à l’accès à
l’information et autres services digitales les médias précédents comme l’ordinateur de
bureau et portable, les PDA. En témoigne les chiffres :
 Parmi plus de 7 milliards d’habitants sur le globe terrestre, il y a 2 484 915 152
d’internautes, soit un taux de pénétration de 35%. (source UIT)
 1,5 milliard de smartphones ont été vendus en 2017 selon Gartner.
 6 572 950 124 de personnes utilisent des téléphones mobiles, soit 93% des
habitants de la terre. (Source UIT).
Figure II.1 : Répartition du trafic web par media (Source rapport Digital 2017)
En Côte d’ivoire, le secteur a suivi la même tendance au point qu’Abidjan a gagné

20 places au dernier classement de l’Indice mondial de l’innovation publié à la mi-juillet
par l’organisation mondiale de la propriété intellectuelle. Des études ont confirmé cette
tendance dont nous mentionnons quelques chiffres :
 Le nombre des abonnés à la téléphonie mobile en Côte d'Ivoire a passé la barre
des 30 millions de clients à la fin 2017, soit 75% de la population. (Source ATCI)
 Le nombre des abonnés Internet a quant à lui dépassé le cap des 17 millions,
contre 10 millions d'abonnés enregistrés en début 2017, confirmant ainsi
l'évolution du marché des TIC dans le pays (Source ATCI)
En définitive, le téléphone mobile intelligent (Smart phone) nous ouvre sur le
monde digital en donnant accès à tout ou presque des services en ligne.
11 | P a g e
II.3.2 Les Systèmes d’exploitation mobiles et applications mobiles

Le marché des téléphones mobile est aujourd’hui dominé par cinq grandes
entreprises de technologie Smartphone qui sont Apple, RIM, Google, Microsoft ,
Samsung, et Nokia qui développent respectivement les systèmes d’exploitation ios,
BlackBerry OS, Android, Windows Phone, Tizen et Symbian OS. Chaque système
d’exploitation dispose de ses propres langages de développement (C++, Objective
C, Swift pour iOS, Java et C++ pour Android) et environnement pour créer des applications
compatibles. Ceci explique en partie la fragmentation du marché des applications
mobiles. Nous allons présenter brièvement chacun des systèmes, ce qui nous permettra
de connaitre le leader du marché :
 Android : le système d’exploitation open source de Google qui équipe la majorité
des smartphones et tablettes d’aujourd’hui.
 iOS : le système d’exploitation d’Apple qui équipe exclusivement les iPhone et
iPad.
 Windows : le système d’exploitation de l’entreprise américaine à l’origine du
même système d’exploitation pour ordinateurs portables et fixes.
 BlackBerry OS : le système d’exploitation développé par BlackBerry qui équipe
exclusivement les téléphones et smartphones BlackBerry.
 Symbian OS (Nokia) : Symbian est le système d’exploitation historique des
premiers téléphones Nokia et Motorola. Cet OS est désormais de moins en moins
répandu.
 Tizen OS (Samsung) : le système d’exploitation Tizen a longtemps équipé les
propriétaires de téléphones Samsung.
Figure II.2 : Part de marché OS mobile (Source http://gs.statcounter.com)

L’expansion exponentielle des téléphones intelligents et des boutiques
d’applications ou «App stores» ouvertes à cet effet à entrainer le développement et la
commercialisation d’applications mobiles très variées, qui répondre aux besoins des
abonnés, tant dans leur espace privé comme professionnel.
Au regard de ces statistiques, il ressort une nette domination du marché par les
plateformes Android (73%) et IOS (20%) et partant de leur boutique d’application en ligne
respectivement Play store et App Store.
II.4 Solutions proposées
En termes de solutions, nous procèderons aux développement et déploiements des
services suivants :
12 | P a g e
Service Accueil ou Portail (Page application mobile d’accès aux services

disponibles)
- Télécharger l’application et S’inscrire via le mobile ;
- Accéder aux applications à destination des usagers ;
- Gérer son abonnement aux services de notification ;
- Recevoir et lire les notifications ;
- Recevoir le fil d’actualité relatif à l’information budgétaire ;
Service d’envoi de notification (Application web avec formulaire d’envoi de
message)
- Editer les messages ;
- Formater et programmer l’envoi de message ;
- Envoyer les messages de formats texte, image.
Service d’administration de la plateforme (Front-end)
- Créer, modifier les profils ;
- Gérer les habilitations (les droits) ;
- Activer et désactiver des comptes ;
- Editer et consulter statistique et rapport ;
- Effectuer les mises à jour de composants applicatifs
II.4.1 Spécification fonctionnelle

Les besoins fonctionnels expriment l’ensemble des actions que doit effectuer le
système en réponse à un évènement déclencheur interne ou externes au système (ex.
pouvoir délivrer des messages). Il n’est accepté que s’il délivre tous les services attendus
de lui. Ceci dit, la nôtre doit couvrir principalement les fonctionnalités suivantes :
- Un abonné doit pouvoir s’inscrire sur la plateforme via le mobile ;

- Valider l’inscription d’un abonné sur la plateforme ;
- Authentifier les utilisateurs /abonnés lors connexion ;
- Accéder aux applications de la plateforme ;
- Editer et formater des notifications à destination des utilisateurs mobiles ;
- Programmer des envois de messages ;
- Envoyer des messages de format texte, image, lien hypertexte aux terminaux des
utilisateurs / Abonnés ;
- Pouvoir recevoir les notifications sur son mobile en mode hors connexion ;
- Ouvrir et lire les messages notifiés sur son mobile ;
- Gérer les abonnements aux différentes rubriques (service) par l’abonné ;
- Gérer les contrôles d’accès et les profils (back-end) ;
- Editer des statistiques des rapports sur les actions du système (back-end) ;
- Se déconnecter (quitter l'application).
II.4.2 Spécification non fonctionnelle
13 | P a g e
Ce sont des exigences qui identifient certaines conditions internes et externes du

système à respecter pour améliorer la qualité du produit et optimiser son
fonctionnement dans son environnement. Les principaux besoins non fonctionnels de
notre application se résument comme suit :
Les normes description Exigence

Sécurité - L’intégrité, c’est-à-dire garantir que les - Système
données sont bien celles que l’on croit Authentification /
être ; Autorisation
- La confidentialité, consistant à assurer - Back-office permet de
suivre la traçabilité de
que seules les personnes autorisées aient
tous les envois et gérer
accès aux ressources échangées ;
les accès et les profils
- La disponibilité, permettant de maintenir - Pouvoir effectuer les
le bon fonctionnement du système mises à jour sans
d’information ; interruption du service
- La non répudiation ou traçabilité,
permettant de garantir qu’une
transaction ne peut être niée ;
- L’authentification, consistant à assurer
que seules les personnes autorisées aient
accès aux ressources.
Performance - Temps de réponse : le temps de - En comparaison à un

chargement de l’application, ouverture poste de travail fixe, les
d’écran et des délais de terminaux mobiles ont
rafraîchissement, temps de traitement des ressources
fonctions de calcul, import/export de matérielles et réseaux
données, et limitées. Le
L’interrogation de données et rapports ; développement devra
- Bande passante : Combien de intégrer ces
transactions par heure le système doit-il contraintes.
être capable de traiter ? - Les smartphones sont
- Mémoire(Stockage) – combien de généralement
données le système doit-il être capable connectés à Internet
de stocker? via les réseaux edge ou
3G+ et de manière
occasionnelle en wifi.
Suivant la localisation
du terminal, l’accès au
réseau de données
peut être interrompu,
le mode hors
connexion doit alors
être géré au niveau de
l’application
14 | P a g e
- les ressources
mémoires,
processeurs, batterie
nécessaires au
fonctionnement du
terminal devront être
utilisé de façon
optimisée par
l’application
Disponibilité - Moyenne des temps de bon - Capacité à
et Fiabilité fonctionnement – Quel est le seuil fonctionner en mode
acceptable de temps d’indisponibilité ? hors connexion
- Le temps Moyen de Rétablissement, si le - Les mises à jour ne
système « tombe », combien de temps doivent pas
est nécessaire pour restaurer le système interrompe le service
à nouveau ? au-delà de 10 minute
-
Ergonomie - Les standards d’ergonomie, la densité - L’application mobile, le
et la disposition des éléments sur les back-office, doit être
écrans, la disposition et le flux, les facile à utiliser. Les
couleurs, l’Interface Utilisateur, les interfaces utilisateurs
raccourcis clavier doivent être conviviales
- Internationalisation / besoins de simple, intuitive et
localisation, langues. accessible. On parle de
«motivational design» ou
encore les «playful
interfaces».
- Design Responsive
(zoning, wireframes…) :
comportement de
l’écran en fonction de la
taille de l’écran du
terminal.
Compatibilité - La compatibilité avec des applications Le client mobile doit

partagées – À quels autres systèmes pouvoir fonctionner sur
doit-il s’interfacer (communiquer) ? les principales
- La portabilité sur des systèmes plateformes mobiles à
d’exploitation différents – sur lesquels il savoir :
être capable de fonctionner. - Android
- Apple (IOS)
- Microsoft
Maintenance - La conformité aux standards Coté Serveur :
et évolutivité d’architecture – à quels standards a-t-il - Architecture: web
besoin de se conformer pour en être service REST
facilement maintenable et le faire - Langage : Java
évoluer ?
15 | P a g e
- La conformité aux standards de design - Technologie : Java

- La conformité aux standards de EE
développement Coté client :
- Disponibilité de la documentation - HTML 5
(document technique, document - JavaScript
utilisateur, etc.) Contrat d’échanges entre
l’application et les
services web et (API) :
JSON
Tableau II.2 : Tableau des besoins non fonctionnels
III. CONCEPTION DE NOTRE SOLUTION

Dans ce chapitre, nous présenterons l’état de l’art de la notification mobile, par suite
l’approche méthodologique adoptée et les choix conceptuels et technique ; et enfin les
outils de développement de la futur solution.
III.1 Méthode et approche adoptées : UP/UML
La méthode UP est un processus itératif, centré sur l'architecture, piloté par des cas
d'utilisation et orienté vers la diminution des risques. Il regroupe l’ensemble des activités
à mener pour transformer les besoins d’un utilisateur en système logiciel. C'est un patron
de processus pouvant être adaptée à une large classe de systèmes logiciels, à différents
domaines d'application, à différents types d'entreprises, à différents niveaux de
compétences et à différentes tailles de l'entreprise. Les caractéristiques essentielles du
processus unifié :
- Le processus unifié est à base de composants ;

- Il utilise le langage UML (ensemble d'outils et de diagramme) ;
- Il est piloté par les cas d’utilisation ;
- Il est centré sur l’architecture ;
- Il est Itératif et incrémental.
Pour mener efficacement un tel cycle, les développeurs ont besoins de toutes les
représentations du produit logiciel :
- Un modèle de cas d'utilisation ;

- Un modèle d'analyse : détailler les cas d'utilisation et procéder à une
première répartition du comportement ;
- Un modèle de conception : définissant la structure statique du système
sous forme de sous-systèmes, de classes et interfaces ;
- Un modèle d'implémentation : intégrant les composants ;
- Un modèle de déploiement : définissant les nœuds physiques des
ordinateurs ;
- Un modèle de test : décrivant les cas de test vérifiant les cas d'utilisation ;
16 | P a g e
- Une représentation de l'architecture.
III.2 Le Portail mobile : Interface d’accès aux services grand publique

Notre approche de description et de conception concernant le développement du
portail mobile a été le prototypage d’interface graphique, méthode plus adapté et plus
efficace en la matière. En effet, Il s’agit de définir le gabarit et l’enchainement des pages
web du portail. Ci-dessus l’organisation et la structure des pages :
LES ECRANS DE L’APPLICATIONS MOBILE
17 | P a g e
Page Accueil Page Authentification
18 | P a g e
Page d’appel de consultation notification Page Paramétrage
19 | P a g e
Page Installation notification Page formulaire Inscription
20 | P a g e
Page Modification compte Page Menu
21 | P a g e
Page Applications disponibles Page Consultation historique Notification
22 | P a g e
Page Paramétrage service de notification
III.3 La plateforme de Notification et back-end

III.3.1 Etat de l’art de la notification mobile
Les notifications push permettent d’envoyer des messages style alerte depuis un
serveur vers un terminal mobile (smartphones, tablette) des utilisateurs des applications
cibles, en passant par le réseau data. Contrairement aux SMS, les notifications peuvent
enrichir l’expérience utilisateur et créer de l’engagement en ajoutant du contenu riche
comme de l’audio ou des images. Le message reçu par l’utilisateur ayant marqué son
accord via une application installé sur son mobile ou un site mobile consulté. Elles sont
caractérisées par les attributs suivants :
- Des messages instantanés, ciblés à un utilisateur ;

- Des notifications contextuelles basées selon des critères (fréquence, plage
d’horaire de réception, type d’information) ;
- Les notifications sont reçues indépendamment de l’état d’activité ou
d’inactivité de l’application ;
- Un lien direct avec les utilisateurs.
Il s’affiche sur le téléphone sous différentes présentations en fonction de l’application

qui l’intègre. Le choix du type de la notification est défini par le développeur et peut être
modifié par l’utilisateur dans le menu “Réglages/Notifications”. On retrouve en générale
les types d’affichage suivant :
23 | P a g e
- la bannière : la notification s’affiche dans la barre des notifications ;

- l’alerte : la notification s’affiche dans un pop-up ;
- le badge : une pastille s’affiche sur l’icône de l’application ;
- le signal sonore : un son est émis à la réception de la notification sous
réserve que le fichier audio soit présent sur le terminal.
Cette stratégie mobile a de nombreux avantages :
- Les notifications bénéficient d’un important taux d’ouverture et de lecture

(similaire à celui des SMS qui est de 95%), c’est donc un excellent outil de
communication et d’engagement client ;
- L’envoi de notifications est quasiment gratuit ! (Il faut tout de même
développer le serveur de push et le client en amont qui ont un coût) ;
- Call-to-action : les notifications ont souvent deux options. Une invitation à
fermer le pop-up ou à découvrir plus de contenus.
Cependant, leur utilisation impose des recommandations et des contraintes :
- La connexion Internet est obligatoire ;

- Laisser le choix à l’utilisateur d’activer/Désactiver la notification ;
- Eviter d’inonder les utilisateurs sous un flot de messages non pertinents
pouvant les amener à désinstaller l’application ;
III.3.2 Principe de fonctionnement et architecture technique

D’un point de vue technique, quel que soit le type d’application cliente (Web App,
appli native), les plateformes de notifications font intervenir les services de push
propriétaire de chaque plateforme mobile. Ainsi, l’envoie de notification passe par les
mécanismes de push propre à chaque OS mobile. Pour les principales OS qui équipent la
plupart des terminaux mobiles on a :
- Pour Android : Google FIREBASE anciennement GCM (Google Cloud Messaging)

;
- Pour IOS : APNS (Apple Push Notification Service) ;
- Pour Windows Phone : MPNS (Microsoft Push Notification Service).
Le schéma ci-dessous présente le fonctionnement d’une plateforme de notification push

mobile :
24 | P a g e
Figure III.1 : Architecture standard système de notification push mobile

1. À chaque ouverture de l’application mobile, demande d’un identifiant unique
(token, URL, ID…) au serveur de sa plateforme pour identifier l’application sur un
mobile spécifique ;
2. Envoi de l’identifiant unique de la plateforme serveur push à l’application mobile ;
3. Transmission de l’identifiant du client mobile au serveur d’envoi qui va le stocker
(ou le mettre à jour) dans une base de données ;
4. Pour l’envoi d’une notification push, votre serveur d’envoi transmet la notification
push au serveur push de plateforme cible. Pour cela il indique l’identifiant du client
mobile concerné et le message associé ;
5. Le serveur push de la plateforme vérifie les paramètres push (autorisations et
identité de l’application) et transmet la notification au mobile ciblé ;
6. Les serveurs push des plateformes envoient immédiatement un rapport de
réception des notifications pour mettre la base d’identifiants à jour (selon les
désinstallations et la désactivation des notifications).
Mettre en place son serveur de notifications requiert de traiter toutes les contraintes
selon les plateformes mais également de devoir maintenir à jour la liste des tokens des
appareils. Il existe pour cela des solutions en SaaS qui permettent de gérer les
notifications push selon les plateformes au cas où nous n’aurions pas les ressources pour
le faire nous-mêmes.
Pour résumer les notifications push sur les 3 plateformes principales, nous présentons
un tableau récapitulatif des spécifications techniques :
25 | P a g e
Tableau III.1 : Tableau récapitulatif des spécifications techniques des notifications mobile
III.4 Architecture cible de la plateforme de notification

III.4.1 L’architecture globale de la plateforme : Client-serveur 3 tiers
26 | P a g e
Figure III.3 : Architecture globale plateforme de notification mobile

1. L’application demande au serveur de sa plateforme un token permettant
d’identifier l’application sur un appareil donné ;
2. L’application envoie le token au serveur de notifications via Http ;
3. Le serveur de notifications doit sauvegarder en base les différents tokens ;
4. Le serveur émet une requête de notification à la plateforme ciblée (un message
+ un token) ;
5. La plateforme se charge d’envoyer la notification sur le smartphone ;
6. Le serveur de notification doit s’assurer de maintenir une liste de tokens à jour
(désinstallation de l’application, désactivation des notifications, …).
De façon plus simplifiée, en rendant transparent le dispositif de push des OS mobiles
on a la présentation schématique suivante :
27 | P a g e
HTTP HTTPS HTTPS
IV. EXPEDITEUR SERVEUR SERVEUR PUSH

CLIENT/ABONNES
D’ENVOI PROPRIETAIRE
Figure III.4 : Plateforme de notification mobile
IV.1.1 Serveur d’application web d’envoi
C’est le serveur http qui gère le noyau de l'application d’envoi de notification aux
clients autorisés à s'y connecter.
IV.1.2 Serveur de base de données
C’est un serveur SGBDR qui stocke l'ensemble des données métier et techniques
nécessaires au bon fonctionnement de l'application.
IV.1.3 L’application mobile : Application mobile native

Les technologies natives sont souvent exploitées pour apporter une expérience
utilisateur poussée (off-line) dans les cas de figure d’un usage récurrent qui justifie un
téléchargement avec une présence de l’application sur le bureau du téléphone de
l’utilisateur. Elles permettent de faire appel aux couches basses du smartphone, c’est à
dire aux fonctions matérielles comme l’accéléromètre, le GPS, les affichages systèmes de
type push, badge, le cache local, les optiques, etc. Ci-dessous le tableau de
correspondance des OS mobile et des technologies mobile.
Ci-dessous les types de technologie applicative et une série de questions à se
poser pour orienter son choix (Web App – App Native – Application Hybride).
28 | P a g e
Figure III.5.1 : technologies applicatives mobiles
Figure III.5 : Check-list pour le choix d’une technologie
IV.2 Les modèles conceptuels de l’application : les diagrammes UML de notre

système
29 | P a g e
Nous présenterons les différents diagrammes qui modélisent notre perception de la

future solution en termes des cas d’utilisation, d’interaction et des objets manipulés.
IV.2.1 Diagramme des cas d’utilisation (Comportement)
Ce diagramme permet d’identifier les possibilités d’interaction entre le système
et les acteurs (intervenants extérieures aux systèmes). Il permet de représenter toutes
les fonctionnalités que le système doit fournir ou délivrer.
 Tableau des acteurs et des rôles
Acteur Rôle
Abonné (utilisateur) - S’inscrire sur la plateforme
- Se connecter
- S’abonner aux services (Rubriques)
- Se désabonner à un service
- Ouvrir un message
- Se déconnecter
Gestionnaire de la - Rédiger / Formater message à notifier
plateforme - Programmer message à envoyer
(Exploitant) - Envoyer message
Administrateur de la - Connecter système source (fournisseur de message)
plateforme - Déconnecter système source
- Définir groupe utilisateur
- Supprimer compte devenu inactif
- Effectuer mise à jour des applicatifs de la plateforme
Système du SIB - Se connecter
- Envoyer message
- Se déconnecter
Tableau III.2 : Tableau des acteurs et des rôles
30 | P a g e
Définir groupe
utilisateur
Désabonner Effectuer mise à
jour
S'inscrire
Connecter système
Utilisateur
S'authentifier Administrateur plateforme
S'abonner Déconnecter
système
Agent DGBF
Public
Ouvrir message Supprimer contact

inactif
Envoyer message
Composer/
Programmer
Formater
message
message
Système éléctronique
Gestionnaire plateforme
Digramme III.1 : Digramme du cas d’utilisation

Du contexte de l’application, nous identifions douze cas d’utilisation codifiés
comme suite :
N° Cas d’utilisation Code Résumé

1 S’inscrire UC001 Télécharger l’application et rentrer ces
informations d’inscription
2 S’authentifier UC002 Vérifier l’identité du demandeur d’accès
au système
3 S’abonner / Souscrire UC003 Choisir les rubriques ou services pour
lesquels nous souhaitons être notifié
4 Se désabonner UC004 Quitter cette option d’abonnement pour
ne plus être notifié
5 Ouvrir un message UC005 Cliquer sur la notification pour consulter le
message
6 Formater un message UC006 Composer le message à notifier
7 Programmer un message UC007 Automatiser l’envoi d’un message
31 | P a g e
8 Envoyer message UC008 Envoyer les notifications sur les mobiles

cibles
9 Créer groupe utilisateur UC009 Paramétrer les profils utilisateur
10 Supprimer contact UC010 Désactiver un compte
11 Connecter Système UC011 Etablir la connexion avec le serveur
d’envoi
12 Déconnecter Système UC012 Couper la connexion avec le serveur
d’envoi
Tableau III.3 : Liste des cas d’utilisation
IV.2.2 Description textuelle du cas d’utilisation

Pour une meilleure description du comportement du système, en plus du
diagramme des cas d’utilisation, UML proposent de faire une description textuelle du
cas d’utilisation afin de rendre plus lisible et donc plus compréhensif le diagramme du
cas d’utilisation.
 Cas d’utilisation « S’inscrire »
Cas d’utilisation UC001

Objectif Disposer d’un accès au service de notification
Acteur - Abonné / utilisateur.
Précondition - Disponibilité d’une connexion Internet ;
- Application store de la plateforme mobile installée (Play
Store)
Post-condition Accès au service de notification
Scenario nominal 1. Lancer l’application de la boutique en ligne
2. le store App affiche la page de recherche
3. Rechercher et sélectionner l’application de notification par
son nom
4. lancer l’installation de l’application de notification
5. le système mobile termine l’installation de l’application
6. l’application se lance et affiche un formulaire à renseigner
7. l’abonné remplit les champs du formulaire et valide sa saisie
8. le système l’enregistre et affiche l’interface d’accueil /
paramétrage.
Scenario alternatif Cas 1 : Installation échoué
1. Le système affiche un message d’erreur et demande de
vérifier la connexion internet
Cas 2 : les champs du formulaire n’ont pas été correctement
renseignés
vérifier les champs à renseigner.
Tableau III.4 : Description Textuelle du cas d’utilisation <S’inscrire>
32 | P a g e
 Cas d’utilisation « S’authentifier »

Objectif Identification et autorisation d’accès
Acteur - Abonné ;
- Administrateur ;
- Exploitant ;
- Autres système.
Précondition - L’application doit être installée sur le smartphone de
l’utilisateur ;
- Disponibilité d’une connexion Internet.
Post-condition Accès aux diverses fonctionnalités de l’application dont le
profil donne droit.
Scenario nominal 1. L’utilisateur lance l’application.
2. L’application affiche le formulaire d’authentification (login
et mot de passe).
3. L’abonné saisit son login et son mot de passe et valide
4. Le système vérifie les champs (champs obligatoires,..).
5. Si L’abonné est identifié, le système affiche l’interface
d’accueil.
Scenario alternatif Cas 1 : l’utilisateur introduit des paramètres
d’authentifications Incorrectes.
1. Le système affiche un message d’erreur et demande à
l’utilisateur de vérifier l’ensemble
des champs.
Tableau III.5 : Description Textuelle du cas d’utilisation <S’authentifier>
 Cas d’utilisation « S’abonner au service »

Objectif Choisir les rubriques ou services pour lesquels nous souhaitons
être notifié
Acteur - Utilisateur
l’utilisateur ;
Post-condition Accès aux services de notification souscris
Scenario nominal 1. L’abonné lance l’application.
2. L’application affiche le formulaire Paramétrage/Notification.
3. L’abonné coche les services qui l’intéressent et valide
4. Le système enregistre l’abonnement et affiche
« Abonnement effectué »
Scenario alternatif Cas 1 : l’enregistrement échoue
1. Le système affiche un message d’erreur et demande au de
vérifier la connexion internet.
Tableau III.6 : Description Textuelle du cas d’utilisation <S’abonner au service>
33 | P a g e
 Cas d’utilisation « Se désabonner aux services »

Objectif Paramétrer les services ou rubriques pour lesquels nous
souhaitons ne plus être notifié
l’utilisateur ;
Post-condition Accès aux services de notification souscris
Scenario nominal 1. L’abonné lance l’application.
2. L’application affiche le formulaire Paramétrage/Notification.
3. L’abonné décoche les services qui ne l’intéressent plus et
valide
4. Le système enregistre le désabonnement et affiche
« Désabonnement effectué »
Scenario alternatif Cas 1 : l’enregistrement échoue
1. Le système affiche un message d’erreur et demande au de
vérifier la connexion internet.
Tableau III.7 : Description Textuelle du cas d’utilisation <Se désabonner au service>
 Cas d’utilisation « Ouvrir un message »

Objectif Consulter le message
Précondition - Souscription aux services effectuée
- Réception d’une notification
Post-condition Message lu
Scenario nominal 1. L’abonné clique sur l’icône de la notification reçue
2. L’application affiche le message.
3. L’abonné consulte le message
Scenario alternatif
Tableau III.8 : Description Textuelle du cas d’utilisation <Ouvrir un message>
 Cas d’utilisation «Formater un message»

Objectif Editer le message
Acteur - exploitant
Précondition - Information à notifiée
- Disposer d’un éditeur de texte ;
Post-condition Message à notifié
34 | P a g e
Scenario nominal 1. lancer l’éditeur de texte l’application.

2. Saisir le texte du message.
4. Enregistrer texte du message.
Scenario alternatif
Tableau III.9 : Description Textuelle du cas d’utilisation < Formater un message >
 Cas d’utilisation « Programmer l’envoi un message »

Objectif Planifier l’envoi automatique du message
Acteur - Exploitant
Précondition - Message édité ;
- Application d’envoi ouverte
Post-condition Envoi programmé
Scenario nominal 1. L’Exploitant lance l’application d’édition et d’envoi de
notification
2. Le système affiche la page d’authentification
3. L’exploitant s’authentifie et se connecte
4. L’application affiche le page formulaire d’envoi
5. L’abonné renseigne les paramètres d’envoi automatique : le
titre du message, le message, date et heure d’envoi, les
destinataires.
6. Le système enregistre l’envoi automatique du message
7. l’exploitant se déconnecte
Scenario alternatif
Tableau III.10 : Description Textuelle du cas d’utilisation < Programmer l’envoi un
message >
 Cas d’utilisation « Envoyer un message »

Objectif Planifier l’envoi automatique du message
Acteur - Exploitant
- Système
Précondition - Message édité
Post-condition Notification envoyée
Scenario nominal 1. L’Exploitant lance l’application d’édition et d’envoi de
notification
3. L’exploitant / Système s’authentifie et se connecte
4. L’application affiche le page formulaire d’envoi
5. L’Exploitant renseigne les paramètres d’envoi : le titre du
message, le message, le ou les destinataires
6. l’exploitant / système expéditeur valide l’envoi en cliquant
sur le bouton envoyer
35 | P a g e
7. Le système délivre la notification sur les plateformes

mobiles
8. l’exploitant se déconnecte
Scenario alternatif Cas 1 : l’envoi échoue
vérifier la connexion internet et de réessayer.
Tableau III.11 : Description Textuelle du cas d’utilisation < Envoyer un message >
 Cas d’utilisation « Créer groupe utilisateur »

Objectif Créer des profils utilisateur
Acteur - Administrateur
Précondition Compte administrateur crée
Post-condition Groupe utilisateur crée
Scenario nominal 1. L’administrateur lance l’application back-end
d’administration
3. L’administrateur s’authentifie et se connecte
4. L’application back-end affiche le page formulaire de gestion
de compte utilisateur et de droit
5. L’administrateur renseigne les paramètres de création de
profil ou groupe utilisateur : le nom, les droit
6 L’administrateur valide
7. Le système crée le groupe utilisateur x
8. L’administrateur se déconnecte
Scenario alternatif Cas 1 : la création échoue
vérifier les paramètres et de réessayer.
Tableau III.12 : Description Textuelle du cas d’utilisation < Créer groupe utilisateur >
 Cas d’utilisation « Supprimer compte utilisateur »

Objectif Désactiver compte utilisateur
Précondition Compte utilisateur existant
Post-condition utilisateur plus notifié
d’administration
36 | P a g e
5. L’administrateur sélectionne le compte et valide la

désactivation
6. Le système désactive le compte
Scenario alternatif Cas 1 : la suppression échoue
Tableau III.13 : Description Textuelle du cas d’utilisation < Supprimer compte utilisateur
>
 Cas d’utilisation « Autoriser système à se connecter »

Objectif Donner accès à un système à s’interconnecter pour envoyer
des notifications
Précondition Contrat d’interface web service
Post-condition Système autorisé à se connecter
d’administration
5. L’administrateur crée un compte et le lie au système à
connecter
6. Le système génère une clé / jeton d’autorisation pour le
système à connecter
7. L’administrateur récupère cette clé et la communique à
l’autre système
Scenario alternatif Cas 1 : l’opération échoue
Tableau III.14 : Description Textuelle du cas d’utilisation < Autoriser système à se
connecter >
 Cas d’utilisation « Déconnecter Système »

Objectif Refuser un accès à un système à s’interconnecter pour
envoyer des notifications
Précondition Contrat d’interface web service
Post-condition Système autorisé à se connecter
37 | P a g e

d’administration
4. L’application back-office affiche le page formulaire de
gestion de compte utilisateur et de droit
5. L’administrateur désactive le compte lié au système à
connecter
6. Le système enregistre l’opération
Scenario alternatif Cas 1 : l’opération échoue
Tableau III.15 : Description Textuelle du cas d’utilisation < Déconnecter Système >
IV.2.3 Diagramme de séquence / cas d’utilisation (Interaction)

Les diagrammes de séquence permettre d’apporter un complément d’information
suivant un axe temporel à la description des cas d’utilisation. Ils présentent la succession
chronologique des interactions entre des acteurs et le système en termes d’opérations
réalisées dans le cas d’un scénario précis.
Dans cette partie, nous allons donc le présenter les diagrammes de séquence par
cas d’utilisation identifiés par notre diagramme des cas d’utilisation.
 Cas d’utilisation « S’inscrire »
38 | P a g e
Installation/Inscription
Interface Market App

Interface app mobile Système notification Serveur push :Firebase mobile
Utilisateur Mobile
Lancer l'application market
Afficher interface Application market
Rechercher application mobile Recherche apllication
Afficher Application sélectionnée

Lancer installation
Installation application
Icone application sur mobile()
Lancer application()
Requete de token ()
Attribuer ID()
Envoyer ID+info
Enregistrer()
Afficher interface d'inscription
Remplir formulaire()
Requete d'enregistrement
Enregistrer()
Message du succès ou erreur Confirmation inscription()
Digramme III.2 : Digramme de séquence cas « S’inscrire »
 Cas d’utilisation « s’authentifier »
39 | P a g e
DiagrammeSequence_Authentifier
Interface Application Système Notification
Utilisateur
Lancer application()
Afficher interface()
Rentrer code de connexion()
Demander verification() Verification()
Accès aux services() Compte autorisé
Invitation à s'inscrire() Code pas reconnu
Digramme III.3 : Digramme de séquence cas « S’authentifier »

 Cas d’utilisation « S’abonner / Désabonner »
DiagrammeSequence_Sabonner
Interface application mobile Système de notification
Abonné
demande interface parametrage de

notification()
Affiche interface()
Cocher / decocher services()

Requete d'enregistrement()
Enregistrement
Message de confirmation ou erreur() Confirmer abonnement()
Digramme III.4 : Digramme de séquence cas « S’abonner »
40 | P a g e
 Cas d’utilisation « Envoyer message »

DiagrammeSequence_Envoyer msg
Application web back office Serveur d'envoi Serveur push : FCM Application mobile
Administrateur
Demande d'accès interface notification Envoi code d'accès()

Vérifier compte()
OK
Afficher interface()
Renseigner destinateur et message

Requête de notification
Envoyer notification() Délivrer message
Afficher message()
Etat mobile()
Feedback()
Etat de la notification() Mise à jour des token
Digramme III.5 : Digramme de séquence cas « Envoyer message »
 Cas d’utilisation « Créer compte utilisateur »

DiagrammeSequence_Creer_Compte
Interface back-office Système
Administrateurs
demande d'accès Envoie id et pw()

Vérifier()
Afficher page d'aministration() OK()
Saisir paramètre de compte()

Créer compte()
Enregistrer compte()
Message de confirmation() Confirmation()
Digramme III.6 : Digramme de séquence cas « Créer compte utilisateur »
41 | P a g e
IV.2.4 Diagramme de classe (Vue statique)
Le diagramme de classes est considéré comme le plus important de la

modélisation orientée objet, il est le seul obligatoire lors d'une telle modélisation. Alors
que le diagramme de cas d'utilisation montre un système du point de vue des acteurs, le
diagramme de classes en montre la structure interne. Il permet de fournir une
représentation abstraite des objets appelé classe du système qui vont interagir pour
réaliser les cas d'utilisation. Chaque langage de Programmation orienté objet donne un
moyen spécifique d'implémenter le paradigme objet de ce diagramme.
Utilisateur
- Register : int GroupUser
- Nom_Utilisateur : String
- NumGroup : int
- Prenom_Utilisateur : String
- Tel_Utilisateur : String - GroupLib : int
1..*
- Ref_Utilisateur : String 1..1 + AjouterProfil () : String
- Email_Utilisateur : String + SupprimerContact () : Boolean
+ AjouterContact () : String + DefinirRubrique ( : String
Rubrique DefinirRubrique)
+ SupprimerContact () : Boolean
+ ConsulterContact () : String
+ Rechercher (Utilisateur Nom_Utilisateur, : String
Utilisateur Prenom_Utilisateur, 0..*
Utilisateur Tel_Utilisateur)
...
0..*
1..*
AccuseRecepion
- Date_Reception : java.util.Date
- Msg_Ouvert : Boolean
+ Cal_Nbre_Msg () : int
...
1..*
Notification
1..* - NumMessage : int
- Titre : String
Rubrique - DateCreation : Date
1..*
- NumRubrique : int - Contenu : String
- RubriqueLibelle : String - Source_envoi : String
- TypeRubrique : String + EnvoyerMsg () : String
+ AjoutRubrique () : String 1..1 + ProgrammerMsg () : Date
+ ModifRubrique () : String + SelectionnerDest () : String
+ SupprimRubrique () : Boolean 1..* + Formater () : Boolean
...
0..*
Notif_Sender
- Id : int
0..1
- Libelle : String
- Commentaire : String
+ Modifier () : int
...
Digramme III.7 : Digramme de classe
42 | P a g e
IV.3 Prototypage et choix des outils et de développement

Les études menées jusqu’à ce stade de notre travaux ont abouti à l’élaboration d’une
architecture et des différents modèles conceptuels de notre solution. Sur la base donc
de « dossier de conception », nous allons passer à la phase de réalisation de notre
solution. Pour cela, il nous faut des outils, de matériels et environnements de
développement adéquats pour construire en fin de compte notre solution. Et le choix de
ces outils est guidé par des objectifs de cohérence avec l’existant (environnement de
production des applicatifs) et d’obtention de livrables de qualité respectant les exigences
émises.
IV.3.1 Prototype d’interface graphique (Maquettes d’écran)
IV.3.1.1 Client : les maquettes d’écran de l’application mobile
Figure III.6 : Prototype d’interface graphique application mobile
IV.3.1.2 Back-end
43 | P a g e
Figure III.7 : Maquette d’écran front-end page Accueil
Figure III.8 : Maquette écran front-end page Créer notification
44 | P a g e
Figure III.9 : Maquette écran front-end page Envoyer notification
IV.3.2 Outils de développement et technologies :

IV.3.2.1 Coté serveur
 Langage de programmation et plateforme :
- Java EE est une plate-forme ou spécification fortement orientée serveur
pour le développement et l'exécution d'applications distribuées. Elle est composée de
deux parties essentielles :
 un ensemble de spécifications pour une infrastructure dans laquelle s'exécutent

les composants écrits en Java : un tel environnement se nomme serveur
d'applications.
 un ensemble d'API qui peut être obtenues et utilisées séparément. Pour être
utilisées, certaines nécessitent une implémentation de la part d'un fournisseur
tiers.
L'utilisation de Java EE pour développer et exécuter une application offre plusieurs

avantages :
 une architecture d'applications basée sur les composants qui permet un

découpage de l'application et donc une séparation des rôles lors du
développement
 la possibilité de s'interfacer avec le système d'information existant grâce à de
nombreuses API : JDBC, JNDI, JMS, JCA ...
45 | P a g e
 la possibilité de choisir les outils de développement et le ou les serveurs

d'applications utilisés qu'ils soient commerciaux ou libres
Elle offre une grande flexibilité dans le choix de l'architecture de l'application en

combinant les différents composants. Ce choix dépend des besoins auxquels doit
répondre l'application mais aussi des compétences dans les différentes API de Java EE.
L'architecture d'une application se découpe idéalement en au moins trois tiers (MVC) :
 la partie cliente : c'est la partie qui permet le dialogue avec l'utilisateur. Elle peut
être composée d'une application standalone, d'une application web ou d'applets
 la partie métier : c'est la partie qui encapsule les traitements (dans des EJB ou des
JavaBeans)
 la partie donnée : c'est la partie qui stocke les données (JPA)
- Java : est un langage de programmation orienté objet, développé par Sun

Microsystems et destiné à fonctionner dans une machine virtuelle. Il permet de créer
des logiciels robustes et modulaires, compatibles avec des nombreux systèmes
d’exploitation. Java est non seulement un langage de programmation puissant conçu
pour être sûr, inter plateformes, mais aussi une technologie qui est continuellement
étendu pour fournir des nouvelles caractéristiques et des bibliothèques permettant de
gérer de manière efficace des problèmes traditionnellement complexes dans les
langages de programmation classiques, tels que le multithreading, les accès aux bases
des données, la programmation réseau, l’informatique répartie. De plus, java permet
de réduire le temps de développement d’une application grâce à la réutilisation du
code développé qui facilite la maintenabilité des applications.
- JavaScript : abrégé "JS", c’est un langage de script, orienté objet,

principalement utilisé comme le langage de script des pages web. Mais il peut aussi
être utilisé sur de nombreux environnements extérieurs au navigateur tel que node.js.
 Environnement logiciel :
- JDK : Java Development Kit un ensemble de bibliothèques logicielles de
base du langage de programmation Java, ainsi que les outils avec lesquels le code
Java peut être compilé, transformé en byte code destiné à la machine virtuelle Java.
Il comprend l'environnement JRE, le compilateur Java et les API Java.
- Netbean : est un IDE (environnement de développement intégré), placé en

open source par Sun en juin 2000 sous licence CDDL et GPLv2. En plus de Java,
NetBeans permet la prise en charge native de divers langages tels le C, le C++, le
JavaScript, le XML, le Groovy, le PHP et le HTML, ou d'autres par l'ajout de greffons.
- Maven : est un gestionnaire de paquetage.
46 | P a g e
- Git : Gestionnaire de versionning.

- WildFly : anciennement JBoss Application Server ou JBoss, est un serveur
d'applications Java EE Libre écrit en Java, publié sous licence GNU LGPL. Étant écrit en
Java, il peut être utilisé sur tout système d'exploitation fournissant une machine
virtuelle Java. WildFly implémente entièrement l'ensemble des services et
spécification Java EE. Il embarque :
o Tomcat : serveur web Tomcat pour exécuter les
parties servlets et JSP des applications déployées sur le serveur ;
o JBoss Portal : Framework de portail ;
o JBoss Seam : Framework web ;
o Hibernate : Framework de persistance ;
o jBPM : moteur de workflow ;
o Drools (ou JBoss Rules) : système de gestion de règles métier.
- Oracle : serveur de base de données.
 Technologies (API et Protocoles) :

- Protocole http : Le protocole HTTP (HyperText Transfer Protocol) est le
protocole le plus utilisé sur Internet. Le but du protocole HTTP est de permettre de
transférer des messages avec des en-têtes décrivant le contenu du message en
utilisant un codage de type MIME. Ainsi donc, HTTP définit les demandes qu'un client
peut envoyer à un serveur et les réponses que le serveur peut envoyer en réponse.
Chaque demande contient une URL, qui est une chaîne qui identifie un composant
Web ou d'un objet statique, comme une page HTML ou un fichier image.
- Service Web REST : Pour des besoins d’échanger des données entre des
environnements hétérogènes. les services web de type REST sont un style
d’architecture applicative inspiré de celle du web fortement basée sur le protocole
http. Contrairement à SOAP, http ou RCP, il n’est pas un protocole encore moins un
format d’échange. Il est utilisé dans le développement d’application orienté
ressource (ROA) ou orienté donnée (DOA) dans un environnement distribué. Il s'agit
donc d'un ensemble de fonctionnalités exposées sur internet ou sur un intranet, par
et pour des applications ou machines, sans intervention humaine, de manière
synchrone ou asynchrone pour fournir des services à la demande. Dans les
spécifications Java EE, JAX-WS 2.x est l’implémentation de référence des services
Web REST et open source et intégré au serveur Glassfish. Plusieurs autres
implémentation propriétaire, dérivé de JAX-WS 2.x ont fait leur apparition :
o Jersey implémentation de référence fournie par Oracle
o RESTEasy pour Jboss et Wildfly.
- Google Firebase Cloud Messaging (FCM) : Cette API de Google permet

d’envoyer, au format JSON, un message d’une taille maximale de 4ko. Ce message
47 | P a g e
va contenir des paramètres propres à la notification, comme sa durée de vie, le ou

les destinataires, mais également des informations à traiter par le terminal. FCM
utilise deux protocoles : GCM HTTP et CCS (XMPP). Il est possible d’utiliser les deux
en même temps. Les différences entre ces protocoles sont :
1. La direction des messages :
 FCM HTTP est unidirectionnel “cloud-to-device” (downstream). C’est à dire

que l’application serveur envoie un message à GCM pour notifier un ou
plusieurs terminaux puis FCM envoie cette notification aux terminaux.
 CCS est multidirectionnel “device-to-cloud, cloud-to-device” (upstream,
downstream). L’application server utilise une connexion persistente XMPP lui
permettant d’envoyer et de recevoir des messages aux terminaux.
2. La synchronisation :
 FCM HTTP est synchrone. Tant que la réponse à la requête HTTP POST n’a pas
été reçue, l’envoi de la notification suivante est bloqué.
 CCS est asynchrone.
3. Le flux JSON :
 GCM HTTP envoi le flux JSON de manière classique via une requête HTTP
POST ;
 CCS encapsule le flux JSON dans un message XMPP.
De façon pratique, il faut se rendre à l’adresse https://console.firebase.google.com/.

Ensuite il suffit de suivre les étapes suivantes :
1. Création du projet via le bouton “CREATE PROJECT” puis, lors du retour à la page
principale, cliquez sur votre projet et vous aurez les “Project Id” et “Project
Number” ;
2. Activation du service de notifications en allant dans “APIs & Auth” > “API”.
Ajoutez ensuite le service “Google Cloud Messaging for Android” ;
3. Génération de l'”API Key” via le menu “APIs & Auth” > “Credentials”. Cliquez sur
le bouton “Create New Key” de “Public API access”. Ensuite, générez une “Server
key”. Vous pouvez laisser la zone de saisie des IPs vide, puis cliquez sur “Create”.
Vous obtenez alors l'”API Key”.
- JSF : Java Server Faces" est un Framework de type MVC, destiné aux
applications web respectant l'architecture Java EE. Le premier objectif de JSF, est
de procurer un environnement de développement permettant de construire une
interface de type web, sans devoir toucher au code HTML et JavaScript. Ceci est
réalisé par la mise en place d'un mapping entre l'HTML et les objets concernés. JSF
est donc basé sur la notion de composants, comparable à celle de Swing, ou l'état
48 | P a g e
de ces composants est sauvegardé puis restauré au retour de la requête. Il

permet :
o une séparation nette entre la couche de présentation et les autres

couches
o le mapping HTML/Objet (voir Annexes)
o un modèle riche de composants graphiques réutilisables
o une gestion de l'état de l'interface entre les différentes requêtes
o une liaison simple entre les actions côté client de l'utilisateur et le code
Java correspondant côté serveur
o la création de composants customs grâce à une API
o le support de différents clients (HTML, WML, XML, ...) grâce à la
séparation des problématiques de construction de l'interface et du rendu
de cette interface.
- Json : Le format Json (JavaScript Object Notation) est un format de données

textuel léger et facilement interprétable. Il permet de représenter de
l’information structurée comme le permet XML par exemple. Un objet Json est un
ensemble de couples clé/valeur.
Figure III.6 : Format de donnés JSON
IV.3.2.2 Coté client

 Langage de programmation :
- Java : C’est le langage de programmation le plus utilisé et le langage par
défaut pour le développement d’applications natives Android. La force de Java,
comparativement à des langages plus « fermés » comme Swift, conçu pour iOS
seulement, Java n’est pas uniquement destiné à Android, et peut être utilisé comme
code de base pour le développement de programmes qui tourneront sur presque
tous les appareils possibles et imaginables. De plus, la communauté de
programmeurs Java est très grande, ce qui garantit une certaine assistance aux
49 | P a g e
développeurs en cas de difficultés. le problème a sûrement déjà été rencontré et

résolu. Java est une valeur sûre pour conduire avec un succès notre projet.
 Environnement logiciel :
- SDK Android : est un kit de développement pour application Android
gratuit qui intègre une grande variété d’outils. Il inclut un éditeur de code, un
débogueur, des bibliothèques logicielles, un émulateur basé sur QEMU, de la
documentation, des exemples de code et des tutoriaux. Ce SDK propose aussi un
plug-in pour l’IDE Java Eclipse qui aidera à générer les ressources XML (comme
les animations ou les menus). Il est téléchargeable à ce lien
https://developer.android.com/studio/.
- Android Studio : est un environnement de développement pour
développer des applications mobiles Android. Il est basé sur IntelliJ IDEA et utilise
le moteur de production Gradle. Il peut être téléchargé sous les systèmes
d'exploitation Windows, macOS et Linux.
 Technologies (API et Protocoles) :

- Google Firebase Cloud Messaging (FCM) : est un ensemble de services qui
fournit un flux de communication fiable et sécurisé entre le serveur Google (Firebase)
et les appareils distants (où l'application est installée) dans l'objectif d'envoyer et
recevoir des messages de notifications. Il était précédemment appelé GCM (Google
Cloud Messaging). Il est supporté par les applications clientes Android naturellement,
IOS, et Web (Java script+HTML5). Il a la capacité d’envoyer environ 170 milliard de
message par jour. Pour l’implémentation pratique, il faut aller à
l'adresse https://console.firebase.google.com/ puis cliquez sur le bouton "Ajouter un
projet" (1). Ensuite, à l'intérieur de la fenêtre qui apparaît, renseignez le nom de
votre projet et le pays où vous vous situez (2). Et suivre les instructions.
Au terme des travaux relatifs à la phase de conception de notre étude, nous avons
obtenu les résultats en termes d’architecture et de modèle de conception suivant :
- L’architecture de la solution ;
- L’architecture applicative ;
- Les diagrammes des cas d’utilisation et de séquence qui se complètent ;
- Le diagramme de classe ;
- les prototypes d’interface graphique ;
- Et enfin le choix des outils et environnement de développement /
Production.
A partir donc de ces éléments qui constituent en quelque sorte notre « dossier de
conception, nous allons entamer l’ultime phase qui consistera en à la réalisation à
proprement parlé de notre solution. Et à terme, nous obtiendrons la plateforme
numérique qui met en œuvre notre solution à la problématique soulevée par notre étude.
50 | P a g e
V. REALISATION
Il s’agira d’une part de procéder au développement (Programmation) des applicatifs
et d’autre part, de déployer l’infrastructure (matériel et réseau) devant les héberger. Par
suite, effectuer les tests fonctionnels et techniques pour s’assurer du bon fonctionnement
de notre solution en situation de production.
V.1 Infrastructures matérielles & réseau de mise en production
Notre solution implémente une plateforme digitale de notification mobile qui est
constituée comme suite :
- Un serveur d’envoi d’architecture Java EE, hébergé dans le data center de la DTI ;
- Un serveur SGBD Oracle, hébergé dans le data center de la DTI ;
- Une application web de back-office (administration et exploitation) ;
- Une application native spécifique à chaque OS mobile, à télécharger et installer
sur le terminal mobil utilisateur ;
- Un serveur push, serveur tiers qui se charge de délivrer les messages sur les
smartphones : celui de Google Firebase.
V.2 Diagramme des composants applicatifs
Nous présentons maintenant le diagramme de composant qui vise à mettre en

évidence l’architecture général de l’application et les dépendances entre les divers
composants.
SGBD
Oracle instance
JDBC Google APP Engine
Serveur d'application Java EE Firebase HTTP/XMTP

Composant service
(EJB+JPA)
Terminal mobile
Service web REST HTTP Application
mobile
Websocket /HTTPS
OS mobile
HTTP
Interface Back-office
Navigateur
Digramme IV.1 : Digramme de composant
51 | P a g e
V.3 Présentation des IHM réalisé
V.4 Déploiement
Le diagramme de déploiement permet d'illustrer l'architecture physique du système
et de montrer la relation entre ses différents nœuds. Voici le diagramme de déploiement
de notre application :
Poste client
Navigateur
HTTP
Serveur d'application Java EE

OS mobile : Magazin application
mobile
Conteneur Web (les

servlets, les pages JSF E budget.apk
Conteneur EJB
Websocket / HTTP
Service web REST
HTTPS Smarphone
E budget.apk
JDBC
Serveur SGBD
Oracle
Digramme IV.2 : Digramme de déploiement
52 | P a g e
CONCLUSION
Les administrations publiques, dans leur quête de modernisation et de performance à
l’image des entreprises privées, rencontrent beaucoup de difficultés d’adaptation aux
technologies nouvelles auxquelles elles ont recours. Ces difficultés sont d’ailleurs liées au
niveau de maturité des TIC dans nos administrations et dans nos Etats en général.
Cependant, si cette adaptation représente un défi, c’est aussi une opportunité sans
précèdent pour le secteur public, celle de réduire l’écart de productivité, d’optimiser ses
processus, d’améliorer sa relation avec les usagers. Le gouvernement à travers ces
administrations et institutions peut mener une multitude de petites actions ayant une
grande portée grâce aux technologies mobiles, en termes d’impact sur la qualité des
services publiques offertes. Pour cela, elles devront revoir leur processus métier, mais
aussi la façon dont elles interagissent avec leur environnement extérieur. La DGBF l’a
compris, en menant des chantiers de transformation numérique dans le cadre du projet
de refonte. Elle a perçu l’opportunité que lui donnaient les TIC d’être une administration
performante et innovante. Et qu’en intégrant de façon intelligente ces outils
électroniques, elle pouvait devenir le partenaire privilégié des citoyens dans l’atteinte de
ces objectifs budgétaires et économiques. La réalisation de ce projet «Mise en place d’une
plateforme de notification budgétaire », qui s’inscrit étroitement dans cette vision de la
DGBF contribue à la « construction » du nouvel système d’information budgétaire (SIB)
qui à terme deviendra la plateforme digitale budgétaire. Bien plus qu’une « brique
applicative » apporté au SIB, elle change radicalement la façon de la DGBF d’interagir, de
communiquer avec tous les usagers (agent DGBF, grand publique) en simplifiant, en
facilitant l’accès à l’information budgétaire. Et en cela elle contribue à l’atteinte de l’un
des objectifs de la DGBF : être une administration transparente, qui se rapproche du
citoyen.
53 | P a g e
VI. SOURCES ET BIBLIOGRAPHIES
[1] https://www2.deloitte.com/content/dam/Deloitte/fr/Documents/Associations
-fondations/Deloitte_ServicePublicnomade_022014.pdf
Rapport d’étude
Titre du document : Les services publics nomades : de l’amélioration de la
performance à l’émergence de nouveaux usages
[2] https://www.gsmaintelligence.com/research/?file=dd7760bf439236e808ea61
ee986845eb&download
Rapport d’étude sur …..par GSM Association
[3] http://www.experip.com/these-Mehdi-BEZZAI.html#_Toc304915604
Thèse Professionnelle
«Comment ouvrir son système d’information aux applications mobiles ?»
Par Mehdi BEZZAÏ
[4] https://journals.openedition.org/edc/1135
Les TIC comme « levier de la modernisation de l’administration » : de la
nécessité de contextualiser et de problématiser par Bruno Raoul
[5] https://journals.openedition.org/pyramides/989
Introduction : Des outils numériques pour améliorer le fonctionnement de
l’état : solutions ou problèmes ?
Luc Wilkin du Centre d'étude et de recherche en administration publique
[6] https://www.gsmaintelligence.com/research/?file=dd7760bf439236e808ea61
ee986845eb&download
L'économie mobile en Afrique de l'ouest par GSM Association
[7] https://www.researchgate.net/publication/312174531_Mobile-
Based_Notification_System_for_University's_Events
Thèse Professionnelle :
«Mobile-Based_Notification_System_for_University's_Events»
Par Qusay Al-Zoubi
[8] https://developers.google.com/web/fundamentals/push-notifications/display-
a-notification
https://www.upsellium.com/pwa-creer-des-notifications-push-avec-firebase/
Tutorial sur push-notifications.
[9] https://developers.google.com/web/fundamentals/push-notifications/how-
push-works
Tutorial : push-notifications/how-push-works
[10] https://firebase.google.com/docs/cloud-messaging/
Google firebase cloud-messaging
[11] E-gouvernement/e-administration: la recherche de l’efficience et une nouvelle
relation aux clients de François Kientzler
[12] Meurer, A. 2002. «L'intégration d'Internet dans les processus administratifs»,
E-gouvernement/e-administration dans la sécurité sociale. Genève, association
internationale de la sécurité sociale
[13] http://undpegov.org
54 | P a g e
Technologies mobiles et autonomisation : Renforcer le développement humain

par la participation et l’innovation rapport a été élaboré par l’équipe e-
gouvernance et accès à l’information au sein du la gouvernance démocratique
du bureau pour les politiques de développement du Pnu groupe de D à new
York. il a été rédigé par Raúl Zambrano, conseiller politique, et Ruhiya Kristine
Seward, analyste de recherche, avec le soutien de Stephanie Ludwig,
assistante de recherche. ce premier rapport est fondé sur une recherche, une
rédaction et une maquette initiales par Mari Denby et Oscar Salazar, et a été
commandité par le PnuD au début 2010.
[14] http://www.itu.int/ITU-D/ict/statistics/
Statistique produites par l’UIT (Union International des Télécommunication)
l'agence des Nations unies pour le développement spécialisé dans les
technologies de l'information et de la communication, basée à Genève.
[15] http://www.geneve.ch/obstech/referentiel/referentiels.html
e-Administration : enjeux et facteurs clés de succès par Christine Aïdonidis,
Giorgio Pauletto du Département des constructions et des technologies de
l'information de Genève.
VII. LES ANNEXES

VII.1 Annexe 1
VII.2 Annexe 2
55 | P a g e

SIB Mobile

Transféré par

Informations du document

Titre original

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

SIB Mobile

Transféré par

Droits d'auteur :

Formats disponibles

DGBF : PORTAIL D’ACCES ET

Auteur : DTI (Direction des traitements informatiques)

Table des matières

IV.3 Prototypage et choix des outils et de développement................................................ 43

Table des figures et diagrammes

Liste des Tableaux

Glossaire des Acronymes

Domaine Technologie de l’information et de la communication

Notification push Sur un mobile, une notification push est un message

I. PRESENTATION DU CADRE DU PROJET D’ETUDE

I.3 Objectifs et résultats attendus

Mise en place d’une plateforme budgétaire mobile permettant aux

II. ETUDE ET ANALYSE

Destinataires Informations notifiées Moyens utilisés

Usagers - Opérateurs - Marché publique - Magazine et revu

Tableau II.1 Tableau récapitulatif des informations notifiées

 La gestion des habilitations (réf. Guide de procédure de la DGBF) ;

 Politique de sécurité (réf. Guide PAQ, Charte informatique).

- Au niveau des supports ou canaux

 Le courrier physique ou postal ;

II.2 Analyse diagnostique du système existant

Le tableau « II.1 Tableau récapitulatif des informations notifiées » met en relief un

en avant pour justifier l’adoption et le déploiement de ces outils dans le contexte du

En Côte d’ivoire, le secteur a suivi la même tendance au point qu’Abidjan a gagné

II.3.2 Les Systèmes d’exploitation mobiles et applications mobiles

Figure II.2 : Part de marché OS mobile (Source http://gs.statcounter.com)

Service Accueil ou Portail (Page application mobile d’accès aux services

II.4.1 Spécification fonctionnelle

- Un abonné doit pouvoir s’inscrire sur la plateforme via le mobile ;

II.4.2 Spécification non fonctionnelle

Ce sont des exigences qui identifient certaines conditions internes et externes du

Les normes description Exigence

Performance - Temps de réponse : le temps de - En comparaison à un

Compatibilité - La compatibilité avec des applications Le client mobile doit

- La conformité aux standards de design - Technologie : Java

Tableau II.2 : Tableau des besoins non fonctionnels

III. CONCEPTION DE NOTRE SOLUTION

- Le processus unifié est à base de composants ;

- Un modèle de cas d'utilisation ;

- Une représentation de l'architecture.

III.2 Le Portail mobile : Interface d’accès aux services grand publique

LES ECRANS DE L’APPLICATIONS MOBILE

Page Accueil Page Authentification

Page d’appel de consultation notification Page Paramétrage

Page Installation notification Page formulaire Inscription

Page Modification compte Page Menu

Page Applications disponibles Page Consultation historique Notification

Page Paramétrage service de notification

III.3 La plateforme de Notification et back-end

- Des messages instantanés, ciblés à un utilisateur ;

Il s’affiche sur le téléphone sous différentes présentations en fonction de l’application

- la bannière : la notification s’affiche dans la barre des notifications ;

Cette stratégie mobile a de nombreux avantages :

- Les notifications bénéficient d’un important taux d’ouverture et de lecture

Cependant, leur utilisation impose des recommandations et des contraintes :

- La connexion Internet est obligatoire ;

III.3.2 Principe de fonctionnement et architecture technique

- Pour Android : Google FIREBASE anciennement GCM (Google Cloud Messaging)

Le schéma ci-dessous présente le fonctionnement d’une plateforme de notification push

Figure III.1 : Architecture standard système de notification push mobile

III.4 Architecture cible de la plateforme de notification

Figure III.3 : Architecture globale plateforme de notification mobile

HTTP HTTPS HTTPS