Rapport de stage PFE - Mémoire master: Développement d'une application Android

Master spécialisé :
Qualité du Logiciel
Mémoire du stage professionnel
DEVELOPPEMENT D’UNE APPLICATION MOBILE ANDROID
Réalisé par :
ELATTAOUI BADR
Date de soutenance : 17 Juillet 2019
JURY :
Stage professionnel effectué à :
MOBIBLANC SARL
Nom et prénom Etablissement Qualité
Mme. AMJAD SOUAD Faculté des Sciences Tétouan Présidente
Mme. BENAMEUR LAMYAE Faculté des Sciences Tétouan Examinatrice
Mlle. SAFOUH CHAIMAE Mobiblanc
Encadrante
professionnelle
M. JELLOULI ISMAIL Faculté des Sciences Tétouan
Encadrant
universitaire
Université Abdelmalek Essaâdi Faculté des Sciences Tétouan

II
Dédicace
A ma source de motivation, à ceux qui n’ont cessé de me soutenir,
m’encourager et me guider tout au long de ma vie, à ceux qui ont tout
sacrifié pour mon bien-être, à mes chers parents, que le Dieu les préserve et
leur accorde une longue vie jusqu’à ce qu’ils me voient répondre à leurs
attentes. Aucun mot ne pourra exprimer ma vie gratitude et ma
reconnaissance à votre égard.
A ma chère sœur Noura, je vous dédie ce travail, et je vous souhaite
un avenir plein de joie, de la réussite, du bonheur et de la sérénité.
A mes grands-parents, tantes, oncles, cousins, cousines et tous les
membres de ma grande et aimable famille qui m’ont toujours soutenu et
poussé à donner le meilleur de moi-même. Je vous porte un grand respect.
A tous mes amis avec lesquels j’ai partagé mes moments de joie et de
bonheur.
Badr,

III
Remerciements
Au terme de mon projet de fin d’études, je tiens à témoigner de mes sincères remerciements
à toutes les personnes qui ont contribué de près ou de loin au bon déroulement de mon stage de fin
d’études et à l’élaboration de ce modeste travail.
Du côté de MOBIBLANC, je tiens à exprimer ma profonde reconnaissance à Mlle.
SAFOUH Chaimaa et Mlle. MOUADDINE Jihad, qui m’ont accompagné durant tout ce travail,
pour leur disponibilité, pour la confiance qu’ils ont su m’accorder et les conseils précieux qu’il
m’a prodigués tout au long de la réalisation de ce projet
Mes plus vifs remerciements s’adressent aussi à tout le cadre professoral et administratif
de la formation Master spécialisé Qualité du logiciel, pour leur patience et savoir qui nous a
illuminés durant ces deux années de formation.
Je tiens à remercier sincèrement les membres du jury qui me font le grand honneur
d'évaluer ce travail.
Enfin et surtout, je ne remercierai jamais assez ma famille et en particulier mes parents
pour m’avoir soutenue depuis le début. Qu'ils trouvent ici l’expression de tout mon amour.
Toutes ces personnes ont contribué par leur disponibilité et leur bonne humeur, et m’ont
permis de développer mes compétences. Je leur en suis particulièrement reconnaissant puisque
grâce à eux, mon stage a été motivant et enrichissant.

IV
Résumé
Ce présent rapport est rédigé dans le cadre du stage PFE effectué au sein de la société
Mobiblanc. L’objectif de ce stage a été de de développer la deuxième version de l’application
mobile pour le compte d’une entreprise très connus au Maroc, Lydec. Ce projet consiste à
développer une agence en ligne pour rendre les services de Lydec accessible 24h/24 et 7j/7.
Mots clés : Android, REST, Lydec, Mobiblanc.
Abstract
This report is written as part of the PFE internship carried out within Mobiblanc. The
objective of this internship was to develop the second version of the mobile application on behalf
of a well-known company in Morocco, Lydec. This project involves developing an online agency
to make Lydec's services accessible 24/7.
Keywords : Android, REST, Lydec, Mobiblanc.

V
Table des matières
Dédicace......................................................................................................................................... II
Remerciements..............................................................................................................................III
Résumé..........................................................................................................................................IV
Abstract .........................................................................................................................................IV
Table des matières..........................................................................................................................V
Liste des Tableaux.........................................................................................................................XI
Liste des Abréviations................................................................................................................. XII
Introduction .....................................................................................................................................1
Chapitre I : Cadre générale du projet ..............................................................................................3
1. Présentation de l’organisme d’accueil..................................................................................4
1.1. Présentation de Mobiblanc ...........................................................................................4
1.2. Les clients de Mobiblanc..............................................................................................4
1.3. Equipe Mobiblanc ........................................................................................................4
1.4. Services ........................................................................................................................5
1.4.1.Développement Mobile ...........................................................................................6
1.4.2.Marketing mobile.....................................................................................................6
1.5. Fiche technique de Mobiblanc .....................................................................................7
2. Cadre générale du projet ......................................................................................................7
2.1. Présentation générale du projet ....................................................................................7
2.2. Problématique...............................................................................................................8
2.3. Solution Existante.........................................................................................................8
2.4. Solution à développer...................................................................................................9
3. Cycle de développement : ..................................................................................................10
3.1. Cycle de Test :............................................................................................................11
4. Élaboration du cahier des charges :....................................................................................11
5. Conclusion..........................................................................................................................12
Chapitre II : Analyse et spécification des besoins.........................................................................13
1. Introduction ........................................................................................................................14
2. Etude fonctionnelle ............................................................................................................14
2.1 Identification de l’acteur..............................................................................................14
2.2 Besoins fonctionnels....................................................................................................14
2.3 Les besoins non fonctionnels.......................................................................................15

VI
2.4 Diagrammes de cas d’utilisation .................................................................................16
2.4.1 Je gère mon compte................................................................................................16
2.4.2 J’agis pour ma ville................................................................................................18
2.4.3 Je contacte mon conseiller .....................................................................................19
2.4.4 Ça m’intéresse........................................................................................................19
2.4.5 Explications textuelles des cas d’utilisation...........................................................20
3. Conclusion..........................................................................................................................26
Chapitre III : Etude conceptuelle et technique ..............................................................................27
1. Introduction ........................................................................................................................28
2. Etude Technique.................................................................................................................28
2.1. Présentation d’Android...............................................................................................28
2.1.1.Introduction............................................................................................................28
2.1.2.Versions d’Android ...............................................................................................29
2.1.3.Architecture logicielle d’Android..........................................................................29
2.2. Les services web.........................................................................................................30
2.2.1.Intérêt des services web.........................................................................................30
2.2.2.Les standards des services web .............................................................................31
2.2.3.Qu’est-ce qu’une API ? .........................................................................................31
2.2.4.Qu’est-ce qu’une Api REST ?...............................................................................31
2.2.5.Api REST ou Api SOAP ?.....................................................................................32
2.2.6.Pourquoi choisir REST ? .......................................................................................33
2.3. Architecture Technique ..............................................................................................33
2.3.1.La sécurité des appels des web services ................................................................35
3. Etude conceptuelle .............................................................................................................36
3.1. Introduction ................................................................................................................36
3.2. Les modèles dynamiques............................................................................................36
3.2.1.Diagrammes d’activité...........................................................................................36
3.2.2.Diagrammes de séquences.....................................................................................39
3.3. Les modèles statiques.................................................................................................43
3.3.1.Diagramme de classe .............................................................................................43
4. Conclusion..........................................................................................................................45
Chapitre IV : Réalisation...............................................................................................................46
1. Introduction ........................................................................................................................47
2. Outils du développement....................................................................................................47
2.1. IDEs............................................................................................................................47
2.1.1.Android Studio ......................................................................................................47

VII
2.2. Outils d’analytiques....................................................................................................47
2.2.1.Facebook analytics.................................................................................................47
2.2.2.Crashlytics par Fabric............................................................................................48
2.3. Langages de programmation ......................................................................................49
2.3.1.Java ........................................................................................................................49
2.4. Outils Google .............................................................................................................49
2.4.1.Firebase..................................................................................................................49
2.4.2.Google maps..........................................................................................................49
2.5. Contrôle de version ....................................................................................................50
2.5.1.Gitlab .....................................................................................................................50
2.5.2.Git ..........................................................................................................................50
2.6. Autres outils ...............................................................................................................50
2.6.1.ProGuard................................................................................................................50
2.6.2.JSON......................................................................................................................51
2.6.3.Invision ..................................................................................................................51
2.6.4.Postman .................................................................................................................51
3. Mise en œuvre ....................................................................................................................52
3.1. Accueil........................................................................................................................52
3.2. Je contacte mon conseiller..........................................................................................54
3.3. Ça m’intéresse ............................................................................................................56
3.4. J’agis pour ma ville ....................................................................................................59
3.4.1.Ajout d’une demande.............................................................................................60
3.4.2.Liste des demandes................................................................................................65
3.4.3.Filtrer les demandes...............................................................................................68
3.5. Je gère mon compte....................................................................................................69
3.5.1.Mes contrats :.........................................................................................................70
3.5.2.Mes règlements & mes consommations ................................................................72
3.5.3.Mes impayés..........................................................................................................74
3.5.4.Paiement direct ......................................................................................................75
3.5.5.Auto relève.............................................................................................................76
3.5.6.Comment ça marche ..............................................................................................76
3.5.7.Inscription..............................................................................................................78
3.5.8.Liens externes........................................................................................................79
3.5.9.Notifications ..........................................................................................................79
3.5.10. profil.................................................................................................................80
4. Conclusion :........................................................................................................................88

VIII
Conclusion générale ......................................................................................................................89
Références .....................................................................................................................................90

IX
Liste des figures
FIGURE 1: LES CLIENTS DE MOBIBLANC ....................................................................................................................4
FIGURE 2: L'ORGANIGRAMME DE MOBIBLANC ..........................................................................................................5
FIGURE 3: CYCLE DE DEVELOPPEMENT........................................................................................................................10
FIGURE 4: CYCLE DE TEST...........................................................................................................................................11
FIGURE 5: DIAGRAMME DE CAS D'UTILISATION JE GERE MON COMPTE .........................................................................17
FIGURE 6: DIAGRAMME DE CAS D'UTILISATION J'AGIS POUR MA VILLE.........................................................................18
FIGURE 7: DIAGRAMME DE CAS D'UTILISATION JE CONTACTE MON CONSEILLER .........................................................19
FIGURE 8:DIAGRAMME DE CAS D'UTILISATION ÇA M'INTERESSE...................................................................................19
FIGURE 9: VERSIONS D'ANDROID.................................................................................................................................29
FIGURE 10: API REST ...................................................................................................................................................32
FIGURE 11: ARCHITECTURE TECHNIQUE DU PROJET.....................................................................................................34
FIGURE 12: DIAGRAMME D'ACTIVITE AJOUT D'UNE DEMANDE .....................................................................................37
FIGURE 13: DIAGRAMME D'ACTIVITE TRAITEMENT D'UNE DEMANDE ...........................................................................38
FIGURE 14: DIAGRAMME D'ACTIVITE: INSCRIPTION......................................................................................................39
FIGURE 15: DIAGRAMME D'ACTIVITE: MODIFICATION DU LOGIN ..................................................................................39
FIGURE 16: DIAGRAMME DE SEQUENCE EFFECTUER AUTO RELEVE ..............................................................................40
FIGURE 17: DIAGRAMME DE SEQUENCE INSCRIPTION ...................................................................................................41
FIGURE 18: DIAGRAMME DE CAS D'UTILISATION GESTION DU PROFIL...........................................................................42
FIGURE 19: DIAGRAMME DE SEQUENCE MODIFICATION DU LOGIN ...............................................................................43
FIGURE 20: DIAGRAMME DE CLASSES...........................................................................................................................44
FIGURE 21: FACEBOOK ANALYTICS..............................................................................................................................48
FIGURE 22: SPLASH SCREEN .........................................................................................................................................52
FIGURE 23: ACCUEL.....................................................................................................................................................53
FIGURE 24: ECRAN JE CONTACTE MON CONSEILLER .....................................................................................................54
FIGURE 25: ECRANS APPEL DIRECT ET ENVOIE DE MESSAGE.........................................................................................55
FIGURE 26: ECRAN ÇA M'INTERESSE.............................................................................................................................56
FIGURE 27: RUBRIQUES ÇA M'INTERESSE......................................................................................................................57
FIGURE 28: ECRAN NOS AGENCES.................................................................................................................................58
FIGURE 29: ECRAN J'AGIS POUR MA VILLE....................................................................................................................59
FIGURE 30: ACCUEIL AJOUT D'UNE DEMANDE ..............................................................................................................60
FIGURE 31: SLIDER D'AIDE D'AJOUT D'UNE DEMANDE...................................................................................................61
FIGURE 32: ETAPES D'IDENTIFICATION .........................................................................................................................62
FIGURE 33: PARAMETRES DE LA CAMERA ....................................................................................................................63
FIGURE 34: FORMULAIRE D'AJOUT D'UNE DEMANDE ....................................................................................................64
FIGURE 35:JOINDRE DES MEDIAS A LA DEMANDE.........................................................................................................65
FIGURE 36: LISTE DES DEMANDES ................................................................................................................................66
FIGURE 37: DETAILS D'UNE DEMANDE..........................................................................................................................67
FIGURE 38: REAGIR A UNE DEMANDE ...........................................................................................................................68
FIGURE 39: FILTRER UNE DEMANDE.............................................................................................................................69
FIGURE 40: ACCUEIL JE GERE MON COMPTE.................................................................................................................70
FIGURE 41: DETAILS FACTURE 1..................................................................................................................................71
FIGURE 42: DETAILS CONTRAT.....................................................................................................................................71
FIGURE 43: LISTE DES CONTRATS ................................................................................................................................71
FIGURE 44: DETAILS FACTURE 2..................................................................................................................................71
FIGURE 45: MES CONSOMMATIONS..............................................................................................................................72
FIGURE 46: MES REGLEMENTS......................................................................................................................................73
FIGURE 47: LISTE DES IMPAYES....................................................................................................................................74
FIGURE 48: PAIEMENT DES FACTURES ..........................................................................................................................74
FIGURE 49: LISTE DES IMPAYES ...................................................................................................................................75
FIGURE 50: HISTORIQUE DU SCAN................................................................................................................................75
FIGURE 51: ECRAN DU SCAN ........................................................................................................................................75

X
FIGURE 52: ECRAN AUTO RELEVE.................................................................................................................................76
FIGURE 53: SLIDER COMMENT ÇA MARCHE..................................................................................................................77
FIGURE 54: ETAPES D'INSCRIPTION...............................................................................................................................78
FIGURE 55: LIENS EXTERNES........................................................................................................................................79
FIGURE 56: NOTIFICATIONS .........................................................................................................................................80
FIGURE 57: ECRAN PROFIL ...........................................................................................................................................81
FIGURE 58: LIENS UTILES.............................................................................................................................................82
FIGURE 59: PARTAGE DE L'APPLICATION .....................................................................................................................83
FIGURE 60: ECRAN DE MODIFICATION DES INFORMATIONS PERSONNELLES..................................................................84
FIGURE 61: MODIFICATION DU LOGIN..........................................................................................................................85
FIGURE 62: MODIFICATION DU MOT DE PASSE .............................................................................................................86
FIGURE 63: ETAPES DE MODIFICATION DU GSM ..........................................................................................................87

XI
Liste des Tableaux
TABLEAU 1: FICHE TECHNIQUE DE MOBIBLANC...........................................................................7
TABLEAU 2: LES FONCTIONNALITES A METTRE EN PLACE ..............................................................12
TABLEAU 3: DESCRIPTION DE CAS D'UTILISATION AUTO RELEVE ...................................................20
TABLEAU 4: DESCRIPTION DE CAS D'UTILISATION INSCRIPTION .....................................................22
TABLEAU 5: DESCRIPTION DE CAS D'UTILISATION PAYER DES FACTURES.......................................23
TABLEAU 6: DESCRIPTION DE CAS D'UTILISATION VOIR LA DERNIERE FACTURE.............................23
TABLEAU 7: DESCRIPTION DE CAS D'UTILISATION GESTION DES CONSOMMATIONS ........................24
TABLEAU 8: DESCRIPTION DE CAS D'UTILISATION IDENTIFICATION................................................25
TABLEAU 9: DESCRIPTION DE CAS D'UTILISATION AJOUT D'UNE DEMANDE....................................26
TABLEAU 10: ARCHITECTURE LOGICIELLE D'ANDROID ..................................................................30

XII
Liste des Abréviations
Abréviation Désignation
API Application programming interface
REST Representational State Transfer
CRC Centre de relations clientèle
SOAP Simple Object Access Protocol
JSON JavaScript Object Notation
UML Unified Modeling Language

1
Introduction
En 2018, le nombre d’internautes s’élève à plus de 4 milliards, en croissance de 7% sur un
an, le monde du digital s’agrandit à chaque instant. Et pour une entreprise, avoir un site internet,
ou une application mobile est de l’ordre de l’essentiel, elle pourra ainsi contrôler son image,
apporter de la visibilité supplémentaire, créer une véritable histoire et accroitre sa propre
communauté.
Pour améliorer son développement digital, Lydec vise à construire son projet Synergies
2020 au terme d’une démarche participative sur la base d’une écoute à 360° de toutes parties
prenantes, le projet d'entreprise « Synergies 2020 » est articulé autour de trois orientations
stratégiques majeures et d'un socle commun : être à l'écoute et au service de tous ses clients, être
le partenaire quotidien des collectivités, de ses habitants et de leurs représentants, être la référence
professionnelle durable des entreprises de service public
Et dans ce cadre s’inscrit notre projet, qui à travers lequel Lydec cherche à offrir un accès
facile aux informations, fidéliser et réactiver les publics-cibles, et multiplier les canaux de contact.
Notre projet consiste à la refonte de l’application mobile Android existante de Lydec, et la
mise en place de la deuxième version qui s’articule autour de 4 rubriques pratiques à savoir :
 Je gère mon compte : paramétrer les données client, consulter les contrats et les
factures, suivre les consommations, payer les factures
 J’agis pour ma ville : remonter un événement, signaler un incident, suivre
l’avancement des demandes et contribuer ainsi à l’amélioration de la qualité de
l'environnement urbain.
 Ça m’intéresse : consulter les actualités de Lydec, avoir des conseils pour la
gestion optimale des consommations
 Je contacte mon conseiller : j’entre en contact avec le conseiller au Centre de
Relation Clientèle
Le présent rapport constitue le mémoire de mon stage de fin d’études effectué au sein de
la société Mobiblanc qui s'est imposé comme le principal fournisseur de services mobiles sur le
marché marocain. Ce stage était dans le cadre de validation de la deuxième année de Master
spécialité Qualité du Logiciel, à la faculté des sciences de Tétouan.

2
Ce présent rapport se compose de quatre chapitres. Dans le premier chapitre, nous
présentons le contexte général du projet et l’organisme d’accueil. Le deuxième fera l’objet de
l’analyse et la spécification des besoins. L’étude technique et la conception du projet sont détaillées
dans le troisième chapitre. Le dernier chapitre, quant à lui, est consacré à la réalisation et la
présentation du fruit travail réalisé. Enfin, une conclusion pour dresser le bilan de ce travail.

Chapitre I
Contexte général du projet
Dans ce chapitre nous allons présenter l’organisme
d’accueil, et le cadre générale du projet

4
CHAPITRE 1 : CONTEXTE GENERAL DU PROJET
1. Présentation de l’organisme d’accueil
1.1. Présentation de Mobiblanc
Mobiblanc, spécialiste des solutions et de marketing mobile est une société qui a été créé
en 2010 pour permettre aux opérateurs de téléphonie mobile, aux entreprises, aux manques et aux
agences d’offrir des expériences mobiles optimisées, centrées sur le client, qui génèrent une
interaction, une consommation de contenu et des transactions à travers l’écosystème mobile.
L’entreprise compte dans son portefeuille clients les plus grandes sociétés et institutions de
la place telles que le groupe OCP, Maroc Telecom, Orange, Inwi, Autoroutes du Maroc, et encore
le Parlement. Afin de renforcer son ancrage en Afrique de l’Ouest, Mobiblanc a aussi signé un
partenariat avec le groupe sénégalais Matforce pour l’accompagner dans sa stratégie de
transformation numérique. Aujourd’hui, Mobiblanc entend dépasser les frontières du royaume, et
aller à la conquête de nouveaux marchés, Dans ce sens, l’entreprise a créé début 2018 une filiale
en Tunisie (Mobiblanc Tunisie) pour se rapprocher de ce marché en pleine croissance.
1.2. Les clients de Mobiblanc
Figure 1: Les clients de MOBIBLANC
1.3. Equipe Mobiblanc
L’équipe MOBIBLANC est composée d’experts de la mobilité. Elle est organisée de
manière à pouvoir traiter l’ensemble du cycle de vie des projets clients.
 Avant-vente : Recueille les besoins des clients pour proposer une offre pertinente et
adaptée.

5
 Conseil : Intervienne en avant-vente et assure la gestion opérationnelle et technique.
 Créativité : Apporte des réponses créatives et innovantes aux problématiques mobiles et
multicanales.
 Projets : Garantie du respect des délais et assure la relation avec les clients et les différents
intervenants.
 Expertise : Maitrise le développement d’applications multimédia mobiles et l’intégration
aux systèmes d’information de nos clients.
 Validation : Test et valide chaque service avant sa mise en ligne.
Ci-dessous l’organigramme de Mobiblanc :
Figure 2: L'organigramme de MOBIBLANC
1.4. Services
Toute entreprise qui déploie des équipes sur le terrain est mobile, ceci dit qu’elle a besoin
de solutions de mobilité pour suivre et optimiser leurs performances. MOBIBLANC fourni à ces
clients Entreprises des solutions terrains destinées à répondre à leurs besoins de mobilité ainsi que
leurs spécifications internes.
Leur expertise varie de la consultation de tableau de bord au support de vente.
De ce fait les services de MOBIBLANC sont catégorisés principalement en solutions de
mobilité entreprise et solutions de marketing mobile.

6
1.4.1. Développement Mobile
Mobiblanc œuvre au quotidien pour mettre à la disposition de ses clients des services
fiables et surtout évolutifs. Ils développent une panoplie d’applications mobiles adaptée aux
besoins des clients :
 Pour entretenir des relations durables avec les clients et les prospects.
 Pour optimiser l’expérience utilisateur (graphisme et ergonomique optimisés).
 Pour exploiter les fonctionnalités avancées du mobile : carnet d’adresse, appareil photo,
GPS…
 Pour proposer un accès au contenu ou services en mode déconnecté.
De plus ils développent également des solutions de « mobile-banking » qui permettent aux
mobinautes d’utiliser leurs mobiles afin d’accéder à l’intégralité de leurs informations bancaires
ou d’effectuer toutes sortes de transactions financières à partir de leurs comptes.
Mais encore des solutions de m-commerce font aussi partie de leurs prestations, et facilitent
désormais le quotidien des usagers puisque maintenant ils peuvent réaliser intégralement leurs
actes d’achats et de vente au moyen de leurs mobiles.
Enfin leur développement graphique est adapté aux différents mobiles et grâce à des possibilités
graphiques et multimédias enrichies, ils assurent une expérience utilisateur optimale et
ergonomique.
1.4.2. Marketing mobile
Mobiblanc accompagne et conseille ses clients lors de toutes les étapes de leurs stratégies
mobiles. Du conseil à la mise en œuvre opérationnelle, en passant par les étapes de promotion et
de communication, leur équipe de spécialiste œuvre au succès des futures stratégies de marketing
mobile.
L’usager est au centre de leurs préoccupations stratégiques, ergonomiques et
fonctionnelles, c’est pourquoi ils offrent des services utiles en exploitant leur potentiel afin
d’interpeller l’usager à travers un accès à des contenus riches et pertinents. L’objectif final étant
d’aboutir à une « expérience utilisateur » à la hauteur de toutes les espérances.
MOBIBLANC propose à ses clients « Corporate » des applications métiers spécialement
conçues pour répondre aux exigences internes des entreprises, de la consultation de tableaux de

7
bords à la grande distribution, mobiblanc a conçu des applications mobiles pour satisfaire tous les
besoins de mobilité exprimés.
Une application mobile pour MOBIBLANC, ne peut être réussie que si elle fait partie d’une
stratégie mobile prédéfinie.
1.5. Fiche technique de Mobiblanc
2. Cadre générale du projet
2.1. Présentation générale du projet
La transformation digitale, que l’on appelle parfois aussi transformation numérique,
désigne le processus qui permet aux entreprises d’intégrer toutes les technologies digitales
disponibles au sein de leurs activités.
La mise en place d’une application mobile pour rendre les services de Lydec proche du
client, est parmi les piliers de cette transformation.
Notre Projet de fin d’études s’inscrit dans le cadre de l’évolution de l’application de Lydec
déjà existante, avec des nouvelles fonctionnalités, dans l’objectif de produire une solution simple
et pratique qui permet aux consommateurs d’accéder 24h/24h et 7j/7 aux nombreux services tel
Nom de l’entreprise Mobiblanc
Date de création Novembre 2010
Secteur d’activité Applications mobiles et web.
Direction
Youssef EL ALAOUI.
Mohammed BENBOUBKER
Activités Développement des solutions mobile et Web.
Nombre de salaries
Equipe spécialisée de 30 ingénieurs, développeurs, designers,
et des chefs de projets.
Capital 1.000.000 Dhs.
Adresse
Angle rues KAMEL Mohamed et FAKER Mohamed, Imm.
SEMIRAMIS 4ème étage, Sidi Belyout, Casablanca 20100,
Maroc.
Site Web www.mobiblanc.com
Siège MAROC (Casablanca) - TUNISIE (Tunisie) – UAE(Dubai)
Tableau 1: Fiche technique de MOBIBLANC

8
que : règlement des factures, localisation de l'agence ou du point de paiement le plus proche, accès
aux dernières actualités, ou encore contact simplifié avec le centre de relation clientèle pour toutes
questions ou réclamations.
La digitalisation de ses services est un choix stratégique pour Lydec qui vise non seulement
à faciliter la vie pour les consommateurs leur en rendre accessible de n’importe où, et à tout
moment de la journée, mais aussi d’augmenter sa notoriété en montrant son implication
quotidienne auprès des citoyens.
2.2. Problématique
Lydec dispose d’un réseau de 13 agences clientèle réparties sur Casablanca et
Mohammedia. Chaque mois, ces agences accueillent plus de 230.000 clients sur un total de 1,3
million, soit près de 10.500 visiteurs par jour. Cela génère le problème de perte du temps des
clients à la fin de chaque mois, en attendant dans des grandes lignes pour payer les factures.
D’autre part on connaît tous, que les citoyens, à la fin de chaque mois, se retrouvent
toujours confus à propos de leur consommation, le montant à payer, sans oublier les fautes qui
peuvent être faite au niveau du relève de l’index de consommation par les agents de Lydec.
En outre, l’un des problèmes majeurs qui sont liés au service de la distribution de
l’électricité et de l’eau potable, c’est la détection et la résolution des incidents, en effet dans une
grande ville comme Casablanca, il est difficile de suivre les incidents pouvant survenir, de la
détection à la résolution, à savoir les fuites d’eau, la lumière publique endommagés. Etc. les
citoyens trouvent des difficultés pour contacter les responsables de Lydec pour signaler et remonter
des incidents.
Certes Servir ce nombre élevé de clients, nécessite un grand potentiel que ce soit matériel
ou humain.
2.3. Solution Existante
Dans un premier temps Lydec a pensée à réduire le temps de résolution des problèmes, et
diminuer le coup des pertes résultant d’incidents relatifs à l’eau potable, électricité, éclairage
public et assainissement, en mettant en place une solution mobile de ticketing permettant la
réclamation des clients via les photos, vidéos ou audio.

9
Cette solution permettra aux utilisateurs authentifiés ou non, d’interagir selon le processus
suivant :
 La création d’un ticket par l’utilisateur
 Qualification du ticket créé par le client
 Résolution du problème signalé si nécessaire
 Notification du client du statut de son ticket
 Gamification du client suite à sa contribution à préserver les ressources par des points de
fidélité.
Pour utiliser l’application et signaler des évènements et des incidents, les utilisateurs
doivent s’identifier avec leur numéro de téléphone, et le confirmer avec un code reçu par SMS.
A noter que ses numéros de téléphones sont liés aux contrats du client. La première version
a été au début réservé juste aux numéros autorisés, c.-à-d. seuls quelques employés de Lydec qui
peuvent signaler et remonter un évènement, pour bien tester l’efficacité de cette solution avant de
la rendre publique.
2.4. Solution à développer
La deuxième version de l’application qui est le sujet de mon stage PFE, c’est l’évolution
de l’application existante en y ajoutant d’autres fonctionnalités, son objectif, en plus de la gestion
des demandes des clients, c’est de rendre l'application agissent comme une agence en ligne, tous
les services relatifs aux clients, vont être disponible auprès du consommateur, sans avoir à se
déplacer vers les agences.
Ma mission principale et d’intervenir dans la partie Android de l’application, (La partie
iOS sera développée par un autre développeur), cette dernière doit être développé en Android natif
avec le langage Java.
Notre projet consiste donc à proposer une solution répondant aux besoins fonctionnels
d’entreprise. Cette solution, en plus de la solution existante, devra entre autres assurer les éléments
suivants :
 Lister les contrats.
 Suivre les consommations et les règlements.
 Effectuer sa propre relève du compteur.
 Lister les factures impayées.

10
 Paiement des factures en ligne.
 Paiement direct.
 Mémoriser l’historique du paiement.
 Modifier les paramètres de son profil.
 Un login et mot de passe pour un accès simplifié à l’agence en ligne.
 Entrer en contact avec le conseiller au Centre de Relation Clientèle.
 Consulter les actualités de Lydec, avoir des conseils pour la gestion optimale des
consommations....
 Trouver l’agence de Lydec la plus proche.
3. Cycle de développement
La finalisation du projet dans les délais est le souci majeur de chaque équipe de
développement d’un logiciel. L’un des problèmes les plus fréquemment affrontés lors du
développement d’un logiciel est la mauvaise spécification et le changement brusque des besoins.
Cela peut influencer non seulement l’équipe de développement en créant un environnement de
stress, mais aussi le temps consacré pour la réalisation du projet et donc des délais de livraison
dépassés.
Afin d’éviter ces situations critiques, nous avons suivi un cycle de développement
itératif.
Figure 3: Cycle de développement

11
Ma mission en ce stage n’a pas été concentré sur le sujet de PFE, en effet, après la livraison
de l’incrément au client, et en attendant le retour, je travaille sur les retours client sur pour d’autre
projet comme MY2M, CTM, ORANGE ET MOI, MAGHREBAIL de Bmce bank et autres…
La durée d’attente pour le retour client a été variée et pas fixe.
3.1. Cycle de Test
Figure 4: Cycle de Test
Le développement du coté back-end a été en parallèle avec le développement des
applications mobile. Et la mise en place en production d’une fonctionnalité passe par le test sur
deux niveaux :
 Version de développement : version développée en interne et déployée sous le domaine :
http://lydec.mobiblanc.com/
 Version de pré-produit : version déployée chez le client sous le domaine :
https://citizen.lydec.ma/test/ cette version est consacré pour tous les tests chez le client.
 Version produit : version finale.
4. Élaboration du cahier des charges
Afin de mener à bien notre projet il est bien donc nécessaire de faire une analyse
préliminaire des besoins et de faire une liste des différentes fonctionnalités à mettre en œuvre.
Les fonctionnalités à mettre en place sont présentées d’une manière générale, dans le
tableau ci-dessous :
Module Fonctionnalités
Je gère Mon compte Les contrats
Les règlements

12
Les impayés
Paiement direct
Auto-relève
Mes consommations
Gestion des notifications
Gestion des informations du profil
Ça m’intéresse Conseils Pratiques
Les Agences
FAQ
Engagements de services
Nos Electriciens agréés Lydec
Je contacte mon conseiller Appel Direct
Message
J’agis pour ma Ville Gestion des demandes
Tableau 2: Les fonctionnalités à mettre en place
5. Conclusion
Dans ce chapitre on a décrit le contexte général dans lequel s’inscrit notre projet de fin
d’études. Au début, nous avons présenté l’entreprise d’accueil MOBOBLANC. Puis on déterminé
la problématique, l’application existante et la solution à développer qui se résume à développer
une agence en ligne. Et pour mettre en place notre projet, on doit effectuer une étude préliminaire
fonctionnelle et technique des besoins, cela fait l’objet du deuxième chapitre.

Chapitre II
Analyse et spécification des
besoins
Dans ce chapitre nous allons effectuer une étude
fonctionnelle du projet, après nous présentons les
différents cas d’utilisation

14
CHAPITRE 2 : ANALYSE ET SPECIFICATION DES BESOINS
1. Introduction
La phase d’analyse et spécification des besoins présente une étape primordiale dans le cycle
de développement d’un projet. En effet, l’expression du besoin est une phase très sensible
nécessitant un effort de la part des deux contractants, le client doit bien expliquer et exprimer
exactement le besoin. De son côté, l’équipe réalisatrice doit relever le maximum d’informations
pour bien répondre à ces besoins.
2. Etude fonctionnelle
L’objectif de notre travail de développer la deuxième version de l’application Android de
Lydec, qui permettra aux clients d’accéder à de nombreux services 24h/24 7j/7, et effectuer
plusieurs opérations relatives à la consommation de l’eau et de l’électricité depuis son smartphone.
2.1 Identification de l’acteur
Un acteur est une entité externe qui interagit avec un système. En réponse à l'action d'un
acteur, le système fournit un service qui correspond à son besoin.
Notre solution a un seul acteur, celui le client (le consommateur) de Lydec, il effectue
toutes les opérations qu’offre l’application.
2.2 Besoins fonctionnels
Les besoins fonctionnels sont les besoins qui déterminent les fonctionnalités indispensables
auxquels doit répondre notre solution. Nous avons cité précédemment que l’application doit agir
comme une agence en ligne, afin de diminuer le recours aux moyen traditionnels de gestion, et
d’intégrer de plus en plus les moyens technologiques.
L’application en sa globalité doit répondre aux exigences fonctionnelles suivantes :
 Avoir un espace pour suivre l’état des tous les contrats du consommateur (Eau et/ou
L’électricité).
 Suivre les consommations et les règlements pour chacune des contrats : obtenir l’historique
des règlements et consommations selon la durée choisie par le client, l’historique doit être
affiché soit en mode tableau, soit en mode graphique.
 Effectuer sa propre relève du compteur : le client doit avoir la possibilité d’effectuer lui-
même son relève du compteur en saisissant l’index de la consommation.

15
 Avoir un espace pour lister les factures impayées, et faciliter la tâche pour le client, en lui
offrant la fonctionnalité de payer ses factures avec sa carte bancaire depuis son smartphone.
 Payer n’importe quelle facture depuis son smartphone en scannant le code à barres, ou
saisissant le numéro de facture.
 Mémoriser l’historique du scan et les codes de factures saisies par le client, pour qu’il
puisse accéder directement aux impayés la prochaine fois, sans avoir à saisir le numéro de
contrats et référence à chaque paiement.
 Modifier les paramètres de son profil : Consultez à tout moment les paramètres de son
compte et modifier à son guise les informations personnelles liées à son compte en ligne.
 Activer ou désactiver les notifications des actualités concernant Lydec et son
environnement, conseils pratiques …
 Avoir une rubrique « je contacte mon conseiller » pour entrer en contact avec le conseiller
au Centre de Relation Clientèle.
 Avoir une rubrique « Ça m’intéresse » pour consulter les actualités de Lydec, avoir des
conseils pour la gestion optimale des consommations....
 Trouver de l’aide au sein de l’application à travers des images explicatives qui illustre les
différentes procédures pas à pas.
 L’application doit comporter des liens utiles vers les comptes des réseaux sociaux de
Lydec, pour faciliter l’accès à l’actualité, et rester toujours en contact avec le CRC de
Lydec, et partager des idées avec la communauté.
2.3 Les besoins non fonctionnels
Les besoins non-fonctionnels sont des besoins/contraintes liés à l'implémentation et à
l'interopérabilité générale. Et pour compléter les besoins fonctionnels, notre projet devra respecter
un ensemble de propriétés contribuant à une meilleure qualité de la solution obtenue. Parmi ces
critères on trouve :
 Une charte graphique standard : en plus des nouvelles fonctionnalités à mettre en place
dans la deuxième version l’application doit respecter une charte graphique unifié, cela
nécessite la refonte de la première version, en respectant le nouveau design proposé.
 Rapidité : il y aura deux couches de web services pour l’interaction entre le terminal
mobile et le SI interne de Lydec, donc l’application doit être rapide au niveau de traitement
des données reçu de la part des services web, pour réduire le temps de réponse attendu de
la part de l’API.

16
 Fiabilité : L’application ne doit pas afficher aux utilisateurs des erreurs, par contre toutes
les exceptions doivent être gérées et toute incidence doit être déclaré dans les logs du coté
back-end pour l’identifier facilement, et pour la résoudre rapidement.
 Sécurité : L’application doit être en toute sécurité pour protéger les données sensibles des
clients, tel que les informations de connexion, les informations liés au paiement…etc., les
données échangées dans le flux, et les données sauvegardés dans le stockage interne du
terminal, doivent être cryptés pour limiter n’importe quelle tentative d’espionnage.
 La douceur d’utilisation : il est prévu que l’application va effectuer beaucoup de
traitement, et des appels à des services web, donc la douceur (smoothness) doit être assurée,
au niveau de la navigation entre les différents écrans, le rendu des élément graphiques, et
le respect des bonnes pratique recommandés par Google pour la construction des interfaces
graphique en Android.
2.4 Diagrammes de cas d’utilisation
Avant de terminer l’étude fonctionnelle et la spécification des besoins, il est donc
nécessaire de présenter des diagrammes de cas d’utilisation, permettant de donner une vision
globale sur la solution à développer.
Notre application est composée de 4 modules principal, J’agis pour ma ville, je gère mon
compte, ça m’intéresse, et je contacte mon conseiller.
On va présenter les diagrammes de cas d’utilisation pour chaque partie composante de
l’application.
2.4.1 Je gère mon compte
La figure ci-dessous illustre le diagramme de cas d’utilisation pour la rubrique « je gère
mon compte » :

17
Figure 5: diagramme de cas d'utilisation je gère mon compte

18
L’application offre plusieurs services, parmi ces services, il y en a ceux qui sont faite avec
l’authentification par un login et un mot de passe, et il y en a d’autre qui sont effectués juste avec
l’identification par le numéro de téléphone.
L’authentification est forte que l’identification, en effet si l’utilisateur dispose d’un login
et un mot de passe, et il est authentifié, dans ce cas-là, il est implicitement identifié.
L’identification permet non seulement d’identifier le client avec son numéro de téléphone,
mais aussi d’associer ce numéro avec son terminal, en envoyant comme paramètre l’UID du
téléphone.
L’identification est faite une fois pour toutes, En effet, l’utilisateur n’as pas besoin de
s’identifier une autre fois, sauf dans le cas de la désinstallation ou la suppression des données de
l’application.
2.4.2 J’agis pour ma ville
La figure ci-dessous illustre le diagramme de cas d’utilisation pour la rubrique « j’agis pour
ma ville » :
Figure 6: diagramme de cas d'utilisation j'agis pour ma ville

19
2.4.3 Je contacte mon conseiller
La figure ci-dessous illustre le diagramme de cas d’utilisation pour la rubrique « je contacte
mon conseiller » :
Figure 7: Diagramme de cas d'utilisation je contacte mon conseiller
2.4.4 Ça m’intéresse
La figure ci-dessous illustre le diagramme de cas d’utilisation pour la rubrique « ça m’intéresse » :
Figure 8:diagramme de cas d'utilisation ça m'intéresse

20
2.4.5 Explications textuelles des cas d’utilisation
Dans cette partie on va voir la description textuelle des quelques cas d’utilisation de notre
application.
2.4.5.1 Diagramme de cas d’utilisation auto-relève
Ce cas d’utilisation permet à l’utilisateur d’effectuer automatiquement une auto relève de
l’index de consommation soit pour l’électricité soit pour l’eau.
Nom du cas Effectuer Auto relève
Acteur L’utilisateur
Précondition L’utilisateur doit être authentifié
post condition Effectuer l’auto relève
Scénario nominal -L’utilisateur ouvre l’application
-l’utilisateur accède à la rubrique je gère mon compte
-il clique sur le bouton « auto-relève »
-l’application fait appel au service web pour récupérer la
liste des contrats.
-l’application affiche l’interface d’auto relève
-L’utilisateur sélectionne le contrat concerné, il saisit
l’index et la date du relève.
-l’utilisateur clique sur valider
-l’application affiche un message de succès.
Scénarios d’exception -au cas où l’utilisateur n’as pas choisi un contrat, ou il
n’as pas saisi la date et l’index de relève il ne peut pas
effectuer une auto relève.
- si l’utilisateur a indiqué une valeur de l’index inférieur
à celle de la relève précédente, l’application affiche un
message d’erreur
-en cas d’une erreur inattendu du coté back-end
l’application indique à l’utilisateur d’essayer plus tard.
Tableau 3: Description de cas d'utilisation Auto relève

21
2.4.5.2 Diagramme de cas d’utilisation « inscription »
Ce cas d’utilisation permet au client de créer un compte.
Nom du cas Inscription
Acteur Le client
Précondition
Le client doit avoir le numéro de facture ou un code à barres à
scanner.
post condition Création du compte.
Scénario nominal
-le client ouvre l’application
-le client clique sur n’importe quel rubrique qui nécessite
l’authentification (ex : voir la liste des contrats)
-l’application redirige le client vers l’écran d’authentification
-le client clique sur le bouton inscription
-l’application redirige le client vers l’écran qui permet de scanner ou
saisir le numéro de facture.
-après le scan ou le saisi du numéro de facture l’application fait appel
au web service pour chercher le numéro de téléphone associé à cette
facture.
-l’application propose au client deux options soit de choisir un
numéro de téléphone parmi les numéros qui avec lesquelles il a déjà
fait l’inscription ou de saisir un nouveau numéro de téléphone.
-le client saisi son numéro de téléphone
-le client confirme son numéro avec sms.
-l’application redirige le client vers l’écran de saisi de son identifiant
(fournis au moment de la création du contrat).
-l’application redirige le client ver l’écran de saisi des informations
personnelle (nom, prénom, adresse, email, mot de passe…)
-le client clique sur valider.
-l’application redirige l’utilisateur vers l’écran d’authentification
Scénarios alternatifs
1) Cas de l’utilisateur sélectionne son numéro parmi les numéros
proposés : l’application redirige l’utilisateur directement vers
l’étape de saisi de son identifiant et ainsi de suite.

22
2) Cas de l’utilisateur déjà identifié avec son numéro et son
terminal : lors du scan ou le saisi du numéro de facture la
première fois, l’application redirige le client directement vers
l’étape de saisi de l’identifiant et ainsi de suite.
Scénarios d’exception
-au cas où le client a saisi un numéro de facture inexistant ou
incorrect l’application affiche un message d’erreur indiquant sa
nature.
-au cas où le code sms de confirmation de téléphone est incorrect,
l’application affiche une erreur.
--en cas d’une erreur inattendu du coté back-end l’application indique
à l’utilisateur d’essayer plus tard.
Tableau 4: Description de cas d'utilisation Inscription
2.4.5.3 Diagramme de cas d’utilisation « payer des factures »
Ce cas d’utilisation permettant à l’utilisateur de payer ses factures. Pour effectuer cette
opération l’utilisateur a deux méthodes, une nécessitant l’authentification, et l’autre à travers
l’identification s’il ne veut pas avoir un compte.
Nom du cas Payer des factures
Précondition L’utilisateur doit être authentifié ou identifié
post condition
Affichage de la page web de paiement des factures dans le SI de
Lydec.
Scénario nominal
-L’utilisateur ouvre l’application
-il clique sur le bouton mes impayés
- l’application affiche la liste des impayés, et les frais s’ils existent.
-le client sélectionne les impayés qu’il souhaite(les frais sont
sélectionnés par défaut)
-il clique sur valider
-l’application redirige l’utilisateur vers la page de paiement.
Scénario alternatif
1- Si l’utilisateur n’est pas authentifié
-l’application redirige l’utilisateur vers l’authentification.

23
2- l’utilisateur est identifié : l’utilisateur clique sur paiement
direct, puis il scan le code à barres, ou il saisit le numéro de
facture, puis l’application le redirige vers la liste de paiement.
3- l’utilisateur peut directement choisir sa facture s’il a été déjà
scanné.
-Si l’utilisateur à saisit un numéro de facture incorrect l’application
affiche une erreur.
-en cas d’une erreur inattendu du coté back-end l’application indique
Tableau 5: Description de cas d'utilisation Payer des factures.
2.4.5.4 Diagramme de cas d’utilisation « voir la dernière facture »
Ce cas d’utilisation permet à l’utilisateur de voir la dernière facture, l’application va
afficher une facture sous forme d’un tableau bien détaillée.
Nom du cas Voir la dernière facture
Précondition L’utilisateur doit être authentifié.
post condition Affichage de la dernière facture sous forme de tableau
Scénario nominal
- l’utilisateur clique sur le bouton mes contrats
-l’application affiche la liste des contrats.
-l’utilisateur sélectionne un contrat quelconque.
-l’application affiche dans un autre écran quelques informations
relatifs à cette contrats, et le montant de la dernière facture
-l’utilisateur clique sur le bouton « voir la facture »
-l’application affiche la facture
Scénarios d’exception -en cas d’une erreur inattendu du coté back-end l’application indique
Tableau 6: Description de cas d'utilisation voir la dernière facture
2.4.5.5 Diagramme de cas d’utilisation « gestion des consommations »

24
Nom du cas Gestion des consommations
Précondition L’utilisateur doit être authentifié.
post condition Affichage de l’historique de consommations
Scénario nominal
-l’utilisateur clique sur le bouton mes contrats
-l’application fait appel au service web pour récupérer la liste des
contrats.
-l’application affiche l’interface de mes consommations
-l’utilisateur sélectionne un contrat quelconque, et il indique la
période de consommation en saisissant la date de début et la date de
fin.
-l’utilisateur clique sur le bouton « rechercher »
-l’application affiche l’historique de consommations.
-l’utilisateur peux pivoter l’écran pour afficher l’historique sous
forme d’histogramme.
Tableau 7: Description de cas d'utilisation gestion des consommations
2.4.5.6 Diagramme de cas d’utilisation « Identification »
Nom du cas Identification
Précondition Le numéro de téléphone doit être valide
post condition L’identification de l’utilisateur
Scénario nominal
-l’utilisateur sélectionne n’importe quel service qui nécessite
l’identification (exemple le paiement direct).
-l’application affiche l’interface de saisi de numéro de téléphone
-l’utilisateur confirme son numéro, puis il clique sur ok

25
-l’application fait appel au web service pour que l’utilisateur reçoit
son code de 4 chiffres.
-l’application affiche l’interface de saisi du code
-l’utilisateur saisi le code, après l’application fait appel au web
service pour confirmer le code.
Scénarios alternatifs
-en cas d’échec l’utilisateur peut essayer à nouveau en cliquant sur un
bouton « renvoyer le code »
-en cas d’une erreur inattendu du côté back-end l’application indique
-si le code est incorrect, ou l’utilisateur a saisi le code après 5 min,
l’application affiche une erreur.
Tableau 8: Description de cas d'utilisation Identification
2.4.5.7 Diagramme de cas d’utilisation « Ajouter une demande »
L’ajout d’une demande permet à l’utilisateur de signaler des problèmes et des incidents
pour aider Lydec pour résoudre les problèmes rapidement.
Nom du cas Ajouter une demande
Précondition L’utilisateur doit être identifié ou authentifié.
post condition Ajout d’une demande
Scénario nominal
-l’utilisateur consulte la carte
-il clique sur le bout d’ajout de nouvelle demande
-l’application ouvre directement l’appareil photo.
-l’utilisateur prend une photo pour l’incident, ou il peut choisir une
image à partir de la gallérie.
- l’application vérifie dans les métadonnées de l’image choisi ou
capturée, s’il contient les informations de localisation, sinon il invite
l’utilisateur à choisir l’adresse sur la carte.
-l’utilisateur ajoute son commentaire puis il clique sur envoyer
-l’utilisateur peut ajouter d’autres images, ou un audio à sa demande.

26
Tableau 9: Description de cas d'utilisation Ajout d'une demande
3. Conclusion
Dans ce chapitre nous avons étudié notre projet par l’approche fonctionnelle. En effet nous
avons parlé des besoins fonctionnels et non fonctionnels, puis nous avons présenté les différents
cas d’utilisation de notre application ainsi que leur description et déroulement. Avant de
commencer la réalisation il fallait une étude technique, et la conception détaillé pour pouvoir
étudier le projet à travers tous ses aspects, cela fait l’objet du prochain chapitre.

Chapitre III
Etude conceptuelle et
technique
Dans ce chapitre nous allons présenter l’étude
technique, puis la conception des modèles statiques et
dynamiques avec le formalisme UML.

28
CHAPITRE 3 : ETUDE CONCEPTUELLE ET TECHNIQUE
1. Introduction
Après l’étape de l’étude préalable et la spécification des besoins, nous réservons cette partie à la
conception détaillée, et l’étude technique de notre projet. En effet, nous allons commencer par
présenter l’univers Android, les services web, et l’architecture de notre projet. Ensuite on va
décrire les différents modèles statiques et dynamiques, en utilisant le formalisme UML.
2. Etude Technique
2.1. Présentation d’Android
2.1.1.Introduction
Android est un système d'exploitation libre basé sur le noyau Linux et comporte une interface
utilisateur développée en Java. Il est destiné pour les appareils mobiles comme par exemple les
smartphones, les tablettes tactiles, les assistants personnels PDA (Personal Digital Assistant), les
baladeurs, les montres ou smartwatches, lunettes, voitures, télévision, électroménager, etc.
Android a été initialement créé par une petite entreprise spécialisée dans le développement
d’applications mobiles qui s’appelle Android Inc, fondée en 2003 aux Etats Unies. En août 2005
Google l’a racheté.
Actuellement, le développement d'Android est contrôlé par l'Open Handset Aliance, c'est un
regroupement de plus de 50 entreprises dirigé par Google.
Avec l'explosion des ventes des smartphones, Android a pu prendre au fil des années une place
importante dans le marché des téléphones mobiles. Il est actuellement le système d’exploitation le
plus utilisé dans le monde pour faire fonctionner les smartphones et les tablettes. Les principaux
concurrents d'Android sont Apple avec l'iPhone, Microsoft avec Windows Mobile.
Le développement d'applications mobiles Android est habituellement réalisé à l'aide du langage
de programmation Java (Java SE : Java Standard Edition) en utilisant le kit de développement
SDK (Software Development Kit) Android développé par Google.
Le SDK fourni de la documentation, des API (librairies Java d'Android) et un ensemble d’outils
en ligne de commande ou intégrés à un éditeur tel que Android Studio ou Eclipse permettant de
compiler, de déboguer les applications, d'y ajouter une signature numérique et de créer le fichier
APK (Android Package).

29
Ce dernier est le package Android de l'application qui sera déployé sur un émulateur Android AVD
(Android Virtual Device) ou sur un appareil mobile réel (handset).
2.1.2.Versions d’Android
Les différentes versions d'Android ont toutes des noms de desserts ou de sucreries.
Figure 9: Versions d'Android
2.1.3.Architecture logicielle d’Android
La plate-forme Android se compose d'une pile de composants logiciels qui est divisé en cinq
couches comme le montre le graphique suivant :

30
Applications
Applications préinstallées sur un appareil mobile
Bureau (home), Contacts, Calendrier, Téléphone, Navigateur, eMail, SMS, Navigateur, ….
Plateforme applicative
API de classes Java offertes aux développeurs
Fournisseur de contenu, Système de vues, Gestionnaire d'activités, Gestionnaire de fenêtres,
Gestionnaire des paquetages, Gestionnaire de la téléphonie, Gestionnaire des ressources, …
Librairies
Bibliothèques C/C++
Média, SQLite, Webkit, OpenGL ES, SSL,
SGL, Libc,
Moteur d'exécution Android
Machine virtuelle
Android RunTime (ART)
Bibliothèques internes (Core Libraries)
Couche d’abstraction matérielle (HAL)
Audio, Wifi, Bluetooth, Caméra, Capteurs, …
Noyau Linux
Pilote de l'écran, Pilote de l'appareil photo, pilote de la mémoire Flash, Pilote IPC, Pilote du
clavier, Pilote Wifi, Pilote Bluetooth, Pilotes audio, Gestion de l'alimentation, ...
Tableau 10: Architecture logicielle d'Android
2.2. Les services web
Selon la définition du W3C (World Wide Web Consortium), un Web service (ou service Web) est
une application appelable via Internet - par une autre application d’un autre site Internet -
permettant l’échange de données (de manière textuelle) afin que l’application appelante puisse
intégrer le résultat de l’échange à ses propres analyses. Les requêtes et les réponses sont soumises
à des standards et normalisées à chacun de leurs échanges.
2.2.1. Intérêt des services web
 Décomposition d'une application en briques fonctionnelles ou unités logiques applicatives.
 Composant réutilisable fournissant des données et des services à d’autres Applications.

31
 Facilite l'interopérabilité des différents modèles de composants en interne comme en externe.
 Met en relation des systèmes hétérogènes.
 Utilisation et intégration très facilitées de composants métiers de partenaires
 Agrégation de plusieurs services de métiers différents sur un même site
(horaires/réservation train, assurance, hôtel...).
2.2.2. Les standards des services web
Il existe deux grands standards de services web, tous deux basés sur XML :
XML-RPC: le plus ancien, fonctionnant sur un principe procédural et sans gestion des états.
SOAP: fonctionnant selon le modèle objet.
Quel que soit le standard utilisé, le principe de programmation est le même : l'appel de méthode
distante est réalisé grâce à une bibliothèque cliente qui transmet la demande au fournisseur de
service en la formatant en XML de manière transparente, au niveau du serveur une bibliothèque
serveur décode la requête, le serveur fait ses traitement, puis répond grâce à cette même
bibliothèque; la bibliothèque client décode enfin la réponse afin qu'elle puisse être utilisée par
l'application client.
2.2.3. Qu’est-ce qu’une API ?
L’API, pour Application Programming Interface, est la partie du programme qu’on expose
officiellement au monde extérieur pour manipuler celui-ci. L’API est au développeur ce que l’User
Interface est à l’utilisateur. Cette dernière permet d’entrer des données et de les récupérer la sortie
d’un traitement. Initialement, une API regroupe un ensemble de fonctions ou méthodes, leurs
signatures et ordre d’usage pour obtenir un résultat.
2.2.4. Qu’est-ce qu’une Api REST ?
Une API REST se doit d’être sans état ou stateless en anglais. La communication entre le client et
le serveur ne doit pas dépendre d’un quelconque contexte provenant du serveur. Ainsi, chaque
requête doit contenir l’ensemble des informations nécessaires à son traitement. Cela permet au de
traiter indifféremment les requêtes de plusieurs clients via de multiples instances de serveurs.

32
Figure 10: Api Rest
2.2.5. Api REST ou Api SOAP ?
Il existe actuellement deux types d’architecture très utilisées pour les API : Simple Object Access
Protocol (SOAP) et Representational State Transfer (REST).
SOAP et REST sont deux solutions permettant à un client d’accéder à des services web. Le choix
d'abord peut sembler facile, mais parfois il peut être étonnamment difficile. D’un côté, SOAP,
initialement développé par Microsoft, est un protocole d'accès aux services Web qui existe depuis
un certain temps. De l’autre, l’architecture REST est la nouvelle venue. Elle vise à résoudre
certains problèmes rencontrés avec SOAP et donner la possibilité de mettre en place une méthode
vraiment simple afin d’accéder à des services web.
Les deux techniques ont des problèmes à prendre en compte au moment de décider quel protocole
utiliser. Avant d'aller plus loin, il est important de préciser que même si SOAP et REST présentent
des similitudes en utilisant le protocole HTTP, SOAP est un ensemble plus rigide que REST. REST
a une architecture qui ne nécessite pas de traitement et qui est naturellement plus flexible. SOAP
et REST reposent sur des règles bien établies que tout le monde a accepté de respecter dans l'intérêt
de l'échange d'informations.

33
2.2.6. Pourquoi choisir REST ?
L’Api avec laquelle l’application mobile interagi avec le back-end mobile est développée avec
REST pour les raisons suivante :
En raison de son évolutivité : Ce protocole se distingue par son évolutivité. Grâce à la séparation
client / serveur, le produit peut être mis à l'échelle par une équipe de développement sans trop de
difficultés.
En raison de sa flexibilité et de sa portabilité : Avec l'exigence indispensable pour que les
données d'une des requêtes soient correctement envoyées, il est possible d'effectuer une migration
d'un serveur à un autre ou d'apporter des modifications à la base de données à tout moment. Avant
et arrière peuvent donc être hébergés sur différents serveurs, ce qui constitue un avantage de
gestion important.
En raison de son indépendance : En raison de la séparation entre le client et le serveur, le
protocole facilite le développement indépendant des différents domaines d’un projet. De plus,
l'API REST s'adapte à tout moment à la syntaxe et à la plate-forme de travail. Cela offre la
possibilité d'essayer plusieurs environnements en cours de développement.
2.3. Architecture Technique
Avant de se lancer dans la conception et le développement de tout système informatisé, il est
important de préparer l’architecture de ce dernier. Le terme architecture est vaste puisqu’il peut
désigner l’architecture logique, l’architecture physique, architecture logicielle, etc. Dans cette
partie nous présentons l’architecture globale client/serveur et tous ses composants, l’emplacement
de notre application au sein de cette architecture, et la manière avec laquelle l’application
communique avec les autres composants.
La figure ci-dessous représente l’architecture globale de notre projet

34
Figure 11: Architecture technique du projet
On remarque d’après la figure ci-dessus, que l’architecture technique s’appuie sur trois tiers. Le
tiers client qui représente les terminaux mobiles que ce soit Android ou iOS.
Le tiers Back-end mobile qui de son côté reçoit toutes les requêtes de la part des terminaux mobiles
pour l’acheminer vers le SI interne de Lydec, et aussi il fait la communication avec le service de
Google Firebase afin de diffuser les notifications vers ces terminaux mobile. Le back-end mobile
joue aussi le rôle de l’intermédiaire entre l’application et le SI interne, tout le traitement et la
manipulation des donnés, est effectué à ce niveau.
Le SI interne de Lydec, dans lequel se repose la partie métier de Lydec.
D’une part la communication entre les terminaux mobiles et le back-end mobile, est faite à travers
une Api REST en utilisant le protocole http, et JSON comme format d’échange de données. Et
d’autre part les services qui sont conçus pour tout ce qui est mobile au niveau de SI interne, sont
exposés avec un service web SOAP.
On peut conclure que l’information passe de l’application vers le SI interne à travers 2 services
web, celui qui est entre l’application et le back-end mobile, et l’autre entre ce dernier et le SI
interne.
Nous avons cité dans la partie précédente que les services web servent à exposer des services vers
le monde extérieur via l’internet, la question qui se pose maintenant, c’est pourquoi avoir deux
couches des services web, pendent que le client mobile peut adresser des requêtes directement à
travers l’Api SOAP offerte par le SI interne ?

35
La réponse qui justifie ce choix, c’est que pour des raisons de sécurité et de confidentialité, les
services interne de Lydec ne sont pas exposés au publique, et pour pouvoir les rendre publiques
pour les applications mobiles, ils ont ajouté une autre couche dans le domaine
https://citizen.lydec.ma/, alors toutes les requêtes du côté client passe à travers ce dernier, et seul
ces requêtes, qui sont autorisés dans le coté du SI interne de Lydec.
En tant que développeur mobile dans ce projet, le domaine de mes interventions se limite à la
communication avec le back-end mobile à travers l’Api REST, et la communication avec Firebase
pour manipuler la réception des notifications. C’est-à-dire que je ne pourrai pas savoir tout ce qui
est métier, ou ce qui concerne la base de données, et tout ce qui ce passe derrière, et dans le back-
end lui-même...Etc.
2.3.1. La sécurité des appels des web services
Afin de sécuriser les requêtes http effectuées par le client mobile contre l’espionnage, nous avons
adopté deux méthode, la première est le cryptage des données sensibles, lorsqu’il s’agit de la
méthode post, et l’Ajout d’un jeton, qui est lui-même crypté, dans le Header de chaque requête
http.
 Le cryptage des données
Le Cryptage (le chiffrement) est l’opération qui consiste à transformer une donnée qui peut être
lue par n’importe qui (donnée dite “claire”) en une donnée qui ne peut être lue que par son créateur
et son destinataire (donnée dite “chiffrée” ou encore cryptogramme). L’opération qui permet de
récupérer la donnée claire à partir de la donnée chiffrée s’appelle le déchiffrement (décryptage).
Le chiffrement se fait généralement à l’aide d’une clé de chiffrement, le déchiffrement nécessite
quant à lui aussi une clé de déchiffrement. On distingue deux types de clés :
 Les clés symétriques : il s’agit de clés utilisées en même temps pour le chiffrement et le
déchiffrement. On parle alors de chiffrement symétrique ou de chiffrement à clé secrète.
 Les clés asymétriques : ici les clés utilisées pour le chiffrement et le déchiffrement sont
différentes. On parle alors de chiffrement asymétrique ou de chiffrement à clé publique.
Pour le cryptage des données nous avons adopté l’algorithme « AES Encryption ».
AES est un algorithme de chiffrement symétrique. L'algorithme a été développé par deux
cryptographes belges, Joan Daemen et Vincent Rijmen. AES a été conçu pour être efficace tant

36
sur le plan matériel que logiciel. Il prend en charge une longueur de bloc de 128 bits et une longueur
de clé de 128, 192 et 256 bits.
 Le concept du jeton
L'un des principes clés de REST est qu'il est sans état. Cela signifie que le serveur ne conserve
jamais l'état utilisateur. Dans le contexte de la sécurité, cet aspect a des conséquences lors de la
mise en œuvre de la sécurité. Cela signifie que les indications d'authentification doivent être
envoyées et vérifiées à chaque fois.
Le mécanisme du jeton consiste à intégrer dans le Header de chaque requête http une clé chiffrée
et unique, qui permet d’identifier l’utilisateur qui a tenter d’effectuer cette requête.
Quel que soit la requête http, s’elle ne contient pas un jeton valide, elle sera refusée, et un message
d’erreur sera relevé.
Le jeton est obtenu ou renouvelé à chaque connexion, ce dernier est stocké d’une façon sécurisé
dans le stockage privé interne de l’application dans le terminal mobile.
3. Etude conceptuelle
3.1. Introduction
Dans cette partie on va présenter la conception de notre application, une étude conceptuelle
détaillée des différents diagrammes sera adoptée pour bien comprendre notre application et son
interaction avec les différents composants de l’architecture précédemment présenté.
3.2. Les modèles dynamiques
La modélisation dynamique d’un système consiste à décrire son comportement lors de sa réaction
à son environnement.
3.2.1. Diagrammes d’activité
Le diagramme d’activité décrit les comportements d’une opération (en termes d’actions). À travers
les diagrammes d’activités, on va modéliser les différents processus, et des opérations liées à notre
application.

37
4.2.1.1 Diagramme d’activité « Ajout d’une demande »
Figure 12: diagramme d'activité Ajout d'une demande
Chaque fois qu’on prend une photo avec un appareil photo numérique ou un smartphone, des
métadonnées supplémentaires, appelées données EXIF (Exchangeable Image File Format), sont
intégrées à chaque image. Les données EXIF peuvent inclure diverses informations, telles que la
date et l'heure de la prise de vue, les données GPS, le modèle de l'appareil photo ou du smartphone,
l'utilisation du flash, etc.

38
Une fois la demande reçu, l’agent Lydec va l'analyser et la qualifier et procédera si nécessaire à
l’allocation des ressources pour résoudre le problème. L’utilisateur sera notifié automatiquement
du statut de sa demande, et un nombre de points sera attribué à l’utilisateur selon sa contribution à
préserver les ressources.
4.2.1.2 Diagramme d’activité « traitement d’une demande »
Une fois la demande est traitée de la part de Lydec, l’utilisateur reçoit une notification indiquant
que ça demande est bien traitée. Et pour encourager les citoyens à interagir dans ce processus,
Lydec les récompense par un nombre de points de fidélité.
Figure 13: diagramme d'activité traitement d'une demande
4.2.1.3 Diagramme d’Activité « Inscription»
La création de compte dans l’agence en ligne, est un processus clé. En effet, cela passe par
plusieurs étapes, en premier lieu le client qui souhaite créer un compte doit posséder un numéro
de facture. Après le scan ou la saisie de ce dernier, l’application fait appel au service web pour
obtenir la liste des numéros avec lesquels le client a déjà fait l’abonnement, puis l’application
propose à l’utilisateur deux options, soit de choisir un numéro parmi les numéros déjà existants ,
soit d’indiquer un nouveau numéro, s’il a indiqué un nouveau numéro, il doit le vérifier d’abord
avant de passer à l’étape suivante.
L’étape suivante c’est d’indiquer l’identifiant fournis au moment de la création du contrat
(généralement l’identifiant et le numéro de CIN), si le tout passe bien, l’application redirige
l’utilisateur vers l’étape du remplissage des informations personnelles, le nom, le prénom, l’email,
le mot de passe…etc. si cela passe bien, le client est devenu inscrit maintenant, l’application le
redirige vers la page d’authentification pour se connecter avec son compte récemment créé.
Exchangeable image file format(EXIF) est une norme (standard) qui spécifie les formats des
images, du son et des étiquettes auxiliaires utilisés par les appareils photo numériques, les
scanneurs et autres systèmes gérant des fichiers image et son enregistrés par des appareils
photo numériques. [Wikipedia]

39
Figure 14: diagramme d'activité: Inscription
4.2.1.4 Diagramme d’activité « Modification du login »
La modification du login de l’utilisateur est une opération très sensible, avant d’effectuer cette
opération, l’utilisateur doit d’abord s’authentifier, pour être sûr que celui qui vient de modifier son
login est lui-même l’utilisateur concerné.
La même démarche est appliquée pour la modification du mot de passe.
Figure 15: diagramme d'activité: modification du login
3.2.2. Diagrammes de séquences
Un diagramme de séquence décrit l’aspect dynamique du système. Il modélise les interactions
entre les objets ou entre utilisateur et objet, en mettant l’accent sur la chronologie des messages
échangés.

40
3.2.2.1.Diagramme de séquence « effectuer auto relève »
Figure 16: diagramme de séquence effectuer auto relève
 Déroulement
Pour effectuer l’auto relève, le client indique l’index de consommation, la date de relève, et le
contrat concerné. Tous les champs sont obligatoires.
L’application fait appel au service web pour effectuer l’auto relève, si l’index de consommation
est inférieur à l’index précédent, l’application affiche une erreur. Sinon l’application indique à
l’utilisateur que l’auto relève a été bien effectué.

41
3.2.2.2.Diagramme de séquence « inscription »
Figure 17: diagramme de séquence inscription

42
3.2.2.3.Diagramme de séquence « modification du login »
Avant d’entamer la description de cette procédure il est donc, nécessaire de bien localiser cette
opération dans l’ensemble des cas d’utilisation de notre application présentés auparavant.
La modification du login est parmi les opérations qui appartiennent au cas d’utilisation « Gestion
du profil » dans la partie je gère mon compte.
La figure ci-dessous illustre un diagramme de cas d’utilisation détaillé de cas d’utilisation
« Gestion du profil » :
Figure 18: diagramme de cas d'utilisation gestion du profil
Pour que l’utilisateur puisse accéder à son profil il doit d’abord être authentifié.
La modification du login et mot de passe, se fait par le même processus pour les deux.

43
Figure 19: diagramme de séquence modification du login
3.3. Les modèles statiques
La modélisation statique permet la description de la structure d’un système.
3.3.1. Diagramme de classe
Le diagramme de classes représente les classes intervenant dans le système. Le diagramme de
classe est une représentation statique des éléments qui composent un système et de leurs relations.

44
Figure 20: diagramme de classes
La figure ci-dessus représente le diagramme de classes utilisé dans notre projet.
Ce diagramme de classe représente les classes modèles qui sont basés sur les réponses des services
web, et cela ne reflète pas vraiment ce qui est métier. Tous les classes implémente l’interface
générique de Java Serializable, pour pouvoir les échanger dans le flux. Ce mécanisme s’appelle la
« Sérialisation ».
La sérialisation est un mécanisme de conversion de l'état d'un objet en un flux d'octets. ... Le flux
d'octets créé est indépendant de la plate-forme. Ainsi, l'objet sérialisé sur une plate-forme peut être
dé-sérialisé sur une plate-forme différente. Pour rendre un objet Java sérialisable, nous
implémentons l'interface java.io.Serializable.

45
La sérialisation et la désérialisation dans notre cas consiste à convertir les objets java vers leur
représentation JSON, et vice-versa.
4. Conclusion
Ce chapitre a été le cœur de notre projet, nous avons présenté dans un premier lieu, tous les
aspects techniques du projet, et dans un second lieu, nous avons présenté les différents
diagrammes nécessaires pour décrire les processus de notre application, puis nous avons terminé
le chapitre avec les modèles statiques à travers un diagramme de classes.

Chapitre IV
Réalisation
Dans ce chapitre nous allons présenter les outils et les
technologies utilisés, puis l’ensemble des
fonctionnalités offertes par notre application

47
CHAPITRE 4 : REALISATION
1. Introduction
Dans ce chapitre nous allons présenter les outils que nous avons utilisés pour la mise en place de
cette solution, ainsi que la démonstration de notre application à travers des captures d’écran.
2. Outils du développement
Dans cette partie nous allons présenter les différents outils utilisés pour la mise en place de notre
solution.
2.1. IDEs
2.1.1. Android Studio
2.2. Outils d’analytiques
2.2.1. Facebook analytics
Facebook Analytics est un outil robuste qui permet aux spécialistes du marketing d'explorer les
interactions des utilisateurs avec des objectifs et des canaux de vente avancés pour les publicités
Facebook.
Android Studio est l'environnement de développement intégré
officiel (IDE) du système d'exploitation Android de Google,
construit sur le logiciel IntelliJ IDEA de JetBrains et conçu
spécifiquement pour le développement Android. Il est disponible
en téléchargement sur les systèmes d'exploitation Windows,
macOS et Linux. Il remplace les outils de développement Eclipse
Android (ADT) comme IDE principal pour le développement
d'applications Android natives.

48
Figure 21: Facebook analytics
2.2.2. Crashlytics par Fabric
Figure 22: Crashlytics Par Fabric
Crashlytics est un outil performant de suivi des plantages,
Crashlytics fournit des informations détaillées et exploitables, y
compris la ligne de code exacte sur laquelle l’application s'est
plantée.

49
2.3. Langages de programmation
2.3.1. Java
2.4. Outils Google
2.4.1. Firebase
Firebase est une plateforme de développement d'applications mobiles et web qui fournit aux
développeurs un pack d'outils et de services pour les aider à développer des applications de haute
qualité, à élargir leur base d'utilisateurs et à gagner plus de profits.
Firebase offres beaucoup d’outils tel que : Real time database, Push notification, Firebase
Analytics, Firebase Authentification, Firebase Cloud Messaging…
2.4.2. Google maps
Java est un langage de programmation et une plate-forme informatique
qui ont été créés par Sun Microsystems en 1995. Java est rapide,
sécurisé et fiable. Java est présente sur plusieurs fronts: des ordinateurs
portables aux centres de données, des consoles de jeux aux
superordinateurs scientifiques, des téléphones portables à Internet…
Google Maps est un service de cartographie développé par Google. Il
offre des images satellites, des photographies aériennes, des cartes
routières, des vues panoramiques à 360° des rues, des conditions de
circulation en temps réel et la planification d'itinéraires pour se
déplacer à pied, en voiture, à vélo, en avion ou en transport public.

50
2.5. Contrôle de version
2.5.1. Gitlab
2.5.2. Git
2.6. Autres outils
2.6.1. ProGuard
Proguard est le rétrécisseur (shrinker), optimiseur, obscurcisseur (obfuscator), et pré-vérificateur
de fichier de classe Java libre. Il détecte et supprime les classes, champs, méthodes et attributs
inutilisés. Il optimise le bytecode et supprime les instructions inutilisées. Il renomme les classes,
les champs et les méthodes restants en utilisant des noms courts sans signification.
GitLab est un outil de gestion du cycle de vie de DevOps basé
sur le Web qui fournit un gestionnaire de référentiel Git
fournissant des fonctionnalités wiki, de suivi des problèmes et de
pipeline CI/CD, en utilisant une licence open-source, développée
par GitLab Inc.
Git est un système de contrôle de version distribué pour suivre
les changements de code source pendant le développement
logiciel. Il est conçu pour coordonner le travail des
programmeurs, mais il peut être utilisé pour suivre les
changements dans n'importe quel ensemble de fichiers. Ses
objectifs incluent la vitesse, l'intégrité des données et la prise en
charge des flux de travail distribués et non linéaires.

51
2.6.2. JSON
2.6.3. Invision
2.6.4. Postman
la notation d'objet JavaScript est un format de fichier standard
ouvert qui utilise du texte lisible par l'homme pour transmettre des
objets de données composés de paires d'attributs-valeurs et de
types de tableaux de données.
InVision est un outil de prototypage créé pour les designers. Il
permet de créer rapidement et facilement des maquettes
interactives. invision offre la possibilité de discuter des maquettes
directement à l'intérieur de l'application en laissant des
commentaires, qui sont connectés à un point sur l'écran.
Postman est une application pour interagir avec les API REST. Il
présente une interface graphique conviviale pour construire des
requêtes et lire les réponses.

52
3. Mise en œuvre
3.1. Accueil
Figure 23: splash screen
Le démarrage de l’application commence par une splash screen, qui s’exécute un certain temp. En
ce moment l’application fait appel au service web, pour le contrôle de version, et l’envoie des
informations relatifs au terminal et le token de Firebase, pour l’envoie des futures notifications.
Le contrôle de version sert à vérifier si l’utilisateur dispose la dernière version de l’application,
sinon un pop-up est affiché pour le rediriger vers Google Play, pour télécharger la dernière version.

53
Par la suite l’utilisateur se retrouve vers un slider qui contient les 4 rubriques principales de
l’application. En cliquant sur le bouton accéder ou n’importe quel point sur l’écran l’utilisateur
peut accéder à la rubrique qu’il souhaite.
Figure 24: Accuel

54
3.2. Je contacte mon conseiller
Cette rubrique permet au client d’entrer en contact avec le conseiller du CRC du Lydec.
Figure 25: écran je contacte mon conseiller

55
Le client aura deux possibilités, soit de les contacter avec un appel direct, ou en envoyant un
mail.
Figure 26: écrans appel direct et envoie de message
En cliquant sur appel direct l’application redirige l’utilisateur vers le centre d’appels téléphonique
d’Android.
En cliquant sur message, l’application redirige l’utilisateur vers l’application définit par défaut
pour l’envoie des emails (généralement Gmail).

56
3.3. Ça m’intéresse
Cette rubrique est consacré pour consulter les actualités de Lydec, avoir des conseils pour la
gestion optimale des consommations, trouvez les agences les plus proches, voir la liste des
électriciens agréés par Lydec.
Figure 27: écran ça m'intéresse
Chaque bouton de cette rubrique, permet d’afficher son contenu sous forme d’une page web.
L’utilisateur clique sur un bouton quelconque, l’application fait appel au web service pour

57
demander le contenu html approprié, puis il l’affiche sous forme d’une page web.
Cette rubrique permet à l’utilisateur de consulter les éléments suivant :
Figure 28: rubriques ça m'intéresse

58
Le client peut aussi voir la liste des agences sur la carte sous forme de marqueurs, et en cliquant
sur un marqueur quelconque il peut voir les détails de l’agence.
Figure 29: écran nos agences

59
3.4. J’agis pour ma ville
La rubrique « j’agis pour ma ville », représente la partie de gestion des demandes,
à travers cette section, le client envoie ses demandes vers Lydec, voir la liste des demandes, soit
sur la carte soit sous forme d’une liste, suivre une demande, filtrer la liste des demande. Il aura
aussi la possibilité d’agir pour une autre demande.
Figure 30: écran j'agis pour ma ville
Au début, lorsqu’il clique sur le bouton accéder il se retrouve sur la carte qui contient l’ensemble
des demandes envoyés par des citoyens, sous forme de marqueurs

60
Figure 31: accueil ajout d'une demande
3.4.1. Ajout d’une demande
L’utilisateur doit être identifié pour qu’il puisse ajouter une demande.
Et avant d’entamer cette étape l’application affiche à l’utilisateur un Slider qui illustre comment
il peut s’identifier.

61
L’identification se fait avec la saisi du numéro de téléphone, un code de 4 chiffres sera envoyer à
ce numéro, puis l’application affiche l’écran de saisi du code pour vérifier son numéro.
Figure 32: slider d'aide d'ajout d'une demande

62
Apres le clique sur le bouton « Démarrer » l’application redirige l’utilisateur vers l’écran
d’identification. A noter que l’identification est faite une seul fois.
La figure ci-dessous illustre successivement cette étape.
Figure 33: étapes d'identification

63
L’ajout d’une demande permet au citoyen de signaler aux agents de Lydec, des incidents.
L’application offre à l’utilisateur un ensemble d’éléments pour enrichir sa demande par des
images, vidéos, des audio …etc. Dans un premier lieu l’application ouvre la caméra du téléphone
pour capturer des images relatives à un incident quelconque. Une fois l’image est capturé
l’application vérifie dans les métadonnées de l’image s’il contient des données GPS, si oui il prend
ces données comme adresse de l’incident sinon il propose à l’utilisateur de choisir une position
dans la carte. En Android ces données ne sont pas ajoutées par défaut, l’utilisateur doit activer
cette fonctionnalité dans les paramètres de la caméra. Pour notre cas, cette fonctionnalité est déjà
activée, comme la montre la figure ci-dessous :
Figure 34: paramètres de la caméra

64
Après la capture de l’image, l’application affiche l’écran d’ajout d’une demande, l’utilisateur doit
au moins ajouter une image, et commentaire textuelle, les autres éléments (vidéo, audio..) sont
optionnels.
En cliquant sur « compléter votre demande » l’utilisateur peut joindre plus de medias pour sa
demande.
Figure 35: formulaire d'ajout d'une demande

65
3.4.2. Liste des demandes
L’application affiche les demandes soit sous forme de marqueurs sur la carte, ou sous forme d’une
liste, la figure ci-dessous illustre la liste des demandes.
Figure 36:joindre des médias à la demande

66
Figure 37: liste des demandes
En cliquant sur suivre, l’utilisateur va recevoir des futures notifications concernant cette demande.
Par un clique sur la demande, l’application redirige l’utilisateur vers les détails de cette demande.

67
Le bouton réagir permet à l’utilisateur d’ajouter son intervention sous forme de commentaire sur
une demande donnée.
Figure 38: détails d'une demande

Rapport de stage PFE - Mémoire master: Développement d'une application Android

Rapport de stage PFE - Mémoire master: Développement d'une application Android

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Rapport de stage PFE - Mémoire master: Développement d'une application Android

Similaire à Rapport de stage PFE - Mémoire master: Développement d'une application Android (20)

Dernier

Dernier (9)

Rapport de stage PFE - Mémoire master: Développement d'une application Android