Vous êtes sur la page 1sur 124

N° d’ordre : 04 / IRS / TCO Année Universitaire : 2016 / 2017

UNIVERSITE D’ANTANANARIVO
----------------------
ECOLE SUPERIEURE POLYTECHNIQUE
-----------------------
MENTION TELECOMMUNICATION

MEMOIRE
en vue de l’obtention
du DIPLOME de Master
Titre : Ingénieur
Domaine : Sciences de l’Ingénieur
Mention : Télécommunication
Parcours : Ingénierie des Réseaux et Systèmes (IRS)
par : ANDRIANEKENA Rado Marius

« COLLECTE DE DONNEES MOBILE SECURISEE


AVEC SIG »
Soutenu le 12 Avril 2018 devant la Commission d’Examen composée de :
Président :
M. RATSIMBAZAFY Andriamanga

Examinateurs :
Mme. ANDRIATSILAVO Haja

M. BOTO ANDRIANANDRASANA Jean Espérant

M. RAJAONARISON Roméo

Directeur de mémoire :
M. Randriamitantsoa Andry Auguste
REMERCIEMENTS

Je rends grâce à Dieu pour sa bonté, de m'avoir donné la force et la santé durant la réalisation
de ce mémoire.

Je tiens à remercier sincèrement, Monsieur Panja RAMANOELINA, Professeur Titulaire, le


Président de l’Université d’Antananarivo, d’avoir dirigé l’université d’Antananarivo qui est
l’ainée de toutes les institutions d’enseignement supérieur à Madagascar.

Je remercie chaleureusement, Monsieur ANDRIANAHARISON Yvon, Professeur Titulaire,


Responsable du Domaine Sciences de l’Ingénieur de l’ESPA (Ecole Supérieure Polytechnique
d’Antananarivo), de nous avoir accueilli au sein de son établissement.

Mes remerciements s’adressent également à Monsieur RAKOTOMALALA Mamy Alain,


Maître de Conférences, Responsable de la mention Télécommunication à l’ESPA, d’avoir mis
à notre disposition les moyens d’élaborer ce travail.

Je tiens à témoigner ma reconnaissance et ma gratitude les plus sincères à Monsieur


RANDRIAMITANTSOA Andry Auguste, Maître de conférences, qui, en tant que Directeur de
ce mémoire, s'est toujours montré à l'écoute et très disponible tout au long de sa réalisation.

Je tiens aussi à remercier Monsieur RATSIMBAZAFY Andriamanga, Maître de Conférences,


qui m'a fait l’honneur de présider les membres du Jury de ce mémoire.

Je témoigne toute ma reconnaissance aux autres membres du jury qui ont voulu examiner ce
travail :

• Madame ANDRIATSILAVO Haja, Assistante d’Enseignement et de Recherche


• Monsieur BOTO ANDRIANANDRASANA Jean Espérant, Assistant d’Enseignement
et de Recherche
• Monsieur RAJAONARISON Roméo, Maître de Conférences
J'adresse tout naturellement mes remerciements à tous les Enseignants de l’ESPA, qui nous ont
formés durant ces cinq années d’études.

J'exprime ma très grande gratitude à ma famille, de m'avoir soutenu tout au long de mes études.
Je reconnais les sacrifices que ces longues années ont représentés et je les remercie d'avoir
appuyé mes choix et d'avoir toujours su m'encourager.

Enfin, je ne saurai oublier toutes les personnes qui m’ont aidée de près ou de loin dans
l’élaboration du présent mémoire.

i
TABLE DES MATIÈRES

REMERCIEMENTS......................................................................................................................... i

TABLE DES MATIÈRES ............................................................................................................... ii

NOTATIONS ET ABREVIATIONS............................................................................................ viii

INTRODUCTION GENERALE ......................................................................................................1

CHAPITRE 1 LE MDC ET LE GIS ...........................................................................................3

1.1 Introduction ........................................................................................................................................ 3


1.2 MDC (Mobile Data Collection) ........................................................................................................... 3
1.2.1 Définition ....................................................................................................................................... 3

1.2.2 Principe de fonctionnement ............................................................................................................. 3

1.2.3 Avantages ....................................................................................................................................... 4

1.2.3.1 Rapidité .......................................................................................................................................... 4

1.2.3.2 Prix ................................................................................................................................................ 4

1.2.3.3 Données de qualité ......................................................................................................................... 5

1.2.3.4 Personnalisable .............................................................................................................................. 5

1.2.3.5 Control et flexibilité ........................................................................................................................ 5

1.2.3.6 Convivial ........................................................................................................................................ 6

1.2.4 Les contraintes de la collecte de données à distance ......................................................................... 6

1.2.4.1 Le budget........................................................................................................................................ 6

1.2.4.2 Le lieu de travail ............................................................................................................................. 7

1.2.4.3 Le téléphone ................................................................................................................................... 7

1.2.4.4 Les agents collecteurs ..................................................................................................................... 7

1.2.4.5 Confidentialité et propriété de données ........................................................................................... 7

1.2.4.6 Disponibilité ................................................................................................................................... 8

1.2.4.7 Consommation de batterie .............................................................................................................. 8

1.2.5 La sécurité de MDC ........................................................................................................................ 8

1.2.5.1 Confidentialité................................................................................................................................ 8

1.2.5.2 Authentification et autorisation ...................................................................................................... 9

1.2.5.3 Gestion des clés et mot de passe ...................................................................................................... 9

1.2.6 Composantes du trafic multimédias dans les réseaux mobiles ......................................................... 10

1.2.6.1 Voix.............................................................................................................................................. 10

1.2.6.2 Données ....................................................................................................................................... 10

ii
1.2.6.3 Vidéo ............................................................................................................................................ 11

1.2.7 Classes de service ......................................................................................................................... 11

1.2.7.1 Services conversationnels ............................................................................................................. 11

1.2.7.2 Services interactifs........................................................................................................................ 12

1.2.7.3 Services streaming........................................................................................................................ 13

1.2.7.4 Services background..................................................................................................................... 13

1.3 SIG (Système d’ Information Géographique).................................................................................... 14


1.3.1 Qu’est-ce que le SIG...................................................................................................................... 14

1.3.2 L’importance de la géographie ....................................................................................................... 14

1.3.3 La puissance du SIG...................................................................................................................... 15

1.3.4 Fonctionnements du SIG ............................................................................................................... 16

1.3.4.1 Interroger ..................................................................................................................................... 16

1.3.4.2 Acquérir ....................................................................................................................................... 16

1.3.4.3 Examiner ..................................................................................................................................... 16

1.3.4.4 Analyser ....................................................................................................................................... 16

1.3.4.5 Agir .............................................................................................................................................. 16

1.3.5 Types de données SIG ................................................................................................................... 17

1.3.5.1 Données géographiques................................................................................................................ 17

1.3.5.2 Données statistiques ..................................................................................................................... 17

1.3.6 Acquisition des données ................................................................................................................ 18

1.3.7 Coordonnées et systèmes de projection .......................................................................................... 19

1.3.8 Géoréférencement ......................................................................................................................... 22

1.3.9 Le Web Mapping .......................................................................................................................... 23

1.4 Conclusion........................................................................................................................................ 23
CHAPITRE 2 CRYPTOGRAHIE ............................................................................................ 25

2.1 Introduction ...................................................................................................................................... 25


2.2 La sécurité informatique ................................................................................................................... 25
2.2.1 Les objectifs de la sécurité informatique ........................................................................................ 25

2.2.2 Les moyens de la sécurité informatique ......................................................................................... 25

2.3 La cryptographie ............................................................................................................................... 26


2.3.1 Les techniques de base de la cryptographie .................................................................................... 26

2.3.2 Les algorithmes de chiffrement symétrique .................................................................................... 26

iii
2.3.2.1 Le problème de l’échange des clés ................................................................................................ 27

2.3.2.2 Panorama des méthodes ............................................................................................................... 27

2.3.2.3 Les modes d’utilisation des méthodes blocs ................................................................................... 28

2.3.2.4 DES.............................................................................................................................................. 31

2.3.2.5 AES .............................................................................................................................................. 33

2.3.2.6 BlowFish ...................................................................................................................................... 34

2.3.2.7 Le codage Base64 ......................................................................................................................... 36

2.3.2.8 La taille des clés ........................................................................................................................... 36

2.3.2.9 Qualités d’un système de chiffrement symétrique.......................................................................... 36

2.3.3 Les algorithmes de chiffrement à clé publique ............................................................................... 37

2.3.3.1 La méthode RSA........................................................................................................................... 37

2.3.3.2 Les avantages des méthodes à clé publiques.................................................................................. 38

2.3.3.3 Panorama des méthodes à clés publiques...................................................................................... 39

2.3.3.4 L’attaque de l’homme du milieu ................................................................................................... 39

2.3.3.5 Les standards PKCS ..................................................................................................................... 40

2.3.3.6 La taille des clés ........................................................................................................................... 40

2.3.3.7 La sécurité d’une méthode cryptograhique ................................................................................... 41

2.3.4 La signature numérique ................................................................................................................. 41

2.3.5 Les protocoles cryptographiques.................................................................................................... 42

2.3.6 Le protocole SSL/TLS .................................................................................................................. 43

2.3.6.2 Le protocole SSLv3....................................................................................................................... 44

2.3.6.3 Le protocole de prise de contact (Handshake) ............................................................................... 44

2.4 Conclusion........................................................................................................................................ 46
CHAPITRE 3 LA PLATEFORME JEE ET LE WEB MAPPING.......................................... 47

3.1 Introduction ...................................................................................................................................... 47


3.2 Plateforme J2E ................................................................................................................................. 47
3.2.1 Généralités .................................................................................................................................... 47

3.2.2 Définitions .................................................................................................................................... 47

3.2.3 Application multi-tiers .................................................................................................................. 48

3.2.4 Le composant client ...................................................................................................................... 48

3.2.4.1 Navigateur Web............................................................................................................................ 49

3.2.4.2 Applet ........................................................................................................................................... 49

3.2.4.3 Composants JavaBeans ................................................................................................................ 49


iv
3.2.4.4 Communications .......................................................................................................................... 50

3.2.5 Le composant Web........................................................................................................................ 50

3.2.6 Le composant Métier..................................................................................................................... 51

3.2.7 Le composant EIS ......................................................................................................................... 52

3.2.8 Architecture du Java EE ................................................................................................................ 52

3.2.8.1 Conteneurs et services .................................................................................................................. 53

3.2.8.2 Types de conteneurs ..................................................................................................................... 54

3.3 Le Web Mapping............................................................................................................................... 55


3.3.1 Architecture .................................................................................................................................. 55

3.3.2 PostGIS ........................................................................................................................................ 56

3.3.3 PostgreSQL .................................................................................................................................. 57

3.3.4 Pourquoi PostgreSQL ? ................................................................................................................. 57

3.3.5 Pourquoi ne pas simplement utiliser Shapefiles? ............................................................................ 58

3.3.6 Les bases de données spatiales....................................................................................................... 59

3.3.6.1 Définition ..................................................................................................................................... 59

3.3.6.2 Types de données spatiales............................................................................................................ 59

3.3.6.3 Les fonctions spatiales .................................................................................................................. 60

3.3.7 GeoServer ..................................................................................................................................... 61

3.3.7.1 Les bases du serveur ..................................................................................................................... 61

3.3.7.2 GeoServer en tant que serveur Map .............................................................................................. 63

3.3.7.3 Web Map Service (WMS).............................................................................................................. 64

3.3.7.4 Web Feature Service (WFS) ......................................................................................................... 66

3.3.7.5 Autres protocoles .......................................................................................................................... 67

3.3.8 Leaflet .......................................................................................................................................... 68

3.3.8.1 Création d’une carte..................................................................................................................... 68

3.3.8.2 Couches et sources ....................................................................................................................... 69

3.3.8.3 Couches WMS .............................................................................................................................. 70

3.3.8.4 Couches GeoJSON ....................................................................................................................... 70

3.4 Conclusion........................................................................................................................................ 71
CHAPITRE 4 PRESENTATION ET REALISATION D’UNE APPLICATION
ANDROID ET D’UNE APPLICATION WEB ............................................................................. 72

4.1 Introduction ...................................................................................................................................... 72

v
4.2 Description du projet......................................................................................................................... 72
4.3 Analyse de l’existant ......................................................................................................................... 72
4.3.1 Analyse des couvertures réseaux mobiles à Madagascar................................................................. 72

4.3.2 Choix des opérateurs ..................................................................................................................... 75

4.4 Mises-en œuvre du projet .................................................................................................................. 77


4.4.1 Application Android...................................................................................................................... 77

4.4.1.2 Authentification ........................................................................................................................... 78

4.4.1.3 Collection de données ................................................................................................................... 79

4.4.1.4 Cryptographie............................................................................................................................... 80

4.4.1.5 Transfert de données vers le serveur ............................................................................................. 81

4.4.2 Modèle de données........................................................................................................................ 83

4.4.3 Web Mapping ............................................................................................................................... 83

4.4.3.1 PostGis ......................................................................................................................................... 83

4.4.3.2 Geoserver ..................................................................................................................................... 85

4.4.4 Application Web ........................................................................................................................... 86

4.4.4.1 Implémentation de Hibernate ....................................................................................................... 86

4.4.4.1 Servlet .......................................................................................................................................... 88

4.5 Test et validation ............................................................................................................................... 89


4.5.1 Collecte de données sur Android ................................................................................................... 89

4.5.1.1 Authentification à l’application .................................................................................................... 89

4.5.1.2 Formulaire ................................................................................................................................... 89

4.5.1.3 Cryptage des données ................................................................................................................... 91

4.5.2 Transfert de données au serveur..................................................................................................... 91

4.5.2.1 SMS ............................................................................................................................................. 91

4.5.2.2 HTTPS ......................................................................................................................................... 92

4.5.3 Serveur ......................................................................................................................................... 96

4.5.3.1 Réception des données .................................................................................................................. 96

4.5.3.2 Vérification des données dans la base de données ......................................................................... 96

4.5.4 Présentation des résultats dans l’application web ............................................................................ 97

4.6 Conclusion........................................................................................................................................ 99
CONCLUSION GENERALE ....................................................................................................... 100

ANNEXES ..................................................................................................................................... 101

vi
ANNEXE 1 LES CONCEPTS DU GEOSERVER ....................................................................... 101

A1.1 Espace de travail............................................................................................................................... 101


A1.2 Entrepôt............................................................................................................................................ 102
A1.3 Couches ............................................................................................................................................ 102
A1.4 Agrégation des couches .................................................................................................................... 103
A1.5 Style.................................................................................................................................................. 104
ANNEXE 2 CODE SOURCE DE L’APPLICATION WEB........................................................ 105

A2.1 Hibernate ......................................................................................................................................... 105


A2.2 Entité ................................................................................................................................................ 105
A2.3 DAO ................................................................................................................................................. 105
A2.4 Servlet............................................................................................................................................... 106
BIBLIOGRAPHIE ........................................................................................................................ 108

FICHE DE RENSEIGNEMENTS ................................................................................................ 111

vii
NOTATIONS ET ABREVIATIONS

1. Minuscules latines
𝑛 Le produit de 𝑝 et 𝑞
𝑝 Nombre entier de l’ordre de 100 chiffres
𝑞 Nombre entier de l’ordre de 100 chiffres

2. Majuscules latines
𝐶% Message crypté
𝐸' System de chiffrement
𝑀) Message claire
𝐾 Clé
𝐿 Données découpée à gauche dans le schéma de Feistel
𝑅 Données découpée à droite dans le schéma de Feistel
𝑋𝑂𝑅 Opérateur ou exclusif

3. Abréviations
ACID Atomicité, Cohérence, Isolation et Durabilité
AES Advanced Encryption Standard
API Application Programming Interface
AWT Abstract Window Toolkit
CBC Cipher Bloc Chaining
CFB Cipher Feed Black
CSV Comma-Separated Values
DES Data Encryption Standard
DNS Domain Name Server
ECB Electronic Code Block
GIS Geographic Information System
GPRS General Packet Radio Service
GPS Global Positioning System
GSM Global System for Mobile Communication
HTML Hypertext Markup Language
HTTP Hyper Text Transfer Protocol
HTTPS HTTP Secure
IDEA International Data Encryption Algorithm

viii
IETF Internet Engineering Task Force
IIS Internet Information Services
IMEI International Mobile Equipment Identity
IMSI International Mobile Subscriber Identity
IPSEC Internet Protocol Security
ITU International Telcommunication Union
IV Initial Vector
JEE Java Enterprise Edition
JNDI Java Naming Directory Interface
JSE Java Standard Edition
JSF JavaServer Faces
JSON JavaScript Object Notation
JSP JavaServer Pages
MAC Message Authentication Code
MD5 Message Digest 5
MDC Mobile Data Collection
MMS Multimedia Messaging Service
NIST National Institute of Standards and Technology
OFB Output FeedBack
OGC Open Geospatial Consortium
ORDBMS Object Relational Database Management System
PGP Pretty Good Privacy
PKCS Public Key Cryptography Standards
RSA Ronald Rivest, Adi Shamir, Leonard Adleman
SIG Système d’Information Géographiques
SIM Subscriber Identity Module
SMS Short Message Service
SQL Structured Query Language
SSH Secure Shell
SSL Secure Sockets Layer
TCP Transmission Control Protocol
TLS Transport Layer Security
UMTS Universal Mobile Telecommunication System
URL Uniform Resource Protocol
VoIP Voice Over IP
ix
WCS Web Coverage Service
WFS Web Feature Service
WGS World Geodetic System
WML Wireless Markup Language
WMS Web Map Service
WPS Web Processing Service
XML Extensible Markup Language

x
INTRODUCTION GENERALE

Les progrès de la technologie de l'information ont ouvert de nouvelles voies passionnantes de


la collecte de données. L'une de ces avancées est le MDC (Mobile Data Collection), qui utilise
de manière innovante la technologie mobile pour remplacer la collecte de données sur papier et
stylo, et qui est de plus en plus adoptée dans le monde entier. Les appareils mobiles se sont
révélés très prometteurs pour améliorer l'efficience et l'efficacité de la collecte de données car
comparé à un processus traditionnel qui repose sur des formulaires sur papier avec transcription
ultérieure à un système informatique, les appareils mobiles offrent la numérisation immédiate
des données recueillies pendant l'enquête. Cela permet une agrégation de données rapide et
automatisée. Il est courant que les organisations publiques et privées basent leurs processus
décisionnels clés sur des données, ce qui signifie que la collecte de données précises est
essentielle pour une précise de décision.

L'expression "un dessin vaut mieux qu'un long discours" s'applique parfaitement aux Systèmes
d'Information Géographiques ou SIG : à l'aide d'une carte vous pouvez visualiser en un coup
d'œil où sont situés les besoins et les ressources, puis décider du meilleur moyen de relier les
deux. Une présentation cartographique de la situation permet d'améliorer de façon spectaculaire
la prise de décision. De ce fait le SIG est beaucoup plus qu'un simple programme qui dessine
des cartes élégantes. Le SIG ne montre pas seulement une carte d'une région géographique, il
associe également une base de données à cette carte et c’est ainsi que la collecte de données et
le SIG sont dépendants entre eux.

Au fur et à mesure que des informations sensibles sont stockées, échangées et traitées pendant
la collecte de données mobile, des questions telles que la confidentialité, l'intégrité, la
disponibilité et l'authentification doivent être traitées en conséquence. De plus, les logiciel SIG
a permis aux utilisateurs de visualiser les données spatiales dans leur format approprié. Par
conséquent, l'interprétation des données spatiales est devenue facile et de plus en plus simple à
comprendre. Malheureusement, tout le monde n'a pas accès au SIG et ne serait pas capable de
passer le temps nécessaire pour l'utiliser efficacement. Le Web Mapping devient un moyen
simple de diffuser des données géospatiales grâce à Internet.

Ce qui nous amène à ce mémoire intitulé « Récolte de données mobile sécurisée avec SIG » qui
a pour but de mettre en relation la collecte de données mobile et le SIG, tout en assurant que les
données manipulées soient protégées en fournissant un niveau adéquat de protection des
données à tout moment, à la fois lorsqu'il est collecté et stocké sur l'appareil mobile, tout en

1
étant transféré et stocké sur le serveur, ainsi que de mettre en œuvre une application web en
JEE (Java Enterprise Edition) afin de visualiser les données collectées par le Web Mapping.

Afin de mieux cerner le sujet, ce livre sera divisé en 4 chapitres : le premier chapitre consiste
en la présentation générale du MDC ainsi que le SIG. Dans le second chapitre, nous aborderons
le principe de la sécurité, la majeure partie de ce chapitre sera consacré à l’étude de la
cryptographie. Dans le troisième chapitre, la plateforme JEE sera présenté suivi de
l’architecture générale du Web Mapping. Dans le dernier chapitre, on va passer à la présentation
du projet proprement dit, ainsi qu’au test et validation du projet.

2
CHAPITRE 1
LE MDC ET LE GIS

1.1 Introduction

Dans ce chapitre, nous allons voir en premier lieu la présentation du MDC pour comprendre
son principe, et en second lieu, nous allons focaliser notre étude à l’explication du Système
d’Information Géographique.

1.2 MDC (Mobile Data Collection)

1.2.1 Définition

La collecte de données mobiles (MDC) fait référence à l'utilisation de produits de technologie


de l'information existants tels que les téléphones, les smartphones et les tablettes (matériel) et à
un certain nombre de programmes (logiciels) différents pour la collecte de données selon les
besoins des bénéficiaires. [1].

1.2.2 Principe de fonctionnement

Le MDC permet la collecte et la transmission des données à partir d’un emplacement


géographique à distant vers un stockage de données à travers un réseau sans fil ou cellulaire.
[2] C’est une combinaison d’une application cliente fonctionnant sur les appareils mobiles,
infrastructure sans fil et de serveur de base de données accessible à distance.

La plupart des systèmes MDC ont le même principe pour collecter des données à distance. Le
processus commence par la conception d’un formulaire, qui contient une série de questions pour
la collecte des informations. Le formulaire est stocké dans une base de données. Puis, les
collectionneurs peuvent télécharger ces formulaires sur leur appareil mobile et les utiliser pour
recueillir les données réelles sur terrain. Les formulaires qui ont été remplis sont stockés sur
l’appareil mobile jusqu’est ce qu’il soit possible de les uploader vers le serveur central. [3]

3
Figure 1.01: Principe de MDC

1.2.3 Avantages

1.2.3.1 Rapidité

En comparaison de la traditionnelle enquête de terrain sur papier, une solution sur mobile peut
apporter des gains de temps, des réponses standardisées, une collecte d’information plus
diversifié et produire des résultats qu’on peut analyser et partager à instant donné. [1]

1.2.3.2 Prix

Les couts initiaux peuvent être plus élevées que la collecte de données sur support papier, car
vous devrez peut-être vous procurer des tablettes, des smartphones, ou dans certains cas, des
licences logicielles mais cela peut également entraîner des économies importantes, notamment
grâce à l'élimination du processus de saisie des données. [4]

L'obtention d'un taux d'erreur considérable avec les méthodes d'enquête traditionnelles
nécessite souvent une « double entrée de données», où deux travailleurs distincts saisissent les
mêmes données et un superviseur identifie les différences entre les deux [5]. L'élimination de
cette redondance représente souvent une réduction significative des coûts. Plus la taille de
l'enquête est grande, plus les économies réalisées grâce à cette activité sont importantes, car la
saisie manuelle nécessite un certain temps. Des économies supplémentaires peuvent être
réalisées sur les coûts d'impression, ce qui peut être important à mesure que la taille de l'enquête
et la durée des interviews augmentent.

4
1.2.3.3 Données de qualité

Comme les données n'ont pas besoin d'être transcrites séparément du papier à un ordinateur, il
n'y a aucune possibilité de mauvaise saisie des données pendant cette phase.

De plus, les outils MDC permettent de valider les données saisies lors d'une interview. Par
exemple, les questions nécessitant une réponse numérique peuvent être forcées à accepter
uniquement une réponse numérique, qui peut également être forcée dans une plage (par
exemple, entre 1 et 99 ans) pour réduire le risque d'erreurs de saisie. Les réponses aux questions,
telles que la date de naissance et l'âge, peuvent être référencées pour se valider les unes les
autres et inciter l'énumérateur à clarifier les incohérences. Les formulaires qui ne sont pas
remplis peuvent être codés pour ne pas permettre la soumission.

En plus des questions programmées dans l'enquête, certains outils MDC collectent
automatiquement les métadonnées telles que les horodatages. Ceux-ci permettent au
superviseur de l'enquête de surveiller les heures de début et de fin des entrevues afin de s'assurer
qu'elles correspondent au comportement d'entrevue prévu, et aide ainsi les agents recenseurs à
être plus responsables.

1.2.3.4 Personnalisable

Bien que l'étendue exacte dépende du choix du logiciel, les outils MDC offrent généralement
un large éventail de possibilités de personnalisation.

Des exemples de ces fonctionnalités supplémentaires incluent la possibilité d'utiliser l'audio,


les graphiques ou la vidéo pour améliorer la compréhension des sujets de l'enquête et d'utiliser
une fonction caméra pour capturer une photo d'une école tout en capturant sa position GPS
(Global Positioning System) pour créer une carte images ainsi que l'emplacement des sites
d'enquête.

1.2.3.5 Control et flexibilité

Un accès plus rapide aux données améliore non seulement l'analyse et la réactivité du
programme, mais améliore la capacité du personnel à réagir aux changements inattendus. Par
exemple, puisque les enquêtes dans les dispositifs MDC peuvent être mises à jour, il est possible
de résoudre de petits problèmes dans la conception des questionnaires tels que les fautes de
frappe, les questions mal formulées ou la logique de filtrage. Pour des études plus longues,
d'autres questions peuvent même être ajoutées pour étudier des résultats intéressants. Les coûts

5
de ces réponses sont négligeables, car le personnel responsable ou les superviseurs de terrain
peuvent apporter des modifications à leur téléphone mobile.

Une supervision efficace des enquêteurs est également un problème commun dans le travail de
terrain, et peut être considérablement atténuée par l'utilisation d'outils MDC. En plus des
métadonnées et des horodatages automatiques, la fonction supplémentaire du GPS (variable
selon la sélection du matériel) permet de suivre l'itinéraire de l'enquêteur pour valider davantage
que les directives du superviseur ont été suivies. Cela permet au personnel de donner des
informations en retour aux équipes d'enquêteurs et d'améliorer leurs performances.

1.2.3.6 Convivial

L'utilisation des technologies MDC permet également aux enquêteurs de renforcer leur capacité
à utiliser les technologies de l'information. La possession de dispositifs MDC peut même
améliorer la crédibilité de la collecte de données ou de la recherche et du personnel aux yeux
de la communauté locale.

Comme l'application guide l'agent recenseur tout au long de l'entrevue, il peut consacrer moins
d'efforts à s'assurer que toutes les bonnes questions sont posées et ainsi mieux se concentrer sur
d'autres aspects pertinents de l'entrevue et maintenir un bon rapport. Plus les conditions pour
poser une question sont compliquées (par exemple, demander seulement si les trois questions
précédentes ont une certaine réponse), plus cet avantage sera évident.

Un recenseur qui collecte des données avec un appareil mobile n'a pas besoin de transporter un
grand nombre de matériel d'enquête. Tout ce qui est nécessaire est l'appareil lui-même et peut-
être un chargeur ou une batterie de secours. Cela réduit les tracas et le fardeau des méthodes
traditionnelles de stylo et de papier.

1.2.4 Les contraintes de la collecte de données à distance

1.2.4.1 Le budget

La plupart des défis rencontrés lors de la sécurisation des systèmes MDC viennent du fait que
de nombreux projets fonctionne sur des petits budgets (Low budget). Cela a des répercussions
sur le type du matériel et des logiciels utilisés. Par exemple, de tel projets utilisent des
téléphones mobiles qui ont une faible puissance de calcul et relativement peu de mémoire. D’où
le problème de trouver un compromis entre la cryptographie des données et la puissance de
calcul disponible.

6
1.2.4.2 Le lieu de travail

De nombreux projets utilisant le MDC sont déployé dans des pays sous-développés où
l’infrastructure pour la communication mobile et l’accès à internet ne sont pas encore
complètement développés [3] [6]. En outre, la collecte des données pourrait avoir dans des
endroits éloignés ou des villages isolés où la possibilité de transmettre des données par un
téléphone mobile peut être très limitée ou même inexistant. Ainsi, il n’est pas raisonnable de
supposer que les données collectées pourraient rester au téléphone pendant plusieurs jours avant
d’être uploadé (remonté au serveur).

Cela signifie que la majeure partie de la collecte de données est effectué hors ligne, et les
collectionneurs doivent être en mesure de s’authentifier sur le téléphone mobile sans se
connecter à internet.

1.2.4.3 Le téléphone

Une autre question est liée au fait que nous ne pouvons pas supposer que chaque téléphone
portable est seulement utilisé par un agent collecteur spécifique, mais il pourrait être utilisé par
plusieurs agents collecteurs et chacun avec leur compte propre et le même agent pourrait être
enregistré sur plusieurs téléphone. Le partage de téléphone entre plusieurs agents pose de
problème en matière de confidentialité et de contrôle d’accès puisque la plupart des travaux est
fait hors ligne et de grandes quantités de données sensibles peuvent être stockées sur un
téléphone. Les différents utilisateurs ne devraient pas pouvoir accéder d’autres données que les
leurs ou compromettre d’autres comptes utilisateurs.

1.2.4.4 Les agents collecteurs

Les agents collecteurs doivent généralement être formés à l’utilisation du MDC avant de
pouvoir aller sur terrain et commencer à collecter des données. L’implémentation de la sécurité
dans le système ne devrait pas compromettre la facilité d’utilisation du dispositif utilisé pendant
la collecte de données. De plus, si les collectionneurs étaient déjà formés pour utiliser un MDC
spécifique, ils pourraient avoir besoin d’être formé à nouveau, si la solution de sécurité adoptée
a conduit à des changements importants dans l’interface utilisateur ou la logique de
l’application.

1.2.4.5 Confidentialité et propriété de données

De nombreux projets qui collectent des informations privées et sensibles pourraient avoir un
problème avec le stockage des leurs données si la base de données se situe dans des serveurs
7
tiers. Il est préférable de configurer son propre serveur plutôt que d’utiliser des systèmes offrant
l’application cliente, le stockage de données et la gestion à la fois. L’inconvénient est bien sûr
que les couts liés à la mise en place et la maintenance de l’infrastructure sont laissés aux projets
individuels [3]. Par conséquent, les couts de fonctionnement devraient être minimisés ce qui
pourraient empêcher l’adoption des solutions de sécurité.

1.2.4.6 Disponibilité

Il est primordial que les données collectées ne soient pas perdues ou rendues inaccessibles
simplement parce qu’un mot de passe de l’appareil mobile a été perdue. Par conséquent, des
mécanismes de récupération adéquats doivent donc être en place. De tels mécanismes devraient
également prendre en considération que le même compte pourrait être utilisé pour accéder aux
services fournis par le serveur ou également à partir d’une application web, non seulement le
téléphone mobile [6]. De ce fait, changer un compte d’utilisateur à partir d’un emplacement ou
un dispositif donné ne devrait pas compromettre l’autre moyens d’accès.

1.2.4.7 Consommation de batterie

Un aspect très important dans la collecte de données à distance est que les appareils mobiles
devraient avoir une longue vie de batterie [7], puisque dans certains régions éloignés,
l’électricité pourrait être une ressource rare et il ne pourrait ne pas toujours être possible de les
charger à chaque fois nécessaire. Par conséquent, si une solution de sécurité proposée
consomme trop de ressources et raccourcit considérablement la vie de batterie, cela pourrait
rendre la collecte de données mobiles tout simplement une alternative irréalisable.

1.2.5 La sécurité de MDC

Le MDC traite une grande quantité des informations sensibles et privées, donc il doit fournir
un niveau de protection adéquat pour les données en tout temps : à la fois pendant qu’il est
recueilli et stocké sur l’appareil mobile, et tout en étant transféré et stocké au serveur. Alors
dans cette section, nous allons voir comment sécuriser les données sur le téléphone mobile et
la solution pour sécuriser la transmission de données entre le client et le serveur.

1.2.5.1 Confidentialité

La première chose qu’on doit prendre en compte c’est de vérifier si les données étaient
correctement protégées contre la divulgation non autorisée lorsqu’elles sont stockées sur
l’appareil mobile et lorsqu’elles sont transférées au serveur.

8
a. La communication

Pour protéger la transmission de données entre le client et le serveur, le MDC doit supporter le
HTTPS [3]. En générale, cette solution est plus que suffisante pour assurer que les données en
transit entre le client et le serveur soient protégées dans de bonnes conditions.

b. Le stockage

Quant aux données, tout en étant stocké sur l’appareil mobile, contrairement à la
communication client-serveur, donnent de sérieuses raisons de préoccupations. Pour cela, on
doit chiffrer les données.

1.2.5.2 Authentification et autorisation

En traitant de l’authentification dans la collecte de données à distance, il y a principalement


deux aspects à considérer : l’authentification locale et l’authentification du serveur.

Chaque client mobile doit fournir une certaine forme d’authentification locale afin d’empêcher
tout utilisateur non autorisé de falsifier les données stockées sur le téléphone, malgré le
cryptage. En fait, une personne autorisée à utiliser l’application pourrait également déchiffrer,
modifier et supprimer des données. Ceci est encore plus critique si plusieurs utilisateurs
partagent le même téléphone.

En ce qui concerne l’autorisation, lorsque plusieurs utilisateurs sont autorisés à partager un


téléphone, ils ne devraient pas partager le stockage, ou s’ils le font, un mécanisme devrait être
en place pour les empêcher de lire les données de l’autre.

1.2.5.3 Gestion des clés et mot de passe

Tant que HTTPS est utilisé pour protéger la transmission de données, un certificat valide
reconnu par l’appareil mobile est nécessaire. Le reste de la gestion des clés est pris en charge
par le protocole SSL/TLS sur lequel HTTPS est basé [8].

Lorsque les mots de passes sont utilisés pour l’authentification des utilisateurs, certains
mécanismes de distribution et de récupération doivent être mis en place pour garantir la
disponibilité du service et des données, dans le cas où les mots de passes sont perdus ou oubliés.

Tant que les informations d’identification sont identiques sur le client et le serveur et qu’elles
ne sont pas stockées sur le client, il est assez facile de les modifier uniquement sur le serveur,
même s’il peut être difficile de les distribuer en toute sécurité aux collectionneurs sur le terrain.

9
1.2.6 Composantes du trafic multimédias dans les réseaux mobiles

D’après le principe de MDC expliqué précédemment, il utilise les réseaux mobiles pour
transférer les données du téléphone mobile vers le serveur. Alors il est impératif d’étudier les
composantes du trafic multimédias dans les réseaux mobiles.

Actuellement, les services offerts par les réseaux mobiles génèrent trois types de trafic : la voix,
les données et la vidéo. Dans cette section, nous allons caractériser chacune de ces composantes
du trafic.

1.2.6.1 Voix

Jusqu’à présent, le trafic de la voix est surtout exploité dans la téléphonie, Les débits et les délais
de ce type de trafic doivent permettre à l’utilisateur d’avoir la qualité de service exigée par ce
type d’application. Ce débit doit varier entre 32 kbps et 384 kbps, tandis que le délai ne doit pas
dépasser les 400 ms [9]. Les contraintes de délais présentées dans le tableau sont définies dans
la recommandation G.114 de l’ITU (International Telecommunication Union). L’ITU a
déterminé ces valeurs pour que le temps d’attente pendant l’utilisation du service vocal ne soit
pas perceptible par les abonnés.

Délai en milliseconde Description


0 – 150 Acceptable pour la plupart des applications
150 - 400 Acceptable pour les usagers mobiles à condition que le réseau
tienne compte du temps de la transmission et offre les meilleurs
délais pendant la communication.
Au-delà de 400 Généralement inacceptable par les utilisateurs mobiles sauf pour
quelques un.

Tableau 1.01: Spécification du délai pour le trafic de la voix

1.2.6.2 Données

C’est le type de trafic le plus utilisé actuellement dans les réseaux mobiles [10]. Sa première
apparition fut avec l’arrivée des systèmes GSM (Global System for Mobile communication), et
le principal service qui le générait était le SMS (Short Message Service). Actuellement, il existe
une panoplie de services multimédia qui le génèrent : MMS (Multimedia Messaging Service),
téléchargement, jeux, messagerie instantanée…

10
Les valeurs de paramètres de transmission (débit, délai) pour le trafic de données dépendent de
l’application qui le génère [9] [11]. En général, la limite du délai de bout en bout pour le trafic
de données est de 250 ms : s’il dépasse 150 ms, il est considéré comme bon et s’il est les
voisinages de 250 ms, il est considéré comme acceptable.

1.2.6.3 Vidéo

Le trafic de type vidéo peut être considéré comme un cas particulier de trafic de données. Mais,
pour certaines applications, il peut avoir les mêmes exigences que le trafic de la voix. C’est le
cas par exemple de la vidéophonie qui consiste à converser avec un interlocuteur tout en
visualisant avec l’écran du terminal.

La caractéristique majeure des applications de type vidéo est l’utilisation d’une bande passante
plus grande. En effet ce type de trafic n’a fait son apparition que dans la dernière décennie à
l’arrivée du GPRS (General Packet Radio Service) qui a comblé le problème des ressources
inadaptées pour la transmission de la vidéo dans les systèmes GSM. La largeur de bande d’un
canal de transmission était égale à 200 kHz et le débit était égal à 9.14 kbps. L’UMTS (Universal
Mobile Telecommunications System) et les autres systèmes de la troisième génération ont
augmenté encore plus ces caractéristiques (3.84 MHz comme largeur de bande de chaque canal
de transmission et au moins 114 kbps pour le débit), ce qui a permis d’offrir plus d’applications
vidéo [10].

En général le délai de bout en bout est considéré bon si s’il ne dépasse pas de 150 ms et
acceptable s’il varie entre 150 ms et 300 ms.

1.2.7 Classes de service

Les caractéristiques des trois composantes de trafic générées dans les réseaux mobiles
dépendent énormément de la nature des applications sollicités. Ces applications peuvent être
classés selon leur comportement et par rapport aux contraintes de transmission (débit, délai,
tolérance à des erreurs). Actuellement, on distingue quatre classes de services :
conversationnelle, interactive, streaming et arrière-plan (background) [12].

1.2.7.1 Services conversationnels

Les services de cette catégorie permettent de transmettre principalement du son et des images
en temps réel entre deux personnes ou un groupe de personnes. Leur qualité est donc assez
sensible aux délai de transmission, car ces données peuvent être facilement perceptibles par les
utilisateurs. Parmi ces services, nous pouvons citer la téléphonie en mode circuit, la téléphonie
11
en mode paquet utilisant le protocole VoIP (Voice over IP) et la vidéophonie. Ce dernier service
est moins tolérant aux erreurs que la téléphonie et requiert généralement un débit plus
important.

La transmission des applications de cette classe doit être symétrique (même débit de
transmission en émission et en réception). Pour les services de vidéophonie, il faut aussi que la
voix et les images soient transmises de manière synchrone pour bien coordonner les images et
le son.

Figure 1.02: Service conversationnel

1.2.7.2 Services interactifs

Cette classe comprend les services nécessitant une certaine interaction avec le destinataire sous
forme de requêtes/réponses. Une application interactive est caractérisée par le fait que
l’expéditeur de la requête attend une réponse du destinataire dans un certain temps. Par
conséquent, la qualité de service est mesurée par le temps d’aller-retour, c’est-à-dire le temps
écoulé entre le moment où le message est envoyé et celui où la réponse arrive. Le destinataire
dans les services interactifs peut être une machine (un serveur par exemple) ou une personne.

Plusieurs types de services appartiennent à cette classe : Les jeux interactifs en font partie, à
condition que la nature de ces jeux n’exige pas de délais de transmission très faibles. La classe
« interactive » comprend aussi les services de localisation, car leur fonctionnement consiste à
répondre aux requêtes envoyées par l’utilisateur mobile. Les interactions avec le réseau Internet
via un terminal mobile constitue une autre catégorie d’applications interactives. Pour ce dernier
service, le temps de réponse doit se situer entre 2 et 4 secondes.

12
Figure 1.03: Service interactif

1.2.7.3 Services streaming

Les services de cette classe utilisent la technique « streaming » qui consiste un flux continu
d’informations et à les traiter instantanément au niveau du terminal mobile. Les informations
utilisées dans ces services sont de type audio ou vidéo. Les services « streaming » sont de plus
en plus utilisés, car la majorité des utilisateurs d’Internet n’ont pas d’accès suffisamment rapide
pour télécharger des fichiers multimédias volumineux en un temps raisonnable. A l’aide de la
technique « streaming », le navigateur client peut commencer à afficher les données avant que
l’intégralité du fichier ne soit téléchargée.

Cette classe de service est unidirectionnelle : la transmission se fait seulement de la station de


base à l’utilisateur mobile. Ces services sont assez récents et offrent un potentiel d’application
assez vaste. Par exemple, dans un terminal mobile, on peut recevoir des fichiers audio et les
écouter sans avoir à les conserver localement, en raison du manque de la mémoire, il en est de
même pour les images que l’on souhaite visualiser rapidement.

Figure 1.04: Service Streaming

1.2.7.4 Services background

Ce sont des services qui ne posent, ou presque, aucune contrainte de temps pendant le transfert
de l’information qu’ils génèrent. Ils peuvent s’exécuter en arrière-plan (background). Le temps

13
de transfert de ces services peut se mesurer en secondes, dizaines de secondes, ou minutes, sans
perturber le déroulement des autres applications de l’utilisateur.

Parmi ces services, il existe la transmission des données des courriels, le SMS, le
téléchargement de contenu des bases de données. Le service d’envoie et de réception de cartes
postales électroniques est un autre exemple d’application background qui devient de plus en
plus populaire.

Figure 1.05: Service background

1.3 SIG (Système d’ Information Géographique)

1.3.1 Qu’est-ce que le SIG

Un Système d’Information Géographique est un outil informatique permettant de représenter et


d’analyser toutes les choses qui existent sur terre ainsi que tous les évènements qui s’y
produisent [13] [14].

1.3.2 L’importance de la géographie

Une transformation est en cours. Les entreprises, et les gouvernements, les écoles et les
hôpitaux, les organisations à but non lucratif, et d’autres en profitent. Partout dans le monde,
les gens travaillent plus efficacement grâce à cela.

L’information limitée aux tableurs et aux bases de données se déchaine d’une manière nouvelle
et passionnante, tout en utilisant la géographie [13]. Mais ce n’est pas la géographie à l’école
primaire. Cette approche utilise la géographie pour acquérir de nouvelles idées et prendre de
meilleurs décisions, plus éclairées.

Lier l’emplacement à l’information est un processus qui s’applique à des nombreux aspects de
la prise de décision dans l’entreprise et de la communauté [15]. Comment les organisations
débloquent-elles la géographie à partir des données qu’elles utilisent chaque jour pour prendre

14
des décisions ? pour quiconque essaie d’évaluer l’information, la façon la plus intuitive de la
voir est sur une carte.

Pas n’importe quelle carte, mais des cartes numériques intelligentes rendues possibles grâce à
la technologie du SIG [13] [16]. Même les personnes qui n’ont jamais utilisé de cartes pour
analyser les données, constatent que les cartes rendent le traitement d’information beaucoup
plus facile et plus efficace.

Les gens utilisent le SIG pour visualiser, questionner, analyser et comprendre les données sur
le monde et l’activité humaine. Souvent, ces données sont visualisées sur une carte, ce qui
constitue un avantage par rapport à l’utilisation de feuilles de calcul ou de base données, parce
que les cartes et l’analyse spatiale peuvent révéler des modèles, et signaler des problèmes et
montrer des connexions qui peuvent ne pas apparaître dans les tableaux ou le texte.

1.3.3 La puissance du SIG

Le SIG est un outil informatique qui relie les informations géographiques (où sont les choses)
avec des informations descriptives (quelles sont les choses). Contrairement à une carte sur
papier, où ce que vous voyez est ce que vous obtenez, le SIG peut présenter de nombreuses
couches d’informations différentes.

Les SIG offrent toutes les possibilités de bases de données (telles que requetés et analyses
statistiques) et ce, à travers d’une visualisation unique et d’analyse géographique propres aux
cartes. Ces capacités spécifiques font du SIG un outil unique, accessible à un public très large
et s’adressant à une très grande variété d’applications. Les enjeux majeurs auxquels nous ont à
faire face aujourd’hui (environnement, démographie, santé public…) ont tous un lien étroit avec
la géographie.

De nombreux autres domaines tels que la recherche et le développement de nouveaux marchés,


l’étude d’impact d’une construction, l’organisation du territoire, la gestion de réseaux, le suivi
en temps réel des véhicules, la protection civile… sont aussi concernés par la puissance des SIG
pour créer des cartes, pour intégrer tout type d’information, pour mieux visualiser les différents
scénarios, pour mieux présenter les idées et pour mieux appréhender l’étendue des solutions
possibles.

Les SIG sont utilisés par tous ; collectivités territoriales, secteur public, entreprise, écoles,
administrations, et états utilisent le SIG. La création de cartes et l’analyse géographique ne sont

15
pas des procédés nouveaux, mais les SIG procurent une plus grande vitesse et proposent des
outils sans cesse innovant dans l’analyse, la compréhension et la résolution des problèmes.

L’avènement des SIG a également permis un accès à l’information à un public beaucoup plus
large.

1.3.4 Fonctionnements du SIG

Un processus en 5 étapes permet d’appliquer le SIG, à toute entreprise ou problème


organisationnel qui nécessite une décision géographique, à savoir : Interroger, Acquérir,
Examiner, Analyser et Agir [13] [17].

1.3.4.1 Interroger

Quel est le problème que vous essayez de résoudre ou d’analyser, et où se situe-t-il ?


L’encadrement de la question vous aidera à décider quoi analyser et comment présenter les
résultats à vote audience [17] [18].

1.3.4.2 Acquérir

Ensuite, vous devez trouver les données nécessaires pour compléter votre projet. Le type de
données et la portée géographique de votre projet aideront à orienter vos méthodes de collecte
de données et d’analyse.

1.3.4.3 Examiner

Vous saurez seulement avec certitude que vos données sont appropriées pour votre étude après
un examen approfondi. Cela inclus la manière dont les données sont organisées, leur précision
et l’origine des données.

1.3.4.4 Analyser

L’analyse géographique est la force principale du SIG. Selon votre projet, il existe plusieurs
méthodes d’analyses différentes. Les outils de modélisation SIG rendent relativement facile de
faire des changements sur les données afin d’en créer une nouvelle.

1.3.4.5 Agir

Les résultats de votre analyse peuvent être partagés à l’aide de rapports, de cartes, de tableaux
et de graphiques afin de livrer en format imprimé ou en format numérique sur un réseau ou sur
le Web. Vous devez décider les meilleurs moyens de présenter votre analyse, et le SIG vous
permet d’adapter les résultats pour différents publics.

16
1.3.5 Types de données SIG

1.3.5.1 Données géographiques

Les couches d'information peuvent être présentées sous la forme de données géographiques qui
vont représenter la forme d'éléments se situant dans l'espace. On différencie ainsi les données
raster et les données vectorielles :

Figure 1.06: Les types de données géographiques dans un SIG

b. Données vectorielles

Dans ce type de données, le point avec ses coordonnées est le porteur de l'information
géométrique. Les lignes et les surfaces se comprennent comme une suite définie de points
caractéristiques. Les données vectorielles sont la plupart du temps le résultat de la numérisation
manuelle ou semi-automatique. De façon générale, dans les données vectorielles on distingue
les points, les lignes et les surfaces qui sont toujours représentés en couches différentes.

c. Données raster

Les données raster ont comme élément essentiel le pixel (picture element). Les données raster
proviennent soit d'une scannérisation (d'une carte), soit d'une image numérique telle que les
images satellites. Les pixels sont répartis dans un raster de façon régulière. Les lignes et les
surfaces ne peuvent être représentées que par l'enchaînement de pixel unique. Un objet ne peut
donc être représenté que de façon approximative; c'est ainsi que la taille du pixel-raster
conditionne l'exactitude de la représentation.

1.3.5.2 Données statistiques

L'une des différences importantes entre un logiciel de dessin assisté par l'ordinateur (DAO) et
un SIG réside dans la possibilité qu'offre ce dernier de relier l'ensemble des objets
17
géographiques placés sur une couche avec les données qualitatives et quantitatives telles que
des statistiques. L'avantage essentiel des données vectorielles est de pouvoir réaliser facilement
une association entre un objet géographique (zone, point ou ligne) et l'information qui permet
de le décrire. Dans les données raster, le pixel représente le véritable objet.

Figure 1.07: Relation entre les données géographiques et attributices dans un SIG

1.3.6 Acquisition des données

Comme l'acquisition de données ou la saisie de données géospatiales en format numérique est


la plus coûteuse et que les procédures prennent du temps. Dans le SIG, les sources de données
pour l'acquisition des données doivent être soigneusement sélectionnées en fonction de
l'application et de l'échelle.

Les sources de données suivantes sont largement utilisées :

• Cartes analogiques : Altitude, sol, climat, etc.


• Données du recensement et de l'enquête : Peut avoir un caractère spatial si chaque
élément a une référence spatiale, ce qui permet d'identifier son emplacement sur la
Terre, et habituellement en format tabulaire
• Photographies aériennes : Première méthode de télédétection, un «snapshot» de la
Terre à un instant particulier dans le temps
• Image satellite : Recueillis par des capteurs à bord d'un satellite, qui sont ensuite reliés
à des stations au sol puis traités par ordinateur pour produire des images
• Relevé au sol: Utilisation de bandes, transits, théodolites, stations total pour collecter
des données de terrain telles que coordonnées, élévations et distances
18
• Données GPS : Technique relativement nouvelle de collecte de données sur le terrain,
les ondes radio / signaux des satellites sont utilisé pour localiser l'emplacement
• Rapports et publications : Attributs, statistiques
1.3.7 Coordonnées et systèmes de projection

Les systèmes de coordonnées géographiques permettent de situer les objets à la surface de la


Terre tandis que les systèmes de projection permettent de les projeter sur une surface plane.

Pour intégrer la géométrie des objets dans la représentation du territoire, il est nécessaire de
connaître leurs coordonnées, ainsi que les transformations qu’elles subissent de la réalité au
modèle. C’est la raison pour laquelle on s’intéresse à la métrique de la description des éléments
du territoire ainsi qu’aux transformations pour passer d’un système de coordonnées à un autre,
en particulier, pour passer de l’espace géographique à la représentation cartographique.

a. Echelles d’observation et de représentation

L’échelle est le rapport entre la distance mesurée sur le modèle (la carte) et la distance réelle.
Elle dépend de l’objet de la représentation et des contraintes techniques, graphiques ou
physiologiques. Le choix de l’échelle repose sur la question du degré de généralisation souhaité,
lui-même dépendant du phénomène observé.

b. Coordonnées et positionnement

Un objet peut être localisé par la notion de voisinage. Par contre, cette notion est très abstraite
et l’on sent bien qu’elle manque d’une métrique clairement définie. Le système de coordonnées
euclidien possède un système d’axes perpendiculaires et une métrique constante. Il se fonde sur
l’hypothèse d’un espace plan et continu. Il est utilisé pour référencer les objets spatiaux. Pour
ce faire, il est nécessaire de projeter la surface sphérique de la terre sur un plan : il s’agit de
l’étape de projection.

c. Systèmes de projection

La géométrie de la terre est une sphère irrégulière appelée géoïde (Figure 1.08). Il s’agit de la
surface équipotentielle en gravité qui présente des variations locales (renflements et
dépressions) par rapport à un ellipsoïde de révolution.

19
Figure 1.08: Modèle du géoïde

La projection s’effectue en deux étapes : l’approximation du géoïde par un ellipsoïde de


révolution (global : WGS84 ou local : en Suisse, l’ellipsoïde de Bessel), puis la projection des
points de l’ellipsoïde de révolution sur le plan, comme l’illustre la Figure 1.09. Cette dernière
étape implique une perte d’information, car on passe d’un système de coordonnées sphérique à
trois coordonnées à un système de coordonnées euclidien à deux coordonnées. C’est la raison
pour laquelle il existe trois types de projection différents, chacune privilégiant une propriété au
détriment des autres.

• La projection conforme conserve les directions.


• La projection équivalente conserve les surfaces.
• La projection équidistante conserve les distances.

Figure 1.09: Etapes de la projection du géoïde à la carte


20
La projection peut être cylindrique, conique ou azimutale. Les erreurs de direction, de distance
et de surface sont négligeables sur un angle de 3° de part et d’autre du grand cercle de tangence
(Figure 1.10). Celles de la projection conique se situent autour du parallèle de tangence (Figure
1.11) et celles de la projection azimutale autour du point tangent (Figure 1.12).

Figure 1.10: Projection cylindrique conforme de Mercator

Figure 1.11: Projection conique conforme de Lambert

Figure 1.12: Projection azimutale stéréographique

21
1.3.8 Géoréférencement

On souhaite intégrer une image dépourvue de référence spatiale (carte scannée par exemple)
dans un SIG. Le géoréférencement est l’étape durant laquelle on lui reconstitue son système de
référence spatiale.

La procédure est divisée en deux étapes. La première consiste en la reconnaissance de points


identiques (dits points de contrôle) sur l’image et une carte de référence, comme illustré à la
Figure 1.13, et la seconde consiste en une série de transformations (de translation, d’échelle et
d’orientation) pour minimiser les écarts entre les points de contrôle de l’image et ceux de la
carte.

Figure 1.13: Points de contrôle sur l’image et sur la carte

Dans la première étape, il est nécessaire de trouver au moins trois points de contrôle, de
préférence facile à identifier et bien répartis sur l’ensemble de la zone, de manière à apporter
une transformation globale de l’image.

La deuxième étape repose sur trois types de transformation : translation, mise à l’échelle et
rotation. Elle est généralement basée sur la transformation de Helmert (transformation affine).
Il est également possible d’utiliser d’autres transformations (polynomiales, splines et
projection) qui sont plutôt utilisées lorsque l’image à projeter contient des déformations locales.
Le changement d’échelle et de l’orientation de l’image entraînent tous deux le besoin de
rééchantillonner l’image.

Pour cela, on crée une nouvelle grille raster pour laquelle il faut attribuer des valeurs aux
nouveaux pixels. Un moyen de le faire est d’attribuer la valeur du plus proche pixel voisin ou
encore une approche bilinéaire ou bicubique si les transformations sont trop importantes
22
1.3.9 Le Web Mapping

Un moyen très efficace de mettre des informations cartographiques à la disposition d’un groupe
de simple utilisateurs consiste à les mettre à disposition sur une page web. Il y a deux grands
types de Web Mapping : statique et interactif [18].

Les cartes statiques affichées en tant qu’image sur une page web sont assez coutantes. Si vous
avez déjà une carte numérique (par exemple, en scannant un document), vous pouvez être
opérationnel très rapidement avec une carte statique sur votre page web.

Les cartes interactives ne sont pas aussi courantes car elles requièrent des compétences
spécialisées pour maintenir ces sites opérationnels. Le terme interactif implique que les
utilisateurs peuvent en quelque sorte interagir avec la carte. Cela signifie qu’on peut
sélectionner différentes couches de données cartographiques pour voir ou zoomer sur une partie
particulière de la carte que vous intéresse. Tout cela est fait en interagissant avec la page web
et une image de la carte qui est mise à jour à plusieurs reprises.

La figure ci-dessous montre un schéma de base de façon dont un utilisateur final demande une
carte à travers le Web Mapping et ce qui se passe derrière la scène : Un utilisateur demande une
carte au serveur Web et celui-ci transmet la requête au serveur de web Mapping.

Figure 1.14: Interaction entre l’utilisateur et le serveur Web Mapping

1.4 Conclusion

Nous avons vu dans la première partie de ce chapitre, le MDC ou autrement dit la collecte de
données par mobile ; les données sont entrées dans un appareil mobile qui peut ensuite exporter
directement dans une base de données centralisée, de ce fait cette méthode offre de nombreux
avantages comparés aux méthodes traditionnelles. Dans la deuxième partie de ce chapitre, nous
avons expliqué ce qu’on entend par SIG, qui n’est autre qu’une représentation sur une carte des
données, afin de faciliter la prise de décision. Donc le MDC et le SIG sont deux méthodes
23
inséparables afin d’améliorer de façon spectaculaire la prise de décision parce que le MDC
assure la collecte de données qui n’est rien d’autre que l’une des 5 étapes du SIG et le SIG
proprement dit fait parvenir l’information à ceux qui en ont besoin.

24
CHAPITRE 2
CRYPTOGRAHIE

2.1 Introduction

Ce chapitre présente la cryptographie. Cette science a pour but de dissimuler la signification


des messages échangés entre deux entités. Les concepts et le vocabulaire de la cryptographie
seront étudié tout au long de ce chapitre.

2.2 La sécurité informatique

2.2.1 Les objectifs de la sécurité informatique

La sécurité informatique c’est l’ensemble des moyens mis en œuvre pour réduire la
vulnérabilité d’un système contre les menaces accidentelles ou intentionnelles. Il convient
d'identifier les exigences fondamentales en sécurité informatique [19] [20]. Elles caractérisent
ce à quoi s'attendent les utilisateurs de systèmes informatiques en regard de la sécurité :

• Confidentialité : demande que l'information sur le système ne puisse être lue que par
les personnes autorisées.
• Intégrité : demande que l'information sur le système ne puisse être modifiée que par
les personnes autorisées.

• Disponibilité : demande que l'information sur le système soit disponible aux personnes
autorisées.
En anglais, le terme CIA (Confidentiality, Integrity and Availability) en est le sigle.

2.2.2 Les moyens de la sécurité informatique

Pour assurer les objectifs de la sécurité informatique, plusieurs techniques sont utilisées [21]:

• La cryptographie : Cette science a pour objectif principal de cacher des informations,


notamment celles transitant sur les réseaux ou stockées dans des fichiers (comme les
mots de passe). La cryptographie est également utilisée dans la vérification de
l’intégrité des données ou dans l’authentification des individus ou des services.
• La sécurité physique : Par exemple, il faut enfermer ses serveurs à clé. C’est une mesure
primordiale de sécurité.
• Les systèmes d’authentification. Actuellement, la connaissance d’un mot de passe est
le moyen d’identification informatique le plus usuel. Les systèmes biométriques
(reconnaissance de l’iris, du lobe de l’oreille…) sont de plus en plus utilisés.

25
• Les droits : les droits associés aux fichiers limitent leur accès à telle personne ou tel
groupe d’individus. Ce système reste la base de sécurisation des ordinateurs sous
Unix/Linux
• Les sommes de contrôle. Elles vérifient l’intégrité des fichiers.
• Les pare-feu : Un pare-feu filtre les paquets réseaux. C’est un outil de protection
indispensable
• Les sauvegardes. Suite à une attaque, on peut perdre des données vitales. La sauvegarde
régulière des données est le seul recours.
• L’audit des principaux événements (connexion réussie, échouée…) du système. Il
garantit le suivi des règles de sécurité et détecte les tentatives d’intrusion.
2.3 La cryptographie

Le but principal de la cryptographie moderne est de résoudre des problèmes de sécurité associés
à la communication en réseau.

Les deux principaux problèmes sont :

• L’échange confidentiel d’informations


• L’authentification des participants
2.3.1 Les techniques de base de la cryptographie

La base de la cryptographie est constituée d’algorithmes de chiffrement, appelés également


méthodes cryptographiques. Ces algorithmes ont pour rôle de rendre incompréhensible un
message pour toute personne autre que son destinataire.

Les algorithmes de chiffrement sont de deux types :

• Symétriques, à clé secrète.


• Asymétrique, à clé publique
Pour résoudre les problèmes cryptographiques, les algorithmes de chiffrement ne suffisent pas.
On utilise d’autres techniques, les deux principales sont :

• Les générateurs d’empreintes


• Les générateurs de nombres aléatoires ou pseudo aléatoires.
2.3.2 Les algorithmes de chiffrement symétrique

Le principe d’utilisation d’une méthode de chiffrement symétrique est très simple : un message
en clair est chiffré (crypté) en utilisant une méthode cryptographique avant d’être transmis au

26
correspondant. Le chiffrement (cryptage) est réalisé par un logiciel ou par du matériel. Le
message crypté peut être intercepté par un tiers sans danger, il est incompréhensible. [22]

L’algorithme n’a pas besoin d’être secret. Toute la sécurité repose sur le maintien secret d’une
clé qui constitue l’élément variable dans le processus de chiffrement.

Un algorithme symétrique ou à clé secrète n’utilise qu’une seule clé qui ne doit être connue que
des correspondants. Elle sert aussi bien au chiffrement qu’au déchiffrement.

2.3.2.1 Le problème de l’échange des clés

Les algorithmes de chiffrement symétriques peuvent assurer la confidentialité des échanges. La


principale difficulté de leur utilisation réside dans le fait que les deux participants doivent
partager secrètement une même clé.

Une solution à ce problème est d’utiliser un algorithme de chiffrement asymétrique pour


échanger la clé secrète.

2.3.2.2 Panorama des méthodes

Les méthodes à clés privées se divisent en deux types :

• Les méthodes codant un flux de bits (Rc4 ou Arcfour…)


• Les méthodes de codage de blocs (AES, 3DES, Blowfish, IDEA, Cast5…)

27
a. Codage par flux

Un générateur pseudo aléatoire génère une suite de bits qui est combinée bit à bit avec le texte
clair pour former le cryptogramme. La même suite aléatoire doit être utilisée pour reconstituer
le texte clair. Comme on utilise l’opération XOR pour combiner les bits, les opérations de
chiffrement et déchiffrement sont identiques.

Figure 2.01: Méthode de flux

b. Codage par blocs

Les ordinateurs utilisent des registres ou des composants matériels pour réaliser le chiffrement.
Ce sont donc en fait des blocs de données qui sont en réalité chiffrés (ou déchiffrés) et les
méthodes à clés secrètes ont donc été majoritairement conçues en ce sens.

2.3.2.3 Les modes d’utilisation des méthodes blocs

Dans les méthodes de codage de blocs, le message est divisé en blocs uniformes de bits par
exemple 64 bits, le message crypté est constitué également de blocs de même taille. Il existe
plusieurs modes d’utilisation de méthodes blocs.

28
a. ECB

Dans la méthode ECB (Electronic Code Block), chaque bloc est toujours codé avec la même
clé. Par conséquent, deux blocs identiques seront codés de la même manière.

Figure 2.02: Mode ECB

Le défaut du mode ECB est que si un cryptanalyste obtient le texte en clair et le texte chiffré de
plusieurs messages, il peut commencer à construire un carnet de codage sans connaître la clé.
[22] Pourtant, si la taille du bloc est de 64 bits, le carnet de codage aura 264 entrées, ce qui est
assez grand pour être précalculé et stocké ; de plus, chaque clé a un carnet différent.

b. CBC

Dans la méthode CBC (Cipher Bloc Chaining) chaque bloc de texte clair est combiné par un
« ou exclusif » avec le bloc chiffré précèdent avant d’être chiffré. Pour le premier bloc, on
utilise un bloc dit vecteur d’initialisation ou IV (Initial Vector), choisi aléatoirement et qui est
inscrit en clair dans le message crypté. Cette méthode est sans doute la plus sûre d’un point de
vue cryptographique, mais une erreur de transmission interdit le déchiffrement du reste du
message. D’autre part, si le dernier bloc n’est pas complet, il faut le remplir (PADDING). En
outre, les opérations de chiffrement et de déchiffrement sont différentes

29
Figure 2.03: Mode CBC

c. CFB

Dans la méthode CFB (Cipher Feed Black), la clé change à chaque bloc. Elle permet un
cryptage identique aux méthodes à codage de flux de bits. Comme dans celui-ci, un octet du
texte chiffré est produit par un ou exclusif entre un octet de la clé et un octet du texte clair.
Chaque octet du texte chiffré sert également à générer le flux de la clé que ce soit lors du
chiffrement ou du déchiffrement.

Figure 2.04: Mode CFB


30
d. OFB

La méthode OFB (Output FeedBack) est similaire à la méthode CFB, mais le chiffrement et le
déchiffrement sont identiques : on n’utilise pas une méthode pour crypter et une autre pour
décrypter. Chaque fois qu’un octet du flux de la clé est généré, il est transmis dans le registre à
décalage qui sert à générer cette même clé. Le flux de texte chiffré est produit par un ou exclusif
entre le flux de la clé et le flux du texte clair. Lors du déchiffrement, c’est l’inverse : Le flux du
texte clair est produit par un ou exclusif entre le flux de clé et le flux de texte chiffré. Cette
méthode émule complétement une méthode par flux : le chiffrement et le déchiffrement sont
identiques.

Figure 2.05: Mode OFB

2.3.2.4 DES

Les DES pour Data Encryption Standard est un algorithme qui a été le standard de chiffrement
symétrique entre 1977 et 2001. Le DES est basé sur un schéma de Feistel. On pratique un
découpage des données en deux parties : gauche (L) et droite (R), on utilise la même fonction
de transformation f à chaque tour. Le DES utilise une clé K de 56 bits, pour chiffrer des blocs
de 64 bits, les blocs chiffrés obtenus ayant aussi 64 bits. Le bloc de texte clair subit d'abord une
permutation initiale. Puis on itère 16 fois une procédure identique décrite ciaprès, où la moitié
droite est recopiée telle qu'elle à gauche, et la moitié gauche est transmise à droite en subissant
au passage une modification dépendante de la clé. A la fin, on inverse les moitiés gauches et
droites (ou bien, comme sur le schéma, on supprime le croisement de la dernière étape), et on

31
applique l'inverse de la permutation initiale pour obtenir le bloc chiffré. Le schéma général de
DES est donc le suivant [23]:

Figure 2.06: DES : schémas général

Le tableau suivant montre la permutation initiale et son inverse

Tableau 2.01: La permutation initiale et son inverse

La permutation initiale et son inverse sont décrits par le tableau 2.01. Les tableaux se lisent de gauche à
droite et de haut en bas, le n-ième nombre est la position avant permutation du bit qui se trouve en n-
ième position après permutation.

32
Après la permutation initiale, le message est séparé en deux moitiés de 32 bits, désignées par
𝐿/ et 𝑅/ . A chaque itération de la procédure, on détermine deux groupes de 32 bits 𝐿% et 𝑅% en fonction
de 𝐿)01 et 𝑅)01 obtenues précédemment. Pour cela, on utilise une clé intermédiaire 𝐾, de 48 bits
calculées à partir de 𝐾 et on applique la formule suivante.

𝐿) = 𝑅)01 𝑒𝑡 𝑅) = 𝐿)01 ⊕ 𝑓(𝑅)01 , 𝐾) ) ( 2.01)


Il y a huit boites-S différentes. On les représente par deux tableaux à 4 lignes et 16 colonnes.
Les premiers et derniers bits de l'entrée déterminent une ligne du tableau, les autres bits
déterminent une colonne. La valeur numérique trouvée à cet endroit indique la valeur des quatre
bits de sortie.

Les 56 bits de sa clef devenant trop peu, une version nommée triple-DES a été conçue pour
augmenter la taille de clef en permettant l’utilisation de deux ou trois clefs indépendantes. Cette
version est encore utilisée aujourd’hui mais elle reste vulnérable.

2.3.2.5 AES

L’AES, pour Advanced Encryption Standard, est le remplaçant du DES depuis 2001 comme
standard de chiffrement symétrique. Il est basé sur l’algorithme RIJNDAEL (contraction du
nom des créateurs Vincent Rijmen et Joan Daemen) vainqueur du concours organisé par le
NIST pour désigner un successeur au DES.

Cet algorithme est basé sur un réseau de substitutions/permutations et a été conçu pour une
facilitée d’implémentation en logiciel ou en matériel. Il possède trois versions où il chiffre par
bloc de 128 bits à l’aide d’une clef de 128, 192 ou 256 bits – selon la version utilisée – qui
comporte respectivement 10, 12 et 14 tours.

Dans le processus de chiffrement un octet est considéré comme un élément du corps fini 𝐺𝐹 (2> )
et chaque bloc interne de 16 octets peut être représenté par une matrice carrée de 4 × 4 octets.
La transposition entre les représentations vectorielle et matricielle est faite en numérotant les
éléments colonne par colonne. Cette transposition est détaillée par la figure suivante.

Tableau 2.02: Transposition entre les visions vectorieel et la matricielle d’un état
intermédiaire d’AES 128
33
Nous décrivons ici le fonctionnement de la version 128 bits de l’AES. Soit un texte clair de 128
bits 𝑀 = (𝑚/ , 𝑚1 , … , 𝑚1C ) et une clef de chiffrement de 128 bits 𝐾 = (𝑘/ , 𝑘1 , … , 𝑘1C ) l’AES-
128 calcule un chiffré 𝐶 = (𝑐/ , 𝑐1 , … , 𝑐1C )par la méthode représentée par la Figure 2.08, en
débutant par une première opération XOR entre 𝑀 et 𝐾 puis en injectant le résultat, 𝑆/ , dans un
cycle de 10 tours. Pour 𝑟 = 1,2, … ,9 chaque tour d’AES-128 𝑟 calcule son état de sortie 𝑆J en
appliquant successivement quatre transformations : SubBytes, ShiftRows, MixColumns et
AddRoundKey à son état d’entrée 𝑆J01 . Le chiffré est finalement défini comme étant la sortie
du dixième et dernier tour qui a pour différence de ne pas comporter d’opération MixColumns.
Le processus de chiffrement est résumé

Figure 2.07: Processus de chiffrement de l’AES

Comme suit :

𝑆/ ← 𝑀 ⊕ 𝐾/ tel que (𝐾/ = 𝐾 ) ( 2.02)


𝑆J = 𝑀𝑖𝑥𝐶𝑜𝑙𝑢𝑚𝑛𝑠 R𝑆ℎ𝑖𝑓𝑡𝑅𝑜𝑤𝑠U𝑆𝑢𝑏𝐵𝑦𝑡𝑒𝑠(𝑆J01 )YZ ⨁ 𝐾J tel que 𝑟 = 1,2, … ,9 ( 2.03)
𝐶 ← 𝑆ℎ𝑖𝑓𝑡𝑅𝑜𝑤𝑠U𝑆𝑢𝑏𝐵𝑦𝑡𝑒𝑠(𝑆\ )Y⨁𝐾1/ ( 2.04)
2.3.2.6 BlowFish

Blowfish est un algorithme qui a été conçu par Bruce Schneider. C’est un algorithme de
chiffrement par blocs de 64 bits à longueur de clé variable. L’algorithme se fait en deux phases
: expansion de la clé et chiffrement des données. L’expansion de la clé convertit une clé de
taille inférieure à 448 bits en plusieurs tableaux de sous-clés d’une taille totale de 4168 octets.

Le chiffrement est obtenu en itérant 16 fois une fonction simple. Chaque ronde consiste en une
permutation dépendante de la clé et une substitution dépendante de la clé et des données. Toutes

34
les opérations sont des additions et des ou exclusif sur des nombres de 32 bits. La seule
opération supplémentaire est la consultation des quatre tableaux indexés par ronde.

Blowfish utilise un grand nombre de sous-clés. Ces sous-clés doivent être précalculées avant
tout chiffrement ou déchiffrement.

Le tableau-P est un tableau constitué de 18 sous-clés de 32 bits :

𝑃1 , 𝑃^ , … , 𝑃1>

Il y a 4 tables-S de 32 bits ayant 256 entrées chacune :

𝑆1,/ , 𝑆1,1 , … , 𝑆1,^CC

𝑆^,/ , 𝑆^,1 , … , 𝑆^,^CC

𝑆_,/ , 𝑆_,1 , … , 𝑆_,^CC

𝑆`,/ , 𝑆`,1 , … , 𝑆`,^CC

Blowfish est un réseau de Feistel constitué de 16 rondes. L’entrée est un élément de données x
de 64 bits. Pour chiffrer, procéder de la manière suivante :

Partager 𝑥 en deux moitiés de 32 bits : 𝐿 et 𝑅;

Pour 𝑖 variant de 1 à 16, effectuer

𝐿 ← 𝐿 ⊕ 𝑃)

𝑅 ← 𝑓(𝐿)⨁𝑅

Echanger 𝐿 et 𝑅

Echanger L et R (annuler le dernier échange)

𝑅 ← 𝑅 ⊕ 𝑃1a

𝐿 ← 𝐿 ⊕ 𝑃1>

Remettre 𝐿 et 𝑅 bout à bout

La fonction 𝑓 est la suivante

Diviser 𝐿 en quatre parts de 8 bits 𝑎, 𝑏, 𝑐, 𝑑

𝑓 (𝐿) = RU𝑆1,d , 𝑆^,e 𝑚𝑜𝑑2_^ Y⨁𝑆_,f Z + 𝑆`,h 𝑚𝑜𝑑2_^ ( 2.05)


Le déchiffrement s’effectue exactement de la même manière en inversant l’ordre des 𝑃) .

35
2.3.2.7 Le codage Base64

La méthode Base64 n’est pas une méthode cryptographique, en effet elle n’utilise pas de clé.
Son objectif est de transformer un message binaire en ASCII et inversement. Comme un
message chiffré est souvent constitué d’une suite de bits, il est souvent nécessaire de le coder
ensuite en utilisant Base64 pour qu’il puisse être manipulé comme un texte.

2.3.2.8 La taille des clés

Les algorithmes à clés secrètes utilisent des clés plus ou moins longues. Un pirate dispose d’une
méthode simple pour trouver le message en clair : c’est d’essayer toutes les clés possibles. Cette
méthode, appelée « l’attaque exhaustive », est d’autant plus efficace que les clés sont courtes.

On exprime la taille d’une clé (et donc le nombre de clé possibles) en puissance de 2. Par
exemple, une clé de 40 bits signifie qu’il existe 240 clés possibles. Les clés de taille 40 bits sont
particulièrement vulnérables.

Les experts considèrent qu’un algorithme à clé secrète doit utiliser des clés de plus de 100 bits
pour assurer une sécurité parfaite.

Chiffrement Longueur des clés


AES Utilise des clés de 128,192 ou 256 bits
Camelia Utilise des clés de 128,192 ou 256 bits
3DES Utilise des clés de 112 bits
DES Utilise des clés de 56 bits
RC4 Utilise des clés de 40 à 256 bits
Blowfish Utilise des clés de 32 à 448 bits
CAST5 Utilise des clés de 128 bits
IDEA Utilise des clés de 128 bits

Tableau 2.03: Longueur de clé secrète

2.3.2.9 Qualités d’un système de chiffrement symétrique

Il existe des centaines de systèmes de chiffrement symétrique, lequel (lesquels) choisir ? Voici
quelques critères :

• Il doit résister à une attaque exhaustive. Pour ce faire la taille des clés utilisées doit être
au moins de 128 bits.
• Il ne doit pas contenir de faille théorique qui permettrait de décrypter les messages sans
36
explorer toutes les clés. Seuls de mathématiciens peuvent réaliser ce type d’attaque. En
conséquence, la meilleure protection est la plus grande publicité. Ainsi, il ne faut utiliser
que les méthodes connues précitées
• Il doit être rapide
• Il doit être simple, Dans ce cas, il sera plus facile de détecter une faille théorique et il
sera également plus facile à optimiser le logiciel ou matériel.
2.3.3 Les algorithmes de chiffrement à clé publique

Un algorithme asymétrique, dit également à clé publique, utilise deux clés, une clé publique et
une clé privée. Ces deux clés sont générées ensemble par un logiciel et elles dépendent
mathématiquement l’une de l’autre. Comme son nom l’indique, la clé publique peut être publié
sans risque, mais la clé privée doit être conservée jalousement secrète par son propriétaire. Le
clé publique sert habituellement à crypter un message et la clé privée à le décrypter, mais
l’inverse est possible.

2.3.3.1 La méthode RSA

En 1978, l'algorithme à clé publique de Ron Rivest, A Shamir, Léonard Adleman apparaît. C'est
un système à clé publique car l'algorithme n'est pas caché, ni la clé de chiffrement. Son
fonctionnement est basé sur la difficulté de factoriser de grands entiers.

a. Fonctionnement

Pour chiffrer le message l'émetteur va utiliser la clé publique que le destinataire a préalablement
publiée. La clé publique est un ensemble de lettre et chiffre qui vont permettre à quiconque veut
lui envoyer des messages confidentiels. Cela veut dire que tout le monde peut connaître la clé
publique qui permet de crypté »'les messages uniquement au destinataire qui a publié la clé
mais seul ce dernier pourra déchiffrer ce qui a été codé avec sa clé publique grâce à sa clé
privée. [22]

b. Génération de clé

Choisir deux nombres entier premier p et q, de l'ordre de 100 chiffres au minimum, pour rendre
la factorisation hors de porter, même avec les meilleurs ordinateurs.

1) Calculer 𝑛 = 𝑝 ∗ 𝑞
2) Calculer 𝑚 = (𝑝 − 1)(𝑞 − 1)
3) Choisir un nombre entier 𝑒 tel que 𝑒 > 2 et 𝑝𝑔𝑐𝑑(𝑒, 𝑚) = 1
4) Calculer 𝑑 tel que 𝑑 ∗ 𝑒 ∗ 𝑚𝑜𝑑 𝑚 = 1
37
On prendra comme clé publique 𝑒 et 𝑛 et comme clé privée 𝑑 et 𝑚

c. Chiffrement

Connaissant la clé publique 𝑒 et 𝑛 et le message à chiffrer 𝑀. On peut la chiffrer de la manière


suivante :

Le message doit être remplacé par un chiffre. Ensuite on découpera le message par bloc de 𝑥
longueurs avec 𝑥 < 𝑛 . Le bloc B est chiffré par la formule

𝐶 = 𝐵n ∗ 𝑚𝑜𝑑(𝑛) (2.06)
c’est un bloc de message chiffré à envoyer vers le destinataire.

d. Déchiffrement

Pour le déchiffrement, on va pratiquer quasiment de la même façon que le chiffrement mais


avec la formule inverse

𝑏 = 𝐶 h ∗ 𝑚𝑜𝑑(𝑛) (2.07)
Ce qui permettra au destinataire de trouver le message clair.

2.3.3.2 Les avantages des méthodes à clé publiques

La cryptographie à clé publique offre plusieurs avantages :

• Elle diminue le nombre de clés nécessaires à la communication entre un nombre


important de personnes
• Elle permet la signature d’un document numérique
• Elle permet l’authentification mutuelle de deux correspondants
a. Diminution du nombre de clés

Si quatre personnes veulent communiquer avec des méthodes à clés secrètes, il faut six clés
secrètes pour couvrir toutes les combinaisons de dialogue secret. Il en faut seulement quatre
avec RSA. Avec les méthodes à clés secrètes, le nombre de clés devient exponentiel au fur et à
mesure que le nombre de personnes augmente.

b. L’authentification mutuelle

Bob veut envoyer un message à Alice, mais il désire que le message reste secret et que seule
Alice puisse la lire et qu’Alice soit sûre de son origine.

1. Bob chiffre son message avec sa clé secrète


2. Bob surchiffre le résultat avec la clé publique d’Alice
38
3. Bob transmet le message à Alice
4. Alice utilise sa clé privée pour dechiffrer le message
5. Alice utilise ensuite la clé publique de Bob pour déchiffrer le résultat précédent. Elle
obtient le message en clair qui ne peut provenir que de Bob et elle seule a pu le
déchiffrer.
2.3.3.3 Panorama des méthodes à clés publiques

• Diffie-Hellman
• RSA (Ronald Rivest, Adi Shamir et Leonard Adleman)
• DSA ou DSS (Digital Signature Algorithm ou Digital Signature Standard)
• Les méthodes elliptiques
2.3.3.4 L’attaque de l’homme du milieu

L’utilisation de méthodes asymétriques résout le problème de l’échange de clés symétriques,


mais il est sensible à une attaque subtile, l’attaque de l’homme du milieu.

1. Alice envoie à Bob sa clé publique. Pierre intercepte cette clé et envoie à Bob sa propre
clé publique
2. Bob envoie un message à Alice, chiffré avec la clé de Pierre. Pierre intercepte le
message, le déchiffre avec sa clé privée. Il le chiffre avec la clé publique d’Alice et
l’envoie à Alice

Figure 2.08: L’attaque de l’homme de milieu

Pour lutter contre ce type d’attaque, les correspondants doivent s’authentifier. L’utilisation du
certificats x509 est une solution à ce problème.

39
2.3.3.5 Les standards PKCS

La société RSA Data Security a publié des documents ayant pour objectif de normaliser
l’utilisation des techniques à clés publiques. Ces documents sont nommés PKCS ( Public Key
Cryptography Standards). Ils sont devenues des standards de facto.

Voici une brève description de ces documents.

PKCS#1 Décrit le chiffrement/déchiffrement RSA


PKCS#3 Décrit l’implémentation de l’algorithme Diffie-Hellman
PKCS#5 Décrit une méthode pour afficher les clés privées
PKCS#6 Extension de la norme X509 (rendue obsolète par la norme x509v3)
PKCS#7 Syntaxe récursive pour décrire des données chiffrés ou signées comme des
signatures électroniques, des certificats… PKCS#7 est compatible avec
PEM
PKCS#8 Décrit une syntaxe pour les clés privées
PKCS#10 Décrit une syntaxe pour des demandes de certificats
PKCS#11 API, appelée Cryptoki (Cryptographic Token API Standard), permettant
de réaliser des opérations cryptographiques avec du matérial (smartcard…)
PKCS#12 Décrit une syntaxe pour stocker dans un fichier des clés publiques
d’utilisateur, des clés privées protégées, des certificats

Tableau 2.04: Les standards PKCS

2.3.3.6 La taille des clés

Comme dans le cas des méthodes symétriques, plus la taille des clés est grande et meilleure est
la sécurité.

En revanche, la taille des clés à utiliser n’a pas de rapport avec une attaque exhaustive. La taille
minimale à utiliser dépend de l’algorithme considéré. Les experts considèrent par exemple, que
pour protéger des informations grâce à la méthode RSA, il faut utiliser des clés d’au moins 1024
bits. Des clés de 20148 bits assureront même une sécurité à plus long terme. La méthode RSA
est sensible à une attaque par factorisation de grand nombres. Si les mathématiques évoluent,
on peut imaginer même que ces clés n’offrent plus de sécurité.

40
2.3.3.7 La sécurité d’une méthode cryptograhique

La sécurité d’une méthode cryptographique ne repose pas entièrement sur la taille des clés. Une
méthode cryptographique peut être attaquée « mathématiquement ». C’est ainsi que la méthode
des sacs à dos, une des premières méthodes asymétriques a été « cassé ». Inversement, le DES
qui a subi l’assaut de milliers de mathématiciens résiste toujours. Par contre, le DES traditionnel
avec des clés de 56 bits a été abandonné pour faire place au TripleDES qui sert de clés de 56x2
ou 56x3 bits.

En cryptographie, on fera toujours plus confiance à un algorithme ou un protocole qui a été


publié qu’à une technique propriétaire conservée secrète. La publicité faite autour d’une
technique cryptographique assure qu’il n’y a pas de faille. Les découvrir devient en effet un
challenge de la communauté scientifique. Dans certains cas, ces challenges peuvent même
rapporter beaucoup d’argent.

2.3.4 La signature numérique

Les algorithmes à clés asymétriques offrent la possibilité d’effectuer des signatures


électroniques. On les appelle aussi signatures numérique.

Une signature numérique, comme une signature manuscrite, a pour objectif d’identifier l’auteur
d’un document et d’en prévenir toute falsification.

Son principe est comme suit :

Bob crée un document, et il calcule une empreinte à partir de ce document. Il utilise ensuite sa
clé privée pour chiffrer cette donnée. Il associe ensuite le résultat au document.

Chacun peut recalculer la somme de contrôle du document et vérifier avec la clé publique de
Bob que le document est authentique et que Bob en est l’auteur.

41
Figure 2.09: La signature numérique

2.3.5 Les protocoles cryptographiques

Les protocoles cryptographiques résolvent des problèmes de sécurité. Ils constituent la matière
la plus concrète de la cryptographie. En tant que protocoles, ils sont constitués de règles
d’échanges entre parties. Pour résoudre les problèmes de sécurité (confidentialité…), ils
utilisent des algorithmes cryptographiques (de chiffrement, de générateurs d’empreintes…)

Protocole Explication
Cram-MD5 Protocole d’authentification
PGP Protocole pour chiffrer et signer des emails
S/MIME Idem, mais basé sur une PKI x509
Kerberos Protocole assurant l’authentification et la confidentialité
SSH Idem
TLS Successeur de SSL assurant l’authentification, la confidentialité et
l’intégrité des données échangées
IPSEC Protocol VPN

Tableau 2.05: Les protocoles cryptographiques


42
2.3.6 Le protocole SSL/TLS

Le protocole cryptographique SSL (Secure Sockets Layers) a été créé par la société Netscape
pour prendre en charge des échanges sécurisés et authentifiés entre un navigateur web et un
serveur web. En fait SSL peut être utilisé pour toute application reposant sur TCP.

Après la version 2 du protocole, Microsoft créa PCT. Cette version 3 est la base du protocole
normalisé TLS (Transport Layer Security) de l’IETF.

SSL réalise les objectifs suivants :

• Authentification du serveur
• Authentification du client
• Confidentialités des échanges
• Contrôle de l’intégrité des échanges

Figure 2.10: Le protocole SSL

43
2.3.6.2 Le protocole SSLv3

Le protocole SSL v3, qui repose normalement sur TCP, est composé de deux sous-couches :

• Message (SSL message layer)


• Enregistrement (SSL records)
a. La sous-couche message

La sous-couche message est composé de plusieurs protocoles :

• Le protocole de prise de contact (Handshake)


• Le protocole alerte (Alert)
• Le protocole de changement de stratégie de cryptage (ChangeCipherSpec)
• Le protocole de transfert de données
b. La sous-couche enregistrement

La sous-couche enregistrement est la sous-couche de base : le client et le serveur échangent des


enregistrements d’une taille maximale de 16383 octets de données. Les enregistrements ne sont
pas liés au découpage de niveau supérieur (sous-couche message), et ainsi un enregistrement
peut correspondre à plusieurs messages et inversement. Chaque enregistrement contient les
informations suivantes :

• Le type de contenu
• La version du protocole
• La longueur
• Les données, cryptées et éventuellement compréssées
• Le MAC (Message Authentication Code)
Le MAC dépend d’un secret détenu par le client et le serveur, du numéro de l’enregistrement
et des données. Le MAC joue donc un rôle très important du point de vue de la sécurité, car il
authentifie l’enregistrement et est le garant de l’intégrité des données. Il évite aussi un certain
nombre de problèmes comme la réutilisation de message (Replay)

2.3.6.3 Le protocole de prise de contact (Handshake)

a. Principe

Les objectifs de la prise de contact (Handshake) entre le client et le serveur sont les suivants :

• Négocier la version du protocole SSL.


• Sélectionner les algorithmes de chiffrement
44
• Authentifier le serveur et/ou le client
• Echanger un secret qui permet de générer une clé de session pour ensuite poursuivre la
conversion de manière chiffrée
Pour s’authentifier, le serveur envoie au client un certificat x509. Le client l’examine, et vérifie
notamment.

1) Si le certificat possède une date valide


2) S’il possède le certificat du CA signataire du certificat du serveur (ou le certificat du CA
qui identifie le certificat du CA intermédiaire, fourni par le serveur, qui identifie le
certificat du serveur et ainsi de suite.
3) Si l’étape 2 aboutit, il peut vérifier la signataire du certificat
4) Via une requête reverse-DNS, il vérifie si l’adresse DNS du serveur correspond bien à
son adresse IP.
Si le client est un navigateur Web, il informe l’utilisateur des problèmes éventuels et lui
demande s’il doit continuer la session.

b. Le déroulement du protocole

Tout échange entre le client et le serveur commence avec ce protocole

1) Un client accède au site via une URL sécurisée, par exemple en Web : https://le-sit/le-
document
2) Le logiciel client envoie le message ClientHello. Il contient :
• La version de SSL la plus haute qu’il comprend
• Une valeur aléatoire
• La numéro de la session (SessionID)
• Son paramétrage de sécurité (méthodes cryptographiques prises en charge, taille
des clés supportées, méthodes de compression prises en charge…)
3) Le serveur répond en envoyant le message ServerHelllo. Ce message est comparable
au message ClientHello
4) Le serveur envoie ensuite son ou ses certificats x509
5) Le client envoie son certificat si le serveur lui en a demandé un
6) Le client envoie le message Échange de clés dont le contenu est différent en fonction de
l’algorithme à clés de publique.
7) Le client envoie le message Vérification du certificat si on lui a demandé un certificat
et que celui-ci ne permet que de réaliser des signatures
45
8) Le client et le serveur échangent des messages Changement de stratégie de cryptage.
Après cet échange, le reste du dialogue est chiffré
9) Le client et le serveur échangent des messages cryptés Prise de contact finie qui
permettent aux correspondants de vérifier s’ils sont synchronisés.
c. Le protocole de changement de stratégie de cryptage

Ce protocole, utilisé vers la fin du protocole de prise de contact, est utilisé pour changer de
stratégie de cryptage. Il peut intervenir à tout instant. Il correspond à une négociation entre le
client et le serveur d’un algorithme de cryptage et de la clé associée.

2.4 Conclusion

Nous avons commencé ce chapitre par un aperçu de la sécurité informatique, qui a pour but
d’assurer la confidentialité, l’intégrité et la disponibilité des données. Pour y arriver, il utilise
la cryptographie comme moyens. On a vu qu’il y a deux type de chiffrement à savoir : le
chiffrement à clé secrète et le chiffrement à clé publique.

46
CHAPITRE 3
LA PLATEFORME JEE ET LE WEB MAPPING

3.1 Introduction

Ce chapitre présentera, la plateforme JEE et le Web Mapping. La première partie de ce chapitre


décrira les applications d'entreprise et la manière dont elles sont conçues et développées et la
deuxième partie se concentrera aux composants de base de Web Mapping qui sont le Map
Server et le Data Server.

3.2 Plateforme Java EE

3.2.1 Généralités

La plateforme Java EE est conçue pour aider les développeurs à créer des applications réseau à
grande échelle, à plusieurs niveaux, évolutives, fiables et sécurisées. Un nom abrégé pour de
telles applications est « applications d’entreprise », car ces applications sont conçues pour
résoudre les problèmes rencontrés par les grandes entreprises. [24]

Les fonctionnalités qui rendent les applications d'entreprise puissantes, comme la sécurité et la
fiabilité, rendent souvent ces applications complexes. La plate-forme Java EE réduit la
complexité du développement des applications d'entreprise en fournissant un modèle de
développement, une API et un environnement d'exécution qui permettent aux développeurs de
se concentrer sur les fonctionnalités.

3.2.2 Définitions

Java EE n’est pas Java, car le terme « Java » fait bien évidemment référence à un langage, mais
également à une plate-forme : son nom complet est « Java SE » pour Java Standard Edition, et
était anciennement raccourci « J2SE ». Celle-ci est constituée de nombreuses bibliothèques, ou
API : citons par exemple java.lang, java.io, java.math, java.util, etc.

Le terme « Java EE » signifie Java Enterprise Edition, et était anciennement raccourci en « J2E
». Il fait quant à lui référence à une extension de la plate-forme standard. Autrement dit, la plate-
forme Java EE est construite sur le langage Java et la plate-forme Java SE, et elle y ajoute un
grand nombre de bibliothèques remplissant tout un tas de fonctionnalités que la plate-forme
standard ne remplit pas d'origine. L'objectif majeur de Java EE est de faciliter le développement
d'applications web robustes et distribuées, déployées et exécutées sur un serveur d'applications.

47
3.2.3 Application multi-tiers

Dans une application multi-tiers, la fonctionnalité de l'application est séparée en zones


fonctionnelles isolées, appelées composants. Généralement, les applications multi-tiers ont un
composant client, un composant intermédiaire et un composant de données (souvent appelé
niveau de système d'informations d'entreprise). Le composant client est constitué d'un
programme client qui envoie des demandes au composant intermédiaire. Le composant
intermédiaire est divisé en un composant Web et un composant métier, qui gère les demandes
des clients et traite les données d'application, en les stockant dans un magasin de données
permanent dans le composant de données.

Le développement d'applications Java EE se concentre sur le niveau intermédiaire pour rendre


la gestion des applications d'entreprise plus facile, plus robuste et plus sécurisée. [25]

Figure 3.01: Application n-tiers

3.2.4 Le composant client

Le composant client est constitué de clients d'application qui accèdent à un serveur Java EE et
qui sont généralement situés sur une machine différente du serveur. Les clients font des
demandes au serveur. Le serveur traite les demandes et renvoie une réponse au client. De
nombreux types d'applications peuvent être des clients Java EE, et ce ne sont pas toujours, ou
même souvent, des applications Java. Les clients peuvent être un navigateur Web, une
application autonome ou d'autres serveurs et ils s'exécutent sur une machine différente du
serveur Java EE.

Une application cliente s'exécute sur une machine cliente et fournit aux utilisateurs un moyen
de gérer des tâches telles que l'administration du système Java EE ou de l'application Java EE.
48
Il possède généralement une interface utilisateur graphique créée à partir d'API Swing ou AWT
(Abstract Window Toolkit), mais une interface de ligne de commande est certainement
possible.

Les application clientes accèdent directement aux beans s'exécutant dans le niveau métier.
Toutefois, si les exigences de l’application cliente le justifient, elle peut ouvrir une connexion
HTTP pour établir une communication avec une servlet s'exécutant dans le niveau Web.

3.2.4.1 Navigateur Web

Le navigateur Web de l'utilisateur télécharge des pages Web HTML (Hypertext Markup
Language), WML (Wireless Markup Language) ou XML (Extensible Markup Language)
statiques ou dynamiques à partir du niveau Web. Les pages Web dynamiques sont générées par
des servlets ou des pages JSP s'exécutant dans le niveau Web.

3.2.4.2 Applet

Une page Web téléchargée à partir du niveau Web peut inclure une applet intégrée. Une applet
est une petite application cliente écrite dans le langage de programmation Java qui s'exécute
dans la machine virtuelle Java installée dans le navigateur Web.

Les pages JSP sont l'API de référence pour créer un programme client basé sur le Web car
aucun plug-in ou fichier de stratégie de sécurité n'est requis sur les systèmes client. En outre,
les pages JSP permettent une conception d'application plus propre et plus modulaire car elles
permettent de séparer la programmation des applications de la conception des pages Web. Cela
signifie que le personnel impliqué dans la conception de pages Web n'a pas besoin de
comprendre la syntaxe du langage de programmation Java pour faire son travail.

3.2.4.3 Composants JavaBeans

Le niveau client peut également inclure un composant basé sur l'architecture du composant
JavaBeans (composant JavaBeans) pour gérer le flux de données entre un client ou une applet
d'application et des composants s'exécutant sur le serveur Java EE.

Les composants JavaBeans écrits pour la plate-forme Java EE ont des variables d'instance et
des méthodes GET et SET pour accéder aux données dans les variables d'instance. Les
composants JavaBeans utilisés de cette manière sont généralement simples en termes de
conception et d'implémentation, mais doivent être conformes aux conventions de dénomination
et de conception décrites dans l'architecture des composants JavaBeans.

49
3.2.4.4 Communications

La figure ci-dessous montre les différents éléments pouvant constituer le niveau client. Le client
communique directement avec le niveau métier s'exécutant sur le serveur Java EE ou, comme
dans le cas d'un client s'exécutant dans un navigateur, en passant par des pages JSP ou des
servlets s'exécutant dans le niveau Web.

Figure 3.02: Communication client

3.2.5 Le composant Web

Les composants Web Java EE peuvent être des pages JSP ou des servlets. Les servlets sont des
classes Java qui traitent dynamiquement les requêtes et construisent des réponses. Les pages
JSP sont des documents textuels qui contiennent du contenu statique et des extraits de code de
langage de programmation Java pour générer du contenu dynamique. Lorsqu'une page JSP est
chargée, une servlet d'arrière-plan exécute les fragments de code et renvoie une réponse.

Comme le niveau client et comme le montre la figure suivante, le niveau Web peut inclure un
objet JavaBeans pour gérer l'entrée utilisateur et envoyer cette entrée aux beans s'exécutant dans
le niveau métier pour traitement.

Figure 3.03: Communication du composant Web


50
Le tableau suivant liste d’autres composants Web qui gèrent l'interaction entre les clients et le
composant métier. Le tableau suivant montre quelques technologies dans le composant Web

Technologie Objectif
Servlets Classes Java qui traitent dynamiquement les requêtes et
construisent les réponses
JavaServer Faces Permet d'inclure des composants UI (tels que des champs et des
boutons) sur une page, de convertir et de valider les données
utilisateur.
Expression Language Un ensemble de balises standard utilisées dans les pages JSP

JavaServer Pages (JSP) Documents basés sur du texte qui sont compilés dans des
servlets et définissent comment le contenu dynamique peut être
ajouté aux pages statiques, telles que les pages HTML.
JavaServer Pages Standard Une bibliothèque de balises qui encapsule les fonctionnalités
Tag Library de base aux pages JSP

Tableau 3.01: Les technologies dans le composant Web

3.2.6 Le composant Métier

Le composant métier comprend des composants qui fournissent la logique métier d'une
application. La logique métier est un code qui fournit des fonctionnalités à un domaine métier
particulier, tel que le secteur financier ou un site de commerce électronique. Dans une
application d'entreprise correctement conçue, la fonctionnalité de base existe dans les
composants de niveau métier.

Les technologies Java EE suivantes sont parmi celles qui sont utilisées dans le niveau métier
dans les applications Java EE :

• Enterprise JavaBeans
• JAX-RS RESTful web services
• Java Persistence API
La figure suivante montre comment les bean reçoivent les données de programmes client, les
traite (si nécessaire) et les envoie au niveau du système d'informations d'entreprise pour le

51
stockage. Un enterprise bean récupère également les données du stockage, les traite (si
nécessaire) et les renvoie au programme client.

Figure 3.04: Communication du composant métier

3.2.7 Le composant EIS

Le composant EIS (Enterprise Information System) traite les programmes EIS et renferme les
infrastructures systèmes de l'entreprise comme les processus de transaction des mainframes, les
systèmes de base de données et d'autres systèmes d'information hérités. Par exemple, une
application Java EE peut avoir besoin d'accéder au système d'information de l'entreprise pour
une connexion à la base de données.

Les technologies Java EE suivantes sont utilisées pour accéder au niveau EIS dans les
applications Java EE :

• Le Java Database Connectivity API (JDBC)


• Le Java Persistence API
• Le Java EE Connector Architecture
• Le Java Transaction API (JTA)

3.2.8 Architecture du Java EE

Normalement, les applications multi-tiers sont difficiles à écrire car elles impliquent de
nombreuses lignes de code complexe pour gérer la gestion des transactions et des états, le
multithreading, le pool de ressources et d'autres détails complexes de bas niveau. L'architecture
Java EE indépendante des composants et des plates-formes facilite l'écriture des applications
Java EE car la logique métier est organisée en composants réutilisables et le serveur Java EE
fournit des services sous-jacents sous la forme d'un conteneur pour chaque type de composant.
52
Parce que vous n'avez pas besoin de développer vous-même ces services, vous êtes libre de
vous concentrer sur la résolution du problème.

3.2.8.1 Conteneurs et services

Les conteneurs sont les interfaces entre un composant et les fonctionnalités spécifiques de bas
niveau de la plate-forme que supporte le composant. Avant qu'un composant web, ou un
composant enterprise bean, ou un composant d'application client s'exécute, ils doivent être
assemblés dans un module Java EE et déployés dans leur propre conteneur. Le processus
d'assemblage implique des paramètres spécifiques des conteneurs dans l'application Java EE et
pour l'application Java EE lui-même. Les paramètres du conteneur personnalisent les supports
sous-jacents fournis par le serveur Java EE incluant les services comme :

• La sécurité : le modèle de sécurité Java EE permet de configurer un composant web ou


une enterprise bean, de ce fait les utilisateurs autorisés sont les seuls à avoir accès aux
ressources systèmes.
• La gestion des transactions : le modèle de transaction Java EE permet de spécifier les
relations entre les méthodes qui composent une simple transaction afin que toutes les
méthodes dans une transaction soient traitées comme une seule unité.
• Le service JNDI (Java Naming Directory Interface) fournit une interface unifiée à
plusieurs services de nommage et d'annuaire dans l'entreprise afin que les composants
d'application puissent accéder aux services de nommage et d'annuaire.
• Le modèle de connectivité à distance Java EE gère les communications de bas niveau
entre les clients et les beans d'entreprise. Une fois qu'un bean d'entreprise est créé, un
client appelle des méthodes sur ce dernier comme s'il se trouvait dans la même machine
virtuelle.
Le fait que l'architecture Java EE fournisse des services configurables signifie que les
composants d'application au sein de la même application Java EE peuvent se comporter
différemment en fonction de l'endroit où ils sont déployés. Par exemple, un enterprise bean peut
avoir des paramètres de sécurité lui permettant un certain niveau d'accès aux données de base
de données dans un environnement de production et un autre niveau d'accès à la base de données
dans un autre environnement de production.

Le conteneur gère également les services non configurables tels que les cycles de vie du bean
enterprise et des servlets, le regroupement des ressources de connexion à la base de données, la
persistance des données et l'accès aux API de plate-forme Java EE décrites dans les API Java
53
EE. Bien que la persistance des données soit un service non configurable, l'architecture Java
EE vous permet de remplacer la persistance gérée par le conteneur en incluant le code approprié
dans votre implémentation de bean enterprise lorsque vous souhaitez plus de contrôle que la
persistance gérée par le conteneur.

3.2.8.2 Types de conteneurs

Le processus de déploiement installe les composants d'application Java EE dans les types de
conteneurs Java EE illustrés par la figure suivante.

Figure 3.05: Les conteneurs

• Un conteneur EJB (Enterprise JavaBeans) gère l'exécution de tous les beans d'entreprise
pour une application Java EE. Les beans Enterprise et leur conteneur s'exécutent sur le
serveur Java EE.
• Un conteneur Web gère l'exécution de tous les composants de page et de servlet JSP
pour une application Java EE. Les composants Web et leur conteneur s'exécutent sur le
serveur Java EE.
• Un conteneur d’application cliente gère l'exécution de tous les composants client
d'application pour une application Java EE. Les clients d'application et leur conteneur
s'exécutent sur l'ordinateur client.
• Un conteneur d'applet est le navigateur Web et la combinaison Java Plug-in s'exécutant
sur l'ordinateur client.

54
3.3 Le Web Mapping

3.3.1 Architecture

L’architecture d’un Web Mapping suit le model client-serveur, avec les navigateurs web en tant
que clients et le site web servant l’application en tant que serveur. La figure 3.06 montre les
composants de base d’un Web Mapping [26].

Figure 3.06: Architecture générale du Web Mapping

Dans le cadre de ce projet, on a utilisé Geoserver comme serveur Map et PostGis comme
Serveur de données, nous allons entrer dans les détails de chaque composant tout au long de ce
document. D’où la nouvelle architecture :

55
INTERFACE UTILISATEUR

SERVEUR D’APPLICATION

GeoServer

BASE DE DONNES

PostGIS

Figure 3.07: Architecture du Web Mapping utilisé

3.3.2 PostGIS

PostGIS est une base de données spatiale. Plus précisément, PostGIS est une extension qui
transforme le système de base de données PostgreSQL en une base de données spatiale.
[27]PostGIS est très similaire en termes de fonctionnalité à la prise en charge spatiale dans
Microsoft SQL Server, Oracle Spatial et DB2 Spatial Extender. PostGIS est un composant
fondamental dans notre architecture, offrant un accès optimisé à de grandes quantités de
données spatiales [28].

56
3.3.3 PostgreSQL

PostgreSQL est un puissant système de gestion de base de données objet-relationnel


(ORDBMS). Il est publié sous une licence de style BSD et est donc un logiciel libre et open
source. Comme beaucoup d'autres programmes open source, PostgreSQL n'est pas contrôlé par
une seule entreprise, mais dispose d'une communauté mondiale de développeurs et d'entreprises
pour le développer. [29]

PostgreSQL a été conçu dès le départ avec l'extension de type en tête: la possibilité d'ajouter de
nouveaux types de données, de nouvelles fonctions et de nouvelles méthodes d'accès au
moment de l'exécution. Pour cette raison, l'extension PostGIS peut être développée par une
équipe de développement distincte, tout en s'intégrant très étroitement dans la base de données
PostgreSQL.

3.3.4 Pourquoi PostgreSQL ?

PostgreSQL dispose les caractéristiques suivantes :

• Fiabilité éprouvée et intégrité transactionnelle par défaut (ACID)


• Prises-en charge des normes SQL (SQL92 complet)
• Extension de fonction
• Modèle de développement orienté vers la communauté
• Pas de limite sur les tailles de colonnes pour supporter les gros objets SIG
• Structure d'index générique (GiST) pour autoriser l'index R-Tree
• Facile à ajouter des fonctions personnalisées
Combiné avec PostGIS, PostgreSQL fournit un moyen très facile pour ajouter de nouveaux
types spatiaux.

Une question fréquemment posée par des personnes qui connaissent bien les bases de données
open source est : «Pourquoi PostGIS ne s'est-il pas integré sur MySQL? ». Souvent, lorsque les
administrateurs parlent d'utiliser MySQL pour des données spatiales, ils ont simplement des
tables de base de données avec des colonnes x / y. Mais on ne tire aucun avantage de la nature
spatiale des données, et cela ne s'adapte pas aux géométries dimensionnelles supérieures comme
les lignes et les polygones. En tant que tels, ce ne sont pas de vraies implémentations spatiales.

57
3.3.5 Pourquoi ne pas simplement utiliser Shapefiles?

Le fichier de formes ou shapefile (et d'autres formats de fichiers) est la manière standard de
stocker et d'interagir avec les données spatiales depuis plus de 20 ans. Cependant, ces fichiers
présentent les inconvénients suivants :

• Les fichiers nécessitent un logiciel spécial pour lire et écrire : SQL est une abstraction
pour l'accès et l'analyse de données aléatoires. Sans cette abstraction, vous devrez écrire
tout le code d'accès et d'analyse vous-même.
• L’accès concurrent peuvent provoquer une corruption : Bien qu'il soit possible d'écrire
du code supplémentaire pour garantir que plusieurs écritures dans le même fichier ne
corrompent pas les données, au moment où vous avez résolu le problème et résolu le
problème de performances associé, vous aurez écrit la meilleure partie d'un système de
base de données. Pourquoi ne pas simplement utiliser une base de données standard ?
• Les questions complexes nécessitent un logiciel compliqué pour répondre : Les
questions compliquées et intéressantes (jointures spatiales, agrégations, etc.) qui sont
exprimables dans une ligne de SQL dans la base de données prennent des centaines de
lignes de code spécialisé pour répondre lors de la programmation de fichiers. La plupart
des utilisateurs de PostGIS sont en train de configurer des systèmes sur lesquels
plusieurs applications doivent pouvoir accéder aux données. Une méthode d'accès SQL
standard simplifie donc le déploiement et le développement. Certains utilisateurs
travaillent avec de grands ensembles de données ; Avec les fichiers, ils peuvent être
segmentés en plusieurs fichiers, mais dans une base de données, ils peuvent être stockés
dans une seule grande table.
En somme, la combinaison de la prise en charge de plusieurs utilisateurs, de requêtes complexes
et de performances sur de grands ensembles de données est ce qui distingue les bases de données
spatiales des systèmes basés sur des fichiers.

58
3.3.6 Les bases de données spatiales

3.3.6.1 Définition

Les bases de données spatiales stockent et manipulent des objets spatiaux comme n'importe
quel autre objet de la base de données. Trois facteurs supplémentaires permettent aux objets
géographiques d'exister nativement dans une base de données :

• Types de données spatiales, pour stocker des formes comme des points, des lignes et
des polygones dans des colonnes de géométrie
• Fonctions spatiales, posées en SQL (Structured Query Language) pour interroger les
propriétés spatiales et les relations
• Les index spatiaux, utilisés pour le traitement efficace des opérations spatiales
3.3.6.2 Types de données spatiales

Les types de données spatiales stockent des formes telles que des points, des lignes et des
polygones dans des colonnes de géométrie. Ils peuvent être compris simplement comme une
représentation binaire d'une forme dans une ligne de base de données (avec l'emplacement).

Figure 3.08: Types de données spatiales

59
Les types de données spatiales sont organisés dans une hiérarchie de types. Chaque sous-type
hérite de la structure (propriétés) et du comportement (méthodes ou fonctions) de son super-
type.

Figure 3.09: Hiérarchie des géométries

3.3.6.3 Les fonctions spatiales

Les fonctions spatiales, dans SQL, permettent d'interroger les propriétés spatiales et les
relations. Les fonctions spatiales, posées en SQL, permettent d'interroger les propriétés
spatiales et les relations.

Pour manipuler des données pendant une requête, une base de données ordinaire fournit des
fonctions pour des opérations telles que (mais sans s'y limiter):

• Fonctionnant mathématiquement sur les nombres


• Extraire des informations des dates
• Travailler avec des chaînes
En plus de ces fonctions de "type de base", une base de données spatiale fournit des fonctions
pour fonctionner sur des géométries. Les fonctions spatiales sont généralement classées par
catégorie d’opération :

• La gestion
Lire les informations de version actuelles (PostGIS_Version)

• Conversion
Afficher la représentation textuelle d’un point (ST_AsText)

Convertir une chaîne de texte en une géométrie PostGIS valide (ST_GeomFromText)

60
• Récupération
Affiche la longueur d’une ligne (ST_Length)

Donne le périmètre d’un polygone (ST_Perimeter)

• Comparaison
Donne si un polygone est proche d’un autre (ST_Touches)

Donne si un polygone est dans un autre polygone (ST_Contains)

• Génération
Consolider deux polygones (ST_Union)

3.3.7 GeoServer

GeoServer est logiciel open source écrit en Java qui permet aux utilisateurs de partager et
d'éditer des données géospatiales. Conçu pour l'interopérabilité, GeoServer publie des données
à partir de n'importe quelle source de données spatiales majeure en utilisant des standards
ouverts [30] [31].

Nous verrons les concepts serveur/service plus en détail. Pour l'instant, pensez à GeoServer
comme une passerelle vers des collections de données géospatiales. GeoServer permet
d’accéder à ces de manière identique.

3.3.7.1 Les bases du serveur

a. Serveur Web

Un serveur Web est un programme qui sert du contenu (pages Web, images, fichiers, données,
etc.) en utilisant HTTP (Hypertext Transfer Protocol). Lorsque vous utilisez votre navigateur
pour vous connecter à un site Web, vous contactez un serveur Web.

61
Le serveur Web prend la requête, l'interprète et renvoie une réponse, que le navigateur affiche
à l'écran.

Figure 3.10: Cycle de vie de la requête du serveur Web

Par exemple, lorsque vous demandez une page Web, votre requête prend la forme d'une URL:

http://example.com/some/path/page.html

Le serveur Web regarde son système de fichiers, et si cette requête pointe vers un fichier valide
(si page.html existe dans certains / path), le contenu de ce fichier sera renvoyé via HTTP.
Habituellement, ces appels proviennent d'un navigateur, auquel cas le résultat est rendu dans le
navigateur.

Il est possible de demander plusieurs types de fichiers via HTTP, pas seulement des pages
HTML:

http://example.com/some/path/image.jpg
http://example.com/some/path/archive.zip
http://example.com/some/path/data.xml

Si votre navigateur est configuré pour afficher le type de fichier, il sera affiché, sinon vous serez
généralement invité à télécharger le fichier sur votre système hôte.

Les serveurs Web les plus populaires utilisés aujourd'hui sont : Apache HTTP Server and
Internet Information Services (IIS).

b. Serveur Web Mapping

Un serveur Web Mapping est un sous-ensemble spécialisé du modèle de serveur Web. Comme
un serveur web, les requêtes sont envoyées au serveur, elles sont interprétées et répondues.

62
Les principales différences entre un serveur de Web Mapping et un serveur Web standard sont
les suivantes : [31] [32]

• Les réponses ne sont pas des documents ou des fichiers (.HTML, .ZIP, .MP3, etc.), mais
des données géographiques.
• La requête est un peu plus spécifique que http: //server/file.extension
Parce qu'il ne serait pas utile de simplement dire «Donnez-moi toute la géographie», nous
utilisons des protocoles spécifiques et structurés pour demander des portions distinctes de la
géographie du serveur Web Mapping.

Les protocoles pouvant être utilisés pour effectuer des demandes de données géographiques
incluent : Web Map Service (WMS) et Web Feature Service (WFS).

Figure 3.11: Serveur Web Mapping

Voici quelques serveurs Web Mapping populaires:

• GeoServer
• MapServer
• Mapnik
• ArcGisServer
3.3.7.2 GeoServer en tant que serveur Map

GeoServer est une implémentation spécifique d'un serveur Web Mapping, offrant un accès aux
données dans un ensemble connu de formats et de sources (fichiers et bases de données)
utilisant des protocoles spécifiques.

D'une certaine manière, GeoServer agit comme une couche d'abstraction. Il permet d'accéder
aux données géospatiales à l'aide de normes, quel que soit le type de données source.

63
a. Les sources de données

GeoServer peut lire de nombreuses sources de données différentes, des fichiers sur le disque
local aux bases de données externes.

Voici une liste des formats de données les plus courants pris en charge par GeoServer. Cette
liste n'est en aucun cas exhaustive.

• Fichier
o Shapefile
o GeoTIFF
o ArcGrid
o JPEG2000
o Formats GDAL
• Base de données
o PostGIS
o ArcSDE
o Oracle Spatial
o DB2
o SQL server
b. Les protocoles OGC

GeoServer implémente des protocoles web standard ouverts établis par l'Open Geospatial
Consortium (OGC), une organisation de normalisation.

GeoServer contient un WMS (Web Map Service) et est en fait l'implémentation de référence
des standards OGC WFS (Web Feature Service) et WCS (Web Coverage Service).

3.3.7.3 Web Map Service (WMS)

Une composante fondamentale de la Web Map (et probablement la plus simple à comprendre)
est l'image de la carte. Le WMS est un protocole standard pour la diffusion d'images
cartographiques géoréférencées générées par un serveur Map.

En bref, WMS est un moyen pour un client de demander des images de carte à partir d'un
serveur. Le client envoie une requête à un serveur Map, puis le serveur Map génère une image
basée sur les paramètres transmis au serveur dans la requête et renvoie finalement une image.

64
La source de données à partir duquel l'image est générée n'a pas besoin d'être une image. Le
WMS génère une image à partir de n'importe quelle source de donnée demandé, qui peut être
des données vectorielles, des données raster ou une combinaison des deux.

Figure 3.12: Principe de WMS

Un diagramme montrant comment un WMS transforme des données en une image de carte

Voici un exemple de requête WMS, rendue sous la forme d'une requête HTTP GET (avec des
sauts de ligne ajoutés pour plus de clarté) à une instance GeoServer :

http://suite.opengeo.org/geoserver/wms?
SERVICE=WMS&
VERSION=1.3.0&
REQUEST=GetMap&
LAYERS=usa:states&
SRS=EPSG:4326&
BBOX=24.956,-124.731,49.372,-66.97&
FORMAT=image/png&
WIDTH=600&
HEIGHT=255

Une analyse rapide de cette requête montre que les informations suivantes sont demandées:

• Détails du serveur (une requête WMS 1.3.0)


• Type de requête (une demande WMS GetMap)
• Nom de la couche (usa:states)
• Projection (EPSG: 4326)
65
• Bounding box (dans ce cas, coordonnées latitude / longitude)
• Propriétés de l'image (600 x 255 PNG)
Pour plus d'informations, consultez le site OGC sur le protocole Web Map Service à l'adresse :
http://www.opengeospatial.org/standards/wms.

3.3.7.4 Web Feature Service (WFS)

Un serveur Web Mapping peut également renvoyer les données géographiques réelles qui
constituent les images de la carte. Cela permet aux utilisateurs de créer leurs propres cartes et
applications à partir des données, de convertir des données entre certains formats, et d'effectuer
des manipulations géographiques brutes des données traitées. Le protocole utilisé pour renvoyer
les données d'entités géographiques est appelé WFS. [33]

Figure 3.13: Principe de WFS

Voici un exemple de requête WFS, rendue sous la forme d'une requête HTTP GET (avec des
sauts de ligne ajoutés pour plus de clarté) à une instance GeoServer :

http://suite.opengeo.org/geoserver/wfs?
SERVICE=wfs&
VERSION=1.1.0&
REQUEST=GetFeature&
TYPENAME=usa:states&
FEATUREID=states.39

Une analyse rapide de cette requête montre que les informations suivantes sont demandées:

• Détails du serveur (demande WFS 1.1.0)


• Type de requête (GetFeature)
• Nom de la couche (usa:states)
66
• ID de l'entité (states.39)
Cette requête particulière interroge le WFS pour une seule entité dans une couche spécifique.

En collant la requête dans un navigateur la réponse contient les coordonnées de chaque sommet
de l'entité en question, ainsi que les attributs associés à cette entité.

Figure 3.14: XML généré par une requête WFS

Bien que XML soit difficile à lire, il est facile pour les ordinateurs d'analyser, ce qui rend les
réponses WFS idéales pour les logiciels. GeoServer propose également d'autres formats de
sortie, tels que JSON, CSV et fichier de formes zippé.

3.3.7.5 Autres protocoles

Il est important de noter que GeoServer offre un support limité pour d'autres protocoles en plus
de WMS et WFS.

a. Web Coverage Service (WCS)

Le WCS est un service qui permet d'accéder aux données raster sous-jacentes (ou «
couverture»). Dans un sens, WCS est l'analogue raster de WFS, où vous pouvez accéder aux
données raster stockées sur un serveur. GeoServer contient un support complet pour les versions
WCS jusqu'à 1.1.1.

Pour plus d'informations sur WCS, veuillez consulter le site OGC sur le protocole Web
Coverage Service à l'adresse http://www.opengeospatial.org/standards/wcs.

67
b. Web Processing Service (WPS)

Le WPS est un service de publication de processus, d'algorithmes et de calculs géospatiaux.

WPS étend le serveur Web Mapping pour fournir une analyse géospatiale. WPS dans GeoServer
permet une intégration directe avec d'autres services GeoServer et le catalogue de données. Cela
signifie qu'il est possible de créer des processus basés sur les données servies dans GeoServer,
y compris les résultats d'un processus à stocker en tant que nouvelle couche. De cette façon,
WPS agit comme un outil d'analyse géospatiale basé sur un navigateur complet, capable de lire
et d'écrire des données depuis et vers GeoServer.

3.3.8 Leaflet

Leaflet est une bibliothèque JavaScript libre de Web Mapping développée par Vladimir
Agafonkin de CloudMade et de nombreux contributeurs. Elle est notamment utilisée par le
projet de cartographie libre et ouverte OpenStreetMap.

Cette section vous donnera un aperçu complet de Leaflet en tant que solution de Web
Mapping. Les modules suivants seront couverts dans cette section :

• Notions de base : Apprenez à ajouter une carte à une page Web avec Leaflet.
• Couches et sources : En savoir plus sur les couches raster et vectorielles
• Contrôles et interactions : En savoir plus sur l'utilisation des contrôles de carte
3.3.8.1 Création d’une carte

Dans Leaflet, une carte est une collection de couches et de diverses interactions et contrôles
pour gérer l'interaction de l'utilisateur. Une carte est générée avec trois ingrédients de base : le
balisage, les déclarations de style et le code d'initialisation.

a. Balisage de la carte

<div id='map'></div>
Cet élément <div> servira de conteneur pour la fenêtre d'affichage de la carte. Ici, l’élément
<div>, mais le conteneur de la fenêtre peut être n'importe quel élément au niveau du bloc.

Dans ce cas, on peut donner au conteneur un attribut id afin de permettre le référencement


comme cible de la carte.

b. Style de la carte

Leaflet est livré avec une feuille de style par défaut qui spécifie comment les éléments sont liés
à la carte doivent être stylés. Il ne fait aucune supposition sur la taille de la carte. Pour cette

68
raison, en suivant la feuille de style par défaut, De ce fait, il est impératif d’inclure au moins
une déclaration de style personnalisée pour donner de la place à la carte sur la page.

<link rel="stylesheet" href="libs/leaflet.css"/>


<style>
#map {
width: 100%;
height: 100%;
}
</style>
Dans ce cas, la valeur d'identifiant du conteneur de carte comme sélecteur, et la largeur
(100%) et la hauteur (100%) pour le conteneur de carte. Les déclarations de style sont directement
incluses dans la <head> de du document HTML. Dans la plupart des cas, les déclarations de
style liées à une carte feront partie d'un thème de site Web plus important lié à des feuilles de
style externes.

c. Initialisation de la carte

L’initialisation d’une carte dans Leaflet se fait en définissant ses coordonnées géographiques et
le niveau de zoom comme l’indique le code suivant.

var mymap = L.map('mapid').setView([51.505, -0.09], 13);

Ensuite, il est indispensable d’ajouter une couche de tuiles, dans ce cas, il s'agit d'une couche
de tuiles « Mapbox Streets ». La création d'une couche de mosaïque implique généralement la
définition du modèle d'URL pour les images de mosaïques, le texte d'attribution et le niveau de
zoom maximal de la couche. Dans cet exemple, nous utiliserons les carreaux mapbox.streets
des «Cartes classiques» de Mapbox (pour utiliser des carreaux de Mapbox, vous devez
également demander un jeton d'accès).

L.tileLayer('https://api.tiles.mapbox.com/v4/{id}/{z}/{x}/{y}.png?access_
token={accessToken}', {
attribution: 'Map data &copy; <a
href="http://openstreetmap.org">OpenStreetMap</a> contributors, <a
href="http://creativecommons.org/licenses/by-sa/2.0/">CC-BY-SA</a>,
Imagery © <a href="http://mapbox.com">Mapbox</a>',
maxZoom: 18,
id: 'mapbox.streets',
accessToken: 'your.mapbox.access.token'
}).addTo(mymap);

3.3.8.2 Couches et sources

Lorsque vous ajoutez une couche à une carte, la source de la couche est généralement
responsable de l'extraction des données à afficher. Les données demandées peuvent être des

69
données raster ou vectorielles. Vous pouvez considérer les données raster comme des
informations affichées sous la forme d'une image côté serveur. Les données vectorielles sont
fournies sous la forme d'informations structurées à partir du serveur et peuvent être affichées
pour être affichées sur le client (votre navigateur).

3.3.8.3 Couches WMS

Lorsque quelqu'un publie un service WMS, il lie probablement un document appelé


GetCapabilities. Dans cet exemple, nous utiliserons les services de carte de démonstration de
GeoServer à l'adresse https://demo.boundlessgeo.com/geoserver/web/. Comme vous pouvez le
voir sur cette page, "WMS" renvoie vers l'URL suivante:

https://demo.boundlessgeo.com/geoserver/ows?service=wms&version=1.3.0&req
uest=GetCapabilities
Leaflet ne comprend pas les documents WMS GetCapabilities. Au lieu de cela, vous devez
créer une couche L.TileLayer.WMS, fournir l'URL WMS de base et spécifier les options WMS
dont vous avez besoin.

L'URL WMS de base est simplement l'URL GetCapabilities, sans aucun paramètre, comme
ceci:

https://demo.boundlessgeo.com/geoserver/ows?

Et la façon d'utiliser cela dans une carte Leaflet est simplement:

var map = L.map(mapDiv, mapOptions);

var wmsLayer =
L.tileLayer.wms('https://demo.boundlessgeo.com/geoserver/ows?',
wmsOptions).addTo(map);

Nous pouvons voir que la démo WMS d'OpenGeo a une couche WMS nommée ne: ne avec un
fond de carte. Voyons voir à quoi ça ressemble:

var wmsLayer =
L.tileLayer.wms('https://demo.boundlessgeo.com/geoserver/ows?', {
layers: 'ne:ne'
}).addTo(map);

3.3.8.4 Couches GeoJSON

GeoJSON est en train de devenir un format de données très populaire parmi de nombreuses
technologies et services SIG - il est simple, léger et simple, et Leaflet est assez bon pour le

70
gérer. D’après http://geojson.org: GeoJSON est un format pour coder une variété de structures
de données géographiques. Un objet GeoJSON peut représenter une géométrie, une
fonctionnalité ou une collection d'entités. GeoJSON prend en charge les types de géométrie
suivants: Point, LineString, Polygon, MultiPoint, MultiLineString, MultiPolygon et
GeometryCollection. Les fonctionnalités de GeoJSON contiennent un objet géométrique et des
propriétés supplémentaires, et une collection d'entités représente une liste d'entités.

Leaflet prend en charge tous les types de GeoJSON ci-dessus, mais Features et
FeatureCollections fonctionnent mieux car ils permettent de décrire des fonctionnalités avec un
ensemble de propriétés. Nous pouvons même utiliser ces propriétés pour styliser nos vecteurs
Leaflet. Voici un exemple d'une fonctionnalité GeoJSON simple:

var geojsonFeature = {
"type": "Feature",
"properties": {
"name": "Coors Field",
"amenity": "Baseball Stadium",
"popupContent": "This is where the Rockies play!"
},
"geometry": {
"type": "Point",
"coordinates": [-104.99404, 39.75621]
}
};

Les objets GeoJSON sont ajoutés à la carte via une couche GeoJSON. Pour le créer et l'ajouter
à une carte, nous pouvons utiliser le code suivant :

L.geoJSON(geojsonFeature).addTo(map);

3.4 Conclusion

Java Entreprise Edition a été conçu comme un environnement pour développer, déployer et
exécuter des applications réparties pour le monde de l'entreprise. Ce contexte de l'entreprise se
caractérise généralement par la nécessité d'assurer des niveaux de qualité de service tels que la
sûreté de fonctionnement, la résistance à des charges d'exécution importantes ou encore la
sécurité. Nous avons également expliqué dans ce chapitre l’architecture de base du Web
Mapping en précisant chaque bloc qui le forme. La base de données PostGIS sert à stocker les
données geospatiales, tan disque le Geoserver accède à cette dernière afin qu’il puisse répondre
aux requêtes des clients, et enfin la librairie de Leaflet pour présenter la carte donnée par le
Geoserver et de permettre l’interaction avec la carte.

71
CHAPITRE 4
PRESENTATION ET REALISATION D’UNE APPLICATION ANDROID
ET D’UNE APPLICATION WEB

4.1 Introduction

Dans ce chapitre, nous allons voir en premier lieu la présentation du projet puis au test et
validation du projet dont trois aspects importants seront soulignés tout au long de ce chapitre
dont :

• La collecte de données par l’application Android


• Le transfert de données du téléphone vers le serveur
• Et enfin la présentation de l’application Web.
4.2 Description du projet

Ce projet a pour objectifs :

• De collecter des données via une application Android afin de les centraliser à un serveur
via les réseaux mobiles tout en sécurisant les données,
• Ainsi que de réaliser une application Web avec la plateforme JAVA EE, pour visualiser
ces données récoltées à l’aide du Web Mapping.
Pour cela, on a choisi le scénario d’une élection présidentielles à Madagascar ; dont
l’application Android sera utilisée par des agents pour récolter les résultats de vote dans chaque
bureau de vote au jour du scrutin plus précisément après le dépouillement, ensuite les résultats
seront envoyés par l’application Android au serveur central via les réseaux mobiles.

L’application Web, elle affichera les résultats de vote dans chaque bureau de vote, de ce fait
elle permet de visualiser les résultats globaux de l’élection à Madagascar. Mais ça particularité
repose sur le fait qu’elle implémente le Web Mapping afin de faciliter la présentation des
résultats.

4.3 Analyse de l’existant

4.3.1 Analyse des couvertures réseaux mobiles à Madagascar

L’une des contraintes considérables rencontré pendant la récolte de données mobile est le lieu
de travail, c’est-à-dire la collecte des données pourrait avoir dans des endroits éloignés ou des
villages isolés où la possibilité de transmettre des données par un téléphone mobile peut être
très limitée ou même inexistant.

72
Cela signifie que la majeure partie de la collecte de données est effectué hors ligne. De ce fait,
il est indispensable d’étudier la couverture des réseaux mobiles à Madagascar afin de
développer l’application qui peut s’adapter au type de couverture existant lors de la collecte de
données.

En combinant la couverture des opérateurs téléphoniques à Madagascar, on a pu obtenir la


figure suivante, montrant les zones couverts par le 2G à Madagascar. [34] [35] [36] [37]

Figure 4.01: Couverture 2G à Madagascar

73
La figure 4.02 montre la statistique :

Nombre de Fokontany

14%

86%

Sans couverture Couvert 2G

Figure 4.02: Statistique des Fokontany couverts par le 2G à Madagascar

74
La figure suivante montre la couverture 3G et 4G à Madagascar.

Figure 4.03: Couverture 3G et 4G à Madagascar

4.3.2 Choix des opérateurs

Pour assurer une meilleure collecte de données, il faut bien choisir l’opérateur optimal qu’on
doit utiliser à un endroit donné. Plus précisément, le carte SIM utilisé par le téléphone Android
pour remonter les données du téléphone vers le serveur. Pour cela, il est impératif d’effectuer
un drive test, c’est à dire, un procédé de mesure et d’évaluation de la couverture, la capacité et
la QoS d’un réseau mobile [38] à un endroit spécifique, afin de déterminer quel opérateur doit-
on utiliser pour un bureau de vote donné.

Bon nombre d’outils permettent d’effectuer cette tâche, mais on a penché vers un outil gratuit,
disponible sur Android et crédible. Pour cela on a choisi l’application « Cell Signal Monitor »

Cell Signal Monitor est une application spécialisée pour les appareils Android qui vérifie un
état des réseaux GSM, UMTS et LTE. Ce moniteur réseau est utile si on veut:

• Vérifier le niveau de puissance des stations de base (BTS) environnantes et analyser la


dynamique de changement

75
• Vérifier la vitesse de la connexion entrante et sortante
• Faire un journal d'identification de cellule
• Afficher les emplacements de BTS (après l'importation du fichier CLF spécial)
• Créer des statistiques d'utilisation des cellules.
Pour cela l’application donne les informations suivantes :

• Etat de l'unité radio;


• Nom de l'opérateur de téléphonie mobile actuel;
• Mobile Country Code (MCC);
• Mobile Network Code (MNC);
• Type de réseau actuel (GPRS / EDGE / UMTS / HSPA / HSDPA / HSUPA / LTE)
• Indicateur d'itinérance
• La vitesse de la connexion entrante et sortante
• Identifiant de cellule (CID)
• Location Area Code (LAC) - pour les réseaux GSM / UMTS
• Tracking Area Code (TAC) - pour les réseaux LTE
• Radio Network Controller (RNC) - pour les réseaux UMTS
• Indication de l'intensité du signal reçue (RSSI ou Received Signal Strength Indication)
• Puissance de signaux reçus de référence (RSRP) - pour les réseaux LTE.

76
Figure 4.04: L’application « Cell signal monitor »

4.4 Mises-en œuvre du projet

4.4.1 Application Android

Comme expliqué dans la description du projet, l’application Android constitue l’un des
éléments de base de ce projet, car cette dernière assure la récolte de données proprement dite.

Dans le cadre de ce projet, les données seront remontées au serveur ; soit par SMS soit par
HTTPS selon la couverture des réseaux mobiles existante au lieu de travail.

77
La figure 4.05 montre l’organigramme de l’application.

Figure 4.05: Organigramme de l’application Android

4.4.1.2 Authentification

L'authentification de cette application vise à faciliter le systèmes d'authentification sécurisés,


tout en améliorant l'expérience de connexion et d'intégration pour les utilisateurs finaux. Il
fournit une solution d'identité de bout en bout, prenant en charge les comptes mails et de mot
de passe, l'authentification par téléphone, ainsi que les identifiants Google.

78
Cette étape permet d’authentifier les agents en mode local (pour le cas des zones sans
couverture) et en mode connecté.

4.4.1.3 Collection de données

Dans le cadre de ce projet, les données à collecter sont :

- Le nombre de vote obtenu par chaque candidat


- Le nombre des électeurs dans le bureau de vote
- Le nombre des électeurs qui ont participé au vote
- Le nombre des bulletins nuls et blancs
- La date et l’heure de la collecte de données
- L’IMEI du téléphone
- Le numéro de la carte SIM utilisé
- Les informations relatives à l’utilisateur.
La figure suivante montre l’organigramme de cette étape.

Figure 4.06: Organigramme de la collecte de données

79
4.4.1.4 Cryptographie

Cette application traite des informations sensibles, donc il doit fournir un niveau de protection
adéquat pour les données en tout temps : à la fois pendant qu’il est recueilli et stocké sur
l’appareil mobile, et tout en étant transféré et stocké au serveur.

En effet, une fois recueilli dans le téléphone, les données sont cryptées, avant d’être stockées
dans le téléphone et transférées au serveur. Pour cela, l’application utilise le cryptographie AES
afin d’assurer la sécurité des données. Le choix de l’algorithme de chiffrement est basé sur sa :

• Rapidité
• Techniquement, le chiffrement doit se faire par blocs de 128 bits, les clés comportant
128,192 ou 256 bits.
• Grande sécurité
• Facilité d’implémentation
De plus, on n’a pas utilisé le chiffrement à clé publique, à cause de l’échange de clé qui s’avère
difficile si le téléphone utilise le SMS comme moyen de communication avec le serveur. Or le
SMS peut être lu en texte clair chez les opérateurs téléphoniques, donc l’utilisation de
l’algorithme de chiffrement à clé publique est vulnérable dans le cas où le SMS est le moyen
pour faire l’échange des clés. C’est pour cela qu’on a opté vers l’algorithme de chiffrement à
clé secrète : AES.

public class AESCrypto {

//AESCrypt-ObjC uses CBC and PKCS7Padding


private static final String AES_MODE = "AES/CBC/PKCS7Padding";
private static final String CHARSET = "UTF-8";
//AESCrypt-ObjC uses SHA-256 (and so a 256-bit key)
private static final String HASH_ALGORITHM = "SHA-256";
//AESCrypt-ObjC uses blank IV (not the best security, but the aim here is
compatibility)
private static final byte[] ivBytes = {0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
//togglable log option (please turn off in live!)
public static boolean DEBUG_LOG_ENABLED = false;
public static String encrypt(final String password, String message)
throws GeneralSecurityException {
try {
final SecretKeySpec key = generateKey(password);
byte[] cipherText = encrypt(key, ivBytes, message.getBytes(CHARSET));
//NO_WRAP is important as was getting \n at the end
String encoded = Base64.encodeToString(cipherText, Base64.NO_WRAP);
return encoded;
} catch (UnsupportedEncodingException e) {
if (DEBUG_LOG_ENABLED)
Log.e(TAG, "UnsupportedEncodingException ", e);
throw new GeneralSecurityException(e);
}

80
Ce code montre une classe permettant de crypter un message à l’aide d’une clé en chaine de
caractère, en utilisant l’algorithme de chiffrement AES et méthode blocs : CBC

4.4.1.5 Transfert de données vers le serveur

D’après le résultat de l’analyse des couvertures des réseaux mobiles à Madagascar, on distingue
3 zones :

• Sans couverture
• Couvert par le 2G seulement
• Couvert par la 3G ou la 4G
a. SMS

Le service de messagerie SMS, plus connu sous le sigle de SMS (pour « Short Message Service
») permet de transmettre de courts messages textuels. C'est l'un des services de la téléphonie
mobile (il a été introduit par la norme GSM). Le SMS permet de transmettre des messages de
plusieurs milliers de caractères — découpés en sous-messages de 160 caractères.

La transmission des données par SMS est utile si la couverture existante à l’emplacement de la
collecte de données n’est que 2G. Et d’après l’analyse de la couverture de Madagascar dans la
section précédente, le 2G occupe encore une grande majorité de couverture par rapport à ses
successeurs. De ce fait la majorité des téléphones utiliseront le SMS afin de transférer les
données vers le serveur.

Afin de permettre l’envoi de SMS dans une application Android, il faut ajouter la permission
au fichier Manifest.xml

<uses-permission android:name="android.permission.SEND_SMS"/>

Et le code suivant montre la méthode utilisé pour envoyer un SMS à un numéro.

public static void sendSMS(Context context,String phoneNumber, String


message) {
PendingIntent sentIntent =
PendingIntent.getBroadcast(context,0,new Intent("SMS_SENT"),0);
SmsManager smsManager = SmsManager.getDefault();
smsManager.sendTextMessage(phoneNumber, null, message,
sentIntent, null);
Toast.makeText(context, "Message sent successfully",
Toast.LENGTH_SHORT).show();
}

81
b. HTTPS

HTTPS est la version sécurisée de HTTP, le protocole sur lequel les données sont envoyées
entre votre navigateur et le site Web auquel vous êtes connecté. Le « S » à la fin de HTTPS
signifie « sécurisé ». Cela signifie que toutes les communications entre votre navigateur et le
site Web sont cryptées. HTTPS est souvent utilisé pour protéger les transactions en ligne
hautement confidentielles. Les pages HTTPS utilisent généralement l'un des deux protocoles
sécurisés pour crypter les communications : SSL (Secure Sockets Layer) ou TLS (Transport
Layer Security). Les protocoles TLS et SSL utilisent tous les deux ce qu'on appelle un système
d'infrastructure à clé publique (ICP) « asymétrique ». Un système asymétrique utilise deux «
clés » pour chiffrer les communications, une clé « publique » et une clé «privée». Tout ce qui
est chiffré avec la clé publique ne peut être décrypté que par la clé privée et vice-versa.

Une fois que l’application Android détecte de la 3G ou de la 4G, elle envoie les données via
Internet par HTTPS.

Pour cela, il faut autoriser l’application à connecter à Internet en ajouter de la permission au


fichier Manifest.xml, comme suit :

<uses-permission android:name="android.permission.INTERNET"/>
Et le code suivant permet d’envoyer les données au serveur à distance via Internet.

public static void sendLocationBySocketIO(final Context context, final


String data) throws URISyntaxException, JSONException {
final io.socket.client.Socket socket =
IO.socket("https://serveur");
socket.on(io.socket.client.Socket.EVENT_CONNECT, new
Emitter.Listener() {
@Override
public void call(Object... args) {
socket.emit("electionData", data);
socket.disconnect();
}

}).on("event", new Emitter.Listener() {


@Override
public void call(Object... args) {

}
}).on(io.socket.client.Socket.EVENT_DISCONNECT, new
Emitter.Listener() {
@Override
public void call(Object... args) {

}
});
socket.connect();

}
82
4.4.2 Modèle de données

La figure 4.07 illustre le MLD de l’application Web.

Figure 4.07: Modèle logique de la base de données

4.4.3 Web Mapping

4.4.3.1 PostGis

a. Création d’une base de données spatiale

PostgreSQL a un certain nombre d’interface graphique pour l’administrer. Le principal est psql
un outil de ligne de commande pour entrer des requêtes SQL. Une autre interface graphique
populaire de PostgreSQL est l'outil graphique gratuit et open source pgAdmin. Toutes les
requêtes effectuées dans pgAdmin peuvent également être effectuées sur la ligne de commande
avec psql. La commande qui permet de créer la base de données spatiales est :

CREATE EXTENSION postgis;

83
b. Chargement des données dans PostGIS

PostGIS offre de nombreuses options pour le chargement de données, supportées par une grande
variété de bibliothèques et d'applications. Cette section se concentrera sur les bases de
chargement de fichiers de formes ou shapefile à l'aide de ligne de commande associée à
PostGIS.

La commande « shp2pgsql » permet d’importer des shapefile dans PosGIS. Le syntaxe de cette
commande est :

shp2pgsql -I -s <projection> <shapefile path> <table name>|


psql -U <user> -d <database>

• <projection>: La projection utilisée par le shapefile

• <shapefile path>: Le chemin vers le shapefile

• <table name>: le nom de la table sur laquelle les données spatiales vont être stockés

• <user>: le nom d’utilisateur dans la base de données PostgreSQL

• <database>: la base de données de destination

Dans le cadre de ce projet, on a utilisé 5 shapefiles de Madagascar :

• mada_province.shp : carte des provinces de Madagascar


• mada_region.shp : carte des regions de Madagascar
• mada_district.shp : carte des districts de Madagascar
• mada_commune.shp : carte des communes de Madagascar
• mada_fokontany.shp : carte des fokontany de Madagascar
Pour Madagascar la projection utilisée est EPSG:29700, donc la valeur de la projection dans le
paramètre de la commande « shp2pgsql » sera 29700

Alors, pour importer ces shapefiles dans la base de données mada_shape qu’on vient de créer,
lancer les commandes suivantes

shp2pgsql -I –s 29700 mada_province.shp mada_province |psql -U user -d


mada_shape
shp2pgsql -I –s 29700 mada_region.shp mada_region | psql -U user -d
mada_shape
shp2pgsql -I –s 29700 mada_district.shp mada_district | psql -U user -d
mada_shape
shp2pgsql -I –s 29700 mada_commune.shp mada_commune | psql -U user -d
mada_shape
shp2pgsql -I –s 29700 mada_fokontany.shp mada_fokontany | psql -U user -d
mada_shape

84
4.4.3.2 Geoserver

a. Création de Espaces de travail

La première étape du chargement des données consiste généralement à créer un espace de


travail ou Workspace. Cela crée un conteneur virtuel pour votre projet. Plusieurs couches
provenant de plusieurs sources peuvent toutes être contenues dans un espace de travail, la
contrainte principale étant que chaque nom de couche soit unique.

Un Espace de travail est composé d'un nom (également parfois appelé « préfixe d'espace de
noms »), représenté par quelques caractères, et d'un URI d'espace de noms. Ces deux champs
doivent identifier de manière unique l'espace de travail. Le tableau suivant montre les champs
nécessaires lors de la création de l’espace de travail :

Nom ELECTION
URI de l’espace de nommage http://localhost:8080/ELECTION

Tableau 4.01: Espace de travail

b. Importation des données à partir de PostGIS

Pour importer des données à partir de PostGIS, il est indispensable de fournir les données
relatives à la base de données qui contient les données géospatiales. Le tableau ci-dessous donne
celles qu’on a utilisé, afin de permetre l’importation des données dans le geoserver.

Espace de travail ELECTION


Nom de la source de données mada_province
dbtype postgis
host localhost
port 5432
database mada_shape
user user
password *****

Tableau 4.02: Information relative à la base de données PostGIS

85
4.4.4 Application Web

4.4.4.1 Implémentation de Hibernate

Hibernate est une solution open source de type ORM (Object Relational Mapping) qui permet
de faciliter le développement de la couche persistance d'une application. Hibernate permet donc
de représenter une base de données en objets Java et vice versa.

Hibernate facilite la persistance et la recherche de données dans une base de données en


réalisant lui-même la création des objets et les traitements de remplissage de ceux-ci en
accédant à la base de données. La quantité de code ainsi épargnée est très importante d'autant
que ce code est généralement fastidieux et redondant.

Hibernate est très populaire notamment à cause de ses bonnes performances et de son ouverture
à de nombreuses bases de données. Les bases de données supportées sont les principales du
marché : DB2, Oracle, MySQL, PostgreSQL, Sybase, SQL Server, Sap DB, Interbase, ...

Le site officiel http://www.hibernate.org contient beaucoup d'informations sur l'outil et


propose de le télécharger ainsi que sa documentation.

Hibernate a besoin de plusieurs éléments pour fonctionner :


• Une classe de type javabean qui encapsule les données d'une occurrence d'une table
• Un fichier de configuration qui assure la correspondance entre la classe et la table
(mapping)
• Des propriétés de configuration notamment des informations concernant la connexion à
la base de données
Une fois ces éléments correctement définis, il est possible d'utiliser Hibernate dans le code des
traitements à réaliser. L'architecture d'Hibernate est donc la suivante :

Figure 4.08: Architecture de Hibernate

86
Dans notre cas, les éléments cités ci-dessus sont assurés par les trois fichiers suivants dont :
hibernate.cfg.xml, hibernate.reveng.xml et NewHibernateUtile.java.

b. hibernate.cfg.xml

Pour exécuter Hibernate, il faut lui fournir un certain nombre de propriétés concernant sa
configuration pour qu'il puisse se connecter à la base de données.

<hibernate-configuration>
<session-factory>
<property
name="hibernate.dialect">org.hibernate.dialect.PostgreSQLDialect</propert
y>
<property
name="hibernate.connection.driver_class">org.postgresql.Driver</property>
<property
name="hibernate.connection.url">jdbc:postgresql://localhost:5432/****
</property>
<property name="hibernate.connection.username">********</property>
<property name="hibernate.connection.password">********</property>
<mapping resource="com/andrana/entity/MadaFokontany.hbm.xml"/>
<mapping resource="com/andrana/entity/MadaRegion.hbm.xml"/>
<mapping resource="com/andrana/entity/VoteFokontany.hbm.xml"/>
</session-factory>
</hibernate-configuration>
c. Fichier de mapping

Pour assurer le mapping, Hibernate a besoin d'un fichier de correspondance (mapping file) au
format XML qui va contenir des informations sur la correspondance entre la classe définie et la
table de la base de données.

Même si cela est possible, il n'est pas recommandé de définir un fichier de mapping pour
plusieurs classes. Le plus simple est de définir un fichier de mapping par classe, nommé du nom
de la classe suivi par ".hbm.xml". Ce fichier doit être situé dans le même répertoire que la classe
correspondante ou dans la même archive pour les applications packagées.

Différents éléments sont précisés dans ce document XML :

• La classe qui va encapsuler les données


• L'identifiant dans la base de données et son mode de génération
• Le mapping entre les propriétés de classe et les champs de la base de données
• Les relations
d. Classe encapsulant les données

Cette classe doit respecter le standard des Javabeans, notamment, encapsuler les propriétés dans
ses champs private avec des getters et setters et avoir un constructeur par défaut.

87
Les types utilisables pour les propriétés sont : les types primitifs, les classes String et Dates, les
wrappers, et n'importe quelle classe qui encapsule une autre table ou une partie de la table.

e. NewHibernateUtile.java

Pour utiliser Hibernate dans le code, il est nécessaire de réaliser plusieurs opérations :

• Création d'une instance de la classe


• Création d'une instance de la classe SessionFactory
• Création d'une instance de la classe Session qui va permettre d'utiliser les services
d'Hibernate
Une instance de la classe Session est obtenue à partir d'une fabrique de type SessionFactory,
elle-même obtenue à partir de l'instance du type Configuration en utilisant la méthode
buildSessionFactory().

La méthode openSession() de la classe SessionFactory permet d'obtenir une instance de la


classe Session. Par défaut, c'est la méthode openSession() qui va ouvrir une connexion vers la
base de données en utilisant les informations fournies par les propriétés de configuration.

4.4.4.1 Servlet

Une servlet est un composant web conçu sous la forme d'une classe Java. Cette dernière existe
au sein d'une application web et la mise en œuvre est gérée par un conteneur web du côté du
serveur web. Une servlet interagit avec un client web par l'intermédiaire du protocole http via
un mécanisme de requête-réponse.

@WebServlet(name = "Fokontany", urlPatterns = {"/Fokontany"})


public class Fokontany extends HttpServlet {
@Override
protected void doGet(HttpServletRequest request, HttpServletResponse
response)
throws ServletException, IOException {
request.setAttribute("idCommune", idCommune);
request.getRequestDispatcher("fokontany.jsp").forward(request, response);
}
@Override
protected void doPost(HttpServletRequest request, HttpServletResponse
response)
throws ServletException, IOException {
}
}
La méthode doGet() d’une servlet est invoqué lorsque son URL est saisie directement dans la
barre d’adresse du navigateur, tan disque doPost() est invoqué lors de l'envoie de donnée
saisie dans un formulaire HTML par un clic sur un bouton de type submit.

88
4.5 Test et validation

4.5.1 Collecte de données sur Android

4.5.1.1 Authentification à l’application

Afin d’autoriser un utilisateur d’accéder à l’application, il doit confirmer et valider son identité
par des identifiants et des mots de passe. Dans cette application, un identifiant peut être un nom
d’utilisateur, adresse email ou un numéro de téléphone.

Figure 4.09: Authentification sur Android

4.5.1.2 Formulaire

Une fois l’utilisateur est authentifié, il peut désormais accéder aux différentes fonctionnalités
de l’application.

89
L’agent peut remplir les formulaires par l’intermédiaire de cette interface.

Figure 4.10: Formulaire

Figure 4.11: Champ d’un candidat

90
Le tableau suivant montre le détail de chaque partie du formulaire

Numéro Explication
Liste de tous les candidats à l’élection ainsi que leurs nombre de vote
respectifs
Champ sur le nombre de vote total ainsi que les détails des bulletins
nuls et blancs
Bouton envoyer permettant de transférer les données recueillies

Image ou logo du candidat

Nom du candidat

Nombre de vote obtenu par le candidat

Tableau 4.03: Formulaire

4.5.1.3 Cryptage des données

Une fois les données sont collectées, la figure suivante montre ce qui se passe en arrière-plan
de l’application Android.

Figure 4.12: Cryptage de données dans Android

Les données sont ensuite cryptés par l’algorithme de chiffrement AES, ainsi les données
cryptées sont montrées par la ligne avec le label « ENCRYPTED »

4.5.2 Transfert de données au serveur

4.5.2.1 SMS

Lorsque l’application ne détecte que le réseau 2G, elle transfert les données par SMS au serveur.
On peut vérifier si les données sont belles et bien envoyés au serveur, en allant dans la boite
d’envoi de SMS d’Android.

91
Figure 4.13: Boite d’envoi de SMS dans Android

Le message envoyé par le téléphone Android par SMS au serveur est le même que celui affiché
à la figure 4.11

4.5.2.2 HTTPS

Afin de capturer le trafic venant du smartphone (Android), on a utilisé l’application Shark, une
version plus léger de Wireshark sur Android. Et c’est le fichier générer par cette application
qu’on va ouvrir dans Wireshark pour analyser.

Wireshark est un analyseur de paquets, gratuit et open source utilisé pour le dépannage et
l'analyse du réseau. Cette section montrera le trafic générer par le smartphone lorsqu’il envoie
les données au serveur par HTTPS.

a. Capture du trafic HTTPS

La figure ci-contre illustre les différentes étapes de l’établissement d’une session SSL entre le
serveur et le smartphone. Pour cela on a appliqué un filtre permettant de n’afficher que le trafic
SSL entre ces deux entités, d’où la commande.

ip.addr == [serveur] and ssl

92
Figure 4.14: Capture du trafic HTTPS

En appliquant le filtre, la figure 4.13 affiche les différentes étapes d’une liaison SSL/TLS
comme expliqué au chapitre 2.

b. Analyse de trafic SSL/TLS Client Hello

La figure suivante montre le premier paquet TLS, marqué Client Hello, qui n’est rien d’autre
que le paquet envoyé par le smartphone au serveur, et ce paquet contient :

• La version de TLS
• Les paramètres de sécurités (méthode cryptographiques, tailles des clés, méthodes de
compression)

Figure 4.15: Trafic SSL/TLS Client Hello

c. Analyse de trafic SSL/TLS Server Hello

Le paquet marqué Server Hello, quant à lui est un paquet comparable au message Client Hello
mais c’est le serveur qui l’envoie au client.

93
Figure 4.16: Trafic SSL/TLS Server Hello

d. Analyse de trafic SSL/TLS Certificate

La figure suivante montre l’envoie des certificats x509 par le serveur. Dans cette figure, le
serveur envoie le certificat qui l’identifie et la chaine des certificats CA.

Figure 4.17: Trafic SSL/TLS Certificate

e. Analyse de trafic SSL/TLS Key Exchange

Après avoir abouti les étapes précédemment, le client et le serveur échangent des messages
contenants la stratégie de crypage.

Figure 4.18: Trafic SSL/TLS Client Key Exchange

94
Figure 4.19: Trafic SSL/TLS Client Key Exchange

Figure 4.20: Trafic SSL/TLS Change Cipher Spec

f. Analyse de trafic HTTS Encrypted Data Exchange

Cette partie montre la dernière étape du trafic HTTPS qui consiste à l’envoie des données
cryptées via HTTP.

Figure 4.21: Trafic SSL/TLS Encrypted Data Exchange

La ligne “Encrypted Application Data” nous montre les données cryptées envoyées par le client
au serveur en utilisant le protocole HTTP.

95
4.5.3 Serveur

4.5.3.1 Réception des données

La figure suivante montre les données reçus par le serveur ainsi que le protocole utilisé pour
transmettre les données.

Figure 4.22: Log du serveur à la réception des données

Dans le log du serveur, la première ligne avec la marque « message » indique le message crypté
par l’application Android, et on remarque ce dernier est exactement le même que celui montré
par la figure 4.12. Ensuite la deuxième ligne montre le message décrypté en format JSON. On
a utilisé ce format parce que c’est flexible, plus compact et dans plusieurs cas c’est plus facile
de l’utiliser notamment quand on travaille avec JavaScript.

4.5.3.2 Vérification des données dans la base de données

Comme expliqué dans le modèle conceptuel de donnée, un agent dispose d’un smartphone et
ce même agent collecte de données dans un et un seul bureau de vote. Pour le test, les données
collectées tout au long de ce chapitre correspondent au résultat de vote du Fokontany qui a pour
id : 8764.

Si les données reçus par le serveur sont valides, ces dernières seront tout de suite insérées dans
la base de données. La figure suivante montre le résultat de vote d’un bureau de vote numéro
8764.

Figure 4.23: Données stockées dans la base de données

Remarque : Pour renforcer la sécurité des données, et pour éviter toutes sortes de piratages, le
serveur ne traitre que les données venantes des agents. Chaque agent dispose alors sa propre clé

96
secrète et cette clé est la combinaison de l’IMEI du téléphone qu’il emploie, l’IMSI de la carte
SIM qu’il utilise pour connecter au réseau mobile, son login et son mot de passe. Donc même
si un pirate utilise l’application pour envoyer des données truquées au serveur, ses données
seront tout de suite rejetées par le serveur parce que son IMEI et son IMSI ne figurent pas dans
la liste des agents dans la base de données.

4.5.4 Présentation des résultats dans l’application web

Cette application web a pour but de présenter les résultats de l’élection présidentielles dans
chaque bureau de vote afin de donner la statique des résultats dans chaque commune, district,
région et province de Madagascar. Mais ce qui le différentie des autres site web c’est son Map
interactif.

Figure 4.24: Résultat global dans tous Madagascar

En effet, la carte de Madagascar occupe une grande partie de la page Web, et cette dernière
présente les 6 provinces dont la couleur change selon la couleur du candidat gagnant dans une
province spécifique. Et comme il s’agit d’un Map interactif, il suffit de faire défiler sur une
province le curseur pour afficher les statistiques des résultats de vote dans cette province.

Notons que, lorsqu’on clique sur une zone de la carte, l’application n’affiche que la zone
sélectionnée ainsi que ses éléments constitutifs.

97
Autrement dit, lorsqu’on clique sur une province, l’application affichera les régions de cette
province et ainsi de suite jusqu’au Fokontany, comme le montre la figure 4.25.

Figure 4.25: Résultat de la région d’Analamanga

On tient à préciser qu’on a déjà généré les résultats de vote pour tous les bureaux de vote sauf
celui envoyé par l’application Android précédemment dont sa localisation est donnée par le
tableau 4.04:

Province Fianarantsoa
Région Haute Matsiatra
District Lalangina
Commune Ivoamba

Tableau 4.04: Localisation du Fokontany d’Ivoamba

La figure 4.24 affiche les données stockées dans la base de données dans l’application Web.
Dans cette figure, l’application affiche le nom du Fokontany, le nombre de vote obtenu par
chaque candidat ainsi que le pourcentage.

98
Ainsi, les données envoyées par l’application Android correspondent à celles affichées par
l’application Web.

Figure 4.26: Présentation du résultat dans l’application Web

4.6 Conclusion

Dans le cadre de ce projet, la collecte de données est assurée par une application Android,
ensuite les données seront remontées au serveur soit par SMS ou via Internet par HTTPS. ,
selon la couverture des réseaux mobiles existantes au lieu de travail. Mais avant d’être
transférées, les données sont cryptées par l’algorithme de chiffrement AES. Les données reçus
par le serveur sont stockés dans une base de données PostgreSQL. Une application Web a été
mis en place afin de présenter les résultats obtenus dans chaque bureau de vote à l’aide du Web
Mapping. D’après le test qu’on a fait, on peut valider que les données exploitées par les agents,
sont sécurisées, lors de la collecte de données que pendant la transmission de données au
serveur, et c’est après le test de validité des données reçus, que le serveur stocke les données
dans la base de données afin que l’application web puisse l’afficher.

99
CONCLUSION GENERALE

Les infrastructures de réseau sans fil, notamment les réseaux cellulaires, deviennent un élément
essentiel de l'échange de données électroniques. La collecte de données mobiles est celle utilisée
pour remplacer la collecte de données sur formulaire papier traditionnel avec des formulaires
numériques électroniques par l'utilisation de systèmes de collecte de données mobiles (MDC)
fonctionnant sur les infrastructures de réseau sans fil. Cependant, bien que de tels systèmes
soient souvent utilisés pour collecter des données sensibles, des problèmes critiques comme la
sécurité et la confidentialité des données personnelles n'ont pas été systématiquement traités.
En particulier, très peu a été fait pour protéger les données stockées sur le téléphone. Ce
document se concentre sur des solutions adéquates pour la protection du stockage et le transfert
des données vers le serveur en s'adaptant sur la couverture du réseau cellulaire existant sur les
lieux de travail des agents collecteurs.

Dans le cadre de ce mémoire, on a choisi le scénario de l'élection présidentielles à Madagascar,


afin de maitre en pratique ce que c'est le MDC. Pour cela, les agents collectent les résultats de
vote dans chaque bureau de vote à l'aide d'une application Android conçue pour cette scénario.
Ensuite, les données collectées par ces agents seront envoyées au serveur central soit par SMS
soit par Internet en utilisant le HTTPS. Mais pour pallier au problèmes de sécurités des données
en transitent dans le réseau mobile, ces dernières sont cryptées par la méthode de chiffrement
AES-128 par l'application Android avant d'être transférées vers le serveur.

Pour visualiser et interpréter, les données reçues par le serveur, on a développé une application
web avec la plateforme JEE, en y intégrant le concept du Web Mapping, afin qu'on puisse
accéder à un ensemble d'informations à l'aide d'une carte interactive.

Après ces différents chapitres allant des études de solutions jusqu’aux tests et validation, on
peut affirmer que le système mis en place fonctionne correctement. On peut dire aussi que les
objectifs ont été atteints en tenant compte des objectifs du projet. Pourtant, le travail réalisé
pourrait être complété et poursuivi sous différents aspects de perspective, notamment :
l’implémentation de l’application de collecte de données mobile dans différentes plateformes
autres que Android, ainsi que l’ajout des fonctionnalités de la plateforme Web afin que les
utilisateurs puissent créer des formulaires le plus simplement possible, et de les synchroniser
aux applications mobiles pour que ces dernières soient flexibles, extensibles et adaptées aux
différents scénarios de collecte de données.

100
ANNEXES

ANNEXE 1
LES CONCEPTS DU GEOSERVER

Vous rencontrerez beaucoup de terminologie lorsque vous travaillez avec GeoServer, et certains
d'entre eux peuvent ne pas vous être familiers, en particulier si vous n'êtes pas habitué à la
cartographie Web. Cette section présente certains des termes les plus couramment utilisés dans
GeoServer. Tous ces termes seront utilisés dans les prochaines sections.

A1.1 Espace de travail

Un espace de travail (parfois appelé espace de noms) est le nom d'un conteneur notionnel
permettant de regrouper des données similaires. Il est conçu pour être un espace séparé et isolé
relatif à un certain projet. En utilisant les espaces de travail, il est possible d'utiliser des calques
avec des noms identiques sans conflits.

Les espaces de travail sont généralement indiqués par un préfixe à un nom de couche
ou un nom de magasin. Par exemple, une couche appelée streets avec un préfixe d'espace de
travail appelé nyc sera référencée par nyc:streets. Cela ne serait pas en conflit avec une autre
couche appelée streets dans un autre espace de travail appelé dc (dc: streets)

Note :

Techniquement, le nom d'un espace de travail est un URI, pas le préfixe court. Un URI est un
identificateur de ressource uniforme, similaire à une URL, mais qui n'a pas besoin d'être résolu
en un site Web. Dans l'exemple ci-dessus, l'espace de travail complet aurait pu être http://nyc
auquel cas le nom complet de la couche serait http://nyc:streets. GeoServer remplace
intelligemment le préfixe d'espace de travail par l'URI d'espace de travail complet, mais il peut
être utile de connaître la différence.

Figure A1.01: Espace de travail

101
A1.2 Entrepôt

Un entrepôt est le nom d'un conteneur de données géographiques. Un entrepôt fait référence à
une source de données spécifique, qu'il s'agisse d'un fichier de formes, d'une base de données
ou de toute autre source de données prise en charge par GeoServer.

Un entrepôt peut contenir plusieurs couches, comme dans le cas d'une base de données
contenant plusieurs tables. Un entrepôt peut également avoir une seule couche, comme dans le
cas d'un fichier de formes ou d'un fichier GeoTIFF. Un entrepôt doit contenir au moins une
couche.

GeoServer enregistre les paramètres de connexion dans chaque entrepôt (le chemin vers
le fichier de formes ou shapefile, les informations d'identification pour se connecter à la base
de données). Chaque entrepôt doit également être associé à un (et un seul) espace de travail.

Un entrepôt est parfois appelé "datastore" dans le contexte des données vectorielles, ou
"coveragestore" dans le contexte des données raster (couverture).

Figure A1.02: Entrepôt

A1.3 Couches

Une couche (parfois appelée featuretype) est une collection d'entités géospatiales ou une
couverture. Typiquement, une couche contient un type de données (points, lignes, polygones,
raster) et a un seul sujet identifiable (rues, maisons, limites de pays, etc.). Une couche
correspond à une table ou à une vue d'une base de données ou à un fichier individuel.

102
GeoServer stocke les informations associées à une couche, telles que les informations de
projection, la boîte englobante et les styles associés. Chaque couche doit être associée à un (et
un seul) espace de travail.

Figure A1.03: Couches

A1.4 Agrégation des couches

Comme son nom l'indique, est une collection de couches. Un groupe de couches permet de
demander plusieurs couches avec une seule demande WMS. Un groupe de calques contient des
informations sur les calques qui composent le groupe de calques, l'ordre dans lequel ils sont
rendus, la projection, les styles associés, etc. Cette information peut être différente des valeurs
par défaut pour chaque couche individuelle.

Les groupes de calques ne respectent pas le concept d'espace de travail et ne sont pertinents que
pour les demandes WMS.

Figure A1.04: Agrégation des couches

103
La figure A1.05 montre les différentes relations entre les espaces de travail, les magasins, les
couches et les groupes de couches.

Figure A1.05: Relation entre les composants de Geoserver

A1.5 Style

Un style est une directive de visualisation pour le rendu de données géographiques. Un style
peut contenir des règles de couleur, de forme et de taille, ainsi qu'une logique permettant de
styliser certaines entités ou certains points en fonction d'attributs ou de niveaux d'échelle.

Chaque couche doit être associée à au moins un style. GeoServer reconnaît les styles au format
SLD (Styled Layer Descriptor).

104
ANNEXE 2
CODE SOURCE DE L’APPLICATION WEB

A2.1 Hibernate

voteFokontany.hbm.xml

<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD
3.0//EN"
"http://www.hibernate.org/dtd/hibernate-mapping-3.0.dtd">
<!-- Generated Jan 13, 2018 8:19:57 AM by Hibernate Tools 4.3.1 -->
<hibernate-mapping>
<class name="com.andrana.entity.VoteFokontany" table="vote_fokontany"
schema="public" optimistic-lock="version">
<id name="idVoteFkt" type="int">
<column name="id_vote_fkt" />
<generator class="assigned" />
</id>
<property name="candidatCode" type="java.lang.Integer">
<column name="candidat_code" />
</property>
<property name="fokontanyCode" type="java.lang.Integer">
<column name="fokontany_code" />
</property>
<property name="nbrVote" type="big_decimal">
<column name="nbr_vote" precision="131089" scale="0" />
</property>
</class>
</hibernate-mapping>

A2.2 Entité

VoteFokontany.java

public class VoteFokontany implements java.io.Serializable {

private int idVoteFkt;


private Integer candidatCode;
private Integer fokontanyCode;
private BigDecimal nbrVote;

public VoteFokontany() {
}
}
A2.3 DAO

Vote_fokontany_implement_interface.java

public interface Vote_Fokontany_Implement_Interface {


List<VoteFokontanyPercent> findAll();
List<VoteFokontanyPercent> findWhere(int commune_code);
List<VoteFokontanyPercent> findWinner(int commune_code);

105
Vote_fokontany_implement.java

public class Vote_Fokontany_Implement implements


Vote_Fokontany_Implement_Interface {

@Override
public List<VoteFokontanyPercent> findAll() {
Session session =
NewHibernateUtil.getSessionFactory().openSession();
List<VoteFokontanyPercent> listVote = new ArrayList<>();
Transaction tx = session.beginTransaction();
Query q = session.createSQLQuery("select * from
vote_fokontany_percent ");
List<Object[]> list = (List<Object[]>) q.list();

for (Object[] objects : list) {


VoteFokontanyPercent vfp = new VoteFokontanyPercent();
vfp.setIdFokontany((Integer) objects[1]);
vfp.setFokontany((String) objects[2]);
vfp.setNbrVote((BigDecimal) objects[3]);
vfp.setCandidatCode((Integer) objects[4]);
vfp.setPourcentage((BigDecimal) objects[5]);
vfp.setNom((String) objects[6]);
vfp.setPartiePolitique((String) objects[7]);
vfp.setCouleur((String) objects[8]);
listVote.add(vfp);

}
return listVote;
}
A2.4 Servlet

Fokontany.java

@WebServlet(name = "Fokontany", urlPatterns = {"/Fokontany"})


public class Fokontany extends HttpServlet {

Vote_Fokontany_Implement_Interface voteFokontany = new


Vote_Fokontany_Implement();
Mada_Candidat_Implement_Interface candidatImplement = new
Mada_Candidat_Implement();
Mada_Fokontany_Implement_Interface madaFokontanyImpl = new
Mada_Fokontany_Implement();
Vote_Commune_Implement_Interface voteCommuneImpl = new
Vote_Commune_Implement();

@Override
protected void doGet(HttpServletRequest request, HttpServletResponse
response)
throws ServletException, IOException {
HttpSession session = request.getSession(false);
String id = (String) session.getAttribute("idCommuneClicked");
int idCommune = Integer.parseInt(id);
request.setAttribute("idCommune", idCommune);
request.setAttribute("resultatFokontany",
voteFokontany.findWhere(idCommune));
request.setAttribute("listWinnerFokontany",
voteFokontany.findWinner(idCommune));
request.setAttribute("listCandidat", candidatImplement.findAll());
request.getRequestDispatcher("fokontany.jsp").forward(request, response);
106
}

@Override
protected void doPost(HttpServletRequest request, HttpServletResponse
response)
throws ServletException, IOException {
String fokontany = request.getParameter("idFokontany");
PrintWriter out = response.getWriter();
out.println(fokontany);
HttpSession session = request.getSession(true);
session.setAttribute("idFokontanyClicked", fokontany);
}

107
BIBLIOGRAPHIE

[1] "Collecte de données mobiles", http://www.cartong.org/fr/collecte-de-donn%C3%A9es-


mobiles, Décembre 2017

[2] L. H. Iwaya, “Secure and privacy aware Data collection and processing in mobile health
sytems”, Mai 2016

[3] F. Mancini et S. Gejibo, “Secure Data Collection System for Low-Budget Settings”, 2015

[4] "Principles for digital development", https://digitalprinciples.org/resource/howto-


choose-mobile-data-collection-plaform/., 2016

[5] E. Saterlee, “Paper to mobile : DATA COLLECTION”, US development lab, 2012

[6] D. Shao, “A proposal of a Mobile Health Data Collection and Reporting System for the
developing world”, 2012.

[7] A. Benevis, “Mobile phone data collection and analysis with Open Battery”, Londre,
2013.

[8] "Logic Monitor”, https://www.logicmonitor.com/support/datasources/data-collection-


methods/webpage-httphttps-data-collection/, Décembre 2017

[9] W. Ajinou, “Modélisation du trafic multimédia dans les réseaux mobiles”, Université
Laval Québec, 2008.

[10] G. Fiches et H. Gérard, “Trafic et performance des réseaux de télécoms”, Termes


Science, 2000.

[11] E. Adjarath, “Planification globale des réseaux mobiles de la quatrieme generation”,


Montréal, 2014.

[12] P. Lescuyer, “UMTS : Les origines, l'architecture, la norme”, 2 ed, DUNOD, Paris:,
2002.

[13] “What is GIS”, New York: ESRI, 2012.

108
[14] “SIG”,https://www.esrifrance.fr/sig11.aspx, Novembre 2017

[15] “The New Geographer : Stories of real people geograher using GIS to make a
difference”, New York: ESRI, 2012.

[16] J. Stephan, S. Marc et S. Amadou, “Systèmes d'information Géorgraphique”, EPFL,


2017.

[17] “Fonctionnement du SIG”, http://www.esri.com/what-is-gis/howgisworks, Nov 2017

[18] T. Mitchell, “Web Mapping Illustrated”, O'Reilly, 2005.

[19] L. Yves, “Sécurité”, 2002.

[20] J. Blanc, “Techniques de cryptograhie”, 2004.

[21] J.-F. Bouchaudy, “Linux Administration: Sécuriser un serveur linux”, 2 edition, Eyrolles
,Paris; 2014

[22] R. T. Ezeckiel, “Panorama sur la cryptograhie moderne”, Cours L3 – TCO, Mention


TCO.- E.S.P.A., A.U. : 2014-2015

[23] A. Wurcker, “Etude de la sécurité d’algorithmes de cryptographie embarquée vis-à-vis


des attaques par analyse de la consommation de courant”, 2015.

[24] R. Eckstein, “Java Entreprise Best Practices”, USA: O'reilly, 2003.

[25] "JEE",http://pawlan.com/monica/articles/j2eearch/#thin.

[26] P. Pavliko, “Interactive topographic web mapping using scalable vector graphics,
Nebraska”, Omaha: University of Nebraska, 2003.

[27] "Spatial and Geographic objects for PostgreSQL", https://postgis.net/, 2018.

[28] "Introduction to PostGIS", http://workshops.boundlessgeo.com/postgis-intro/, 2018.

[29] https://www.postgresql.org/, 2018

[30] http://geoserver.org/, 2017

[31] S. Lacovella, “Geoserver beginner's guide”, Packt , Washington, 2013.

109
[32] "Introduction to GeoServer", http://workshops.boundlessgeo.com/geoserver-
intro/overview/index.html#geoserver-overview, 2017.

[33] "WFS", http://docs.geoserver.org/latest/en/user/services/wfs/reference.html, 2017

[34] "Couverture TELMA,", http://www.telma.mg/reseaux/couverture-reseaux/voir-la-


carte.html, 2018

[35] "Couverture Orange" , http://www.orange.mg/extra/couverture.html, Janvier 2018

[36] "Couverture AIRTEL”, http://africa.airtel.com/wps/wcm/connect/africarevamp/Mada


gascar/Home/service-clientele/autres/zone-de-couverture/, Janvier 2018

[37] "Couverture operateur Madagascar," https://www.nperf.com/fr/map/MG/-/-/signal/.

110
FICHE DE RENSEIGNEMENTS

Nom : ANDRIANEKENA

Prénom(s) : Rado Marius

Adresse : Lot 254 Cité 67 Ha Sud

Antananarivo - Madagascar

Mail : rado.marius@gmail.com
Téléphone : +261 34 84 585 38 / +261 32 87 002 48

Titre du mémoire :

COLLECTE DE DONNEES MOBILE SECURISEE


AVEC SIG

Nombres de pages : 100

Nombres de tableaux : 10

Nombre de figures : 60

Directeur de mémoire : RANDRIAMITANTSOA Andry Auguste,

Mail : andriau23@gmail.com,

Téléphone : +261 34 96 638 65

111
RESUME

Ce mémoire traite de l'intégration d'une cartographie Web améliorée et plus flexible avec la
plateforme JEE. Mais pour générer de telles cartes Web, l'ensemble de données correspondant
doit être disponible, et ces données sont fournis par le système de collecte de données mobile.
Par ailleurs, de tels systèmes sont souvent utilisés pour collecter des données sensibles, donc la
sécurité et la confidentialité des données personnelles doivent être systématiquement traités. Ce
document propose des solutions adéquates pour la protection du stockage de données, et le
transfert des données vers le serveur.

Mots clés : MDC, Android, Cryptographie, JEE, Web Mapping

ABSTRACT

This thesis deals with the integration of an improved and flexible web mapping with the JEE
platform. But to generate such web maps, the corresponding data set must be available, and this
data is provided by the mobile data collection system. In addition, such systems are often used
to collect sensitive data, so the security and confidentiality of personal data must be
systematically addressed. This document provides adequate secure solutions for protecting data
storage, and transferring data to the server.

Keywords : MDC, Android, Cryptography, JEE, Web Mapping