La Dematerialisation Des Procedures D'abonnement: Cas de Camtel

REPUBLIQUE DU CAMEROUN REPUBLIC OF CAMEROON
Paix – Travail – Patrie Peace – Work – Fatherland
ECOLE NATIONALE SUPERIEURE NATIONAL ADVANCED SCHOOL OF

DES POSTES ET TELECOMMUNICATIONS POSTS AND TELECOMMUNICATIONS
DIVISION TECHNIQUE DES TECHNICAL TELECOMMUNICATIONS

TELECOMMUNICATIONS DIVISION
LA DEMATERIALISATION DES
PROCEDURES D’ABONNEMENT :
CAS DE CAMTEL
Mémoire de fin d’études
Présenté en vue de l’obtention du Diplôme d’Ingénieur des Télécommunications
Option : Sécurité des Réseaux et Systèmes (SERES)
Par :
TZORNEU NGANSOP Patrick
Matricule : 12T32027
Ingénieur des Travaux en Télécommunications :
Option Informatique et Réseaux
Sous la Direction de :
 Encadreur académique : Dr. Batchakui Bernabé
 Encadreur professionnel : Ing. ABANDA ATAH Serges
Devant le jury constitué de :
 Président : Pr. NDONGO ETIENNE
 Examinateur : Dr. Siaka Francis
 Rapporteur : Dr. Batchakui Bernabé
 INVITE : Ing. ABANDA ATAH Serges
Soutenu publiquement le 18 Février 2017
Année Académique : 2015-2016

Dédicaces
Mémoire d’Ingénieur en Télécommunications, SUP’TIC 2016

Par TZORNEU NGANSOP Patrick ii
Remerciements
Les résultats obtenus à l’issu de nos travaux, ont suscité l’appui, de nombreux conseils et de
nombreuses recommandations de la part de plusieurs personnes à qui nous adressons nos
remercîments les plus sincères. Il s’agit :
 du président de jury Pr. NDONGO Etienne qui a fait l’honneur de le présider;
 de l’examinateur Dr. Siaka Francis pour avoir accepté d’examiner nos travaux ;
 du Dr BATCHAKUI Bernabé pour sa disponibilité et les orientations dans la
direction de nos travaux ;
 de M. ABANDA ATAH Serge, sous-directeur des systèmes d’Informations de
CAMTEL, pour la confiance qu’il a eu pour nous en nous confiant ce thème très
passionnant et tous les accompagnements nécessaires pour pouvoir le réaliser ;
 de l’équipe pédagogique de SUP’TIC pour la qualité de ses enseignements, ses
conseils et le partenariat pédagogique avec SUPCOM, rendant cette formation
encore plus enrichissante.
 de la société CAMTEL pour son accueil chaleureux et son staff très qualifié et
dynamique qui a bien su nous orienter tout au long de notre stage ;
 de ma très chère famille NGANSOP pour son appui moral et financier ;
 de mes camarades de la promotion 2014-2016 au sein de SUP’TIC pour leurs
conseils et soutiens;
 de mes amis dont SOH KAMDJO John, DOUANLA ZEBAZE PAUL
ROMMEL, ASSAMBA Marcelin, NOUWOU Stevia, KUETCHE Platini pour
avoir donné leurs points de vus objectifs vis-à-vis de ces travaux ;
 de toutes les autres de personnes ayant contribué de près ou de loin.

Par TZORNEU NGANSOP Patrick iii
Sigles et Abréviations
Sigle Signification
CAMTEL Cameroon Telecommunication

CNI Carte Nationale d’Identité
EBIOS Expression des Besoins et Identification des Objectifs de Sécurité
EDI Echange de Données Informatisées
E-service Electronic Service
GED Gestion Electronique des Documents
GPS Global Positionning System
GUI Graphical User Interface
HTTP HyperText Transport Protocol
HTTPS HyperText Transport Protocol Secure
IHM Interface Homme Machine
ISMS Information Security Management System
JSF Java Server Faces
MACAO Méthode d’Analyse et de Conception Orientée Objet
MRZ Machine-Readable Zone
MVC Modèle-Vue-Contrôleur
NGBSS Next Generation Business SubSystem
NTP Network Time Protocol

OCR Optical Character Recognition
PDCA Plan-Do-Check-Act
PKCS Public Key Cryptographic Standards
PKI Public Key Infrastructure
POO Programmation Orientée Objet
QR Quick Response
RAD Rapid Application Development
RFC Request For Comments
ROSI Return On Security Investment
RSA Rivest Shamir Adleman
SAN Storage Area Network
SIG Système d’Information Géographique
SMSI Système de Management de la Sécurité de l'Information
SNI Schéma Navigationnel d’Interactions
SOA Service Oriented Architecture
SOAP Simple Object Access Protocol
UML Unified Modeling Language
VPN Virtual Private Network
WSDL Web Services Description Language
XML eXtensible Markup Language

Par TZORNEU NGANSOP Patrick iv
Résumé
CAMTEL rencontre des difficultés dans ses procédures d’installation nécessitant une
intervention chez l’abonné. L’abonné est obligé de se rendre à une agence pour initier ou suivre
son installation. En plus CAMTEL ne supervise pas la chaine d’abonnement en temps réel et a du
mal à assurer la traçabilité des anciens rapports d’installation sous formes papiers.
A cet effet, malgré l’ampleur de la cybercriminalité dans le monde nous recourons à la
dématérialisation pour aider CAMTEL à améliorer ses procédures d’abonnement. C’est pourquoi
nous mettons sur pieds une plateforme web/mobile sécurisée permettant de digitaliser le flot
d’installation chez CAMTEL. Pour arriver à cette fin, nous avons dans un premier temps étudié les
solutions existantes et dans un second temps, nous avons conçu un SMSI pour la gestion du risque
associé à une telle plateforme grâce à la méthode EBIOS. Pour concevoir la plateforme, nous avons
utilisé la méthode RAD et avons profité de l’approche MACAO pour rendre intuitives les interfaces
graphiques. Nous avons ainsi obtenu la plateforme dénommée « CAMTEL ONLINE SERVICE
TOOLS ».
La plateforme réalisée s’interface d’une part d’un portail web composé de deux sous portails
(un portail pour le personnel de CAMTEL et un portail pour les abonnés), et d’autre part elle
s’interface d’une application Android permettant aux personnels : d’accéder en temps réel aux
notifications à chaque étape qu’ils sont sollicités par le workflow ; d’authentifier les documents par
scannage de leurs codes QR et d’authentifier les CNI des abonnés par lecture automatique des
MRZ. La solution intègre aussi la géolocalisation des agences et des installations. L’estimation
financière de la plateforme est de 60 511 500 FCFA en ne considérant seulement les coûts de
développement, de déploiement et de sécurité. Le retour sur investissement de sécurité (ROSI) est
estimé à 108,7% par an et réduit le risque annuel d’environ 20 871 462 FCFA.
L’avantage de cette plateforme est qu’elle va permettre à CAMTEL d’archiver les données
d’installation pendant de très grandes périodes, de mieux traiter, analyser et rechercher les données
d’installations en vue de prendre des décisions stratégiques qui conduiront à l’augmentation du
chiffre d’affaire de l’entreprise. En outre elle renforcera le lien entre les clients et l’entreprise par
des interactions temps réel qu’elle leurs propose en leurs induisant des gains en temps et en argent.
Mots clés : Dématérialisation, Géolocalisation, MRZ, QR, SMSI, Workflow.

Par TZORNEU NGANSOP Patrick v
Abstract
CAMTEL encounters difficulties in its procedures of subscriptions requiring physical

deployment at the subscriber’s home. The subscriber must go to an agency to initiate or follow his
installation. In addition, CAMTEL can’t monitor the process of installing the subscriber in real
time. It’s the same with the traceability of old subscriptions reports wich are in sheets of papers.
That’s why, despite the scale of cybercrimes in the world we used dematerialization to help
CAMTEL improve its subscription procedures. We have done this by designing a secure web /
mobile platform to digitize the installation workflow at CAMTEL. In order to do this, we first
studied existing solutions and then developed an Information Security Management System (ISMS)
using the EBIOS method while designing the platform with the RAD approach. The platform’s
Graphical Users Interfaces are designed to be intuitive by using the MACAO approach.
The platform we have finally created is called "CAMTEL ONLINE SERVICE TOOLS".
It integrates on the one hand a web portal to manage real-time installation flow, divided into two
sub-portals, namely the administration portal and the subscriber portal and on the other hand
interfaces with an Android application enabling the staff to: be notified at each step they are solicited
by the workflow; authenticate documents by scanning their QR codes and authenticating
subscribers' Identity Card by automatically reading the MRZ. Our solution also include
geolocalisation to help both technicians and subscribers. This realization cost about 60 511 500
FCFA while considering only the costs of development, deployment and security. The return on
security investment is estimated at 108.7% per year and avoids an annual loss of approximately
20,871,462 FCFA.
The advantages of this platform are that, it will help CAMTEL to logging installation files
for very long periods; in addition it will bring a gain in efficiency of processing and analysis of
subscription’s data. Moreover, it will strengthen the link between customers and the company
through real-time interactions while saving them time and reducing expenses.
Keywords: Dematerialization, Geolocalisation, ISMS, MRZ, QR, Workflow.

Par TZORNEU NGANSOP Patrick vi
Sommaire
Résumé ....................................................................................................................................................... v
Abstract ...................................................................................................................................................... vi
Sommaire .................................................................................................................................................. vii
Liste des Figures ...................................................................................................................................... viii
Liste des tableaux ....................................................................................................................................... x
1. chapitre1 : Introduction Générale ...................................................................................................... 1
1.1 Contexte.................................................................................................................................... 1
1.2 Problématique ........................................................................................................................... 3
1.3 Objectifs et motivations ............................................................................................................ 4
1.4 Méthodologie ............................................................................................................................ 5
1.5 Plan du travail ........................................................................................................................... 5
2. Chapitre 2 : Etat de l’art .................................................................................................................... 6
2.1 Concepts théoriques .................................................................................................................. 6
2.2 Approches de dématérialisation .............................................................................................. 18
2.3 Notre contribution .................................................................................................................. 19
Bilan du chapitre ................................................................................................................................. 20
3. Chapitre 3 : Conception et Implémentation ..................................................................................... 21
3.1 Description des méthodes de conception et approches de réalisation..................................... 21
3.2 Technologies et Outils utilisés ................................................................................................ 22
3.3 Réalisation du SMSI ............................................................................................................... 27
3.4 Analyse et conception de la plateforme .................................................................................. 38
Bilan du chapitre .................................................................................................................................. 60
4. Chapitre 4 : Résultats et Commentaires .......................................................................................... 61
4.1 Présentation des résultats ........................................................................................................ 61
4.2 Evaluation financière de la solution ...................................................................................... 77
4.3 Limites de la solution ............................................................................................................. 81
Bilan du chapitre .................................................................................................................................. 82
5. Chapitre 5 : Conclusion Générale.................................................................................................... 84
Bilan et Démarche............................................................................................................................... 84
Résultats ............................................................................................................................................... 84
Recommandations ................................................................................................................................ 85
Perspectives ......................................................................................................................................... 85
Références Bibliographiques .................................................................................................................... 86
Annexe ....................................................................................................................................................... xi
Annexe 1 : Présentation de CAMTEL .................................................................................................. xi
Annexe 2: fiche de demande d’installation FTTH ............................................................................. xiii
Annexe 3 : SAN [7] ............................................................................................................................ xiv
Annexe 4 : SOAP [12] ......................................................................................................................... xv

Par TZORNEU NGANSOP Patrick vii
Liste des Figures
FIGURE 1.1 : ARCHITECTURE LOGIQUE DU SYSTEME NGBSS 3
FIGURE 2.1 : LES ETAPES DE LA DEMATERIALISATION 7
FIGURE 2.2 : PRINCIPE DES ALGORITHMES DE CHIFFREMENT ASYMETRIQUES [14] 12
FIGURE 2.3 : PRINCIPE D’UNE FONCTION DE HACHAGE [15] 12
FIGURE 2.4 : GENERATION D’UNE SIGNATURE ELECTRONIQUE [16] 13
FIGURE 2.5 : VERIFICATION DE LA SIGNATURE [16] 14
FIGURE 2.6 : STRUCTURE D’UN CODE QR [17] 16
FIGURE 2.7 : APERÇU DE MRZ [18] 16
FIGURE 2.8 : APERÇU D’UN SIG 17
FIGURE 3.1 : LES PLATEFORMES MOBILES LES PLUS UTILISES DANS LE MONDE [25] 24
FIGURE 3.2 : ARCHITECTURE DE LA PLATEFORME DE DEMATERIALISATION 29
FIGURE 3.3 : PROPOSITION D’UNE ARCHITECTURE SECURISEE DE LA PLATEFORME 37
FIGURE 3.4 : PROCESSUS DE DEMANDE D’INSTALLATION. 38
FIGURE 3.5 : PROCESSUS D’ETUDE DE DEMANDE D’UNE INSTALLATION. 39
FIGURE 3.6 : PROCESSUS D’INSTALLATION. 40
FIGURE 3.7 : DIAGRAMME DE CAS D’UTILISATION DU PROCESSUS DE DEMANDE 41
FIGURE 3.8 : DIAGRAMME DE CAS D’UTILISATION DU PROCESSUS D’ETUDES D’INSTALLATIONS 42
FIGURE 3.9 : DIAGRAMME DE CAS D’UTILISATION DU PROCESSUS D’INSTALLATIONS 43
FIGURE 3.10 : DIAGRAMME DE CAS D’UTILISATION POUR L’ADMINISTRATION DE LA PLATEFORME 44
FIGURE 3.11 : DIAGRAMME DE SEQUENCE DU SCENARIO D’IDENTIFICATION 45
FIGURE 3.12 : DIAGRAMME DE SEQUENCE DE DEMANDE D’UNE INSTALLATION 46
FIGURE 3.13 : DIAGRAMME DE SEQUENCE D’UNE SIGNATURE 48
FIGURE 3.14 : DIAGRAMME DE PAQUETAGE. 49
FIGURE 3.15 : DIAGRAMME DE CLASSES DU MODULE PKI 50
FIGURE 3.16 : DIAGRAMME DE CLASSE DU PAQUETAGE CRUD 51
FIGURE 3.17 : DIAGRAMME DE CLASSES DU MODULE « DEMANDE D’INSTALLATION » 52
FIGURE 3.18 : DIAGRAMME DE PAQUETAGE DU PROCESSUS D’ETUDE D’INSTALLATION. 53
FIGURE 3.19 : DIAGRAMME DE CLASSES DU PAQUETAGE D’INSTALLATION 54
FIGURE 3.20 : DIAGRAMME DE CLASSE DU PAQUETAGE « D’INSTALLATION » 55
FIGURE 3.21 : DIAGRAMME DE CLASSE DU PAQUETAGE DE NOTIFICATION 56
FIGURE 3.22 : PLANCHE SNI POUR LE PORTAIL D’ADMINISTRATION 57
FIGURE 3.23 : PLANCHE SNI DU CSA 57
FIGURE 3.24 : PLANCHE SNI POUR L’ELABORATION D’UNE ETUDE 58
FIGURE 3.25 : PLANCHE SNI DE LA DRIMS 59
FIGURE 3.26 : DIAGRAMME DE DEPLOIEMENT 60
FIGURE 4.1 : SCHEMAS SYNOPTIQUE DE LA PLATEFORME WEB/MOBILE 61

Par TZORNEU NGANSOP Patrick viii
FIGURE 4.2 : ENTETE DU PORTAIL D’ACCUEIL D’ABONNE 62
FIGURE 4.3 : CORPS DE LA PAGE D’ACCUEIL. 63
FIGURE 4.4 : FICHE D’IDENTIFICATION DU CLIENT 63
FIGURE 4.5 : GEOLOCALISATION DES AGENCES 64
FIGURE 4.6 : FORMULAIRE D’AUTHENTIFICATION DE L’ABONNE 64
FIGURE 4.7 : FICHE DE DEMANDE D’INSTALLATION 65
FIGURE 4.8 : VISUALISATION DES DEMANDES EN COURS 66
FIGURE 4.9 : BILAN D’UNE ETUDE POSITIVE 66
FIGURE 4.10 : VERSION PDF DE LA FICHE D’ETUDE 67
FIGURE 4.11 : VISUALISATION DES CONTRATS DE L’ABONNE 67
FIGURE 4.12 : VISUALISATION DES INSTALLATIONS EN COUR DE L’ABONNE 68
FIGURE 4.13 : SIGNATURE D’UN RAPPORT D’INSTALLATION PAR LE CLIENT 68
FIGURE 4.14 : VISUALISATION DES NOTIFICATIONS 68
FIGURE 4.15 : VUES DE GESTION DU PROFIL DE L’ABONNE 69
FIGURE 4.16 : PAGE D’ACCUEIL DU PORTAIL D’ADMINISTRATION 70
FIGURE 4.17 : MENUS DU CSV 70
FIGURE 4.18 : LISTE DES DEMANDES EN COURS POUR TRAITEMENT 71
FIGURE 4.19 : PRE-ETUDE D’UNE DEMANDE 71
FIGURE 4.20 : EXEMPLE DE VISUALISATION DE STATISTIQUES (CAS DE DEMANDES) 72
FIGURE 4.21 : GRAPHE RECAPITULANT LES STATISTIQUES DE DEMANDES 72
FIGURE 4.22 : MENU DE LA DRIMS 72
FIGURE 4.23 : GESTION DES AGENCES 73
FIGURE 4.24 : GESTION DES TYPES D’INSTALLATIONS 73
FIGURE 4.25 : MENU DU GESTIONNAIRE DE PKI 74
FIGURE 4.26 : GESTION DES IDENTIFICATIONS 74
FIGURE 4.27 : GESTION DES CERTIFICATS D’UN ABONNE. 74
FIGURE 4.28 : CARTE D’ABONNEE GENEREE PAR LE GESTIONNAIRE DE PKI. 75
FIGURE 4.29 : ACTIVITE D’ACCUEIL DU MODULE ANDROID 75
FIGURE 4.30 : ACCES AUX NOTIFICATIONS 76
FIGURE 4.31 : AUTHENTIFICATION D’UN DOCUMENT 76
FIGURE 4.32 : AUTHENTIFICATION D’UNE CNI 77

Par TZORNEU NGANSOP Patrick ix
Liste des tableaux
TABLEAU 2.1 : SYNTHESE DES TRAVAUX ANTERIEURS 19
TABLEAU 3.1 : ETUDE COMPARATIVE D’API DE PKI 24
TABLEAU 3.2 : ETUDE COMPARATIVE DES API DE GESTION DES CODES QR 25
TABLEAU 3.3 : ETUDE COMPARATIVE DES OCR 25
TABLEAU 3.4 : ETUDE COMPARATIVE DES SOLUTIONS DE CARTOGRAPHIE WEB 26
TABLEAU 3.5 : ENVIRONNEMENT DE DEVELOPPEMENT ET DE TESTS 27
TABLEAU 3.6 : ELEMENTS ESSENTIELS DU SI 30
TABLEAU 3.7 : RESSOURCES UTILISEES PAR LE SYSTEME CIBLE. 30
TABLEAU 3.8 : MATRICE D’UTILISATION DE RESSOURCES PAR LE SYSTEME CIBLE. 31
TABLEAU 3.9 : ECHELLE DES BESOINS DE SECURITE 31
TABLEAU 3.10 : EXPRESSIONS DES BESOINS DE SECURITE DES ACTIFS DE LA PLATEFORME 32
TABLEAU 3.11 : VULNERABILITES DE LA PLATEFORME 33
TABLEAU 4.1 : COUTS DE DEVELOPPEMENT DE LA PLATEFORME 77
TABLEAU 4.2 : COUT DE DEPLOIEMENT 79
TABLEAU 4.3 : COUTS DE SECURISATION DE LA PLATEFORME 79
TABLEAU 4.4 : PROBABILITE D’OCCURRENCE ET COUT ASSOCIE AUX RISQUES PAR AN 80
TABLEAU 4.5 : ESTIMATION DE LA REDUCTION DU RISQUE AVEC NOTRE SMSI 81

Par TZORNEU NGANSOP Patrick x
INTRODUCTION GENERALE
1. chapitre1 : Introduction Générale
1.1 Contexte
L’expansion des TIC aujourd’hui dans le monde et particulièrement dans le tiers monde, est
une trivialité. Bon nombres d’opérations qui, jadis, nécessitaient le déplacement des personnes et
des biens, se font désormais à distance. Par exemple le e-commerce permet d’acheter des produits
sans se déplacer, le e-learning permet de se former à distance... De nombreuses entreprises doivent
à cet effet s’adapter au nouveau paradigme d’offrir des e-services à leurs clientèles, et de gagner à
la fois du temps et de l’argent. Comme le font remarquer les sociologues, ce paradigme fait
cependant apparaitre un phénomène nouveau : de nos jours, tandis que la clientèle veut éviter de se
déplacer pour accéder aux services, cette dernière veut être informée de l’évolution du traitement
de leurs demandes… Ceci conduit les entreprises à recourir à la dématérialisation. La
dématérialisation d’une manière générale est la transformation des objets physiques en une version
numérique [1]. Elle est un processus ayant pour but de passer de l’utilisation du papier physique
vers celui du papier numérique facilement modifiable. L’un des challenges aujourd’hui auxquels
est confrontée la dématérialisation est la sécurité. La sécurité est une science de gestion du risque
induit par les vulnérabilités, les cyberattaques et leurs impacts sur les organisations. Les critères de
base de la sécurité sont la confidentialité, l’intégrité et la disponibilité. D’après les statistiques de
l’organisme Global State of Information Security pour le compte de l’année 2016, les cyberattaques
sont responsables : de 38,27% des pertes de données des clients , de 16,82% de la perte de la part
de marché, de 25,93% de perte de données internes, de 33,25% de perte des données des employés,
de 21,74% de la baisse de réputation, de 9,61% de sanctions légales [2]. En outre Global State of
Information Security ajoute que 30,5% de ces impacts ont fait perdre aux entreprises par an, entre
zéros dollars et cinquante-mille dollars. Les entreprises comme CAMTEL, conscientes de ces
enjeux (avantages et risques), désirent malgré recourir à la dématérialisation, voie vers laquelle
migrent 66% entreprises dans le monde [3]. Créée par décret présidentiel N°98/198 du 08
septembre 1998, CAMTEL (Cameroon Telecommunication) est l’opérateur historique des
télécommunications au Cameroun. Elle offre une gamme variée de services télécoms, des TIC et
son siège social est situé à Yaoundé (Voir Annexe 1), Avenue du 20 mai. CAMTEL se trouve
depuis 2005 dans une phase de redynamisation ayant pour but d’améliorer sa qualité de service. En
effet, le marché des Télécommunications du Cameroun est ouvert depuis 1998 à la concurrence et
CAMTEL se doit d’être à la hauteur du contexte hyperconcurrentiel imposé par quatre opérateurs

Par TZORNEU NGANSOP Patrick 1
de télécommunication (Orange, Nexttel, MTN, CAMTEL), d’une dizaine de MVNO (Vodafone,

Set Mobile, …) et d’une centaine d’ISP (Yoomee, Matrix, ...). Pour ce faire, elle se doit de
développer et d’offrir des services innovants et de pointe à ses abonnés. Pour réussir cette phase de
redynamisation, elle s’est dotée d’un staff dynamique et qualifié présenté dans l’organigramme en
annexe 1.
Dans certains cas, l’accès à certains services nécessite une installation d’équipements
physiques ; une procédure d’abonnement a été définie à cet effet. Par exemple, pour un abonnement
FTTH, un client est une personne physique ou morale. L’abonnement au service FTTH se fait
généralement en trois étapes :
 premièrement, le client se rend dans une Agence Commerciale Grand Public (ACGP)
muni d’une photocopie de sa carte nationale d’identité, de quatre photos 4x4 et du plan
de localisation de son domicile ou de son entreprise. Par la suite, il est présenté au client
un formulaire à remplir (voir Annexe), à signer et à transmettre au service technique ;
 deuxièmement, le service technique une fois notifié, doit étudier la faisabilité de
l’installation en remplissant une fiche (voir Annexe) pour indiquer les résultats de
l’étude. En cas d’étude favorable, le système NGBSS - (Next Generation Business
SubSystem) prend en compte la facturation et une équipe est déléguée pour mener
l’installation.
 troisièmement, l’équipe procède à l’installation. A la fin de l’installation, ladite équipe
remplit une fiche d’installation. Une fois la fiche d’installation établie, elle devra être
signée par le client, le chef d’équipe d’installation (technicien d’intervention) et le
technicien de configuration.
Le Système « NGBSS » dont l’architecture fonctionnelle est représentée à la figure 1.1 est
le système d’information actuel de CAMTEL chargé d’effectuer : l’acquisition des données
d’installations ; le stockage des données d’installation ; le traitement des données d’installation ;
la restitution qui consiste à présenter à qui de droit l’information traitée dans un format et une
présentation accessible à l’utilisateur (texte, graphique, image, son, vidéo) sur un support
numérique (écran, casque) ou physique (papier).

Figure 1.1 : architecture logique du Système NGBSS

NGBSS dans sa version actuelle, ne permet pas la dématérialisation des procédures, ce qui
ne permet pas d’optimiser le recrutement d’abonnés et d’améliorer l’image de la CAMTEL.
1.2 Problématique
Après l’analyse des procédures actuelles chez CAMTEL, nous avons pu identifier, les
problèmes suivants dans les procédures d’abonnement aux services nécessitant une installation chez
le client :
- les clients doivent être présents physiquement à l’agence pour initier le processus
d’abonnement. Toutefois, les clients se trouvant dans des lieux éloignés des agences doivent
effectuer des efforts considérables ;
- la recherche d’une fiche client n’est pas optimale car on est amené parfois à fouiller une
pile importante lorsque la fiche a été dans à des années très antérieures ;
- l’accès aux dossiers des clients n’est pas sécurisé s’il survient un incendie, toutes les fiches
répertoriées peuvent disparaitre ; dans certains cas, un intrus présent dans une agence peut
dérober ces fiches sous forme de papiers ;
- un client ne peut voir en temps réel l’évolution de son dossier ;
- la signature physique peut facilement être falsifiée ;
- les informations présentes sur la carte d’identité nationale du client sont vérifiées par un
agent commercial qui parfois peut se tromper;
- l’analyse des statiques relatives aux informations est fastidieuse ;
- un client en temps réel ne peut pas observer les différentes opérations de maintenance
effectuées sur sa ligne ;

De l’analyse de toutes ces données, il s’avère que le système actuel ne permet pas à
CAMTEL d’être compétitive. Comment l’optimiser afin de rendre compétitive CAMTEL et
l’adapter à l’environnement hyperconcurrentiel actuel ?
1.3 Objectifs et motivations

Notre objectif général, est de concevoir pour les entreprises, une plateforme sécurisée accessible
via le web et les terminaux mobiles, permettant d’optimiser les processus d’abonnement et leurs suivies
en temps réel. La plateforme doit pouvoir s’adapter aux flots des entreprises parmi lesquelles CAMTEL.
Nos objectifs spécifiques sont les suivants :
 proposer un système simple, intuitif et sécurisé aux clients CAMTEL pour leurs
abonnements (Le portail doit pouvoir être accessible via web ou mobile) ;
 proposer un moyen de suivi du flot d’installation par le personnel de CAMTEL ;
 proposer un système de collecte et d’analyse des statistiques d’installation pour
l’amélioration de la qualité de service rendu ;
 mettre sur pied un Système de Management de la Sécurité du Système d’information de
la plateforme ;
 proposer des mécanismes de signatures électroniques de contrats et de procédures (via
l’utilisation de la certification électronique) ;
 mettre sur pied un système basé sur le scan des codes QR pour l’authentification de
signatures des documents ;
 proposer un système de suivi en temps réel des opérations d’installation ;
 exploiter les techniques d’OCR pour renforcer le processus d’authentification pièces
d’identité du client ;
 géolocaliser les agences et les installations des clients.
Ce projet apportera à CAMTEL plusieurs atouts dont : la performance de traitement et de
suivi des informations d’abonnement [1] ; la pérennité des données d’installations ; le parallélisme
des traitements (le papier numérique peut être consulté instantanément par plusieurs personnes) [4] ;
l’optimisation de la classification et du temps de recherche des fiches et rapports d’installations [5] ;
la traçabilité « versioning » des documents ; la confidentialité et l’intégrité des données sont plus
facile à implémenter avec le papier électronique par l’implémentation de la signature
électronique [5]; l’utilisation des procédures numériques apporterait à une entreprise une
optimisation de gain en temps de recherche d’environ 50%, en efficacité de travail d’environ 30%
à 40% et en terme d’efficience commerciale d’environ 20% [5].

1.4 Méthodologie
Pour le développement de notre plateforme, nous avons adopté la méthode RAD (Rapid
Application Development) car cette procédure est adaptée au projet de délai court [6]. Nous
adoptons la méthode analytique « MACAO » pour la conception de nos IHM en vue de garantir la
facilité d’utilisation de la plateforme. Pour la mise sur pied de notre SMSI nous utilisons la méthode
EBIOS (Expression des Besoins et Identification des Objectifs de Sécurité) car le coût de sa mise
en œuvre est quasiment nul (ne nécessite pas d’outils commercialisés) et sa renommée est sans égale
quand on sait qu’elle est utilisée par des organismes tels que MICHELIN, l’OTAN, la Banque de
Paris [7].
1.5 Plan du travail

Le corps de notre travail se résume en trois chapitres :
 le chapitre 2, présente les concepts généraux qui nous ont conduits à
l’implémentation de la solution ; en outre nous y présentons quelques travaux déjà
effectués dans le même sens que notre projet afin de dégager l’originalité de notre
travail;
 le chapitre 3, présente la mise en œuvre de notre solution ; elle commence par une
sélection des technologies et outils, puis continue par la conception de notre SMSI et
se termine par l’analyse, la conception et l’implémentation de la plateforme.
 le chapitre 4, présente les résultats obtenus et leurs commentaires. Nous présentons
d’abord les différentes vues de ladite plateforme, ensuite nous effectuons une analyse
financière de la plateforme en déterminant les couts de réalisation et de déploiement
sans oublier de déterminer le retour sur investissement de sécurité ; enfin nous
déterminons les limites de notre travail afin de déterminer les travaux ultérieurs en
guise d’amélioration

Etat de l’art
2. Chapitre 2 : Etat de l’art
D
es solutions de dématérialisation faisant appel à plusieurs technologies ont été
proposées du point de vue national et international. Il est alors important
d’apprécier les forces et les faiblesses de ces solutions en vue de mettre sur pieds
une solution innovante pour CAMTEL qui souhaite améliorer sa qualité de service. C’est dans cet
ordre d’idée qu’a été conçu ce chapitre. Mais avant tout, il est nécessaire de s’imprégner de la
théorie des concepts liés à ce sujet.
2.1 Concepts théoriques

2.1.1 La dématérialisation des documents et procédures
2.1.1.1 Définition La Dématérialisation
La dématérialisation d’une manière générale est la transformation des objets physiques en
une version numérique. Elle est un processus ayant pour but de migrer de l’utilisation du papier
physique vers l’utilisation du papier numérique modifiable facilement. Selon l’AFNOR [8], le
papier numérique est un document résultant soit d’un processus de numérisation de l’information
initialement sur papier ou sur papier microforme, soit d’un processus informatique. La
dématérialisation fait appel à d’autres disciplines dont les principales sont la gestion électronique
des documents et la gestion des flots d’informations.
2.1.1.2 La gestion électronique des documents
La gestion électronique de documents (GED) est, l’optimisation, le contrôle, la
supervision du cycle de vie complet des documents électroniques par le biais de ressources
informatiques matérielles et logicielles. Le cycle de vie d’un document électronique quant à lui, est
l’ensemble des opérations effectuées sur ce document de sa naissance à sa destruction, en passant
par sa modification, sa publication, sa diffusion, etc. [5].
2.1.1.3 La gestion des flots d’informations (Workflow)
Un workflow est un flux d'informations au sein d'une organisation. C’est une gestion
optimisée des flux et du traitement de l'information entre les acteurs d’un système [9]. Un workflow
vise d’une part à optimiser et à aiguiller le flux d’information entre les acteurs du processus métier ;
d’autre part il est pour l’utilisateur un guide dans son travail, car il lui permet d’attribuer et de
suivre les différentes tâches passées et à venir sur un flux. Les avantages du workflow sont

Etat de l’art
implicitement titrés dans sa définition pourtant son inconvénient provient du fait que ses utilisateurs
le perçoivent comme un moyen de surveillance [5]. Le workflow induit à la dématérialisation
l’élaboration en plusieurs étapes.
2.1.1.4 Les étapes de la dématérialisation [4]
la dématérialisation commence d’abord par l’acquisition numérique du document qui fait
typiquement intervenir un scanner, mais aussi des outils de reconnaissance de champs et de
caractères (typographiques et manuscrits), notamment pour la prise en compte de formulaires ;
ensuite l'archivage des documents au sein d'une base de données qui peut être effectué par des
interventions manuelles ou partiellement automatisées en s'appuyant sur les solutions de RAD
(Reconnaissance Automatique de Documents) ou de gestion des connaissances tels que les moteurs
de catégorisation et de classement ; enfin la transmission et l'évolution du document qui passent par
la mise en œuvre d'un outil de workflow: il orchestre l'ensemble des grandes étapes de la vie d'un
document numérisé. Le processus de dématérialisation exporte les données sous plusieurs formes :
papiers, formats numériques, SMS, synthèses vocales, etc. Nous avons monté la figure 2.1 en guise
de résumé des étapes de la dématérialisation.
Figure 2.1 : les étapes de la dématérialisation

2.1.1.5 Les avantages et les défis de la dématérialisation des documents et procédures
La dématérialisation des documents et de procédures présente plusieurs avantages. Entre
autres nous pouvons recenser [1] :
 du point de vue organisationnel elle apporte la diminution du nombre de litiges, le
gain en productivité, la fluidification et un meilleur contrôle du processus métier,
l’amélioration des délais de livraison ;
 du point de vue financier elle permet la diminution des coûts de traitement des
documents, l’amélioration des flux de trésorerie, la réduction des délais de

Etat de l’art
recouvrement, la fiabilisation de la chaîne financière et la diminution des coûts de

stockage et archivage papier ;
 du point de vue temps elle induit la diminution des temps d’échange, de saisie, de
circulation des documents, la réactivité, le fonctionnement en temps réel, diminution
des frais postaux ;
 du point de vue image elle implique l’augmentation de la valeur ajoutée des tâches
proposées aux collaborateurs, l’amélioration de la satisfaction relation client,
l’amélioration de la satisfaction relation fournisseur ;
 du point de vue sécurité elle apporte une traçabilité accrue, la sécurisation des
échanges, la conformité avec les obligations.
Cependant, les murs auxquels se confronte la dématérialisation sont la sécurité, les moyens
technologiques et les utilisateurs [9]. Les autres défis à relever par la dématérialisation sont les
moyens d’acquisition de l’information numérique parmi lesquels, la reconnaissance optique des
caractères.
2.1.1.6 La reconnaissance optique de caractères
La reconnaissance optique de caractère (OCR) est une branche de l’orthotypographie1 .
Comme son nom l’indique, cette discipline a pour principal but d’extraire du texte contenu dans
une image. Ces images résultent le plus souvent des documents physiques scannés ou
photographiés. L’un des plus gros projets dans le domaine des OCR a été lancé par la bibliothèque
nationale de France [10]. L’OCR dispose deux modes. Le mode « hors ligne » permet de
reconnaitre un texte préalablement écrit. Tandis que le mode « en ligne » ou encore temps réel
reconnait le tracé du texte et la nature du stylo (souris, stylo numérique, tablette tactile) utilisé.
Les notions de dématérialisation, d’applications et de services électroniques sont
étroitement liées. Plus généralement une entreprise pour communiquer avec ses partenaires ou ses
clients utilisent des e-services.
2.1.2 Les E-services et leur sécurité

2.1.2.1 E-services
Un E-service diminutif de « Electronic –service » est une application indépendante et
modulaire accessible via Internet, qui assure une fonction utile à ses utilisateurs (personnes,
1
L’orthotypographie est l’art d’écrire correctement une langue tant au plan de la grammaire que de sa
forme graphique (imprimerie, manuscrits…) et notamment ce qui relève du code typographique.

Etat de l’art
entreprises ou autres e-service). Un E-service est mis sur pieds par une entité (fournisseur ou
service provider) et est destiné à plusieurs entités (consommateurs ou e-service requester). L’organe
de communication entre un fournisseur et un consommateur s’appelle le courtier (e-service broker).
Pour consommer un e-service, l’utilisateur négocie un contrat de QoS avec le courtier appelé (SLA
ou Service Level Assurance), puis le courtier recherche le service approprié grâce à un annuaire
appelé registre.
La classification d’un e-service se fait soit :
 selon l’atomicité, un e-service composite est un ensemble de e-services basiques qui, eux-
mêmes sont non décomposables ;
 selon le type des acteurs qui interviennent, les e-services Business-to-Business(B2B)
prestation de services entre entreprises ; les e-services Business-to-Costumer(B2C)
prestation de services entreprises vers particuliers (les variantes du B2C sont le E-commerce
appelé commerce électronique et le M-Commerce appelé commerce mobile ) ; les e-services
Government-to-Business(G2B) prestation de services entre gouvernement et entreprises ;
les e-services Government-to- Citizen (G2B) prestation de services entre gouvernement
et citoyens ;
Les E-services présentent trois principaux avantages :
 l’interopérabilité : Les E-services sont créés avec des divers langages de
programmation mais sont publiés sous des formats standards. A cet effet, Les
entreprises ayant des architectures informatiques différentes, peuvent communiquer
via des E-services. L’un des protocoles les plus connus de publication des web services
est le WSDL (Web Services Description Language) via lequel les échanges de
messages se font avec le protocole SOAP (voir annexe).
 l’intégration et collaboration (temps réel): Avant l’arrivée des E-services, les
entreprises orientaient leurs systèmes d’informations autour de nombreuses
applications qui communiquaient de manière croisée. Le nombre de liens entre les
applications explosait avec l’augmentation des applications à tel point qu’il était
difficile d’insérer ou de retrancher une application dans l’architecture. On parlait alors
d’ « architecture en spaghetti » [11]. Aujourd’hui, les E-services couplés au concept
d’architecture orientée service (SOA) ont permis de rendre moins complexe les
architectures de systèmes d’informations.
 l’encapsulation : le principe de l’encapsulation est de percevoir le E-service comme
une boite noire possédant des entrées, une fonction utile et des sorties. Ce gros avantage

Etat de l’art
permet de substituer facilement un E-service par un autre dans l’architecture du SI et

permet également d’assurer la pérennité des E-services composites dépendant des E-
services basiques de fournisseurs différents.
Un E-service possède un cycle de vie [12] qui commence par l’idée de le créer
(initialisation), puis vient sa création (description) après quoi son exposition au grand public
(publication). Par la suite les utilisateurs viendront auprès du courtier qui leur fera savoir qu’un tel
E-service existe, on parle alors de « découverte ». Après la phase de découverte, vient celle
d’ « invocation », car les utilisateurs étant séduits par le E-service l’implore pour sa fonction
d’utilité. Enfin, l’E-service étant délaissé par ses consommateurs ou par ses fournisseurs sera tout
simplement mis hors services : c’est le « retrait » de l’E-service. Ce retrait peut être anticipé par un
incident. Durant les phases de « publication », de « découverte » ou « d’invocation » notre E-
service est vulnérable car est exposé aux consommateurs. A cet effet comment assurer la sécurité
d’un E-service.
2.1.2.2 Les services de sécurité de bases pour un E-service
La sécurité [12] de manière générale pour un système est la gestion du risque qui lui est
associé. Le risque est une fonction de vulnérabilité, de menaces, d’attaques, d’impacts et de contre-
mesures. Une vulnérabilité [12] est un point faible dans une application, un produit ou une ressource
rendant infaisable, voire impossible de contrecarrer une attaque si celle-ci survient ; une menace
pour un système est une action dont la réalisation peut être nuisible (néfaste) pour ce système, tandis
qu’une attaque pour un système est la concrétisation d’une menace vis-à-vis de celui-ci. L’impact
désigne les dégâts susceptibles d’être observés après des attaques tandis que les contre-mesures
sont des précautions prises pour éviter des menaces.
A cet effet sécuriser, un e-service revient à optimiser les risques jusqu’à un certain niveau
acceptable appelé niveau de sécurité. Les besoins élémentaires en sécurité d’un e-service sont :
 l’authentification, qui assure que les entités qui communiquent sont bien celles prétendent
être ;
 l’intégrité des données, qui garantit que les données échangées ne sont modifiées
uniquement par les ayant-droits ;
 la confidentialité des données qui garantit que seules les entités autorisées ne peuvent lire
certaines données ;
 la non-répudiation qui veut que les entités ayant effectué de transactions ne doivent en
aucun cas nier leurs responsabilités dans la transaction ;

Etat de l’art
 la fiabilité qui est la capacité d’un e-service(ou celle de ses sous e-services) à exécuter ses
fonctions et d’inter-opérer avec le courtier ou le demandeur sous des ‘conditions fixées’ à
l’avance et durant une certaine période de temps ;
 l’anonymat qui garantit que ni le demandeur, ni le fournisseur ne doit en aucun cas avoir
son identité divulgué après une transaction ;
 le respect de la vie privée qui garantit que les données personnelles de l’utilisateur ne
doivent pas être utilisées à d’autres fins que celles spécifier pendant la négociation du
service.
La sécurité étant la gestion du risque nécessite alors un système de gestion.
2.1.2.3 Système de gestion de la sécurité de l’information
Un système de gestion de la sécurité de l'information (en anglais : Information security
management system, ou ISMS) est, comme son nom le suggère, un système de gestion concernant
la sécurité de l'information. Cette expression désigne un ensemble de politiques concernant la
gestion de la sécurité de l’information [13] . Un SMSI doit mettre sur pied une politique de sécurité
qui est un ensemble de moyens et de stratégies (règles) que l’entreprise met sur pied pour maintenir
le risque associé à son SI au plus bas niveau possible. Un SMSI doit être efficace et efficient sur le
long terme, c’est-à-dire pouvoir s’adapter aux changements qui ont lieu dans l’environnement
interne et externe.
L’un des plus gros challenges dans la sécurité des SI est celle d’établir un système de
confiance entre l’entreprise prestataire de service et sa clientèle. L’un comme l’autre se méfie du
correspondant se trouvant de l’autre côté du nuage qu’est Internet. C’est pourquoi l’on fait appel à
la certification électronique.
2.1.3 Signature électronique et la certification électronique

2.1.3.1 Signature électronique et horodatage
2.1.3.1.1 Algorithmes asymétriques
Un couple de clefs numériques (couple de grands entiers) est construit de manière à ce que
le cryptogramme (texte chiffré) généré à partir d’un texte en clair et l’une des clefs ne puisse être
aisément retrouvé qu’avec l’autre clef [14]. En pratique, l’une des clefs est conservée secrètement
(clef privée), tandis que l’autre est diffusée publiquement (clef publique) dans un annuaire. Seul le
propriétaire d’une clef privée (Bob dans notre exemple) peut déchiffrer un texte chiffré avec la clef
publique associée (figure 2.2). Comme exemple nous avons les algorithmes RSA et ELGAMAL.

Etat de l’art
Figure 2.2 : principe des algorithmes de chiffrement asymétriques [14]
2.1.3.1.2 Les fonctions de hachages

Comme illustrée à la figure 2.3, une fonction de hachage est une application qui transforme
une chaîne de taille quelconque en une chaîne de taille fixe [14]. L’empreinte de taille fixe obtenue
après hachage s’appelle « Hash » ou « scelle », « condensat », ou encore « digest ». Une fonction
de hachage doit satisfaire les conditions suivantes [14] : la résistance à la pré-image (étant donné
une empreinte, il est difficile de trouver en temps raisonnable le message original), la résistance à
la seconde pré-image (étant donné un message, il doit être difficile de trouver en temps raisonnable,
un autre message différent tel que leurs empreintes soient identiques) et la résistance aux collisions
(il doit être difficile de trouver en temps raisonnable deux messages différents ayant les mêmes
empreintes). Par ces trois critères, on parvient à donner la fonction de hachage, le rôle de
vérificateur d’intégrité de message puisqu’une fois les données modifiées, leurs empreintes sont
immédiatement affectées.
Figure 2.3 : Principe d’une fonction de hachage [15]

Etat de l’art
Comme exemple de fonctions de hachages, nous distinguons : MD5 (Message Digest

version 5) qui manipule des blocs de 512 bits et génère une empreinte de 128 bits ; SHA2 (Secure
Hash Algorithme version 2) développée conjointement par la NSA et le NIST. Il travaille sur des
blocs de 512 bits et produit des empreintes de 160 bits. SHA est basé sur MD4 et est réputé plus
sûr que MD5 [15].
2.1.3.1.3 Principe de la signature électronique et exemples
La norme ISO 7498-2 définit la signature électronique comme des « données ajoutées à
une unité de données, ou transformation cryptographique d’une unité de données, permettant à un
destinataire de prouver la source et l’intégrité de l’unité de données et protégeant contre la
contrefaçon. La signature électronique est possible par la combinaison de fonctions de hachages et
des algorithmes de chiffrement asymétrique. La signature de la donnée (figure 2.4) se fait d’une
part par le calcul de l’empreinte via une fonction de hachage, et d’autre part, le hash obtenu est
chiffré avec la clé privée du signataire suivant un algorithme asymétrique. Le cryptogramme
obtenue est la signature de la donnée ;
Figure 2.4 : génération d’une signature électronique [16]

Pour vérifier une signature (Figure 2.5), il faut avoir la donnée originale ainsi que sa
signature. La signature est déchiffrée en utilisant l’algorithme inverse du chiffrement muni de la clé
publique du signataire ; puis le hash de la donnée est à nouveau calculé et comparé à la valeur de la
signature déchiffrée. Si les deux valeurs sont égales, la signature est valide sinon soit la donnée a
été modifiée, soit son signataire n’est pas celui qu’il prétend être.

Etat de l’art
Figure 2.5 : Vérification de la signature [16]
La signature électronique d’une donnée, n’étant pas liées au temps, peut être réutilisée par
des malintentionnés. A cet effet, comment lier une signature à une date ?
2.1.3.1.4 Horodatage
L’horodatage est un mécanisme qui consiste à lier une signature à une date dans le but
d’empêcher la réutilisation de la signature à une autre date. Elle donne alors la possibilité d’effectuer
des contrats dans le monde numérique. Tout comme la signature électronique, elle possède deux
phases ; la seule différence est qu’après le calcul du hash de la donnée originale, on y ajoute la date
de signature avant le chiffrement par la clé privée du signataire. A cet effet, la vérification d’une
signature horodatée nécessite le paramètre date de signature. Avec l’horodatage et la signature
électronique on parvient à prouver alors qu’une donnée a été signée par une clé privée donnée à
une date donnée. Mais comment garantir que la clé publique que nous possédons pour vérifier la
signature est bien celle du signataire ?
2.1.3.2 Certification électronique

2.1.3.2.1 Définitions
La certification électronique est un mécanisme qui vise via l’utilisation des certificats
l’authentification d’une clé publique. Elle permet aux entités d’une transaction de s’authentifier
mutuellement. Un Certificat est structure de donnée permettant de lier une clé publique à
différents éléments au moyen de la signature d’une autorité de certification (Certificate Authority –
CA). Il possède au moins les informations suivantes : le nom du propriétaire de la clé, la date de
validité, le type d’utilisation autorisée. La norme couramment utilisée pour représenter et décrire le
contenu d’un certificat est la recommandation ITU X.509 [14]. Aujourd’hui cette norme est à sa

Etat de l’art
version 3 après avoir commencé à la version 1 et transiter vers la version 2. Le nombre de clés
publiques est souvent très important à gérer pour un utilisateur. C’est pourquoi l’on fait appel à une
infrastructure à clef publique.
2.1.3.2.2 Infrastructure à clef publique
Une Infrastructure à clef publique (Public Key Infrastructure, PKI) ou encore un tiers
de confiance est un système de gestion des clefs publiques prévus pour une utilisation à grande
échelle. Les entités fonctionnelles d’une PKI sont [16]:
 l’autorité de certification est chargée de signer les certificats, à la demande de
l’autorité d’enregistrement, et de publier les certificats dans un annuaire ;
 l’autorité d’enregistrement contrôle les demandes de certificats et les accorde ou non
suivant une politique de certification précisée par l’organisme qui la gère. L’autorité
d’enregistrement peut annuler des certificats qu’elle a créées ;
 le demandeur est la personne désirant faire certifier ses données d’identité et sa clé
publique auprès de l’autorité d’enregistrement ;
 l’annuaire est une base de données servant à contenir notamment les certificats générés
par l’autorité de certification ainsi que des listes d’annulation ;
 le vérificateur de certificats est une fonction chargée de valider un certificat qui lui
est présenté, en vérifiant notamment la signature de l’autorité émettrice et le fichage
possible du certificat dans une liste noire (CRL, Certificate Revocation List) ;
Les clefs de cryptographie, les signatures électroniques et les certificats
électroniques ont besoin de représentations simples; pour ce faire, des formats et codes sont
proposés.
2.1.3.3 Les PKCS, Les Codes QR et MRZ
2.1.3.3.1 Les PKCS
Les PKCS (Public Key Cryptographic Standards), ou standards de cryptographie à clé
publique, sont un ensemble de spécifications conçues par les laboratoires RSA en Californie [15].
Deux PKCS retiennent notre attention. Il s’agit notamment du PKCS#7 et du PKCS#12. Le
PCKCS#7 (Cf. RFC 2315) est utilisé pour signer et/ou chiffrer des messages dans le cadre d'une
infrastructure à clé publique [15] .Il sert également à la transmission de certificats. Le PKCS#12
quant à lui définit un format de fichier généralement utilisé pour stocker la clé privée et le certificat
de clé publique correspondant en les protégeant par un mot de passe.

Etat de l’art
2.1.3.3.2 Les codes QR et MRZ

Un code QR (Quick Response) est une image en 2 dimensions qui permet de coder un texte sur
une très petite surface. Pour décoder la chaine de caractère encodée, il suffit d’un scanner de code
QR. Le scanner prend en paramètre l’image du code QR et renvoie en retour le texte correspondant.
Ce scanner peut être embarqué dans un Smartphone ou être disponible sous forme de e-services.
La figure 2.6 présente la structure d’un code QR.
Figure 2.6 : Structure d’un code QR [17]

Il existe 40 versions de code QR en fonction de leurs résolutions, de la version 1 (21x21) à
la version 40 (177x177). Les scanneurs embarqués des smartphones ne peuvent supporter des
versions au-delà de la version 10. Ceci est dû à la faible résolution des caméras embarquées.
2.1.3.3.3 MRZ
Une zone de lecture automatique, ou zone de lecture optique (en anglais Machine-
Readable Zone, MRZ) est une zone sur un document officiel, réservée à la lecture, à l'identification
et à la validation de ce document [18]. Généralement, il s’agit d’une chaine de caractères
alphanumériques s’étalant sur deux à trois lignes et contenant des champs séparés par une suite de
symbole « < ». La figure 2.7 présente un exemple de MRZ sur une carte d’identité.
Figure 2.7 : Aperçu de MRZ [18]
Il se dégage alors que la signature et la certification électronique renforcent le lien de

confiance entre deux entités effectuant des échanges dans le monde numérique. Mais le plus

Etat de l’art
souvent, les clients préfèrent se rendre physiquement chez leurs fournisseurs et ont alors besoin
d’un guide pour leurs renseigner de la situation géographique de ce fournisseur.
2.1.4 Les Systèmes d’Informations géographiques

2.1.4.1 Définition
Un SIG (Système d’Information Géographique) est un système informatique permettant à
partir de diverses sources de rassembler, d’organiser, de gérer, d’analyser, de combiner, d’élaborer
et de présenter des structures de l’information géographique. Les domaines d’applications des SIG
sont aussi nombreux que variés. Il permet entre autre : d’établir les cartographies rapides ; fournir
des itinéraires, des plans adoptés ; de gérer unes multiplicités d’informations attributaires sur des
objets ; etc. La figure 2.8 est un aperçu d’un SIG [19].
Figure 2.8 : aperçu d’un SIG [19]

Il existe deux modes de représentation graphique de données dans un SIG : le mode Raster
et le mode Vectoriel. Les Rasters sont de simples photographies composées d’unité élémentaires
appelées pixels tandis que les images vectorielles sont composées d’un ensemble de points
composés chacun de coordonnées géographiques qui servent à les repérer à la surface de la Terre.
Une coordonnée géographique est caractérisée par sa latitude (mesure de l’arc du méridien passant
par ce point, compris entre l’équateur et la Parallèle de ce point), sa longitude (mesure de l’arc de
l’équateur entre le méridien qui traverse ce point et le méridien d’origine) et son altitude qui est la
hauteur entre ce point et le niveau de la mer. Une Carte géographique est la représentation d’un
espace géographique qui met en valeur l’étendu de cet espace, sa localisation relative par rapport
aux espaces voisins, ainsi que la localisation des éléments qu’il contient. Pour élaborer, un SIG nous
avons besoin de sources de données fiables. Les différentes sources de données sont : les prises
d’images satellitaires, les missions aériennes, les images prises par des drones, les levées
topographiques, les cartes (donnée Raster), l’utilisation du GPS, etc.

Etat de l’art
2.1.4.2 Le GPS [19]

GPS (GLOBAL POSITIONNING SYSTEM) est un système qui donne les informations sur
le temps, la position et la vitesse de n’ importe quel objet disposant d’un récepteur approprié, n’
importe où et n’importe quand sur la surface de la terre. Le système GPS comprend au moins 24
satellites évoluant dans l’orbite terrestre à une altitude de 20000 kilomètres environ. Ils fonctionnent
par triangulation et permettent de déterminer facilement une localisation. Trois satellites envoyant
simultanément des signaux au récepteur. Le récepteur déduit sa position à partir des signaux tout
en corrigeant l’erreur grâce à un quatrième satellite. Au sol, les appareils de géolocalisation GPS
comme on trouve dans les automobiles ou les Smartphones ont des antennes qui captent des signaux,
un récepteur GPS note l’heure à laquelle le signal a été émis et en déduit le temps mis pour accomplir
ce trajet. Les ondes radio se propagent à la vitesse de la lumière, on peut donc en déduire la distance
au satellite.
2.2 Approches de dématérialisation

De nombreux travaux réalisés à travers le monde attirent notre attention dans le cadre de la
réalisation de ce travail. Quelques-uns ont été étudiés à cause de leur forte corrélation avec notre
sujet. Il s’agit des travaux suivants :
 MAKAM LONLA [19] a travaillé sur la mise en place d’une plateforme de signature et de
notariat numérique. Ses travaux ont abouti à la mise sur pied de la plateforme nommée
« ConfianceOnline », pouvant être déployée dans un réseau local d’entreprise ou utilisée par
un tiers sous forme d’un e-service. Les utilisateurs de la dite plateforme peuvent obtenir des
certificats et des clefs (après demandes) qui leurs permettront de signer des documents
numériques. Un code QR est généré puis placé sur ce document comme matérialisation de la
signature électronique. Un processus de scannage via Smartphone est utilisé pour authentifier
la signature du document. Ce système exploite la puissance des SIG ;
 DJOMO TCHONANG A [9] a travaillé sur la mise sur pied d’une plateforme de GED au sein
de CAMTEL par la réalisation de la plateforme « GedTel » focalisée sur l’archivage des
documents électroniques. En outre une politique de signature électronique ainsi qu’une politique
d’archivage ont été mises en œuvre. Cependant sa solution est limitée à CAMTEL et n’exploite
pas les performances des SIG ;
 OPHELIE Julian [4] a travaillé sur la la mise en place de la dématérialisation des dossiers
du personnel dans les établissements publics et privés français. la dématérialisation des
dossiers des personnels ont été mis en avant à travers le scanneur à employer, la GED, le

Etat de l’art
système d’archivage électronique, la signature électronique et le coffre-fort numérique. Le

scanneur et la GED sont le point de départ dans la création et la gestion des pièces du dossier
au format numérique. En outre, cette solution recommande juste un ensemble d’outils et
peut cependant s’adapter à toute entreprise sans prendre en compte le workflow de
l’organisation.
Aucunes études poussées n’ont été faites sur la gestion des risques associés aux systèmes
proposés dans ces travaux cités. En plus ces travaux ne prennent pas en compte le workflow des
organisations et n’adoptent aucunes démarches analytiques pour la conception des IHM
intuitives. Nous pouvons résumer ces travaux par la table 2.1. La première ligne présente les
travaux tandis que la première colonne présente les critères de comparaison. Le « rond » dans
une cellule indique que le travail correspondant implémente le critère courant. Dans le cas
contraire il s’agit d’un manquement.
Tableau 2.1 : synthèse des travaux antérieurs

MAKAM LONLA [19] DJOMO TCHONANG A [9] OPHELIE Julian [4]
Coffre-fort
numérique
GED
Workflow
SIG
Certification
électronique
QR
OCR
Méthode
analytique de
conception d’IHM
2.3 Notre contribution

Puisque la plupart des solutions de dématérialisation proposées à la section précédente
implémente des solutions de GED, de certification électronique et de coffre-fort numérique, nous

Etat de l’art
le ferons également. Nous utiliserons également les codes QR et les technologies OCR bien qu’ils
soient implémentés par quelques-unes de ces solutions.
La valeur ajoutée de notre travail, est de proposer un système qui s’adapte aux workflows
d’abonnements dans des organisations en prenant comme organisation de test CAMTEL.
Egalement nous devons proposer un système plus intuitif grâce à une étude analytique des IHM via
la méthode MACAO. Un autre avantage de notre système est qu’une étude des risques doit être
mise en œuvre par la méthode EBIOS en vue de recommander un SMSI pour maintenir le risque à
un bas niveau.
Bilan du chapitre
Nous avons présenté dans ce chapitre les concepts liés à la dématérialisation des procédures
et traitements. En outre nous avons cité quelques travaux allant dans le même sens que le nôtre. Il
en ressort que les coffres forts électroniques, la signature électronique, la GED, les OCR et les SIG
sont nos points communs avec les systèmes étudiés. Mais en dépit de cela, nous ajoutons d’une
part un SMSI pour la minimisation du risque et d’autre part nous utilisons une approche analytique
pour la conception des interfaces graphiques en vue de rendre la plateforme plus facile à exploiter.
L’implémentation fait au chapitre suivant s’oriente vers cette spécification.

Conception et Implémentation
3. Chapitre 3 : Conception et Implémentation
L
a conception des logiciels nécessite une démarche orientée résultat et qualité. Faire
la qualité et non contrôler la qualité est l’objectif du génie logiciel. En outre, il faut
sécuriser la plateforme que nous allons mettre sur pieds ; cela implique cette fois,
de mettre sur pieds un SMSI. Par ailleurs, le choix des outils et des technologies de réalisation de
notre plateforme doit être mené avec beaucoup d’objectivités en vue de garantir l’efficience, la
portabilité, l’extensibilité, la robustesse, la modularité, la réutilisation, la fiabilité, la compatibilité
avec d’autres systèmes existants ou à venir (par exemple NGBSS) et la facilité exploitation de la
plateforme à réaliser.
3.1 Description des méthodes de conception et approches de réalisation.

3.1.1 Méthodes de conception
Comme mentionnée à l’introduction générale, la méthode EBIOS nous permet de mettre sur
pieds notre SMSI. Nous l’avons utilisée parce qu’elle est française et ouverte. Cette méthode se fait
en six étapes : l’étude du contexte, l’expression des besoins de sécurité, l’étude des menaces,
l’identification des objectifs de sécurité et la détermination des exigences de sécurité [7]. Pour
recommander des solutions à la fin d’étude, nous utiliserons le guide ISO/CEI 17799 :2005 [7].
Pour concevoir la plateforme, deux méthodes seront utilisées :
 La méthode RAD pour l’initialisation, le cadrage (analyse des besoins), le design (la
conception), la construction (la réalisation) et la finalisation (recette et déploiement) [20].
Le choix porté à la méthode RAD se justifie par le fait qu’elle est semi-itérative, adaptée au
projet de délai court et fait intervenir une équipe de petite taille appelée SWAT [6].
 La méthode MACAO nous servira juste de concevoir des IHM intuitives via des modèle
SNI (Schéma Navigationnel d’Interactions), tirant leurs sources des modèles de
diagrammes de classes et de cas d’utilisations UML2.0. Nous avons choisi cette méthode
parce que contrairement aux autres méthodes de conception d’IHM qui utilisent des
approches normatives et statiques, elle propose une démarche analytique et dynamique ; en
outre elle puise ses sources des diagrammes UML [21].

3.1.2 Approches de réalisation

Nous utilisons une approche orientée service (SOA) pour le développement des modules car
cette approche tend à réduire les impacts liés aux évolutions du processus et garantira la
compatibilité avec d’autres systèmes [11]. La logique de programmation sera orientée objet (POO).
Un service sera un ensemble d’objets inter communicant. La POO offre les avantages suivants : la
modularité, la réutilisabilité, l’extensibilité, la portabilité, l’efficience, la maintenabilité et
bien d’autres atouts, [21].
Les codes sources seront organisés suivant le modèle MVC: le modèle est l’ensemble des
données des services (Base des données et fichiers divers), la vue est la présentation des
informations à l’utilisateur (affichages, saisies), le contrôleur représente les commandes de
l’utilisateur et traitement des événements. Les architectures MVC se développent avec des
Framework. Littéralement, un Framework est un « cadre de travail » [22]. Concrètement, c'est un
ensemble de composants qui servent à créer les fondations, l'architecture et les grandes lignes d'un
logiciel.
3.2 Technologies et Outils utilisés

3.2.1 Outils de modélisation
Pour la modélisation UML, nous choisissons Enterprise Architect. En effet, Enterprise
Architect créé par l’entreprise « SPARX »est un Atelier de génie logiciel (outil de conception
d’autres logiciels) bien adapté à UML 2.0 qui bien qu’étant payant propose des versions d’essai.
En ce qui concerne la modélisation des IHM avec MACAO, nous utilisons VisualSNI qui
est pour le moment le seul outil adapté [23]. VisualSNI est un plugin2 Eclipse Open Source
permettant de créer des SNI conformes aux spécifications de la méthode MACAO.
3.2.2 Technologies et Langages de programmation

3.2.2.1 Cas des modules web/Mobile
3.2.2.1.1 Langages de programmation
Pour la réalisation de la plateforme web/mobile nous utilisons les langages de
programmation suivants :
2
Eclipse est un logiciel extensible dont les extensions sont appelées plugins

 le langage Java car il est utilisé chez CAMTEL pour le développement des services.
Java est un langage de programmation orienté objet caractérisé par sa fiabilité, sa
Sécurité, sa simplicité, sa portabilité, son architecture neutre. Dans notre cas, le
Langage Java est utilisé côté serveur d’application ;
 le langage HTML5 ; HTML est le langage permettant de créer des pages du web. Dans
sa version 5, il apporte le concept d’interface « responsive » ou encore adaptative, car
le rendu des pages HTML5 s’adapte en fonction du type de terminal (tablette, PC,
console de jeux, etc.) utilisé.
 CSS3 ; CSS a pour objectif principal de séparer le contenu de la page de son apparence
visuelle ; CSS3 version 3 de CSS vient en accompagnateur de HTML5 ;
 JavaScript est un langage de programmation de scripts principalement utilisé pour les
pages web interactives comme les pages HTML. JavaScript est exécuté sur l’ordinateur
de l'internaute par le navigateur lui-même. Il permet d’alléger les opérations de
vérification des formulaires qui autre fois étaient délaissées à l’application serveur.
3.2.2.1.2 Nos Frameworks
Comme nous l’avons mentionné, le développement suivant le modèle MVC nécessite un
outil appelé Framework. Ayant choisi le langage Java comme langage de programmation côté
serveur, il nous faut donc un Framework Java comme JSF car il est le plus récent et le mieux
recommandé par la communauté Java [24].
Bootstrap est un Framework pour le développement des vues du web en utilisant JavaScript,
HTML et CSS. Il permet de développer rapidement les interfaces ergonomiques pour le web. Pour
éviter d’utiliser JavaScript (car n’est pas assez portable), nous utilisons JQuery dont l’objectif
est de rendre plus portable le JavaScript, en l’orientant sous forme de Framework [22].
3.2.2.2 Choix de de la plateforme Mobile pour le système de géolocalisation, de reconnaissance et
de notification en temps réel
Les Smartphones sont des véritables compagnons électroniques des humains et les assistent
aujourd’hui presque dans toutes leurs tâches professionnelles et personnelles. Les Smartphones les
plus utilisés à travers le monde sont de type Android [25]. A cet effet, le système de géolocalisation,
de reconnaissance et de notification sera développé pour les terminaux ANDROID.
La figure 3.1 ci-après présente les parts de marché de différents types de Smartphone à
travers le monde.

Figure 3.1 : les plateformes mobiles les plus utilisés dans le monde [25]
3.2.2.3 Choix du SGBD
CAMTEL utilise le SGBDR (Système de Gestion de Bases de Données Relationnelles)
Oracle, A cet effet notre base de donnée sera orienté Oracle. En plus Oracle est leader mondial
des bases de données [26].
3.2.2.4 Choix des API de programmation
3.2.2.4.1 API pour la PKI
Nous avons étudié les trois solutions de PKI les plus utilisées dans le monde (Tableau 3.1).
De ces études, nous préférons l’API Bouncy Castle [27] car il est fait en Java, plus simple à mettre
en œuvre, indépendant des Systèmes d’Exploitation (SE), adaptable à tout type de base de données
et est gratuit.
Tableau 3.1 : Etude comparative d’API de PKI

Paramètres Open CA EJBCA Bouncy Castle
Système d’exploitation Linux, Solaris, BSD, Mac OS Indépendant du SE Indépendant du SE

X
implémentation C, JavaScript, Perl, PL/SQL, Java Java

Unix Shell
Supporte LDAP et OCSCP ? Oui Oui Oui
Algorithmes de Choix dynamique Choix dynamique Choix dynamique

cryptographie
Base de données PostgresSQL, MySQL, Oracle, MySQL, PostgresSQL, Oracle, Tous types de bases de données
DBM DB2, Derby, Sysbase, accessibles via l’API JDBC
informix, Ingres
Extensible ? Non extensible Extensible Très extensible
Configuration Complexe Très Complexe Simple à mettre en

œuvre
Coût Gratuit gratuit Gratuit

3.2.2.4.1 Choix de l’API pour la gestion des codes QR

Grâce aux études de la table 3.2, nous avons choisi ZXing comme API de gestion des codes
QR, car son niveau de résistance aux erreurs est bon ; il est libre; sa vitesse de scannage est
excellente et il est à la fois disponible pour les environnements Android et IOS.
Tableau 3.2 : Etude comparative des API de gestion des codes QR

Nom du Spécificité Moteur de Scan Niveau de Accessibilité Plateforme
scanner résistance aux
erreurs
i-nigma Moteur propre excellent Libre Android, IOS
Quickmark Moteur propre excellent Pas Android
totalement libre
SPARQ.me Scan très ZXing Bon Libre android
rapide
ZXing Open Moteur Bon Totalement libre Android, IOS
Barcode source propre
BeeTagg Moteur Excellent Libre Android, IOS
propre
RedLaser Très similaire à Bon Libre Android, IOS
ZXing
3.2.2.4.2 API pour OCR

Pour le choix de l’API d’OCR, nous étudions les différentes solutions selon, le fabricant, les
langages de programmation, les types de polices de caractères, le nombre de langues reconnues et
les formats de sorties lors de la reconnaissance (Tableau 3.3). Par conséquent, nous préconisons
Tesseract, car le mode de reconnaissance est « hors -ligne», il est adapté aux systèmes Windows,
MAC OS, Linux, et BSD. En outre, Le fait qu’il soit adapté au C et au C++ fait qu’il peut être
utilisé avec Java étant donné qu’il existe des outils permettant de transformer des codes sources C
ou C++ en Java.
Tableau 3.3 : Etude Comparative des OCR

Tesseract ScreenWorm ExperVision AliusDoc AD-SCI
TypeReader & RTK
Créateur HP en 1985/supervisé En 2013 par Funchip Créé en 1987 Créé en 2005
par Google mais exploite le moteur
de Tesseract
Licence Apache Propriétaire Propriétaire Propriétaire
En ligne? Non Non oui Non
SE Windows, Mac OS Mac OS Windows, Mac OS, Windows
Linux, BSD IOS, Android
Langages C++ ,C Objective-C++ C/C++ Vb.Net
Langues Plus de 100 57 21 Toutes langues
ASCII
Formats Text, OCR, TXT XML, Plain
sorties PDF Text

3.2.2.4.3 Choix de la solution de SIG

Il se dégage d’après l’étude (Tableau 3.4) que pour notre projet, Google Maps est mieux
adapté. En effet, Google Maps bien que sous Licence Google est libre et est compatible avec les
navigateurs IE7+, Firefox 2.0.0.8+, Safari 3+, Mozilla 1.7+, Opera 8.02+, Google Chrome 1+. En
plus, il prend en comptes plus de 58 langues et dispose des API Java et JavaScript.
Tableau 3.4 : Etude comparative des solutions de Cartographie web

Critères Google Maps Bing Maps MapQuest OpenStreetMap
Licence Propriétaire mais Propriétaire propriétaire ODbL
gratuit
Nombre de pays 12 64 Seulement les Tous les pays
où bénéficiants de USA
tous les Avantages
Navigateurs IE7+, Firefox IE7+, Firefox IE6+, Firefox IE7+, Mozilla
supportés 2.0.0.8+, Safari 3+, 3.6+, Safari 5+, 2+, Safari 3+ Firefox 3.5+, Google
Mozilla 1.7+, Opera Google chrome, Chrome 4+, Safari 4+
8.02+, Google Chrome Navigateurs
1+ mobile
Nombre de Plus de 58 langues Plus de 117 Plus de 10 Plus de 50 langues
langues supportées langues langues
Backend JSON JSON, XML, XML
JavaScript, .Net
Mise à jour des journalier Par mois Journalier
données
d’imagéries
API disponible Java,Javascript, Javascript, Oui Oui
WPF, .NET (C#,
VB), C++,
Windows 8/10,
WP 7/8, REST
3.2.3 Outils de développements et de Tests

Nous présentons les différents environnements de test et de développement par le tableau 3.5. Nous
regroupons ces outils selon leurs rôles. Les environnements de test sont utilisés pour évaluer les
performances de la plateforme avant déploiement en environnement de production tandis que les
outils de développement sont utilisés pour la réalisation du système.

Tableau 3.5 : environnement de développement et de tests

Logiciels Logiciels Développements Logiciels de Tests
Développement
Outils fonctions
Web/mobile JDK8 Boites à outils Java Navigateur web pour smartphones et

PC :
 Mozilla Firefox
NetBeans 8.1 IDE3
 Internet Explorer
 Opéra Mini
 Google Chrome
Oracle db SGBD-R
GlassFish4 Serveur Web
Module Android SDK Android Boite à outil java pour Emulateur Android BlueStacks
Android
NDK Traduction de Tessearct en

Java
Eclipse IDE
ADT module Android pour

eclipse
3.2.4 Outils d’élaboration du SMSI

Comme, nous avons choisi EBIOS pour l’élaboration de notre SMSI, il est alors
recommandable d’utiliser des outils correspondants. Le logiciel EBIOS est l'outil d'assistance à la
réalisation de la méthode. En dépit de l’utilisation du logiciel EBIOS, il est nécessaire que nous
utilisions un logiciel pour monter l’architecture du SI à sécuriser. A cet effet nous choisissons le
logiciel « Visio Professional » édité par Microsoft.
3.3 Réalisation du SMSI

3.3.1 Etude du contexte de l’entreprise
La réalisation de la méthode EBIOS commence par l’étude du contexte de l’entreprise. Cette
étape vise à de déceler les différentes vulnérabilités.
3
Un IDE (Environnement de Développement Intégré) facilite l’édition du code source des logiciels et leurs
compilations.

3.3.1.1 Présentation de l’entreprise et Contraintes

La présentation de CAMTEL a déjà été faite à l’introduction générale. Dans la réalisation de
ses missions, elle a pour ministère de tutelle le MINPOSTEL. Pour se doter d’infrastructures et des
technologies de pointe, elle s’appuie sur des équipementiers de télécommunications tels que
HUAWEI, ZTE, CISCO, … et s’entoure d’entreprises du secteur des télécommunications comme
partenaires. Elle se doit de protéger les données relatives à ses abonnées et aux différentes
installations et de garantir l’ubiquité de ses services avec un budget provenant des subventions de
l’Etat Camerounais.
Les catégories du personnel sont diversifiées et les horaires de travaux précises. Un service
de sécurité permet de contrôler les entrées sur site. Elle utilise : des applications professionnelles
du domaine des télécommunications, la technologie VPN, des technologies RAID pour la
sauvegarde des données et des pare feux. La maintenance de certains équipements est externalisée
et le mode de fonctionnement des applications est orienté services.
Elle est repartie sur plusieurs sites géographiques distincts dans tous les dix régions du
Cameroun. Dans les dix régions du Cameroun, elle dispose des délégations urbaines et prévoit
l’extension de son réseau en Afrique. Son siège social est à Yaoundé. Les décisions stratégiques
sont validées par la Direction générale. Les contraintes d’ordre réglementaire sont régies en grande
partie par les lois en vigueur relatives à la communication électronique, à la cybersécurité et la
cybercriminalité du Cameroun.
3.3.1.2 Système cible de l’étude
Notre étude portera uniquement sur une partie du système d’information appelée système
cible qui est constituée de :
 F1 : services de demandes d’abonnements aux installations et de suivi de dossiers
 F2 : gestion des études des dossiers de demandes d’installations
 F3 : analyse des données d’installation
 F4 : La gestion des ressources humaines et matérielles de l’installation
 F5 : La gestion des formats de demandes, d’études et de rapports d’installation
3.3.1.3 Architecture du SI concernant le système cible
CAMTEL pour des raisons de sécurité dispose d’une zone démilitarisée (DMZ) qui contient
les ressources partagées entre l’intranet et le public. Les directions, les sous directions, les clients
et le personnel mobile de CAMTEL accèdent aux services de dématérialisation à partir de leurs
navigateurs via le protocole HTTP (HyperText Transfer Protocol). Le système NGBSS, les clients

et personnels mobiles doivent communiquer avec la plateforme en utilisant des e-services. Avec le
système NGBSS ce mode est obligatoire. Mais avec les clients et personnels mobiles, ce mode de
communication n’est applicable que lorsqu’ils utilisent l’application Android. La figure 3.2 présente
l’architecture du SI de dématérialisation.
Figure 3.2 : Architecture de la plateforme de dématérialisation

3.3.1.4 Règles de sécurité du système d’informations
CAMTEL pour assurer la sécurité de son SI fixe les règles suivantes :l’accès à la salle de
serveurs se fait par carte magnétique ;les salles de serveurs sont climatisées ; les salles serveurs
disposent des caméras pour la vidéo-surveillance ; l’accès aux applications est régi par un système
d’utilisateur/mot de passe; des extincteurs sont installés dans les salles serveurs ; les salles
serveurs disposent de sorties de secours ; les sauvegardes automatiques sont faites ; les réseaux sont
segmentés ; un système de groupes électrogènes existe et entre en fonctionnement après quelques
secondes de coupures ; des onduleurs disposant de batteries de quelques minutes sont présents dans
les réseaux dans le but d’éviter les fluctuations de tensions; les équipements des salles serveurs sont
déposés sur des planchers pour éviter les inondations ; les câbles réseaux sont véhiculés dans des
tubes résistants aux rongeurs.

3.3.1.5 Enjeux du système cible

CAMTEL veut fournir à ses clients une plateforme Web/Mobile disponible à 99.999% pour
le suivi en temps réels de leurs installations. Les informations personnelles des clients circulent
alors via INTERNET, pour ce CAMTEL se doit de les protéger. Le personnel mobile de CAMTEL
doit pouvoir accéder à la plateforme partout, n’importe et en toute sécurité; la signature des
documents électroniques doit être fiable, à cet effet le serveur de certificats doit être sécurisé et le
temps d’horodatage utilisé pour la signature doit être fiable ; Le système de facturation NGBSS
doit communiquer avec la plateforme. A cet effet, ces échanges doivent être fortement sécurisés.
3.3.1.6 Eléments essentiels du SI
Il s’agit particulièrement des éléments de la table 3.6. Ces éléments sont au cœur du métier
et permettent la traçabilité des opérations dans le workflow du processus d’installation.
Tableau 3.6 : éléments essentiels du SI
 I1 : demande du client  I6: Fiche de travaux
 I2: Carte d’abonnement du client  I7: Rapport d’installation
 I3 : Rapport de pré-étude  I8 : temps fournit par l’horloge d’horodatage
 I4 : Rapport d’étude  I9 : certificats du client
 I5 : Reçu de paiement  I10 : certificats du personnel
3.3.1.7 Liste des Ressources utilisées par le système cible

Le système cible utilise les ressources spécifiées dans la table suivante.
Tableau 3.7 : ressources utilisées par le système cible.

E1 : Intranet. E11 : Périphérique de traitement : Imprimante réseaux.
E2 : Internet. E12 : Support (bandes magnétiques).
E3 : Réseau Local E13 : Support papier.
E4 : Système NGBSS E14 : Energie électrique.
E5: SGBD Oracle E15: Equipements réseaux (Switch, router).
E6 : Serveur GlassFish E16: Messagerie d’entreprise et outil de collaboration
E7 : serveur de stockages certificats E17 : Locaux (bâtiments).
E8 : serveur de temps E18 : Groupe électrogène.
E9: Système d’exploitation E19 : Onduleurs.
E10: Matériel ordinateur portable. E20 : Climatisation.

La table 3.8 présente comment les processus du système cible, exploitent ces ressources.
Tableau 3.8 : Matrice d’utilisation de ressources par le système cible.
E1 E2 E3 E4 E5 E6 E7 E8 E9 E10 E11 E12 E13 E14 E15 E16 E17 E18 E19 E20
F1 x x X x x x x x x x x x x
F2 x x x X x x x x x x x x x x x x x x x
F3 x x X x x x x x x x x x
F4 x x X x x x x x x x x x x x x x x x
F5 x x X x x x x x x x x x x
Il se dégage donc que les ressources systèmes qui sont les plus convoitées sont : Internet, le
réseau local, le SGBD Oracle, le Serveur GlassFish, le serveur de stockage de certificats, le serveur
de temps, les systèmes d’exploitation, le matériel ordinateur portable, les supports (bandes
magnétiques), l’énergie électrique, les équipements réseaux (Switch, routeur), la messagerie
d’entreprise et les outils de collaboration, les Locaux (bâtiments), les groupes électrogènes, les
onduleurs et équipements de climatisation.
3.3.2 Expression des besoins de sécurité et étude des vulnérabilités

du système
3.3.2.1 Critères de sécurité
Afin de rendre cette étude plus précise, il est nécessaire d’établir une graduation et de
déterminer des valeurs de références pour chacun des critères de sécurité déterminés précédemment.
A partir des enquêtes et interviews effectués auprès des clients et techniciens, nous obtenons la
classification de la table 3.9.
Tableau 3.9 : Echelle des besoins de sécurité
Note Confidentialité Disponibilité Intégrité

0 L’élément est accessible à tous sans L’élément peut être indisponible Il n y a aucun besoin de garantir
restriction. définitivement ou pas sans que cela ait un l’intégrité de l’entité.
impact.
1 L’élément n’est accessible qu’aux L’élément peut être indisponible plus d’un mois sans que cela ait un impact.
employés de CAMTEL et au client
concerné.
2 L’élément n’est accessible qu’aux L’élément doit être disponible dans le mois. Besoin d’intégrité moyen.
employés de CAMTEL
3 L’élément n’est accessible L’élément doit être disponible dans la semaine.
qu’aux employés de la direction
responsable du projet.
4 L’élément n’est accessible L’élément doit être disponible en temps réel. L’élément doit être parfaitement
qu’aux responsables des directions intègre.
concernées, à la direction générale
de CAMTEL, et à certains systèmes
internes et partenaires (comme
l’Etat).

3.3.2.2 Expression des besoins de sécurité

Afin de déterminer les besoins en sécurité des entités sensibles et des unités fonctionnelles
déterminées à l’étape précédente, nous avons dans un premier temps, déterminé des impacts
pertinents en collaboration avec la direction générale qui sont présentés ci-après : Arrêt total de
fonctionnement de la plateforme de dématérialisation, Perte totales de l’historique des transactions,
Perte de données de facturation, Perte du d’une part du chiffre d’affaire, Perte d’image de marque
ou Infraction aux lois et règlements.
Après analyse, nous avons pu classer les entités essentielles dans la table 3.10 ci-après :
Tableau 3.10 : expressions des besoins de sécurité des actifs de la plateforme

Confidentialité Intégrité Disponibilité
I1 0 4 4
I2 0 4 1
I3 1 4 4
I4 1 4 4
I5 1 4 4
I6 2 4 4
I7 1 4 4
I8 4 4 4
I9 0 4 4
I10 3 4 4
F1 0 4 4
F2 3 4 4
F3 3 2 1
F4 4 4 3
F5 4 4 1
Ces statistiques montrent l’inéluctable nécessité d’accorder beaucoup plus d’intérêts aux
services d’intégrité et de disponibilité en faveur des actifs de CAMTEL.
3.3.2.3 Etude des vulnérabilités
Nous avons déterminé les vulnérabilités potentielles pesant sur notre système en les
regroupant selon les trois niveaux d’appréhension de la sécurité informatique qui sont [7] : Sécurité
Organisationnelle, Sécurité Physique et Sécurité Technologique. Ces vulnérabilités recensées
sont consignées dans le tableau 3.11. Les colonnes représentent les vulnérabilités et les risques ; les
lignes reprennent les trois niveaux d’appréhension de la sécurité informatique.

Tableau 3.11 : vulnérabilités de la plateforme

Type de de menaces Vulnérabilités Risques
Organisationnel Politique de sécurité globale existante mais pas de politique de sécurité Plateforme exposée à tous types d’attaques
particulière pour la plateforme
charte d’utilisation de la plateforme non encore existante Négligence des utilisateurs pouvant être
fatale à leurs sécurités et compromettre la
sécurité de la plateforme
Politique d’accès et classification de données pas encore existent pour la Divulgation des informations
plateforme
Politique de sauvegarde spécifique non existent pour la plateforme Capacité de reprise après incident affaiblie
Les applications de la plateforme ne sont pas encore documentées Maintenances très difficile
Politique d’échanges de données de la plateforme avec l’extérieur non définie Divulgation de l’information
confidentielle
Politique de gestion de mot de passe inexistant Intrusion au réseau, attaque d’accès
Politique de gestion de clés de cryptographie Falsification des documents, signature
frauduleuse, atteinte à la confidentialité des
données
Physique Absence de matériel de destruction de documents Confidentialités des documents affaiblies
Système de sauvegarde hors site spécifique absent pour la plateforme Capacité de reprise après incident limitée
Le serveur de certificat est dans la DMZ Attaque d’accès, compromission de

l’intégrité des documents électronique
Le serveur de temps est dans la DMZ Dos du service de temps, paralysie du
système de signature, compromission,
compromission de l’intégrité des
documents électronique
La BD de la plateforme est dans la DMZ Attaque par l’accès, reconnaissance, Dos,
intégrité et confidentialité affaiblies

Vidéosurveillance mais aucun agent de sécurité pour garder les serveurs Attaque par l’accès, reconnaissance, Dos
Technologique Protocole d’échange http Intrusions réseaux, attaque de l’homme du

milieu
Les agences et les directions communiquent avec la plateforme via Dos, intrusions dans le Réseau
INTERNET
Aucun IDS Réseau ou machine Intrusion,
Aucun IDS applicatif n’existe pour ORACLE injection SQL, perte de données,
affaiblissement de l’intégrité et de la
confidentialité
Le protocole d’e-service d’échange n’est pas spécifié Intrusions réseaux, attaque de l’homme
du milieu
Aucun protocole sécurisé d’échange de clés n’est définie Intrusions réseaux, attaque de l’homme
du milieu
Les ports de certains PC et serveurs non utilisé sont ouverts Attaques par reconnaissance, accès
Aucun mécanisme de journalisation n’est défini pour la plateforme Reniement d’action
Les PCs possèdent au plus qu’un antivirus de mise à jour non contrôlées Attaque par les logiciels malveillants
Protocole d’échange avec NGBSS et extérieur non spécifiée

3.3.3 Détermination des exigences de sécurité

3.3.3.1 Identification des objectifs de sécurité
En se basant sur les besoins en sécurité recensés à l’étape 2 et les vulnérabilités à la section
précédente, il en découle les objectifs de sécurité suivants : l’intégrité totale des entités du système
d’information doit être garantie ; il faut implémenter des mécanismes pour prévenir le système
d’arrêts temporaires ou définitifs de fonctionnement ; des dispositions doivent être prises afin de
garantir l’intégrité des documents confidentiels ; des dispositions doivent être prises pour la
protection du serveur de base de données Oracle, du serveur de temps et du serveur de stockage de
certificats ; tout accès au système doit être protégé par un dispositif d'identification et
d'authentification ; des dispositions doivent être prises afin de garantir le contrôle des mesures de
sécurité et leur adéquation par rapport aux objectifs de sécurité ; CAMTEL doit s'assurer que
l'ensemble des lois et règlements applicables sont pris en compte dans la politique de sécurité ; des
mécanismes de prévention contre les intrusions et de pannes doivent être pris en compte.
3.3.3.2 Détermination des exigences de sécurité
Afin de remédier aux vulnérabilités recensées à la section précédente, nous allons proposer
des solutions que nous structurerons selon les 10 chapitres du guide ISO/CEI 17799 :2005.
3.3.3.2.1 Définir une politique de sécurité spécifique à la
plateforme
Il faut : établir une charte d’utilisation de la plateforme pour les utilisateurs ; définir des
sanctions auxquelles s’exposent les personnes ne respectant pas la politique de sécurité de la
plateforme ; Appliquer la politique plan-do-check-act afin de rendre le processus de sécurisation du
système évolutif ; définir une politique d’échange des données avec le milieu extérieur ; Etablir une
politique de gestions des clés et certificats.
3.3.3.2.2 Organisation de la sécurité de la plateforme
Il faut définir un organe (une équipe de personnes qualifiées) chargé de la sécurité de la
plateforme, définir les attributions précises de l’organe chargé de la sécurité de la plateforme.
3.3.3.2.3 Classification et contrôle des actifs de la plateforme
Il faut recenser les différents actifs (équipements, applications), Définir des niveaux de
sécurité, classifier les différents actifs recensés selon les niveaux de sécurité définis.
3.3.3.2.4 Sécurité du personnel
Il faut établir les profils des différents postes et fonctions existants pour ladite plateforme et
former le personnel aux soins de premier secours vis-à-vis de la plateforme.

3.3.3.2.5 Sécurité physique et de l’environnement

Il faut recruter des agents de sécurité pour surveiller la salle des serveurs, acquérir des coffres
forts pour stocker les documents confidentiels et mettre dans une enceinte isolée le serveur de
stockage de certificats, le serveur de temps et la base de données.
3.3.3.2.6 Exploitation et Réseaux
Les agences et directions doivent communiquer avec la plateforme via l’INTRANET. Seul les
personnels autorisés et les clients doivent pouvoir communiquer avec la plateforme en utilisant
INTERNET. Il faut concevoir un SAN (voir annexe) pour améliorer la sauvegarde des données. Il
faut ajouter un détecteur d’intrusion applicatif pour lutter contre les injections SQL et Intégrer un
IPS réseau derrière le pare-feu pour détecter les intrusions qui ont pu traverser le pare-feu. Il faut
également intégrer un IPS réseau devant le pare-feu pour détecter et prévenir des intrusions avant
le pare-feu.
3.3.3.2.7 Contrôle d’accès logique
Il faut : migrer du protocole http au protocole https; activer un moyen comme SHA-2, pour
authentifier les échanges avec le serveur de temps ; Implémenter les e-services avec le protocole
d’échange SOAP.
3.3.3.2.8 Développement et maintenance des systèmes
Il faut : concevoir un système de reporting des opérations de maintenance qui pourra s’appuyer sur
une base de connaissances ; cela permettra de capitaliser la connaissance ; Etablir une
documentation précise du système qui devra comporter les fichiers de configuration des
équipements réseaux et serveurs pour le fonctionnement de la plateforme.
3.3.3.2.9 Continuité d’activité
Il faut définir des procédures de réaction en cas de sinistre pour la plateforme et établir des
procédures de reprise après incident pour la plateforme.
3.3.3.2.10 Conformité
Il faut mener des audits de la politique de sécurité de la plateforme afin de s’assurer de sa conformité
légale.
3.3.3.3 Mise en œuvre
3.3.3.3.1 Proposition d’une politique de contrôle d’accès
Applicatif
Pour garantir le contrôle d’accès applicatif, nous optons pour un contrôle d’accès basé sur
les rôles et sur le modèle de Biba. En effet, le modèle de Biba privilégie l’intégrité à la
confidentialité ce qui cadre avec nos études qui ont placées très haut l’intégrité des actifs par rapport

à leurs confidentialité. Un utilisateur ne pourra lire que des objets de niveaux de sécurité inférieure
ou égale, et créer les objets de niveaux de sécurité supérieurs. En outre, le contrôle d’accès basé sur
les rôles est beaucoup plus souple. Effet, les rôles sont des métiers élémentaires du processus et sont
indépendants des utilisateurs. A un moment donné, un utilisateur pourra avoir un ensemble de rôles.
Si un incident survient sur l’utilisateur (maladie, démission, mort, etc.), ses rôles pourront être
attribués facilement à quelqu’un d’autre.
3.3.3.3.2 Proposition d’une architecture sécurisée
Figure 3.3 : proposition d’une architecture sécurisée de la plateforme

3.4 Analyse et conception de la plateforme

3.4.1 Analyse de la plateforme
3.4.1.1 Etude du processus métiers : diagrammes d’activités
Pour mieux concevoir le système, il est nécessaire de comprendre le fonctionnement global
du processus métier. Les diagrammes d’activités d’UML 2.0 nous permettent de représenter les
workflows. Nous avons distingué trois principaux workflows : le workflow de demande
d’installation, le workflow d’étude d’installation, le workflow d’installation.
3.4.1.1.1 Le workflow de demande d’installation
La Figure 3.4 présente le workflow associé à la demande d’installation. La demande
d’installation ne peut être faite que par des abonnées identifiées par le processus d’inscription. Le
dossier d’inscription du client est transmis au gestionnaire de la PKI qui en cas de validité, lui génère
un certificat et une paire de clefs sous format PKCS #12. Le client peut alors générer une demande,
la signer et la transmettre au CSV. En cas de validité, le dossier est transmis pour étude au CSA.
Dans tous les cas, le client est notifié de la décision prise.
Figure 3.4 : Processus de demande d’installation.

3.4.1.1.2 Workflow d’étude de demande

La figure 3.5 présente le workflow associé à l’étude d’une demande. Le CSA reçoit les
fiches d’études qui lui sont transmises par le CSV. Il peut alors rédiger le rapport d’étude de la
demande. L’étude se boucle par une décision finale qui doit être envoyée au client par SMS ou par
mail. En cas d’un avis favorable, le rapport d’étude est transmis au gestionnaire qui est chargé de
générer le contrat du client. Le contrat ici désigne les frais d’installation. Le client notifié par le
devis à payer soit par SMS, soit par mail, se rend alors dans une agence pour régler celui-ci au près
d’un caissier. Une fois l’encaissement faite, le caissier envoie le reçu de paiement au gestionnaire.
Figure 3.5 : Processus d’étude de demande d’une installation.

3.4.1.1.3 Workflow d’installation
La Figure 3.6 présente le circuit d’information du processus d’installation. Dès lors que le
gestionnaire reçoit le reçu de paiement, il établit la fiche de travaux contenant les différentes
ressources nécessaires à l’installation. Cette fiche est transmise au SRAF qui à son tour configure
la ligne du client. La configuration est inscrite dans le rapport d’installation transmis au CSA chargé
de le compléter à la fin de l’installation. Le client est alors invité à signer ce rapport par le billet
d’un mail ou un SMS. La signature du rapport d’installation par le client scelle le dossier.

Figure 3.6 : Processus d’installation.
3.4.1.2 Spécification des besoins : diagramme des cas d’utilisation

L’étude des cas d’utilisation a pour but de déterminer ce que chaque acteur attend du système.
La détermination des besoins est basée sur la représentation de l’interaction entre l’acteur et le
système.
3.4.1.3 Modèle des cas d’utilisation
Un cas d’utilisation est une unité fonctionnelle assurée par un ou plusieurs acteurs. Il possède
des préconditions (d’autres sous cas ou simple critères à remplir), des sous cas d’utilisation et des
extensions (cas d’utilisations possibles d’effectuer lorsqu’on réalise la fonction).
3.4.1.3.1 Diagramme de cas d’utilisation du processus de
demande
Ce diagramme est représenté à la figure 3.8 .A cette phase, les acteurs qui interviennent sont :
l’abonné, le gestionnaire de la PKI, le CSV, l’ACGP, NGBSS et la DRIMS. Leurs actions sont
déduites en fonction du workflow de demande d’installation.

Figure 3.7 : Diagramme de cas d’utilisation du processus de demande

3.4.1.3.2 Diagramme de cas d’utilisation du processus d’étude
d’installation
La Figure 3.8 décrit les cas d’utilisation possibles à cette étape. A cette phase, les acteurs qui
interviennent sont : l’abonné, le gestionnaire, le CSA, le CS, NGBSS, le caissier et la DRIMS. Les
acteurs principaux ici sont : le chef secteur adjoint et le caissier. L’abonné est également présent
comme acteur principal car c’est lui qui initie la demande; il peut être aussi vu comme acteur
secondaire car il doit avoir en temps réel l’état de sa demande (rejetée ou validée).

Figure 3.8 : Diagramme de cas d’utilisation du processus d’études d’installations
3.4.1.3.3 Diagramme de cas d’utilisation du processus

d’installation
La figure 3.9 décrit les cas d’utilisation possibles à cette étape. A cette phase, les acteurs qui
interviennent sont : l’abonné, le gestionnaire, le CSA, l’ACGP (le chef d’agence), NGBSS, le SRAF
et la DRIMS. Les acteurs principaux ici sont : le chef secteur adjoint, le gestionnaire et le SRAF.
L’abonné est présent comme secondaire car il doit savoir ce qu’en est de son dossier. Le DRIMS et
le chef d’agence doivent avoir en temps réel les statistiques concernant le circuit.

Figure 3.9 : Diagramme de cas d’utilisation du processus d’installations

3.4.1.3.4 Diagramme de cas d’utilisation de l’administration
La Figure 3.10 décrit les cas d’utilisation possibles à cette étape. A cette phase, les acteurs
qui interviennent sont : le gestionnaire de la PKI, la RH, l’ACGP et la DRIMS. Ce module est au
cœur du système. Il englobe la création et l’édition : des fiches d’installation, des fiches d’étude et
des fiches d’installation. En outre, ce module permet : la gestion des certificats des abonnés et du
personnel, la gestion du personnel et équipes, la gestion des agences, la gestion de stocks et la
visualisation des statistiques.

Figure 3.10 : Diagramme de cas d’utilisation pour l’administration de la plateforme
3.4.2 Description des cas d’utilisations : diagramme de séquences

Certains cas d’utilisations ne sont pas intuitifs. C’est pourquoi, il est important de les décrire
de manière textuelle et via des diagrammes. Nous avons choisi de le faire avec des diagrammes de
séquences UML qui permettent de zoomer la communication entre acteurs pour l’aboutissement
d’un cas d’utilisation.
3.4.2.1 Scénario d’identification
 Titre : Identification du client
 Acteur principal : le client
 Acteurs secondaires : Le gestionnaire de la PKI
 Description des enchaînements
 Préconditions : le client est présent sur le portail web/Mobile
 Post Conditions : Le client est identifié puis obtient via un mail son certificat
électronique X.509 (fichier d’extension « .cer »), sa carte d’abonné et sa paire
de clés (chiffrées) dans sous format PKCS#12 (fichier d’extension « .p12 »).

 Scénario : voir Figure 3.11. Une boucle permet de contrôler la cohérence de la

demande avant de l’enregistrer dans le système. Ensuite en fonction de l’état de
la demande dans le temps suite à l’intervention du gestionnaire de PKI, le
système peut notifier le client.
Figure 3.11 : Diagramme de séquence du scénario d’identification

3.4.2.2 Diagramme de séquence de la demande d’installation de services

 Titre : demande d’installation de services
 Acteur principal : le client
 Acteurs secondaires : Chef Section vente de l’agence (CSV) la plus proche du domicile
du client.
 Préconditions : le client est présent sur le portail web/Mobile
 Post Conditions : La demande du client est signée puis sauvegardée et le chef
Section vente la plus proche est notifiée de la demande du client.
 Scénario : voir la Figure 3.12. On boucle la vérification des paramètres de
la demande jusqu’à ce que ceux-ci soient valides. Ce diagramme fait intervenir le
diagramme de séquence de signature électronique.
Figure 3.12 : diagramme de séquence de Demande d’une installation

3.4.2.3 Diagramme de séquence de la demande d’installation de services

 Titre : Signer un objet dans le système
 Acteur principal : tout utilisateur du système
 Acteurs secondaires : Serveur de temps
 Préconditions : l’utilisateur s’est authentifié sur le portail web/Mobile, et a
ensuite choisir l’option « signer un objet » (objet bien déterminé).
 Post Conditions : Si l’objet est signé, le système renvoie un « OK », sinon
le système renvoie un « non OK »
 Scénario : Voir la Figure 3.13. On boucle la vérification des paramètres de
signature (certificats et clés privées) jusqu’à ce que ceux-ci soient valides. Dans le
cas de leurs validités, le système récupère les champs non modifiables de l’objet à
signer et leurs associe avec la date obtenu du serveur de temps, puis signe et exporte
la signature dans un fichier PKCS#7 dont l’empreinte digitale est exportée en code
QR.

Figure 3.13 : Diagramme de séquence d’une signature
3.4.3 Conception de la plateforme

3.4.3.1 Diagramme de paquetage
Notre diagramme de paquetage est représenté par la figure 3.14. Il pour but de regrouper les
classes de notre système en module fonctionnel. A cet effet, il participe à rendre modulaire notre
plateforme. Ceci implique alors plusieurs avantages dont la réutilisabilité des modules et la
maintenance aisée. Pour ce faire nous avons pu recenser les modules fonctionnels suivant : le
module PKI possède des classes permettant la gestion de notre PKI ; le module CRUD possède
les classes centrales de toute la plateforme ; ce module exploite les classes du module PKI et du
module QR ; le module « demande d’installation » possède la liste des classes nécessaires pour la

gestion des demandes d’installation ; le module « étude d’installation » possède la liste des classes
nécessaires à l’étude d’installation; le module « installation » contient la liste des classes
nécessaires à l’installation de l’abonné ; le module notification qui sert de support au système de
notification de la plateforme ; le module de géolocalisation qui permet de gérer la géolocalisation
des objets géo référencés ; le module « OCR » permet de faire abstraction aux API d’OCR ; le
module « QR » permet de faire abstraction aux API de traitement de code QR et le module LOG
permet de gérer la journalisation des opérations à travers la plateforme ; ce module interagit avec le
module PKI.
Figure 3.14 : Diagramme de paquetage.
3.4.3.2 Diagramme de classes

Ayant présenté le diagramme de paquetages, il nous faut alors présenter la composition de
chaque paquetage. La constitution d’un paquetage se fait par le billet d’un diagramme de classe qui
présente les différentes classes et les relations qui les lient.

3.4.3.2.1 Diagramme de classe pour le module PKI

La figure 3.15 donne une description détaillée des classes du module PKI. Dans le module
PKI, la classe « Signataire » désigne tout acteur susceptible de signer un document. Un
« Certificateur » qui est avant tout signataire, est toute entité susceptible de produire un certificat à
un signataire ou à un autre certificateur. Les certificats sont représentés par la classe « Certificat ».
Chaque certificateur possède sa liste de certificats révoqués. Une révocation est matérialisée par un
objet de la classe « CRL ». Une signature électronique est représentée par la classe « Signature ».
A une signature est associée une signée manuscrite (de classe « SignaturePhysique ») et un code
QR (objet de classe « QR »). Tout objet susceptible d’être signé doit dériver de la classe
« Signable ». Un objet de type « Signable » peut posséder un ensemble de signatures.
Figure 3.15 : diagramme de classes du module PKI

3.4.3.2.2 Diagramme de classes du paquetage CRUD

Le paquetage CRUD constitue le ciment de la plateforme. La figure 3.16 donne dans tous
ses détails la constitution de ce paquetage. L’abonné est soit une personne physique ou morale. Les
personnels sont des certificateurs. Les certificateurs et les abonnés sont des signataires ; chaque
signataire possède un compte. Les personnels sont dans une agence et sont associés à plusieurs
équipes. L’agence possède des véhicules et de stocks de matériels de plusieurs variétés.
Figure 3.16 : diagramme de classe du paquetage CRUD

3.4.3.2.3 Diagramme de classe du paquetage « demande

d’installation »
La figure 3.17 présente ce diagramme. Une demande d’installation est un objet de la classe
« DemandeInstallation ». Elle est composée d’un ensemble de valeurs (objets de la classe
« Valeur »). Une valeur est liée à une unique propriété (objet de la classe « Propriete ») qui elle-
même est possédée par un service (Objet de la classe « Service »). Un type d’installation (Objet de
la classe « TypeInstallation ») possède un ensemble de services. Chaque propriété de services
possède un ensemble de valeurs par défauts (Objets de la classe « ValeurParDefaut »). Une
demande d’installation est un type spécifique de la classe « Signable ». Elle concerne un domicile
(appartenant à un abonné) et est destinée à une agence.
Figure 3.17 : Diagramme de classes du module « demande d’installation »

3.4.3.2.4 Diagramme de classe du paquetage « étude
d’installation »
La figure 3.18 présente un approfondissement des classes de ce paquetage. Une étude est
un « signable » et présente des valeurs pour les différents critères d’études. Elle est faite par un

personnel et peut générer au plus un contrat. L’étude peut en outre recommander du matériel pour
l’installation.
Figure 3.18 : diagramme de paquetage du processus d’étude d’installation.
3.4.3.2.5 Diagramme de classe du processus d’installation

Une installation possède (figure 3.19) : des valeurs pour des éléments de rapports, des valeurs
pour les paramètres de configuration. Il est également important de connaitre, les responsables de

la configuration et de l’installation. Une fiche de travaux associée à l’installation, recommande

des matériels, une équipe et un véhicule à l’installation.
Figure 3.19 : diagramme de classes du paquetage d’installation

3.4.3.2.6 Diagramme de classe pour la géolocalisation

Dans ce module, Les entités géoréférencées (possédant les coordonnées géographiques)
telles que les agences et les domiciles se retrouvent dans des quartiers. Un quartier se retrouve dans
une ville, la ville dans un département, le département dans la région et la région dans le pays.
L’abonné possède un domicile. La figure 3.20 présente le diagramme de classe du module de
géolocalisation.
Figure 3.20 : Diagramme de classe du paquetage « géolocalisation »

3.4.3.2.7 Diagramme des classes pour la gestion des notifications
La figure 3.21 présente le diagramme du module de notification. Il est important de notifier
les utilisateurs et de garder la traçabilité des notifications. C’est la raison d’être de ce module. Un
Signataire (du paquetage PKI) peut être émetteurs ou destinataires de plusieurs messages. Un
message peut avoir plusieurs pièces jointes tandis qu’une pièce jointe n’est associée qu’à un unique
message.

Figure 3.21 : Diagramme de classe du paquetage de notification
3.4.3.3 Modèle SNI
Dans cette partie, il est question pour nous de présenter les différentes interactions entre les
IHM du portail d’administration de la plateforme. Nous organisons nos modèles en plusieurs
planches. Une planche SNI est un sous diagramme SNI qui peut faire références elle-même à
d’autres planches.
3.4.3.3.1 La planche principale du portail d’administration
La figure 3.22 est un résumé de ce paragraphe. Cette planche désigne le point d’entrée de
toutes les autres planches. Avant d’accéder aux options du portail d’administration, l’utilisateur doit
s’authentifier en tant qu’un Personnel. A cet effet une unité de dialogue lui demande d’abord de
saisir les paramètres de son compte dans l’unité de saisie, ensuite il devra choisir son rôle de
connexion dans la liste des rôles qui lui sont présentés et enfin si l’authentification échoue, une
unité de dialogue affiche la nature de l’erreur sinon, l’utilisateur accède à la planche correspondante
à son rôle de connexion.

Figure 3.22 : planche SNI pour le portail d’administration
3.4.3.3.2 Planches du CSA

Le CSA, tel que décrit par la figure 3.23 peut soit éditer un rapport d’étude ou un rapport
d’installation. Le CSA a deux principaux menus : l’édition des rapports d’études et l’édition des
rapports d’installation.
Figure 3.23 : planche SNI du CSA

Le menu « éditer une étude » (Figure 3.24) fait appel à une unité d’affichage de la liste des
études en y appliquant un trie ascendant (trie noté « dateDebut-A ») sur les études en cours avec
comme critère de trie la date de début de l’étude et en y appliquant également un filtre des études
non traitées (filtre noté « traite==false »). Pour la sélection d’une étude l’on peut voir ses détails
ou la traiter. Le traitement de l’étude correspond à l’affichage simultané des critères de l’étude et
des unités de saisie pour la spécification de ces critères ainsi qu’une unité de saisie pour le
renseignement de l’observation générale et de l’avis à tirer de l’étude. Bien sûre qu’il faut signer
l’étude en faisant appel à la planche signature. Après signature, une unité de dialogue nous fait le
rapport de l’opération.
Figure 3.24 : planche SNI pour l’élaboration d’une étude
3.4.3.3.3 Planches du DRIMS

Si le rôle de connexion est « DRIMS », alors la planche (Figure 3.25) correspondante à
l’utilisateur lui permet de gérer les types d’installations, de gérer les agences et de visualiser les
statistiques générales. La gestion d’un type d’installation consiste à visualiser la liste de tous les
types d’installations pour y soit à ajouter un nouveau type d’installation, ou soit en modifier un ou
supprimer plusieurs. La gestion des types installation implique aussi pour un type d’installation
sélectionné, de gérer : les services associés correspondants, les matériels requis, les éléments de
rapport, les paramètres de configuration et les éléments du format d’étude.

Figure 3.25 : planche SNI de la DRIMS
3.4.3.4 Diagramme de déploiement

Le diagramme de déploiement (figure 3.26) a pour but de présenter l’architecture détaillée
de la plateforme. Il présente les différents terminaux physiques ainsi que les éléments logiciels ou
matériels à déployer sur ceux-ci pour rendre opérationnelle la plateforme. Nous disposons des
nœuds de déploiement suivants : le serveur web, est une machine physique qui doit contenir une
machine virtuelle Java (JVM) , l’application Glass Fish dans laquelle doit être déployé le module
web (fichier d’extension « .ear ») et les e-services nécessaires pour la communication avec les
entités consommatrices ; le serveur de base de données est une machine physique dans laquelle
est déployé le Système de gestion de base de données oracle dans lequel on doit exécuter le script
(fichier « script_bd.sql ») de création de la base de données ; les PC à la direction générale, dans
les agences et chez les abonnés doivent posséder un navigateur web ; Le smartphone de l’abonné
et celui du personnel possèdent de récepteurs GPS. Sur ces Smartphone doit être déployé
l’application Android (fichier d’extension APK). Ces terminaux peuvent avoir un navigateur web
dans la mesure où ils veulent accéder au module web mobile.

Figure 3.26 : diagramme de déploiement
Bilan du chapitre
En somme, ce chapitre a consisté à la mise sur pieds du SMSI, à l’analyse et la conception
de la plateforme. La méthode EBIOS nous a permis de mettre sur pieds notre architecture sécurisée
et à proposer à CAMTEL des recommandations pour la sécurité de la plateforme. Suivant une
approche orientée service, nous avons pu scinder le travail en sous modules appelés services. Il
s’agit notamment du service demande d’installation, du service d’étude de demande d’installation,
du service d’installation, du service de géolocalisation, du service de PKI, du service d’OCR et du
service central CRUD (service au cœur du métier). La compréhension des attentes des utilisateurs
vis-à-vis de ces services s’est faite par des diagrammes UML2.0. Pour pouvoir mieux comprendre
les fonctionnalités de chaque service, nous avons usé des diagrammes de classes et de paquetages.
Pour rendre les IHM intuitives, nous avons recouru au modèle SNI (qui prend pour appui les
diagrammes de classes et de cas d’utilisation) recommandé par MACAO. Le diagramme de
déploiement a permis de ressortir les différents nœuds de l’architecture matérielle et logicielle de la
plateforme. A cet égard, quel résultat peut-on tirer d’une telle étude.

Résultats et Commentaires
4. Chapitre 4 : Résultats et Commentaires
A
près la conception de la plateforme et la réalisation de son SMSI, la finalité a été
son implémentation fidèlement aux spécifications prescrites par les études faites
dans les chapitres antérieurs. Il est maintenant question de présenter clairement
l’aboutissement de l’implémentation, d’estimer le coût afin d’en extraire les forces et les limites.
L’estimation de l’apport du SMSI se fera par le retour sur investissement en terme de sécurité : le
ROSI.
4.1 Présentation des résultats

Le portail final ainsi développé s’appelle « CAMTEL ONLINE SERVICES’TOOLS ». Il
est doté de deux sous portails dont l’un pour les abonnés et l’autre pour le personnel tel que
recommandé par nos études de sécurité. La figure 4.1 présente le schéma synoptique de la
plateforme.
Figure 4.1 : Schéma synoptique de la plateforme web/mobile

4.1.1 Présentation du portail Web/Mobile côté Abonné

4.1.1.1 Page d’accueil
La page d’accueil du portail d’abonné est constituée de trois parties : un entête, un corps et
un pied de page. L’entête (Figure 4.2) est constitué d’une barre de menu, d’une image d’accueil, de
deux boutons très important à savoir le bouton « inscription » et le bouton « connexion ».
La barre de menu quant à elle possède : le menu « accueil » pour retourner à la page d’accueil
, le menu «nos agences » qui permet de géolocaliser les agences ; pour un abonné authentifié, le
menu « mes demandes » lui permet de visualiser ses demandes en cours, le menu « mes factures »
lui permet de visualiser ses factures, le menu « mes installations » lui permet d’accéder à la liste de
ses installations, le menu « Mes notifications » lui permet d’accéder à sa liste de notifications; le
menu « A propos » permet de visualiser l’aide, la charte de sécurité et l’équipe de développement
logiciel.
Figure 4.2 : Entête du portail d’accueil d’abonné

Le corps de la page (Figure 4.3) d’accueil présente sous forme d’icônes la liste des types
d’installations enregistrées dans le système. Lorsque l’utilisateur s’approche avec le pointeur de la
souris sur une icône, celle-ci passe en mode surbrillance et fait ressortir l’option « en savoir plus »
qui redirige vers le site de CAMTEL. L’option « M’abonner » permet d’effectuer une demande
d’installation. Nous rappelons que l’option « M’abonner » n’apparait uniquement dans le cas où le
type d’installation a été clairement spécifié par la DRIMS.

Figure 4.3 : corps de la page d’accueil.

4.1.1.2 Formulaire d’identification de l’abonné
Lorsque l’abonné accède au menu « inscription », la fiche d’identification (Figure 4.4) lui
est présentée. Elle s’adapte en fonction du type de l’abonné. Si l’utilisateur coche le bouton radio
« Personne Physique », il obtient les spécificités d’une personne physique dans le cas contraire il
obtient les spécificités d’une personne morale.
Figure 4.4 : Fiche d’identification du client

4.1.1.3 Menu « nos agences »

Ce menu permet à l’utilisateur de géolocaliser les agences. L’utilisateur obtient sur une carte
(Figure 4.5) la liste des agences. Il peut alors zoomer la carte en avant ou en arrière, cliquer sur un
marqueur rouge pour avoir les détails de l’agence. En outre l’utilisateur peut déterminer l’itinéraire
qui mène à l’agence.
Figure 4.5 : géolocalisation des agences
4.1.1.4 Authentification de l’abonné

Les abonnés dont l’identification a réussie peuvent alors s’authentifier avec un login et un
mot de passe (Figure 4.6). L’option « Réinitialiser mot de passe » permet de réinitialiser son mot
de passe en cas d’oubli.
Figure 4.6 : Formulaire d’authentification de l’abonné

4.1.1.5 Demande d’une installation.

La fiche de demande (Figure 4.7) possède quatre (04) principaux blocs : le lieu d’installation,
les paramètres de spécification du service (dépend du type d’installation), le lieu de dépôt de dossier
et la zone de signature. L’utilisateur est invité à importer sa clé privée (fichier d’extension « .p12 »)
et son passe-phrase pour signer électroniquement la demande. Une zone de dessin lui est présentée
pour qu’il signe de façon manuscrite.
Figure 4.7 : Fiche de demande d’installation

4.1.1.6 Visualisation des demandes en cours

Cette option permet à l’abonné de visualiser la liste de ses demandes en cours (Figure 4.8).
Il peut alors savoir si la demande a été validée ou pas par le CSV, avoir les résultats de l’étude de
celle-ci. Une lampe verte indique une étape valide, le rouge indique un rejet de dossier. Le mot « en
attente » indique tout simplement que le dossier n’a pas encore été traité.
Figure 4.8 : visualisation des demandes en cours

Si l’utilisateur clique sur une étude favorable, il obtient alors les détails de l’étude (Figure
4.9).
Figure 4.9 : bilan d’une étude positive

Si l’utilisateur décide alors d’imprimer la fiche, il obtient la version PDF (Figure 4.10).
Figure 4.10 : version PDF de la fiche d’étude
4.1.1.7 Visualisation des contrats en cours

Le menu « Mes contrats » présente à l’utilisateur la liste de ses contrats (Figure 4.11). Les
contrats payés sont marqués en vert et les non payés en rouges.
Figure 4.11 : visualisation des contrats de l’abonné
4.1.1.8 Visualisation des installations en cours

Dans ce cas, l’abonné peut savoir si l’installation a été configurée (voir les détails de
configuration) ou savoir si l’installation a été menée avec succès (voir le rapport d’installation).
Dans le cas d’une installation réussie, l’abonné peut signer le rapport s’il est satisfait en cliquant
sur le pinceau de la ligne correspondante.

Figure 4.12 : visualisation des installations en cour de l’abonné
S’il choisit l’option « signer le rapport d’installation », il obtient alors la vue suivante (lui
demandant d’importer son certificat et sa clé privée).
Figure 4.13 : signature d’un rapport d’installation par le client

4.1.1.9 Visualisation des notifications
L’abonné peut accéder à l’historique de ses notifications (Figure 4.14). Il peut filtrer les
notifications lues des notifications non lues. Avoir les détails d’une notification et télécharger les
pièces jointes.
Figure 4.14 : visualisation des notifications

4.1.1.10 Gestion du profil

Pour gérer son profil (Figure 4.15), l’abonné doit cliquer sur l’option « profil ». Il obtient
alors une vue affichant son profil, et des options pour modifier son mot de passe ou révoquer son
certificat.
Lorsque l’utilisateur sélectionne l’option Lorsque l’utilisateur clique sur « révoquer

« profil » certificat »
Lorsque l’utilisateur clique sur « changer de

pasword»
Figure 4.15 : vues de gestion du profil de l’abonné

4.1.2 Présentation du portail Web/Mobile côté Personnel côté

Personnel
4.1.2.1 Page d’accueil
La page d’accueil du portail d’administration (Figure 4.16) possède un entête (Figure
4.16(a)), un corps que nous appelons ici le menu « bureau », et un pied de page. Lorsqu’un
utilisateur non authentifié essaie d’accéder à un menu, celui-ci se voit rediriger vers la page de
connexion (Figure 4.16(b)).
Figure 4.16(a) : vue d’accueil Figure 4.16(b) : vue de connexion

Figure 4.16 : page d’accueil du portail d’administration
4.1.2.2 Menu du CSV
Le CSV peut voir ses notifications et traiter les demandes en cours (Figure 4.17).
Figure 4.17 : menus du CSV
S’il choisit l’option « demandes en cours », il obtient alors la liste des demandes non traitées
(Figure 4.18).

Figure 4.18 : Liste des demandes en cours pour traitement

Si le CSV sélectionne une demande, il peut voir ses détails. S’il choisir l’option « traiter » il
obtient à cet effet le formulaire de traitement de demande (Figure 4.19).
Figure 4.19 : pré-étude d’une demande
4.1.2.3 Menu du chef d’agence

Le chef d’agence d’une manière générale, accède aux statiques d’études, de demandes,
d’installations, de configurations, de trésorerie et de « reporting ». Il peut également accéder aux
fichiers logs de l’agence. Si par exemple le chef d’agence décide d’accéder aux statistiques de
demandes (figure 4.20), il choisit l’intervalle de temps correspondant, spécifie un filtre (demandes
traitées ou en attentes, demandes valides ou demandes rejetées), puis clique sur le bouton d’icone
une loupe pour rafraichir la liste.

Figure 4.20 : exemple de visualisation de statistiques (cas de demandes)

Si l’utilisateur clique sur le bouton « visualiser le graphe » (bouton d’icone un crayon), un
graphe similaire à celui de la figure 4.21 est affiché.
Figure 4.21 : graphe récapitulant les statistiques de demandes

4.1.2.4 Menu du DRIMS
Le DRIMS peut gérer les agences, gérer les formats d’installations, visualiser les statistiques
globaux de la plateforme, accéder à sa boite à notifications (Figure 4.22).
Figure 4.22 : Menu de la DRIMS

S’il choisit l’option de gestion des agences, il accède à une IHM (Figure 4.22) qui présente
la liste des agences avec les options d’ajout, de suppression et de modification.
Figure 4.23 : gestion des agences

S’il choisit l’option « gérer » les types d’installations, il obtient la liste des différents types
d’installation (Figure 4.24). Pour une ligne, il peut gérer les services, le format de la fiche d’étude,
le format de rapport d’installation, les paramètres de configurations et les types de matériels.
Figure 4.24 : gestion des types d’installations

4.1.2.5 Menu du gestionnaire de la PKI
Le gestionnaire de la PKI peut identifier les abonnés (valider ou invalider), gérer les badges
du personnel ou les cartes d’abonnés, configurer la PKI ou gérer les certificats électroniques.
Trivialement, il peut accéder à sa boite à notifications (Figure 4.25).

Figure 4.25 : Menu du gestionnaire de PKI

S’il accède au menu « identifier les abonnés », il obtient l’IHM de la figure 4.26. A cet effet,
il est capable de gérer les certificats de l’abonné, supprimer l’abonné ou visualiser les informations
de l’abonné.
Figure 4.26 : gestion des identifications
S’il clique sur le menu « gérer certificat » pour un abonné, il obtient l’IHM de la figure 4.27.
A cet effet, il peut révoquer ou générer un certificat à l’abonné courant. Après création du certificat
d’un client, un certificat X.509, une carte d’abonnement (Figure 4.28), une clef privée sont générée
et sont envoyés par mail au client.
Figure 4.27 : gestion des certificats d’un abonné.

La signature sur la carte d’abonnement est matérialisée par le code QR. Les informations du
certificat de l’abonné y sont également représentées.
Figure 4.28 : Carte d’abonnée générée par le gestionnaire de PKI.
4.1.3 Présentation du Module Android de notifications en temps

réel, d’authentification de badges et de documents
4.1.3.1 Interfaces d’accueil
Pour accéder aux fonctionnalités de ce module, l’utilisateur est appelé à s’authentifier. Les
fonctionnalités sont : la consultation des notifications, l’authentification de CNI, l’authentification
des documents et la consultation d’aide (Figure 4.29).
Figure 4.29 : Activité d’accueil du module Android

Si l’utilisateur choisit l’option « Mes Notifications », il accède à ses notifications. Lorsqu’il

sélectionne une notification, il obtient les détails de celle-ci (Figure 3.30).
Figure 4.30 : Accès aux notifications

En outre, l’accès au menu authentification de document lance le scanner de code. L’opération
de scannage analyse le code QR en recherchant le document correspondant dans la plateforme. Si
le document existe, il est instantanément affiché (Figure 4.31).
Figure 4.31 : Authentification d’un document

Le menu « authentifier Badge », scanne le MRZ derrière la CNI puis effectue une recherche
de l’abonné correspondant. Dans le cas où l’abonné est retrouvé, sa carte d’abonnement est affichée
dans le terminal (figure 4.32).
Figure 4.32 : Authentification d’une CNI
4.2 Evaluation financière de la solution

4.2.1 Coût de développement
Le coût de développement de la plateforme est dépendant du cout des logiciels, des matériels
et API utilisées pendant le développement sans oublier les différentes charges rattachées à cette
phase. La table 4.1 récapitule la totalisation des frais de développement de la plateforme.
Tableau 4.1 : coûts de développement de la plateforme

Catégories Produit prix unitaire (en prix total (en
quantité
FCFA) FCFA)
Logiciels EBIOS 1 0 0
Enterprise Architect Professionnel 1 99 500 99500
Adobe Photoshop 1 52 000 52000
Eclipse 1 0 0
BlueStacks 1 0 0
GlassFish 1 0 0
Mozilla FireFox 1 0 0
Google Chrome 1 0 0
Adobe Reader 1 52000 52000

NetBeans 1 0 0
Oracle 11g 1 100000 100000
JDK1.8 1 0 0
SDK 1 0 0
Visual SNI 1 0 0
NDK 1 0 0
API Tesseract 1 0 0
google Map API 1 0 0
ksoap2 1 0 0
Zxing 1 0 0
Bouncy Castle 1 0 0
Licence technologies Jquery 1 0 0
Bootstrap 1 0 0
JSF 1 0 0
Matériels Ordinateur portable (HP Core i7)
3 850000 2550000
Imprimante HP 1 35000 35000

Scanner HP 1 450000 450000
Terminal Android (Motorola) 1 150000 150000
Modem Camtel Fako wifi 1 90000 90000
Râme de papier formats 2 5000 10000
Rallonge 5 10000 50000
Câble croisé 6 500 3000
Charges courant électrique 5000 0
Connexion Internet (par mois)
6 25000 150000
honoraire (par mois) 6 450000 2700000

frais taxi (par mois) 6 20000 120000
Total TTC 6 611 500
4.2.2 Coût de déploiement

Ces couts sont récapitulés Il s’agit des couts liés au déploiement de la plateforme au sein de
l’entreprise. Nous ne prenons pas en compte les frais de maintenance ou la charge du personnel.

Tableau 4.2 : cout de déploiement

Catégories Produit quantité prix unitaire (en prix total
FCFA) (en FCFA)
Logiciels GlassFish 1 0 0
Serveur NTP 1 100000 100000
Oracle 11g 1 100000 100000
JDK1.8 1 0 0
Annuaire LDAP 1 0 0
Matériels Ordinateur desktop (HP Core i3) 70 250000 1750000

0
mprimante HP 20 35000 700000
Scanner HP 20 450000 9000000
Terminal Android 70 150000 1050000

(Motorola) 0
Serveur 5 100000 5000000

0
Disque dur 10 100 000 1000000
Total TTC 43 900 000
4.2.3 Coût de réalisation du SMSI

Il s’agit ici d’estimer le cout des équipements et modules de sécurité recommandés à la fin
de notre étude EBIOS. Nous estimons ces couts à la table 4.3.
Tableau 4.3 : coûts de sécurisation de la plateforme
Catégories produit fonction quantité prix unitaire prix total (en
(en FCFA) FCFA)
Logiciels Fortinet IPS+firewall 2 500 000 1 000 000
Kaspersky Internet Antivirus 1 2 000 000 2 000 000

Security (70 postes)
SNORT IPS Machine et 3 0 0

applicatif
Matériels -Baie de disque de pour le SAN 1 7000000 7 000 000

10To
Total TTC 10 000 000

A cet effet, le coût de mise en œuvre de la solution est de l’ordre de 50 511 500 FCFA. En
prenant en compte les frais de sécurité, on obtient environ 60 511 500 FCFA.
4.2.4 Evaluation du ROSI

Nous définissons le ROSI par la formule suivante [28]:
𝐩𝐞𝐫𝐭𝐞𝐬 é𝐯𝐢𝐭é𝐞𝐬 𝐩𝐚𝐫 𝐥𝐞 𝐒𝐌𝐒𝐈−𝐜𝐨𝐮𝐭 𝐒𝐌𝐒𝐈
𝐑𝐎𝐒𝐈 =
𝐜𝐨𝐮𝐭 𝐒𝐌𝐒𝐈
Pour évaluer les probabilités d’occurrences et les couts des risques dénoncés par notre
étude EBIOS, nous exploitons les résultats du rapport de l’institut américain Ponemon sur les
statistiques de cybercriminalité dans le monde [29] grâce à la table 4.4.
Tableau 4.4 : probabilité d’occurrence et cout associé aux risques par an
Risque Probabilité Cout en dollars Total (en dollars)
Virus, vers, chevaux de Troie 1 1579 1579
Logiciels malveillants 0,95 1517 1441,15
Injection de mauvais (comme 0,38 26787 10179,06
SQL Injection)
Vol de données 0,46 24968 11485,28
Déni de service 0,32 172 238 55116,16
Négligence du personnel 0,38 30 397 11550,86
Intrusion dans le réseau 0,38 166 251 63175,38
Total (en dollars) 152947,89
A cet effet, nous estimons le risque associé à notre plateforme à environ 152947,89 dollars
par an. Ayant recommandé la redondance des éléments critiques dans notre plateforme, il s’avère
que le taux de disponibilité passe à 1 − 𝑑 2 si d était la probabilité que le système se paralyse (déni
de service), 𝑑 vaut 0.322 soit 0.1. En outre, nous prenons pour hypothèses que l’antivirus
Kaspersky bloque 86,11% d’attaques liés aux logiciels malicieux, virus, ver, etc [30]. A cet effet,
la probabilité de suivre les attaques de virus, ver et chevaux de Troie passe à 0,14. En plus SNORT
peut détecter jusqu’à 40% des intrusions [31]. Ce qui permettrait alors de réduire le risque des
injections SQL de 0,6 ∗ 0,38 = 0,228. Notre SMSI nous permet alors de mettre à jour la table du
risque. La table 4.5 est une mise à jour de la table 4.4 après réévaluation des probabilités
d’occurrences des attaques.

Tableau 4.5 : estimation de la réduction du risque avec notre SMSI

Risque Probabilité Cout en dollars Total (en dollars)
Virus, vers, chevaux de Troie 0,14 1579 221,06

Logiciels malveillants 0,95 1517 1441,15
Injection de mauvais (comme 0,228 26787 6107,436
SQL Injection)
Vol de données 0,46 24968 11485,28
Déni de service 0,1 172 238 17223,8
Négligence du personnel 0,38 30 397 11550,86
Intrusion dans le réseau 0,38 166 251 63175,38
Total (en dollars) 111204,966
A cet effet, notre SMSI maintient le risque à environ 86 871,67 dollars par an. Ceci nous
évite alors à perdre en moyenne par an 152 947,89 − 111 204,966, soit 41742,924 dollars ou
encore 20 871 462 FCFA (il s’agit de la réduction en terme de pertes financières si notre système de
sécurité était pris en compte pendant le déploiement de la solution. C’est-à-dire si l’on déploie la
plateforme en prenant en compte le SMSI, on limiterait la valeur des impacts de moins de 20 871 462
FCFA par an). Comme notre SMSI nous coute environ 10 00 000 FCA l’année, le ROSI estimé est alors :
20 871 462−10 000 000
ROSI = 10 000 000
∗ 100 = 108,7%
4.3 Limites de la solution

4.3.1 Perspectives Techniques
Pour rendre plus performante la plateforme ainsi réalisée, nous proposons les travaux
suivant :
 intégration d’un moyen de paiement électronique pour rendre le service encore plus
flexible ;
 déléguer le fonctionnement de la PKI à une autre plateforme interne ou externe. Ceci
permettra à la plateforme de se concentrer uniquement sur le processus métier et par
conséquent une amélioration de ses performances.

4.3.2 Limites Humaines

La réussite de notre projet est tributaire de ses utilisateurs. En effet, le taux de camerounais
utilisant le commerce électronique est à peine 2% [32]. La réussite d’une telle plateforme doit passer
par une multiplication de publicités et une campagne de sensibilisation.
En outre, les utilisateurs ayant eu l’habitude de suivre le workflow sans logiciel de contrôle,
pourront paraître très méfiant vis-à-vis de l’arrivée de la plateforme.
Nous notons aussi que la certification électronique est un concept méconnu des citoyens. Il
faudra programmer des séminaires en conséquences, faire des animations vidéos très simple pour
montrer le rôle de la certification électronique.
4.3.3 Limites sur le plan sécuritaire

La sécurité est un tout. Lorsqu’un élément de la chaine dévient vulnérable le système entier
est exposé. Nous avons intégré dans notre plateforme des API fabriquées par des tiers et à cet effet,
la sécurité de notre système est tributaire de ces API. Il est donc judicieux de mettre des moyens en
œuvre pour développer nos propres API. En outre, les êtres humains constituent les premières failles
de sécurité dans les systèmes électroniques. Sur ce plan, nous recommandons de sensibiliser les
utilisateurs du système plus particulièrement les abonnés qui sont les principaux responsables de
leur sécurité. Par exemple si un abonné néglige sa clé privée, son identité est trivialement exposée
à une usurpation.
Bilan du chapitre
Tout au long de ce chapitre, il a été question pour nous de présenter les résultats obtenus dans
le cadre de la réalisation de la plateforme de dématérialisation des procédures d’abonnements de
CAMTEL dénommée « CAMTEL ONLINE SERVICE TOOLS ». C’est pourquoi, nous avons fait
ressortir le portail web composé de deux sous portails comme recommandé par notre SMSI à savoir
le portail d’administration et le portail pour les abonnés. Ce portail web est tributaire d’une
application Android permettant aux personnels : d’accéder en temps réels aux notifications à chaque
étape qu’ils sont sollicités par le workflow ; d’authentifier les documents par scannage de leurs code
QR et d’authentifier les CNI des abonnés par lecture des MRZ de leurs CNI. Le cout de
développement de la plateforme est d’environ 6 611 500FCFA tandis que son déploiement coute
environ 43 900 000 FCFA. Pour assurer la sécurité de la plateforme nous estimons un

investissement d’environ 10 000 000 FCFA, soit pour total d’environ 60 511 500 FCFA FCA. Les
investissements sur le plan sécuritaire permettent d’atteindre un retour d’investissement de l’ordre
de 108,7% soit au minimum 20 871 462 FCFA à éviter de perdre par an si en déployant le système
on prend en compte son SMSI. Dans cette mesure, il faut sensibiliser le personnel et développer nos
propres API pour rendre le risque le plus bas possible.

Conclusion Générale
5. Chapitre 5 : Conclusion Générale
Bilan et Démarche
Se questionnant sur comment améliorer le système d’abonnement chez CAMTEL, nous
nous sommes fixé pour objectif, la dématérialisation des procédures en passant par la réalisation
d’une plateforme web/mobile sécurisée pour gérer les différentes phases d’abonnements chez les
entreprises comme CAMTEL pour des services nécessitant une installation physique chez
l’abonné. Ce travail ne pouvait débuter sans une compréhension de l’existant dans le monde en ce
qui concerne la dématérialisation dans le but de proposer une solution innovante. Il fallait
également mettre l’accent sur la sécurité de la plateforme. C’est pourquoi nous avons mené une
étude guidée par la méthode EBIOS en vue de ressortir clairement les besoins et objectifs de sécurité
pour le fonctionnement de la plateforme avant même son développement qui s’est fait par une
analyse et une conception menées par la méthode RAD et la méthode MACAO. RAD nous a permis
de cadrer le projet et de le designer avec les modèle UML2.0. MACAO a pris la relève pour
proposer nos différents modèles SNI d’IHM à partir des diagrammes de classes et de cas
d’utilisation d’UML.
Résultats
L’originalité de notre plateforme par rapport aux plateformes existantes est qu’elle
implémente les fonctionnalités de : coffres forts électroniques, signature électronique, GED, OCR
et SIG comme certaines mais en dépit de cela, elle possède un SMSI pour la minimisation du risque
associé, et des IHM intuitives grâce à l’approche analytique MACAO. La plateforme ainsi réalisée
s’appelle « CAMTEL ONLINE SERVICE TOOLS » et dispose d’un module web/mobile et d’un
module Android. Cette réalisation a couté 60 511 500 FCFA en ne considérant que les couts de
développement, de déploiement et de sécurité. Le retour sur investissement de sécurité est estimé à
108,7% par an si l’on implémente le SMSI lors du déploiement de la plateforme.

Conclusion Générale
Recommandations
La certification électronique étant méconnue des citoyens, Il faut programmer des
séminaires en conséquences, faire des animations vidéos très simples pour montrer son rôle et ses
avantages. En outre il faut sensibiliser les utilisateurs dans l’optique de les encourager à se servir
de la plateforme tout en se conformant à la politique de sécurité mise sur pieds.
Perspectives
Le risque associé à la plateforme peut être encore réduit, si nous développons nos propres
API, pour QR et OCR (adapté au MRZ) afin de maitriser les risques associés. Aussi, il faut intégrer
un module de paiement en ligne et interconnecter notre plateforme au centre de contact pour le
suivi des réclamations.

Références Bibliographiques
[1] C. Lucot, Tout processus métier a sa dématérialisation : Quelle est la vôtre ?,

Lyon: Livre blanc, 2010, pp. 5-7.
[2] S. REKHIS, Intrusion Prevention, Detection, and Response, Tunis: SUP'COM,

2016, pp. 3-6.
[3] T. Murray, Immobilisation & Dematerialisation of Listed, London: Horatio

House, 2013, p. 6.
[4] O. JULIAN, La mise en place de la dématérialisation des dossiers de personnel

des établissements de France : de l’état de projet à leur communication, Paris, 2016,
pp. 22-28.
[5] J. B. Fontaine, Mise en place d'une GED, 2009, pp. 6-7. Master 2 ICD
GIDE. Lille 3.
[6] M. James, Rapid Application Development, Macmillan, 1991, pp. 2-25.
[7] D. P. Prosper, Analyse de la sécurité du système d’information de la C.A.A en

vue de l’obtention de la certification ISO 27001, 2009, pp. 3-8, 32. Mémoire
d'Ingénieur des Télécommunications. ENSPT. Yaoundé.
[8] AFNOR, «Spécifications relatives à la conception et à l’exploitation de

systèmes Informatiques en vue d’assurer la conservation et l’intégrité des documents
stockés dans ces systèmes, norme AFNOR NF Z42-013,» Paris, 2001.
[9] D. T. A. José, Conception d’une plateforme d’échanges et d’archivage

numérique sécurisé des documents personnels et administratifs au sein de Camtel :
GedTel, 2015, pp. 16-24, 31-42. Mémoire d'Ingénieur des Télécommunications.
ENSP.
[10] Bibliothèque Nationale de France, Réferentiel OCR, Paris: Bibliothèque

Nationale de France, 2013, p. 7.

[11] G. Raymond, SOA : Architecture Logique, 2.1 éd., Paris: Livre blanc, 2011, p.
19.
[12] S. G. E. Fatmi, La sécurité des e-services, Yaoundé: SUP'COM, 2016, pp.

3,7,38.
[13] CLUB 270001, BENCHMARK DES OUTILS SMSI, Paris: Livres Blancs,
2013, p. 6.
[14] J.-L. Parouty, R. Dirlewanger et D. Vaufreydaz, «La signature électronique,

contexte, applications et mise en œuvre,» JRES, Novembre 2003.
[15] J.-L. R. E. T. S. V. Jean-Guillaume Dumas, Théorie des codes, Paris: Dunod,

2007, p. 354.
[16] B. ZOUARI, Ingénierie de la Sécurité, Yaoundé: SUP'COM, 2016.
[17] M. S. Haque et R. Dybowski, «Advanced QR Code Based Identity Card,» First

International Conference on Systems Informatics, Modelling and Simulation, p. 77,
2014.
[18] CERTISSIM, La fraude dans le -ecommerce, Paris: Livre Blanc, 2014, p. 25.
[19] M. L. AURELLE, Mise en Place d'une plateforme de signature et de notariat

Numériques, Yaoundé: ENSP, 2014, pp. 10-16. Mémoire d'Ingénieur des
Télécommunications, ENSP. Yaoundé.
[20] J.-P. Vickoff, Méthode RAD, Le Développement Rapide d'Applications, Paris:

RAD.fr, 2000, pp. 3-18.
[21] C. DELANNOY, Programmer en Java, vol. 3, Paris: Eyrolles, 2010, p. 6.
[22] A. Bacco, Développez votre site web avec le framework Symfony2, OC, 2013,
p. 9.
[23] J. Crampes, MODELISATION ET METHODOLOGIE DE CONCEPTION

D’UNE IHM, LA, Ellipses, 2003.
[24] «Premiers pas avec JSF,» [En ligne]. Available:

http://www.openclassrooms.com. [Accès le 15 06 2016].

[25] statistiques sur les utilisateurs-de-smartphones [En ligne]. Available:

https://blog.socialreflex.fr/2012/03/26/statistiques-sur-les-utilisateurs-de-
smartphones/. [Accès le 18 6 2016].
[26] CommentCaMarche, «Oracle - Introduction au SGBD Oracle,» [En ligne].

Available: http://www.commentcamarche.net. [Accès le 7 7 2016].
[27] D. Hook, Begenning cryptography with Java, 2008.
[28] enisa, Introduction On Security Investment, Heraklion: ensia, 2012, p. 2.
[29] Ponemon Institute, 2012 Cost of Cyber Crime Study:, Michigan: HP Enterprise
Security, 2012, pp. 10-13.
[30] Kaspersky, Kaspersky Security for Virtualization, USA: Kaspersky Lab, 2012,
p. 2.
[31] T. Kaur et S. Kaur, «Comparative Analysis of Anomaly Based and Signature,»

SPsymposuim, p. 2, 2013.
[32] .investiraucameroun, «Le taux de pénétration du e-commerce au Cameroun

atteint à peine 2%,» [En ligne]. Available:
http://www.investiraucameroun.com/tic/1704-6274-le-taux-de-penetration-du-e-
commerce-au-cameroun-atteint-a-peine-e-2. [Accès le 28 Juin 2016].

Annexes
Annexe
Annexe 1 : Présentation de CAMTEL
I. Plan de Localisation de CAMTEL centre

Par TZORNEU NGANSOP Patrick xi
Annexes
II. Organigramme des directions de CAMTEL

-
Direction Génerale
DG
Directeur Directeur
Géneral Adjoint 1 Général Adjoint 2
DG 1 DG 2
Services Rattachés à la
Administratrion Centrale Services Exterieurs
Direction Générale
SRDG AC SE
Direction des Réseaux IP du

Direction Marketing et Direction des Achats et du Direction des Direction de la Planification Multmédia et des DIrection des Finances et du DIrection des Ressources
DIrection Commerciale
Communication PAtrimoine infrastructures de Projets Plateformes de Serviecs Budget Humaines
(DRIMS)
DMC DAP DI DPP DRIMS DC DFB DRH
Département Sécurité des Centre National de

Service Statistique et Département des Systèmes Département des Département des Réseau IP Centre National des Centre d'hebergement Web
Systèmes d'Inforation et Supervison des Réseaux et Centre de Services Support
Reporting d'information Plateformes de Services et Réseaux d'entreprises Services MAnagés et de messagerie
des Communications Sytèmes
service de developpement service d'exploitation des

10 développeurs
et datamining applications

Par TZORNEU NGANSOP Patrick xii
Annexes
Annexe 2: fiche de demande d’installation FTTH

Par TZORNEU NGANSOP Patrick xiii
Annexes
Annexe 3 : SAN [7]

Le SAN est un réseau de stockage ouvert et évolutif qui relie, à des périphériques de
stockage, des serveurs/stations et postes de travail, par ailleurs reliés au réseau d'entreprise. Les
technologies d’interconnexion utilisées pour la création d’un SAN sont Fibre Channel et ISCSI.
La Fibre Channel bénéficie d’un standard établi, d’un grand nombre de résultats d’interopérabilité
et, grâce à un support physique de type cuivre ou fibre optique, permet une connexion à grande
vitesse sur de grandes distances. La Fibre Channel répond aux architectures complexes exigeant des
hautes performances, de fortes consolidations de stockage et pour les applications critiques d'une
entreprise. Fibre Channel affiche des performances optimales sur fibre optique avec, des distances
entre noeuds pouvant atteindre 10 km, et une bande passante, plus rapide que le SCSI : 1 Go/s, 2
Go/s et 4 Go/s. L’iSCSI(Internet Small Computer System Interface) est apparu plus tard et permet
l’encapsulation des commandes SCSI via le protocole IP, ce qui permet sa rapide intégration dans
l’infrastructure existante de l’entreprise. Bien que moins rapide que la fibre channel, il reste
performant et permet de ne pas avoir à investir dans un très coûteux équipement fibre optique. Le
SAN rend totalement virtuel l'espace de stockage et travaille au niveau des blocs. Ceci permet le
partage centralisé des données via des "Switch" intelligents. Grâce à la gestion centralisée, les coûts
d'administration du stockage diminuent de 70 à 90 % d’après CISCO. De même, le partage des
ressources et la consolidation d'îlots de stockage réduisent la capacité inutilisée, et le réseau dédié
permet de décharger le réseau local du trafic occasionné par les sauvegardes et autres transactions.

Par TZORNEU NGANSOP Patrick xiv
Annexes
Annexe 4 : SOAP [12]

Caractéristiques :
 Protocole de transmission de messages dont le but est de sécuriser le transfert de messages
 Basé sur un ensemble de règles
 Indépendant des protocoles, des systèmes d’exploitation et des langages utilisés
 Généralement: fonctionne sous HTTP ou SMTP
Le modèle SOAP
 Construit par le biais de ‘jetons de sécurité’, combinés avec des signatures
numériques pour protéger et authentifier les messages SOAP.
 ‘jeton de sécurité’: une liste de droits (ou privilèges (claims))
 ‘Claim’: information incluse dans le jeton par une entité et englobant le nom,
l’identité, le groupe, les clés, les privilèges,…)
 ‘jeton de sécurité signé’: jeton signé par une autorité de confiance à l’exemple:
certificat numérique du type X509.
 un jeton de sécurité signé peut être utilisé pour garantir les liens entre des éléments
d’authentification et l’identité principale (identité du propriétaire de la clé).
 En absence d’une approbation par une autorité ou un tiers de confiance, le jeton ne
peut garantir les droits qu’il contient.
Entête SOAP :

Par TZORNEU NGANSOP Patrick xv

La Dematerialisation Des Procedures D'abonnement: Cas de Camtel

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

La Dematerialisation Des Procedures D'abonnement: Cas de Camtel

Transféré par

Droits d'auteur :

Formats disponibles

REPUBLIQUE DU CAMEROUN REPUBLIC OF CAMEROON

Paix – Travail – Patrie Peace – Work – Fatherland

ECOLE NATIONALE SUPERIEURE NATIONAL ADVANCED SCHOOL OF

DIVISION TECHNIQUE DES TECHNICAL TELECOMMUNICATIONS

Soutenu publiquement le 18 Février 2017

Année Académique : 2015-2016

Mémoire d’Ingénieur en Télécommunications, SUP’TIC 2016

Mémoire d’Ingénieur en Télécommunications, SUP’TIC 2016

CAMTEL Cameroon Telecommunication

NTP Network Time Protocol

Mémoire d’Ingénieur en Télécommunications, SUP’TIC 2016

Mots clés : Dématérialisation, Géolocalisation, MRZ, QR, SMSI, Workflow.

Mémoire d’Ingénieur en Télécommunications, SUP’TIC 2016

CAMTEL encounters difficulties in its procedures of subscriptions requiring physical

Keywords: Dematerialization, Geolocalisation, ISMS, MRZ, QR, Workflow.

Mémoire d’Ingénieur en Télécommunications, SUP’TIC 2016

Mémoire d’Ingénieur en Télécommunications, SUP’TIC 2016

Mémoire d’Ingénieur en Télécommunications, SUP’TIC 2016

Mémoire d’Ingénieur en Télécommunications, SUP’TIC 2016

TABLEAU 2.1 : SYNTHESE DES TRAVAUX ANTERIEURS 19

TABLEAU 3.1 : ETUDE COMPARATIVE D’API DE PKI 24

TABLEAU 3.2 : ETUDE COMPARATIVE DES API DE GESTION DES CODES QR 25

TABLEAU 3.3 : ETUDE COMPARATIVE DES OCR 25

TABLEAU 3.4 : ETUDE COMPARATIVE DES SOLUTIONS DE CARTOGRAPHIE WEB 26

TABLEAU 3.5 : ENVIRONNEMENT DE DEVELOPPEMENT ET DE TESTS 27

TABLEAU 3.6 : ELEMENTS ESSENTIELS DU SI 30

TABLEAU 3.7 : RESSOURCES UTILISEES PAR LE SYSTEME CIBLE. 30

TABLEAU 3.8 : MATRICE D’UTILISATION DE RESSOURCES PAR LE SYSTEME CIBLE. 31

TABLEAU 3.9 : ECHELLE DES BESOINS DE SECURITE 31

TABLEAU 3.10 : EXPRESSIONS DES BESOINS DE SECURITE DES ACTIFS DE LA PLATEFORME 32

TABLEAU 3.11 : VULNERABILITES DE LA PLATEFORME 33

TABLEAU 4.1 : COUTS DE DEVELOPPEMENT DE LA PLATEFORME 77

TABLEAU 4.2 : COUT DE DEPLOIEMENT 79

TABLEAU 4.3 : COUTS DE SECURISATION DE LA PLATEFORME 79

TABLEAU 4.4 : PROBABILITE D’OCCURRENCE ET COUT ASSOCIE AUX RISQUES PAR AN 80

TABLEAU 4.5 : ESTIMATION DE LA REDUCTION DU RISQUE AVEC NOTRE SMSI 81

Mémoire d’Ingénieur en Télécommunications, SUP’TIC 2016

1. chapitre1 : Introduction Générale

Mémoire d’Ingénieur en Télécommunications, SUP’TIC 2016

de télécommunication (Orange, Nexttel, MTN, CAMTEL), d’une dizaine de MVNO (Vodafone,

Mémoire d’Ingénieur en Télécommunications, SUP’TIC 2016

Figure 1.1 : architecture logique du Système NGBSS

Mémoire d’Ingénieur en Télécommunications, SUP’TIC 2016

1.3 Objectifs et motivations

Mémoire d’Ingénieur en Télécommunications, SUP’TIC 2016

1.5 Plan du travail

Mémoire d’Ingénieur en Télécommunications, SUP’TIC 2016

2. Chapitre 2 : Etat de l’art

2.1 Concepts théoriques

Mémoire d’Ingénieur en Télécommunications, SUP’TIC 2016

Figure 2.1 : les étapes de la dématérialisation

Mémoire d’Ingénieur en Télécommunications, SUP’TIC 2016

recouvrement, la fiabilisation de la chaîne financière et la diminution des coûts de

2.1.2 Les E-services et leur sécurité

Mémoire d’Ingénieur en Télécommunications, SUP’TIC 2016

Mémoire d’Ingénieur en Télécommunications, SUP’TIC 2016

permet de substituer facilement un E-service par un autre dans l’architecture du SI et

Mémoire d’Ingénieur en Télécommunications, SUP’TIC 2016

2.1.3 Signature électronique et la certification électronique

Mémoire d’Ingénieur en Télécommunications, SUP’TIC 2016

Figure 2.2 : principe des algorithmes de chiffrement asymétriques [14]

2.1.3.1.2 Les fonctions de hachages

Figure 2.3 : Principe d’une fonction de hachage [15]