SlideShare une entreprise Scribd logo
1  sur  90
Télécharger pour lire hors ligne
Ministère de l’Enseignement Supérieur, de la Recherche Scientifique et de
l’Innovation
(M.E.S.R.S.I)
------------------
Secrétariat Général
------------------
Université Nazi BONI (U.N.B.)
------------------
ÉCOLE SUPERIEURE D’INFORMATIQUE (E.S.I)
Cycle des Ingénieurs de Travaux Informatiques (C.I.T.I)
Option : Analyse et Programmation (A.P)
RAPPORT DE FIN DE CYCLE
Période du 01 Septembre 2016 au 31 Janvier 2017
Auteurs : M. LANKOANDE Yiénouyaba & M. OUEDRAOGO Soufiane
Thème : « Mise en place d'une plateforme de suivi de l'exploitation
des Adductions d'Eau Potable Simplifiées (A.E.P.S). »
Maître de stage
M. Malick TAPSOBA
Directeur de la Formation et
de la Promotion des TIC
à l’ANPTIC.
Superviseur
Dr Borlli Michel Jonas SOME
Enseignant Chercheur
Ecole Supérieure d’Informatique
Année académique 2015-2016
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 2
AVANT-PROPOS
L’Ecole Supérieure d’Informatique est un institut au sein de l’Université Nazi BONI. Elle
propose à ses étudiants deux diplômes, dont le premier, l’Ingéniorat de Travaux Informatiques,
marque la fin des études du premier cycle. Ce diplôme du Cycle d’Ingénieurs de Travaux
Informatiques n’est accordé qu’aux étudiants ayant validé trois (03) années d’études, et démontré
leurs capacités lors d’un stage pratique d’au moins trois mois en entreprise.
C’est dans cette logique que nous avons été accueillis, pour notre stage de fin de cycle au
sein de l’Agence Nationale de Promotion des Technologies de l’Information et de la
Communication, placée sous la tutelle du Ministère du Développement de l’Economie Numérique
et des Postes. Le contexte dans lequel nous avons évolué a clairement été défini par un contrat de
stage dans lequel étaient décrits entre autres le thème de stage, le règlement intérieur et les
conditions de travail dans l’entreprise.
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 3
REMERCIEMENTS
Nous tenons à remercier dans un premier temps, toute l’équipe pédagogique de l’Ecole
Supérieure d’Informatique et les intervenants professionnels pour avoir assuré la majeure partie de
notre formation. Nous remercions également toute l’équipe professionnelle de l’Agence Nationale
de la Promotion des Technologies de l’Information et de la Communication pour nous avoir
accueillis, suivis et encadrés pendant cette période de stage.
Nos vifs remerciements particuliers vont à l’endroit de :
Dr Borlli Michel Jonas SOME, Enseignant chercheur à l’ESI, notre superviseur ;
M. Malick TAPSOBA, Directeur de la Formation et de la Promotion des TIC à
l’ANPTIC, notre maître de stage ;
Toute l’équipe de l’IRC pour sa brillante collaboration ;
M. Moustapha SABA, Ingénieur de Conception à l’ANPTIC pour son assistance et ses
multiples conseils.
Pour finir, nous témoignons de notre gratitude à tous ceux qui, d’une manière ou d’une autre, ont
contribué à notre formation ou à la réussite de ce travail.
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 4
RESUME
L'accès à l'eau potable et à l'assainissement demeure un enjeu majeur au Burkina Faso.
Conscient de cela, le gouvernement à travers le programme national d’approvisionnement en eau
potable et d’assainissement a mis en place des adductions d’eau potable simplifiées dans les centres
semi-urbains et ruraux, afin d’accroître considérablement le taux d’accès à l’eau potable.
L’exploitation de ces adductions d’eau potable simplifiées est confiée à des opérateurs privés qui
doivent continuellement rendre compte de leur gestion. Ce compte rendu devrait permettre à l’Etat
de suivre l’évolution de ces ouvrages, mais l’on relève des difficultés dans la collecte et l’accessibilité
des informations sur l’exploitation des adductions d’eau potable simplifiées. Pour pallier ces
difficultés, il s’avère nécessaire de mettre en place une plateforme de suivi de l’exploitation des
adductions d’eau potable simplifiées.
Ce travail fournit un effort d’analyse, de conception et de développement d’une application
web pour résoudre la problématique posée. La conception faite avec Unified Modeling Language et
le processus Two Track Unified Process permet de regrouper les fonctionnalités en neuf (09)
modules qui sont : gestion des Adductions d’Eau Potable Simplifiées (AEPS), gestion des rapports,
gestion des indicateurs de performances, messagerie, gestion des statistiques, gestion des
utilisateurs, gestion de la géolocalisation, gestion du renouvèlement des équipements et gestion des
commentaires. Ces différents modules ont été développés avec le Framework Symfony et Maria
DB comme système de gestion de base de données.
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 5
ABSTRACT
Access to drinking water and sanitation remains a major challenge in Burkina Faso. Aware
of this, the Government through the national program of drinking water supply and sanitation has
implemented the simplified drinking water providers in the semi-urban and rural centers, in order
to significantly increase the rate of access to safe water. The simplified drinking water providers’
operation is entrusted to private operators who continually are accountable for their management.
This account will allow the State to follow the evolution of these structures, however there are
difficulties in collecting and the accessibility of the information on the exploitation of the simplified
drinking water providers. To surmount these difficulties, it is necessary to set up a platform to
follow-up the exploitation of simplified drinking water providers. This document provides an effort
of analysis, design and web application development to solve the raised problem.
The design made with Unified Modeling Language and Two Track Unified Process allows
to group features in nine (09) modules which are: management of simplified drinking water
provider, management of reports, indicators of performance, e-mail management, management of
Statistics, user’ management, management of geolocation, management of equipment renewal and
management of comments. These modules have been developed on the web platform PHP with
Symfony Framework and Maria DB the database management system
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 6
TABLE DES MATIERES
AVANT-PROPOS ............................................................................................................................. 2
REMERCIEMENTS...........................................................................................................................3
RESUME........................................................................................................................................... 4
ABSTRACT........................................................................................................................................5
TABLE DES MATIERES.................................................................................................................. 6
LISTE DES TABLEAUX................................................................................................................... 9
LISTE DES FIGURES......................................................................................................................10
LISTE DES ABREVIATIONS, SIGLES ET ACRONYMES .............................................................11
INTRODUCTION GENERALE......................................................................................................13
CHAPITRE 1 : PRESENTATION DU CONTEXTE DE STAGE....................................................14
1.1 Introduction.......................................................................................................................15
1.2 Présentation de l'ESI ..........................................................................................................15
1.2.1 Présentation générale ......................................................................................................15
1.2.2 Formation......................................................................................................................16
1.2.3 Organigramme de l’ESI...................................................................................................17
1.3 Présentation de l’agence nationale de promotion des TIC .....................................................17
1.3.1 Généralités.....................................................................................................................17
1.3.2 Objectifs et missions.......................................................................................................17
1.3.3 Organes d’administration et de direction ..........................................................................19
1.3.4 Organigramme de l’ANPTIC...........................................................................................20
1.3.5 Présentation de l’IRC......................................................................................................21
1.4 Présentation du projet.........................................................................................................21
1.4.1 Problématique ................................................................................................................21
1.4.2 Objectifs et Résultats attendus.........................................................................................23
1.4.3 Gestion de projet............................................................................................................24
1.4.4 Le Planning prévisionnel.................................................................................................25
1.5 Conclusion........................................................................................................................ 26
CHAPITRE 2 : DEMARCHE ET MOYENS DE REALISATION ....................................................27
2.1 Introduction.......................................................................................................................28
2.2 Exigences fonctionnelles et techniques ................................................................................28
2.3 Méthode de résolution du problème ................................................................................... 29
2.3.1 Choix du langage de modélisation................................................................................... 29
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 7
2.3.2 Choix de la méthode d’analyse et de conception ...............................................................30
2.4 Estimation du coût du projet...............................................................................................31
2.4.1 Méthode de calcul du coût...............................................................................................31
2.4.2 Différents coûts..............................................................................................................32
2.5 Conclusion.........................................................................................................................33
CHAPITRE 3 : DOMAINE D'ETUDE.............................................................................................34
3.1 Introduction.......................................................................................................................35
3.2 Etude de l’existant ..............................................................................................................35
3.2.1 Le parc informatique.......................................................................................................35
3.2.2 Les applications réalisées.................................................................................................36
3.2.3 Architecture réseau .........................................................................................................37
3.3 Délimitation et analyse du domaine .....................................................................................37
3.3.1 Identification des concepts clés du domaine. ....................................................................38
3.3.2 Le dictionnaire de données..............................................................................................38
3.3.3 Le diagramme de classes..................................................................................................39
3.4 Conclusion.........................................................................................................................42
CHAPITRE 4 : SPECIFICATIONS DU FUTUR SYSTEME.............................................................43
4.1 Introduction...................................................................................................................... 44
4.2 Identification des acteurs et des cas d'utilisation................................................................... 44
4.2.1 Identification des acteurs du système .............................................................................. 44
4.2.2 Identification des cas d’utilisation ................................................................................... 44
4.2.3 Description textuelle de quelques cas d’utilisation............................................................ 46
4.3 Diagramme des cas d'utilisation...........................................................................................50
4.4 Diagrammes de séquences...................................................................................................51
4.4.1 Authentification..............................................................................................................51
4.4.2 Gérer un incident............................................................................................................52
4.4.3 Gérer un équipement à renouveler...................................................................................53
4.5 Conclusion.........................................................................................................................54
CHAPITRE 5 : ARCHITECTURE DU SYSTEME FUTUR ..............................................................55
5.1 Introduction.......................................................................................................................55
5.2 Identification des composantes logicielles ............................................................................55
5.2.1 Plateforme de développement .........................................................................................55
5.2.2 Système de Gestion de Bases de Données ........................................................................56
5.2.3 Le Framework ORM.......................................................................................................56
5.2.4 Environnement de développement ..................................................................................57
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 8
5.2.5 Librairies........................................................................................................................57
5.3 Architecture logicielle .........................................................................................................57
5.3.1. Diagramme de packages..............................................................................................57
5.3.2. Diagramme de déploiement ...............................................................................................58
5.4 Conclusion.........................................................................................................................59
CHAPITRE 6 : CONCEPTION DE LA SOLUTION ...................................................................... 60
6.1 Introduction......................................................................................................................61
6.2 Diagramme de classes d'application .....................................................................................61
6.3 Schémas logique et physique des données ........................................................................... 64
6.4 Conclusion........................................................................................................................ 66
CHAPITRE 7 : REALISATION ET BILAN......................................................................................67
7.1 Introduction...................................................................................................................... 68
7.2 Modules développés .......................................................................................................... 68
7.3 Enchaînement des écrans................................................................................................... 68
7.3.1 Interface pour utilisateur non-connecté........................................................................... 68
7.3.2 Interface pour utilisateurs principaux du système. .............................................................73
7.4 Analyse des écarts...............................................................................................................82
7.4.1 Le Planning réel..............................................................................................................82
7.4.2 Explication des écarts......................................................................................................82
7.4.3 Résultats obtenus............................................................................................................83
7.5 Politique de sécurité............................................................................................................83
7.5.1 Notion de sécurité..............................................................................................................83
7.5.2 Gestion des mots de passe et de la connexion à l’application.................................................83
7.5.3 Gestion des attaques.......................................................................................................... 84
7.5.4 Mise en place de la sauvegarde et de la restauration ..............................................................85
7.5.5 Protection contre les catastrophes ...................................................................................... 86
7.6 Conclusion.............................................................................................................................. 86
CONCLUSION GENERALE...........................................................................................................87
LISTE DES REFERENCES BIBLIOGRAPHIQUES........................................................................88
BIBLIOGRAPHIE........................................................................................................................88
WEBOGRAPHIE........................................................................................................................ 89
ANNEXE 1 SYMFONY.................................................................................................................. 90
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 9
LISTE DES TABLEAUX
Tableau 1 : Coût de développement...................................................................................................32
Tableau 2 : Coût de formation des utilisateurs....................................................................................32
Tableau 3 : Coût total de réalisation...................................................................................................32
Tableau 4 : Liste de quelques applications..........................................................................................36
Tableau 5 : Description du concept AEPS.........................................................................................38
Tableau 6 : Description du concept Rapport......................................................................................38
Tableau 7 : Description du concept Opérateur...................................................................................39
Tableau 8 : Description du concept Incident......................................................................................39
Tableau 9 : Principales règles de gestion.............................................................................................40
Tableau 10 : Liste des cas d'utilisation................................................................................................45
Tableau 11 : Description du CU Gérer un incident ............................................................................ 46
Tableau 12 : Description du CU Gérer une AEPS..............................................................................47
Tableau 13 : Description du CU S'authentifier................................................................................... 48
Tableau 14 : Description du CU Gérer un équipement à renouveler ................................................... 49
Tableau 15 : Description de la classe Gaeps ...................................................................................... 62
Tableau 16 : Description de la classe GIncident..................................................................................63
Tableau 17 : Description de la classe GIndicateur.............................................................................. 64
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 10
LISTE DES FIGURES
Figure 1 : Organigramme de l'ESI.......................................................................................................17
Figure 2 : Organigramme de l'ANPTIC...............................................................................................20
Figure 3 : Diagramme de GANTT du planning prévisionnel ............................................................... 26
Figure 4 : Architecture réseau .............................................................................................................37
Figure 5 : Diagramme de classes .........................................................................................................41
Figure 6 : Diagramme de cas d'utilisation.............................................................................................50
Figure 7 : Diagramme de séquences du cas d’utilisation « s'authentifier » ...............................................51
Figure 8 : Diagramme de séquences du cas d'utilisation « Gérer un incident » ........................................52
Figure 9 : Diagramme de séquences du cas d'utilisation « Gérer un équipement à renouveler » ...............53
Figure 10 : Diagramme de packages ....................................................................................................58
Figure 11 : Diagramme de déploiement...............................................................................................59
Figure 12 : Modèle physique de donnée...............................................................................................65
Figure 13 : Interface d’accueil (1) ....................................................................................................... 69
Figure 14 : Interface d’accueil (2) ........................................................................................................70
Figure 15 : Interface détails d'une AEPS.............................................................................................. 71
Figure 16 : Visualisation des branchements d'une AEPS.......................................................................72
Figure 17 : Formulaire de connexion...................................................................................................73
Figure 18 : Interface accueil pour utilisateur authentifié........................................................................74
Figure 19 : Accueil du module Gestion AEPS......................................................................................75
Figure 20 : Interface d'ajout d'une BF..................................................................................................76
Figure 21 : Volet édition d'un rapport ................................................................................................. 77
Figure 22 : Liste des rapports..............................................................................................................78
Figure 23 : Visualisation d'un rapport soumis.......................................................................................79
Figure 24 : Situation des BF sous formes de graphes............................................................................80
Figure 25 : Visualisation des charges d'exploitation ..............................................................................81
Figure 26 : Diagramme de GANTT du planning réel ...........................................................................82
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 11
LISTE DES ABREVIATIONS, SIGLES ET
ACRONYMES
2TUP Two Track Unified Process
AEPS Adduction d’Eau Potable Simplifiée
AJAX Asynchronous Javascript And XML
ANPTIC Agence Nationale de Promotion des TIC
API Application Programming Interface
BF Borne Fontaine
BODI Burkina Open Data Initiative
BP Branchement Privé
CAT Cellule d’Appui Technique
CITI Cycle d’Ingénieurs de Travaux Informatiques
CU Cas d’Utilisation
DCT Département de la Comptabilité et de la Trésorerie
DDM Département du Développement et de la Maintenance
DDRH Département du Développement des Ressources Humaines
DE Département des Etudes
DEA Département de l’Exploitation des Applications
DEAT Département des Equipements et de l’Assistance Technique
DEI Direction des Etudes et de l’Ingénierie
DESR Département de l’Exploitation et du Support Réseaux
DEST Direction de l'Exploitation et du Support Technique
DFB Département des Finances et du Budget
DFC Direction des Finances et de la Comptabilité
DFCO Département de la Formation Continue
DFPTIC Direction de la Formation et de la Promotion des TIC
DG Direction Générale
DGAP Département de Gestion Administrative et de Paie
DGEP Direction Générale de l’Eau Potable
DIC Département de l’Innovation et de la Certification
DICOM Département des Infrastructures de Communication
DIG Direction de l’Intranet Gouvernementale
DME Département de la Mise en Exploitation
DMPI Département des Marchés de Prestations Intellectuelles
DMTS Département des Marchés de Travaux et Biens de Services
DMZ DeMilitarized Zone
DNIS Département de la Normalisation et de l’Intégration des Systèmes
DOC Département des Outils de Communication
DPA Département du Patrimoine et de l’Approvisionnement
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 12
DPOTIC Département de la Promotion des Outils des TIC
DREA Direction Régionale de l’Eau et de l’Assainissement
DRH Direction des Ressources Humaines
DS Département de la Sécurité
DSA Direction des Systèmes Applicatifs
DVP Département de la Veille et de la Prospective
ESI Ecole Supérieure d’Informatique
HTML HyperText Markup Language
IDE Integrated Development Environment
IRC International Water and Sanitation Center
JEE Java Enterprise Edition
LMD Licence Master Doctorat
OMT Object Modeling Technique
OOSE Object Oriented Software Engineering
PDF Portable Document Format
PDF Portable Document Format
PHP Php HyperText Preprocessor
PMH Pomme à Motricité Humaine
PRM Personne Responsable des Marchés
RESINA Réseau Informatique Nationale de l’Administration
SAI Service d’Audit Interne
SAJ Service des Affaires Juridiques
SCMRP Service de la Communication, du Marketing et des Relations Publiques
SG Secrétariat General
SGBD(R) Système de Gestion de Base de Données (Relationnelle)
SDWP Simplified Drinking Water Provider
SP Secrétariat Particulier
SQL Structured Query Language
TIC Technologies de l’Information et de la Communication
UML Unified Modeling Language
UNB Université Nazi BONI
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 13
INTRODUCTION GENERALE
Le Ministère du Développement de l’Economie Numérique et des Postes a
initié en 2013 le Burkina Open Data Initiative. Ce projet vise à encourager les services
publics, du secteur privé et de la société civile, à mettre à disposition de façon libre
et gratuite, des données électroniques qui constituent un patrimoine immatériel qui
pourront être ensuite exploitées pour créer de la valeur ajoutée par le développement
de e-services et de startup pour promouvoir le développement de l’économie
numérique. C'est dans ce cadre que l'ANPTIC, structure chargée du projet nous a
confié l'étude et la mise en place d'une application web devant permettre la collecte
et le partage d’informations sur l'exploitation des adductions d'eau potable
simplifiées. L’objectif de cette application est de présenter un cas de réutilisation de
données ouvertes publiées sur la plateforme officielle de BODI.
Dans le présent rapport qui s’articule autour de sept (07) chapitres, il sera
question dans un premier temps de faire une présentation succincte de la structure
d’accueil et du cadre général du thème, ensuite sera exposée l’analyse du système,
puis viendra la conception détaillée et enfin une présentation de la solution
implémentée et un bilan du travail.
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 14
CHAPITRE 1 : PRESENTATION
DU CONTEXTE DE STAGE
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 15
1.1 Introduction
Le passage du milieu universitaire à celui de l’entreprise n’est pas toujours
aisé, encore moins dans le cadre d’un stage. Dans ces conditions il s’avère nécessaire
de connaître le fonctionnement interne de l’entreprise ainsi que son mode de
communication afin de faciliter son intégration.
Le présent chapitre est le lieu de revenir d’abord sur l'organisation
administrative de l'école et le dispositif pédagogique. Ensuite il sera question pour
nous de présenter notre structure d’accueil l’ANPTIC, son historique et ses domaines
d’intervention. Nous évoquerons par la suite, la problématique et les résultats
attendus de notre étude pour finir par une proposition de solution aux problèmes
posés.
1.2 Présentation de l'ESI
1.2.1 Présentation générale
L’Ecole Supérieure d’Informatique a été créée en 1991 à Ouagadougou et transférée
en 1995 au sein de l’Université Polytechnique de Bobo-Dioulasso, devenue
aujourd’hui Université Nazi BONI. L’ESI a pour mission :
• La formation fondamentale, appliquée et/ou professionnelle dans les
domaines de l’informatique ;
• La formation continue ;
• La recherche scientifique et technologique ainsi que la valorisation des
résultats de la recherche ;
• La diffusion de la culture et de l’information dans les domaines relevant de sa
compétence ;
• La collaboration avec d’autres structures de formation et/ou de recherche
pour la préparation des diplômes ;
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 16
• Et la participation à des programmes internationaux de formation et de
recherche.
1.2.2 Formation
L’ESI a connu deux systèmes d’enseignement, le système classique de 1991 à 2010
et le système Licence Master Doctorat à la rentrée de 2010-2011. La formation à
l’ESI est sanctionnée par les diplômes suivants :
• Une License d’informatique ;
• Un diplôme d’ingénieur de conception informatique.
1.2.2.1 Licence d’informatique
Ce cycle a pour objectif de former des cadres moyens, opérationnels et évolutifs dans
une diversité de domaine d’applications de l’Informatique. La durée de formation
pour ce cycle est de trois (03) ans répartis en deux années de tronc commun et une
année de spécialisation dans l’un des domaines suivants : l’ingénierie des systèmes
d’information et l’ingénierie des réseaux et systèmes. Les étudiants de ce cycle
doivent effectuer à la fin de leur formation un stage pratique obligatoire et réaliser
un projet de fin de cycle. Le stage pratique vise à garantir une intégration rapide des
futurs diplômés en milieu professionnel et doit s’effectuer en entreprise (publique ou
privée) ou dans une administration publique.
1.2.2.2 Cycle des Ingénieurs de Conception Informatique
Pour ce cycle, la durée de formation est de deux (02) ans. Elle est ouverte aux
titulaires d’un diplôme de niveau BAC+3 en informatique. A ce niveau également,
les étudiants doivent effectuer pendant leur formation de première année, un stage
en entreprise et réaliser un mémoire de fin de cycle faisant l’objet d’une soutenance
publique en deuxième année.
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 17
1.2.3 Organigramme de l’ESI
L’organisation de l’ESI peut être illustrée par l’organigramme de la figure 1
Figure 1 : Organigramme de l'ESI
1.3 Présentation de l’agence nationale de promotion des TIC
1.3.1 Généralités
L’ANPTIC est une agence publique à caractère administratif créée en février 2014
afin de répondre à la volonté politique des autorités burkinabè de faire des TIC un
levier de développement de l’économie nationale. Elle est l'autorité technique
nationale en matière de réalisation des projets et programmes relatifs aux TIC au
Burkina Faso.
1.3.2 Objectifs et missions
L’ANPTIC a pour missions d'une part l'opérationnalisation de la stratégie du
gouvernement en matière d'administration électronique et d'autre part, la promotion
de l'utilisation des TIC dans les autres domaines de développement social,
économique, scientifique et culturel.
Directeur
Directeur des
études
Directeur des
stages
Secrétaire
Chef de services
des affaires
financières
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 18
A ce titre, elle est chargée :
En matière d'administration électronique :
• D’assurer l’exploitation, le développement et la maintenance du RESINA ;
• D’assurer l'exploitation, le développement et la maintenance des outils de
communication ou de collaboration électroniques de l'Administration ;
• D’assurer l'exploitation et le développement des data center de
l'Administration ;
• D’élaborer les normes et référentiels communs pour la mise en œuvre de
systèmes d'information et de veiller à leur application ;
• D’assurer l'exploitation et la maintenance des applications métiers
transversales de l'administration ;
• D’assurer l'exploitation et la maintenance des applications métiers sectoriels
au besoin ;
• D’assurer le développement des services en ligne ;
• De réaliser des études d'orientation stratégiques et des missions d'audit
informatique des grands systèmes ;
• D’élaborer et mettre en œuvre le plan d'équipement de l'Administration ;
• D’assurer la sécurité des systèmes d'information de l'Administration ;
• D’accompagner les services informatiques de l'Administration dans le cadre
de leurs missions.
En matière de promotion de l'utilisation des TIC dans les autres domaines de
développement social, économique, scientifique et culturel :
• D’être un incubateur d'entreprises TIC de pointe et aider à la valorisation
et à la diffusion des systèmes et produits des TIC conçus et réalisés
localement ;
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 19
• De mettre à la disposition des établissements publics et privés des
formations en informatique, des spécialistes afin de promouvoir des
formations d'excellence ;
• D’assurer l'accompagnement des personnes souhaitant développer des
capacités professionnelles dans l'utilisation des outils liés aux TIC ;
• De promouvoir l'utilisation des logiciels libres ;
• De contribuer à améliorer, grâce aux TIC, la compétitivité de l'économie
nationale et promouvoir le commerce électronique ;
• D’exécuter toute mission de service public confiée par le gouvernement
dans le cadre de la mise en œuvre des cybers stratégies sectorielle.
1.3.3 Organes d’administration et de direction
Les Organes d'Administration et de Direction de l’ANPTIC sont le Conseil
d'Administration et la Direction Générale.
1.3.3.1 Le conseil d’administration
L'ANPTIC est présidée par un Conseil d'Administration de neuf (09) membres. Le
Conseil d'Administration est l'organe de délibération de l'ANPTIC.
1.3.3.2. La direction générale
L'Agence est dirigée par un Directeur Général nommé par décret pris en Conseil de
Ministres sur rapport du Ministre de la tutelle technique. Le Directeur Général assiste
aux délibérations du Conseil d'Administration avec voix consultative, entouré de ses
plus proches collaborateurs. La Direction Générale de l'ANPTIC est organisée
autour des structures suivantes :
• Le Secrétariat Général (SG) ;
• Le Service des Affaires Juridiques (SAJ) ;
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 20
• Le Service de la Communication, du Marketing et des Relations Publiques ;
• Le Service d'Audit Interne ;
• La Cellule d'Appui Technique.
1.3.4 Organigramme de l’ANPTIC
L’organisation de l’ANPTIC est illustrée par l’organigramme ci-dessous. Notre stage
s’est essentiellement déroulé à la direction de la formation et de la promotion des
TIC qui est chargée entre autres :
• De mettre au profit des établissements publics et privés de formation en
informatique, des spécialistes afin de promouvoir des formations
d’excellence ;
• De soutenir la formation continue des professionnels des TIC, afin d’aider
les entreprises locales du secteur à développer une expertise reconnue, et
valoriser cette expertise sur le marché international ;
• De promouvoir l’utilisation des logiciels libres et l’accès universel et non
discriminatoire aux services offerts sur Internet.
Figure 2 : Organigramme de l'ANPTIC
DG
SP SAJ SAI SCMRP CAT SG
DRH
DDRH
DGAP
DFC
DPA
DPT
DFB
PRM
DMPI
DMTS
DEI
DVP
DE
DNIS
DSA
DME
DDM
DEST
DESR
DEA
DEAT
DIG
DS
DICOM
DOC
DFPTIC
DIC
DFOC
DFOTIC
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 21
1.3.5 Présentation de l’IRC
Afin de réussir ce projet, l’ANPTIC a collaboré avec l’IRC.
Créé en 1968, IRC est une organisation non gouvernementale néerlandaise qui assure
la production, le partage, la promotion et l’utilisation des connaissances afin que les
gouvernements, organisations et acteurs individuels puissent améliorer durablement
l’accès à l’eau potable, à l’hygiène et à l’assainissement des populations des pays en
voie de développement. Au Burkina Faso, IRC et ses partenaires locaux développent
et testent des approches innovantes et appuient les changements de politiques et de
pratique en stimulant le partage des connaissances. Le programme pays repose sur
deux volets. Le premier volet est la recherche-action qui consiste en appuis
méthodologiques et conceptuels pour tester des approches visant à améliorer la
planification, la gestion et le suivi des services d’eau potable, d’assainissement et
d’hygiène. Le second volet qui porte sur le partage des connaissances consiste en
activités de formation, de mise en place et de facilitation de plateformes de partage
d’informations et de connaissances - notamment via les médias électroniques - et de
participation aux processus décisionnels locaux et nationaux.
1.4 Présentation du projet
1.4.1 Problématique
Dans sa volonté d’offrir de l’eau potable à tous, le gouvernement du Burkina Faso a
pris l’engagement d’équiper les chefs-lieux de communes et les villages de plus de
3500 habitants d’AEPS. Une AEPS est un système constitué d’une station de
pompage mécanique, alimenté par énergie thermique ou solaire, d’un château d’eau
et d’un mini réseau de distribution d’eau sous-pression desservant des bornes
fontaines et parfois des branchements privés. Afin d’assurer une meilleure gestion
des AEPS, il a été adopté une politique de gestion décentralisée dont la commune est
le maitre d’ouvrage. La commune à son tour peut déléguer la gestion de ses AEPS à
un opérateur privé professionnel sur la base d'une offre de service. Ainsi l’opérateur
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 22
rend compte semestriellement -à travers un rapport- de la gestion technique et
financière des AEPS à la commune avec qui il a signé le contrat. La commune après
réception du rapport le transmet à la DREA pour des analyses poussées. Le résultat
de ces analyses est transmis à la DGEP qui procède à des prises de décisions devant
faciliter la gestion des AEPS. Depuis, aucun retour d’expérience structuré n’a été
organisé pour faire l’état de la gestion des AEPS au Burkina Faso. Cela s’explique par
un certain nombre de problèmes identifiés par les principaux acteurs impliqués dans
la mise en œuvre et le suivi de ces ouvrages.
Ces difficultés sont entre autres :
• L’absence d’informations sur le fonctionnement des AEPS en temps réels ;
• L’absence de données pour des analyses statistiques ;
• Les difficultés liées à la rédaction du rapport semestriel de l’exploitant ;
• La non-soumission des rapports par les opérateurs privés ;
• La lenteur dans les prises de décision due à la remontée tardive de
l’information.
Ce disfonctionnement entrave le partage d’informations avec les bailleurs de fonds
dans le secteur de l’eau et de l’assainissement alors que ces derniers ont besoin de
connaître régulièrement la situation afin de comptabiliser ou d’entreprendre des
actions.
Dans un souci de partage de l’information aux citoyens l’ANPTIC à travers le
Burkina Open Data Initiative a mis en place une application de cartographie des
points d’eau (CARTEAU). Les informations sur la situation des AEPS devraient
alimenter CARTEAU. C’est au vue de tout cela qu’en collaboration avec l’IRC,
l’ANPTIC nous a confié le projet de mise en place d’une plateforme de suivi de
l’exploitation des AEPS.
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 23
1.4.2 Objectifs et Résultats attendus
Au regard de toutes ces difficultés précédemment citées, une analyse approfondie
s’avère nécessaire afin de proposer une solution qui puisse y remédier. L’objectif de
cette analyse est de faciliter le suivi des AEPS à travers :
• La pérennisation de l’information ;
• La centralisation des données ;
• La rédaction et de la soumission rapide du rapport semestriel par les
exploitants ;
• L’accès rapide aux rapports par les communes, les DREA et la DGEP ;
• Le partage d’informations sur les AEPS entre les différents acteurs pour des
analyses statistiques et des prises de décisions ;
Pour ce qui concerne les résultats attendus, le système devra permettre de :
• Recenser l’ensemble des informations techniques et financières sur les AEPS
(nombre de bornes fontaines, nombre de branchements privés, recettes …) ;
• Localiser sur une carte les AEPS, les bornes fontaines et les branchements
privés associés ;
• Alimenter l’application CARTEAU conçue dans le cadre du BODI avec les
informations sur la localisation des bornes fontaines et des branchements
privés des différentes AEPS ;
• Consulter l’état de fonctionnement des AEPS, des bornes fontaines et des
branchements privés en temps réel.
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 24
1.4.3 Gestion de projet
1.4.3.1Acteurs du projet
Le Comité de pilotage
Le comité de pilotage est un groupe d’encadreurs chargé de veiller au bon
déroulement du projet. Son rôle est d’orienter le groupe de projet, de valider les choix
méthodologiques, de s’assurer que le projet reste en phase avec les objectifs initiaux
et de valider toutes les étapes du projet. Il est constitué de :
• Mr TAPSOBA Abdoul Malick Directeur de la DFPTIC, maître de stage ;
• Mr BASSONO Richard chargé de recherche action à l’IRC Burkina ;
• Dr SOME Borlli Michel Jonas enseignant chercheur à l’ESI, superviseur.
Groupe de projet
Le groupe de projet est chargé de l’étude, de la conception et de l’implémentation du
projet sous la supervision du groupe de pilotage. Il se compose des personnes
suivantes :
• LANKAONDE Yiénouyaba élève-Ingénieur de travaux en Analyse et
Programmation 3ème année à l’ESI ;
• OUEDRAOGO Soufiane élève-Ingénieur de travaux en Analyse et
Programmation 3ème année à l’ESI.
Groupe d’utilisateurs
Le groupe d’utilisateurs regroupe l’ensemble des acteurs qui interagissent directement
avec le système afin de fournir ou d’obtenir des informations spécifiques. Il est
composé :
• Du délégué général de l’eau potable ;
• Des délégués régionaux de l’eau et de l’assainissement ;
• Des délégués communaux ;
• Des opérateurs privés ;
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 25
• De l’administrateur des données.
1.4.4 Le Planning prévisionnel
La bonne gestion d’un projet nécessite une organisation : planification des tâches
et activités, suivi des échéances, des ressources affectées. Le diagramme de Gantt est
une représentation schématique des tâches à effectuer assorties de leurs durées de
réalisation (date de début et date de fin). Un planning prévisionnel a été établi dès le
lancement du projet. Le diagramme de GANTT de la figure 3 illustre la planification
des différentes tâches qu’il fallait exécuter. Notons cependant que pour des raisons
académiques, le stage a été suspendu pendant tout le mois d’octobre.
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 26
Figure 3 : Diagramme de GANTT du planning prévisionnel
1.5 Conclusion
Dans ce chapitre nous avons en premier lieu présenté l’organisation
administrative de l’école, le dispositif pédagogique et la structure d’accueil. Par la
suite, nous avons présenté la problématique, les objectifs et les résultats attendus.
Pour finir, nous avons présenté les acteurs du projet et proposé un planning
prévisionnel d’exécution. Nous pouvons ainsi, conformément à notre méthode de
développement entamer la démarche et les moyens de réalisation du projet.
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 27
CHAPITRE 2 : DEMARCHE ET
MOYENS DE REALISATION
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 28
2.1 Introduction
La phase de la démarche et du moyen de résolution permet d’identifier
exactement ce que le futur système devra réaliser en termes de métier. Ainsi pour
réduire le risque d’échec du projet, il est important de bien choisir la démarche à
suivre et la méthode à appliquer. Dans cette partie nous énumérerons les exigences
fonctionnelles et techniques puis annoncerons la méthode retenue pour la résolution
du problème.
2.2 Exigences fonctionnelles et techniques
D’après les besoins recueillis auprès des différents acteurs, les fonctionnalités
attendues du système peuvent être citées comme suit :
• Gestion des utilisateurs : ce module rassemble les fonctionnalités
permettant la gestion sécurisée et complète des utilisateurs, partant de
l’enregistrement, l’attribution des privilèges jusqu’à la modification d’un
compte utilisateur.
• Gestion des AEPS : ce module regroupe les fonctionnalités permettant
l’enregistrement ou la mise à jour des AEPS ainsi que les ouvrages qui leur
sont associés à savoir les BP, les BF et les PMH.
• Gestion des rapports : ce module rassemble les fonctionnalités facilitant non
seulement le suivi mensuel des différentes BP, BF et des PMH mais aussi du
rapport semestriel durant son cycle de vie : de la création, la rédaction continue
jusqu’à la soumission.
• Gestion des indicateurs de performances : A travers ce module on a la
possibilité d’enregistrer, de mettre à jour et de consulter les indicateurs de
performances d’une AEPS donnée.
• Messagerie : ce module offre la possibilité aux utilisateurs connectés de
communiquer entre eux à travers un message texte. Ils pourront donc
recevoir, envoyer ou supprimer un message texte.
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 29
• Gestion des commentaires : à travers ce module nous donnons
l’opportunité à tout utilisateur connecté ou pas, de faire un commentaire au
vu des informations qui lui sont présentées.
• Gestion des équipements : ce module permet de répertorier pour chaque
AEPS, la liste des équipements à renouveler et de la rendre accessible par les
ayants droit.
• Gestion des statistiques : ce module regroupe les fonctionnalités
permettant de générer des statistiques à partir des données de l’exploitation
des AEPS.
• Gestion de la géolocalisation : ce module permet de visualiser l’ensemble
des ouvrages : AEPS, BF, BP et PMH de tout le territoire burkinabè sur une
carte géographique.
2.3 Méthode de résolution du problème
2.3.1 Choix du langage de modélisation
La réalisation de tout système informatique nécessite une modélisation préalable.
Un langage de modélisation est un langage artificiel qui peut être utilisé pour exprimer
de l'information dans un formalisme qui est définie par un ensemble cohérent de
règles. Dans la conduite de ce projet, nous avons choisi UML comme langage de
modélisation. UML est le résultat de la fusion de précédents langages de modélisation
objet : Booch, OMT, OOSE. Principalement issu des travaux de Grady Booch,
James Rumbaugh et Ivar Jacobson, UML est à présent un standard adopté par
l'Object Management Group. Il présente plusieurs avantages en ce sens qu’il permet :
• Une modélisation du système, en utilisant les techniques orientées objet ;
• Une modélisation de très haut niveau indépendante des langages et des
environnements ;
• Une communication efficace entre les différents acteurs du projet ;
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 30
• Une expression dans un seul modèle de tous les aspects statiques et
dynamiques d’un projet ;
• Une simulation à travers les scénarii avant de construire un système.
2.3.2 Choix de la méthode d’analyse et de conception
La méthode d'analyse et de conception est un procédé ayant pour objectif de
permettre la formalisation des étapes préliminaires du développement d'un système,
afin de rendre ce développement plus fidèle aux besoins du client.
Parmi la panoplie de méthodes d’analyse et de conception, nous avons choisi 2TUP,
pour sa simplicité, son itération, sa bonne gestion des risques dans son cycle de
développement. 2TUP est un processus proposant un cycle de développement en Y,
qui dissocie les aspects techniques des aspects fonctionnels. Il s'articule autour de
trois phases essentielles :
• Une branche technique ;
• Une branche fonctionnelle ;
• Une branche de réalisation.
2.3.2.1Branche fonctionnelle
Les principales étapes de la branche fonctionnelle se présentent comme suit :
• Capture des besoins fonctionnels : Cette phase a pour objectif de définir
la frontière fonctionnelle entre le système et son environnement et les
activités attendues des différents utilisateurs par rapport au système.
• Analyse : consiste à étudier précisément les spécifications fonctionnelles
de manière à obtenir une idée de ce que va réaliser le système en termes de
métier.
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 31
2.3.2.2 Branche technique
Les principales étapes de la branche technique se présentent comme suit :
▪ Capture des besoins techniques : Cette étape recense toutes les
contraintes sur les choix de technologies pour la conception du système.
▪ Conception générique : Définit les composants nécessaires à la
construction de l’architecture technique. Cette conception est
complètement indépendante des aspects fonctionnels. Elle permet de
générer le modèle de conception technique qui définit les Frameworks.
2.3.2.3 Phase conception – réalisation
Les principales étapes de cette branche sont les suivantes :
• Conception préliminaire : Cette étape permet de produire le modèle de
conception système. Ce dernier organise le système en composants,
délivrant les services techniques et fonctionnels. Ce qui induit le
regroupement des informations des branches techniques et fonctionnelles.
• Conception détaillée : permet d’étudier comment réaliser chaque
composant. Le modèle logique y est particulièrement important dans la
mesure où c’est dans cette étape qu’on gère le plus grand nombre
d’informations.
• Codage et tests : permet d’effectuer la production des composants et les
tests des unités de code au fur et à mesure de leur réalisation.
• Recette : consiste à valider les fonctionnalités du système développé.
2.4 Estimation du coût du projet
2.4.1 Méthode de calcul du coût
En ce qui concerne le calcul du coût de développement, la méthode la plus
couramment utilisée est la méthode COCOMO (Constructive COst MOdel). Celle-
ci permet d’estimer le coût de développement d’un logiciel à partir du type de
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 32
projet (qualification des acteurs, maitrise de l’environnement de développement),
de la taille de l’application (nombre de lignes de code à écrire) et du salaire moyen
d’un informaticien. Cependant, le fait que nous travaillons avec un Framework
nous empêche de l’utiliser. En effet, les lignes de codes générées par le Framework
viendront gonfler la taille estimée du produit, donnant ainsi un coût de
développement erroné.
De ce fait, le groupe de réalisation a opté pour la méthode d’estimation propre à lui.
Celle-ci permet d’estimer le coût de développement du produit en se basant sur la
composition de l’équipe de réalisation, le temps que chacun a passé sur le projet et
l’estimation de son salaire horaire moyen.
2.4.2 Différents coûts
Le matériel nécessaire dans le cadre de ce projet existe déjà. Il en est de même pour
les logiciels utilisés qui sont tous gratuits. Le coût du matériel et logiciel est estimé à
0 FCFA. Les tableaux 1, 2 et 3 présentent les autres coûts relatifs au projet.
Tableau 1 : Coût de développement
Travailleurs Heures de travail Coût horaire Montant
LANKOANDE
Yiénouyaba
704 H soit 8 H par
jour
1 500 FCFA 1 056 000 FCFA
OUEDRAOGO
Soufiane
704 H soit 8 H par
jour
1 500 FCFA 1 056 000 FCFA
Total 2 112 000 FCFA
Tableau 2 : Coût de formation des utilisateurs
Nombre d’heures Coût horaire Nombre d’utilisateurs Montant
5 H 5 000 FCFA 321 8 025 000 FCFA
Tableau 3 : Coût total de réalisation
Désignation Montant
Coût de développement 2 112 000 FCFA
Coût de formation des utilisateurs 8 025 000 FCFA
Coût total 10 137 000 FCFA
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 33
2.5 Conclusion
Après avoir abordé le thème d’étude qui nous a été attribué, nous avons adopté
le processus de développement 2TUP et le langage de modélisation UML comme
outils d’analyse et de conception pour ce projet. En joignant ceux-ci au plan de travail
préétabli, nous sommes dans les conditions pour attaquer le domaine d’étude qui fera
l’objet du prochain chapitre.
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 34
CHAPITRE 3 : DOMAINE D'ETUDE
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 35
3.1 Introduction
Comme son nom l’indique, ce chapitre nous permettra de présenter l’existant et
d’analyser le domaine. Pour ce faire, nous allons dans un premier temps étudier
l’existant et procéder à la délimitation et à l’analyse du domaine.
3.2 Etude de l’existant
3.2.1 Le parc informatique
Les éléments qui composent le parc informatique de l’ANPTIC se présentent comme
suit :
• Une trentaine de postes de travail qui sont les ordinateurs fixes du réseau à
partir desquels les utilisateurs accèdent à leurs sessions ;
• Une dizaine de serveurs qui sont des ordinateurs dotés d’une très grande
puissance de traitement, d’une très grande capacité de stockage et qui sont très
robustes. Ils permettent d’assurer la disponibilité des services réseau tels que
le web, la messagerie, la sauvegarde de données, le partage de fichiers ;
• Des ordinateurs portables utilisés par les stagiaires et quelques agents pour se
connecter au réseau ;
• Du matériel de téléphonie IP ;
• Des imprimantes, scanners, photocopieuses qui constituent les outils
bureautiques ;
• Des équipements d’interconnexion : ce sont les éléments du réseau qui relient
plusieurs nœuds. Ils sont composés de switchs, de routeurs et de pare-feu ;
• Des onduleurs pour la protection des équipements ;
• Des systèmes d’exploitation linux/cent OS et Unix/Solaris installés sur les
différents serveurs ;
• Et des systèmes d’exploitation Windows 7, 8 et 10 installés sur les ordinateurs
de bureau.
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 36
3.2.2 Les applications réalisées
L’ANPTIC a mise en place des applications permettant d’améliorer la productivité
des services publiques et d’encourager l’utilisation des TIC. Le tableau suivant
présente la liste de quelques plateformes qui ont été développées :
Tableau 4 : Liste de quelques applications
Applications Description
DATA.GOV.BF Plateforme Open Data du
Gouvernement.
Open Elections Application permettant le suivi des
résultats des élections présidentielles en
temps réel.
NENDO Une application qui présente les
indicateurs et les statistiques sur les
écoles du Burkina Faso
CARTEAU-BF Application permettant de localiser les
points d’eau au Burkina Faso.
eConseil des ministres Application facilitant une meilleure
préparation des sessions du Conseil des
Ministres et améliorant les
communications/collaboration entre
Ministres ou entre cabinets
ministériels;
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 37
3.2.3 Architecture réseau
L’architecture réseau du système informatique de l’ANPTIC peut être illustrée par
la figure 5.
Figure 4 : Architecture réseau
3.3 Délimitation et analyse du domaine
L’objectif de l’analyse du domaine est d’obtenir un modèle précis, concis,
compréhensible et correcte du monde réel. Cette analyse permet d’avoir une bonne
compréhension du domaine d’étude à travers la description des différents concepts.
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 38
3.3.1 Identification des concepts clés du domaine.
Les concepts clés du domaine d’étude sont les suivants : AEPS, Opérateur,
Rapport, Incident et Indicateur.
3.3.2 Le dictionnaire de données
Tableau 5 : Description du concept AEPS
Tableau 6 : Description du concept Rapport
AEPS
Attribut Type Description
IdAEPS Numérique Clé primaire d’une AEPS
Nom Alphanumérique Le nom de l’AEPS (unique)
DateService Date La date de mise en service de l’AEPS
SourceEnergie Alphanumérique Le type d’énergie permettant l’alimentation de la
pompe
Observation Alphanumérique Informations générales sur l’AESP
Etat Booléen Spécifie si l’AEPS est fonctionnel ou pas.
ReseauDistribution Alphanumérique Description du réseau de distribution
ReseauRefoulement Alphanumérique Description du réseau de refoulement
Stockage Alphanumérique Description de la capacité de stockage
Latitude Réel Position du château en latitude
Longitude Réel Position du château en longitude
Rapport
Attribut Type Description
IdRapport Numérique Identifie de façon unique le rapport
ObservationGenerale Chaîne de caractères Observations liées à l’AEPS
EstSoumis Booléen Spécifie l’état du rapport
DateSoumission Date Correspond à la date de soumission du rapport
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 39
Tableau 7 : Description du concept Opérateur
Tableau 8 : Description du concept Incident
3.3.3 Le diagramme de classes
Le diagramme de classes exprime la structure statique du système en termes de classes
et de relations entre ces classes. Son intérêt est de modéliser les entités du système
d’information et permettre de représenter l’ensemble des informations finalisées qui
sont gérées par le domaine.
Opérateur
Attribut Type Description
IdOperateur Numérique Clé primaire d’un opérateur privé
Nom Alphanumérique Le nom de l’opérateur privé
AdresseSiege Alphanumérique L’adresse du siège de l’opérateur privé au Burkina Faso
Incident
Attribut Type Description
IdIncident Numérique Clé primaire d’un incident
DateIncident Date Date à laquelle l’incident s’est produit
DateEnregistrement Date La date d’enregistrement de l’incident
Element Alphanumérique Nom de l’équipement concerné par l’incident
Description Alphanumérique Description de l’incident
Cause Alphanumérique Cause de l’incident
DateSolution Date La date à laquelle l’incident a été résolue
Solution Alphanumérique Procédure de résolution de l’incident
CoutSolution Numérique Le cout de la solution
EtatFinal Alphanumérique L’état final de l’incident
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 40
3.3.3.1 Règles de gestion
Afin de mieux structurer les données et d’éviter les redondances dans la base de
données, nous avons établi des règles de gestion. Certaines découlent du
fonctionnement du système actuel et d’autres ont été introduites par le groupe de
projet dans le but de corriger les insuffisances du système.
Tableau 9 : Principales règles de gestion
N° Principales règles de gestion
1 Une commune est située dans une région
2 Une région possède plusieurs communes
3 Une commune possède plusieurs villages
4 Dans un village il y a éventuellement une AEPS
5 Une AEPS possède éventuellement une ou plusieurs BF
6 Une AEPS possède éventuellement un ou plusieurs BP
7 Une AEPS possède éventuellement une ou plusieurs PMH
8 Un BP, BF ou PMH ne peut appartenir qu’à une AEPS
9 La direction générale dispose d’un compte d’utilisateur sur la plateforme
10 Chaque DREA dispose d’un compte utilisateur sur la plateforme
11 Chaque commune dispose d’un compte utilisateur sur la plateforme
12 Un opérateur privé peut gérer plusieurs AEPS dans des communes différentes
13 Un opérateur privé dispose d’un compte d’utilisateur sur la plateforme
14 Les équipements d’une AEPS peuvent être renouvelés
15 Un équipement est caractérisé par son nom et sa catégorie spécifiant sa durée de vie.
16 Une AEPS possède au moins un indicateur de performance
17 Les indicateurs de performance sont mis à jour tous les six mois pour chaque AEPS
18 Un rapport semestriel ne porte que sur la gestion d’une seule AEPS.
19 Un rapport semestriel ne peut être créé et mis à jour que par un opérateur privé
20 Un rapport semestriel ne peut être consulté que par les utilisateurs affectés à la gestion de l’AEPS concerné.
21 Un utilisateur peut envoyer un message texte à un autre utilisateur.
22 Tout internaute y compris les utilisateurs peut poster un commentaire sur la gestion d’une AEPS.
23 Un incident concerne une et une seule AEPS
24 Un opérateur gère une AEPS sous la base d’un contrat
25 Les équipements d’une AEPS peuvent être renouvelés plusieurs fois
3.3.3.2 Représentation
La figure 6 présente le diagramme de classes.
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 41
Figure 5 : Diagramme de classes
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 42
3.4 Conclusion
Dans ce chapitre consacré au domaine d’étude, nous avons d’abord identifié
l’existant matériel, réseau et logiciel. Par la suite nous avons porté une analyse sur le
domaine d’étude. Cela nous permettra maintenant, conformément à notre méthode
de développement de passer à la spécification du futur système, ce qui fera l’objet du
chapitre suivant.
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 43
CHAPITRE 4 : SPECIFICATIONS DU
FUTUR SYSTEME
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 44
4.1 Introduction.
Dans ce chapitre, il s’agira pour nous de présenter les spécifications du futur système.
Après avoir identifié les acteurs et les différents cas d’utilisation du système, nous
présenterons quelques diagrammes fondamentaux du langage de modélisation UML.
Ces dits diagrammes sont le diagramme des cas d’utilisation et le diagramme de
séquences.
4.2 Identification des acteurs et des cas d'utilisation
4.2.1 Identification des acteurs du système
Un acteur représente un rôle joué par une personne ou une chose qui interagit avec
le système. La même personne physique peut donc être représentée par plusieurs
acteurs en fonction des rôles qu’elle joue. Les différents acteurs susceptibles
d’interagirent avec le système sont :
• La DGEP ;
• La DREA ;
• La commune ;
• L’opérateur privé ;
• L’administrateur système ;
4.2.2 Identification des cas d’utilisation
L’identification des acteurs en interaction avec le système, simplifie grandement la
collecte des besoins fonctionnels, car il suffit alors d'analyser acteur par acteur et de
vérifier pour chacun qu'il dispose de toutes les fonctionnalités qui lui seront utiles au
regard de sa mission et du périmètre du projet. Ainsi après analyse des fonctionnalités
souhaitées et de l’environnement du projet, il en ressort les cas d’utilisation énumérés
dans le tableau 9.
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 45
Tableau 10 : Liste des cas d'utilisation
N° Cas d’utilisation
CU01 Gérer un utilisateur
CU02 Gérer une AEPS
CU03 Gérer un indicateur de performance
CU04 Gérer un rapport semestriel
CU05 Gérer une dépense
CU06 Gérer une recette
CU07 Gérer une provision
CU08 Gérer une BF
CU09 Gérer une BP
CU10 Gérer une PMH
CU11 Gérer un suivi mensuel d’ouvrage
CU12 Gérer un incident
CU13 Gérer un message
CU14 Gérer un équipement à renouveler
CU15 Gérer un commentaire
CU16 Consulter les statistiques
CU17 Exporter/Imprimer des informations
CU18 Gérer les affectations des opérateurs privés
CU19 Consulter un rapport semestriel
CU20 Consulter les indicateurs de performances d’une AEPS
CU21 Consulter les équipements à renouveler
CU22 Gérer le personnel
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 46
4.2.3 Description textuelle de quelques cas d’utilisation
La description textuelle d’un cas d’utilisation permet de comprendre son
fonctionnement général en précisant clairement son objectif. Les cas d’utilisation
Gérer un incident, Gérer une AEPS, S’authentifier et Gérer un équipement à
renouveler sont respectivement décrits dans les tableaux 10, 11, 12 et 13 :
Tableau 11 : Description du CU Gérer un incident
CU : « Gérer un incident »
Objectif : ce cas d’utilisation permet
d’enregistrer les incidents survenant
dans l’exploitation d’une AEPS.
Acteurs : opérateur privé
Version : 1.0.
Date de création : 22/09/2016.
Pré conditions : l’utilisateur est connecté, l’utilisateur sélectionne une AEPS.
Scénario nominal :
1. L’utilisateur demande à enregistrer ou mettre à jour un incident ;
2. Le système présente le formulaire d’enregistrement ou de mise à jour ;
3. L’utilisateur renseigne les informations puis valide ;
4. Le système vérifie les informations renseignées (A1) ;
5. Le système actualise la liste des incidents puis notifie à l’utilisateur du succès de
sa requête ;
Enchainements alternatifs :
A1 : les informations renseignées sont incorrectes ou incomplètes : l’enchainement
commence au point 4 du scénario nominal.
5. Le système notifie à l’utilisateur que les informations sont incorrectes.
6. L’utilisateur corrige ou complètes les informations.
L’enchainement continue au point 4 du scénario nominal.
Post conditions : un incident a été enregistré ou mis à jour.
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 47
Tableau 12 : Description du CU Gérer une AEPS
CU : « Gérer une AEPS »
Objectif : ce cas d’utilisation permet
d’enregistrer ou de mettre à jour une
AEPS.
Acteurs : la commune
Version : 1.0.
Date de création : 22/09/2016.
Pré conditions : l’utilisateur est connecté, l’utilisateur sélectionne une AEPS.
Scénario nominal :
1. L’utilisateur demande à enregistrer ou mettre à jour une AEPS ;
2. Le système présente le formulaire d’enregistrement ou de mise à jour ;
3. L’utilisateur renseigne les informations puis valide ;
4. Le système vérifie les informations renseignées (A1) ;
5. Le système notifie à l’utilisateur du succès de sa requête ;
Enchainements alternatifs :
A1 : les informations renseignées sont incorrectes ou incomplètes : l’enchainement
commence au point 4 du scénario nominal.
7. Le système notifie à l’utilisateur que les informations sont incorrectes.
8. L’utilisateur corrige ou complètes les informations.
L’enchainement continue au point 4 du scénario nominal.
Post conditions : une AEPS a été enregistrée ou mise à jour.
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 48
Tableau 13 : Description du CU S'authentifier
CU : « S’authentifier »
Objectif : ce cas d’utilisation permet de
se connecter au système en fonction de
ses droits.
Acteurs : Opérateur privé, commune, DREA,
DGEP
Version : 1.0.
Date de création : 22/09/2016.
Pré conditions : l’utilisateur n’est pas encore connecté.
Scénario nominal :
1. L’utilisateur demande à accéder au système ;
2. Le système demande l’identifiant et le mot de passe ;
3. L’utilisateur renseigne son identifiant et son mot de passe et valide ;
4. Le système vérifie les informations renseignées (A1, E1) ;
5. Le système présente l’interface d’accueil selon les droits de l’utilisateur ;
Enchainements alternatifs :
A1 : l’identifiant et/ou le mot de passe sont incorrects : l’enchainement commence au
point 4 du scénario nominal.
6. Le système notifie à l’utilisateur que l’identifiant et/ou le mot de passe sont
incorrects.
L’enchainement continue au point 3 du scénario nominal.
Enchainements d’exception :
E1 : le compte est déjà bloqué
5. Le système notifie à l’utilisateur que le compte est bloqué.
6. Fin du cas d’utilisation.
Post conditions : l’utilisateur est connecté en fonction de ses privilèges.
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 49
Tableau 14 : Description du CU Gérer un équipement à renouveler
CU : « Gérer un équipement à renouveler »
Objectif : ce cas d’utilisation permet
d’enregistrer les équipements
renouvelables d’une AEPS.
Acteurs : Opérateur
Version : 1.0.
Date de création : 22/09/2016.
Pré conditions : l’utilisateur est connecté.
Scénario nominal :
1. L’utilisateur demande à enregistrer un équipement
2. Le système présente le formulaire d’enregistrement de l’équipement ;
3. L’utilisateur renseigne les informations puis valide ;
4. Le système vérifie les informations renseignées (A1) ;
5. Le système actualise la liste des équipements à renouveler puis notifie à
l’utilisateur du succès de sa requête ;
Enchainements alternatifs :
A1 : les informations renseignées sont incorrectes ou incomplètes : l’enchainement
commence au point 4 du scénario nominal.
5. Le système notifie à l’utilisateur que les informations sont incorrectes.
6. L’utilisateur corrige ou complètes les informations.
L’enchainement continue au point 4 du scénario nominal.
Post conditions : un équipement renouvelable a été enregistré ou mis à jour.
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 50
4.3 Diagramme des cas d'utilisation
La figure 7 représente le diagramme de cas d’utilisation du futur système.
Figure 6 : Diagramme de cas d'utilisation
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 51
4.4 Diagrammes de séquences.
Le diagramme de séquences permet de représenter les interactions entre objets en
précisant la chronologie des échanges de messages, il représente aussi une instance
d’un cas d’utilisation et fait ressortir les acteurs, les objets et les messages.
4.4.1 Authentification
La figure 8 présente le diagramme de séquences de « S’authentifier ».
Figure 7 : Diagramme de séquences du cas d’utilisation « s'authentifier »
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 52
4.4.2 Gérer un incident
La figure 9 présente le diagramme de séquences du cas d’utilisation « Gérer un
incident ».
Figure 8 : Diagramme de séquences du cas d'utilisation « Gérer un incident »
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 53
4.4.3 Gérer un équipement à renouveler
La figure 10 présente le diagramme de séquences du cas d’utilisation « Gérer un
équipement à renouveler ».
Figure 9 : Diagramme de séquences du cas d'utilisation « Gérer un équipement à renouveler »
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 54
4.5 Conclusion
Dans ce chapitre consacré à la spécification du futur système, nous avons d’abord
identifié les acteurs et les différents cas d’utilisation du système. Par la suite nous
avons présenté le diagramme de cas d’utilisation, la description textuelle de certains
cas d’utilisation et le diagramme de séquences de certains cas d’utilisation. Cela nous
permettra maintenant, conformément à notre méthode de développement de passer
à l’architecture du futur système, ce qui fera l’objet du chapitre suivant.
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 55
CHAPITRE 5 : ARCHITECTURE DU
SYSTEME FUTUR
5.1 Introduction
Ce chapitre traite de l’architecture du futur système. L’objectif de l’analyse
architecturale est de définir l’architecture de l’application telle qu’elle sera
implémentée et déployée. Dans un premier temps nous identifierons les différentes
composantes logicielles à utiliser, puis nous décrirons l’architecture logicielle de
l’application en présentant le diagramme de package et le diagramme de déploiement.
5.2 Identification des composantes logicielles
5.2.1 Plateforme de développement
Une plateforme de développement est une base de travail à partir de laquelle on peut
écrire, lire, utiliser, développer un ensemble de logiciels ou de programmes. Dans le
cadre de ce projet, nous avons le choix entre une panoplie de plateformes à savoir :
JAVA EE, ASP.NET, PHP. Suite à une étude comparative, notre choix s’est porté
sur PHP dans sa version 7 parue en Décembre 2015. En effet PHP est gratuit et ne
nécessite aucun coût. Elle dispose également d’une documentation détaillée et d’une
grande communauté de développeurs actifs qui rendent disponibles de milliers de
librairies. De par sa facilité, PHP accélère le temps de développement tout en
optimisant le code en permettant sa réutilisation, en toute sécurité à travers ses
Frameworks comme Symfony que nous utiliserons d’ailleurs dans ce projet.
Le Framework Symfony possède une solide réputation car elle dispose d’un
écosystème stable et est de plus en plus reconnu par les professionnels. Il présente
plusieurs avantages parmi lesquels nous citons :
• Une compatibilité totale avec PHP 7 ;
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 56
• Une compatibilité avec la quasi-totalité des systèmes de gestion de base
de données ;
• Une implémentation du MVC qui est une bonne pratique de
programmation recommandant le découpage du code en trois parties
que sont le Modèle, la Vue et le Contrôleur ;
• Une possibilité d’intégrer de l’AJAX mais aussi de gérer un système de
Template.
Bien plus qu’un Framework MVC, Symfony réunit les meilleurs outils de
développement PHP afin d’aborder avec cohérence la réalisation d’applications web.
5.2.2 Système de Gestion de Bases de Données
Un SGBD est une application conçue pour prendre en charge la structuration, le
stockage, la mise à jour et la maintenance d'une base de données. Il est l'unique
interface entre les informaticiens et les données, ainsi qu'entre les utilisateurs et les
données. Pour mieux gérer la persistance des données, nous avons opté pour le
SGBD Maria DB dans sa version 10.1.14 parue en Mai 2016, certainement la plus
récentes des SGBD. Maria DB est une version améliorée de MySQL qui se donne
pour but de fournir une version stable et toujours gratuite d’une branche MySQL, de
s’assurer d’une complète compatibilité en phase avec les versions de MySQL (une
branche est créée à chaque nouvelle version de MySQL).
5.2.3 Le Framework ORM
Un ORM est une technique de programmation informatique qui crée l'illusion
d'une base de données orientée objet à partir d'une base de données relationnelle en
définissant des correspondances entre cette base de données et les objets du langage
utilisé. Dans le cadre de ce projet nous avons utilisé Doctrine dans sa version 2 qui
est l’ORM par défaut de Symfony. Doctrine propose son propre langage
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 57
d’interrogation DQL orienté objet et permettant ainsi d’effectuer des requêtes assez
complexes.
5.2.4 Environnement de développement
Notre choix s’est porté sur l’IDE Netbeans en sa version 8.2 pour le développement
de l’application. Netbeans est Open Source et intègre toute la puissance d’un IDE
moderne (auto-complétion, coloration syntaxique, refactoring, plugins, …).
Netbeans est multiplateforme et dispose de plugins pour le développement avec
Symfony 3. Au côté de cet IDE, nous avons aussi utilisé Sublime Text qui est l’un
des meilleurs éditeurs de texte du moment. Sublime Text est léger, rapide, fluide,
facile à personnaliser et offre une possibilité d’automatiser les tâches répétitives à
travers des snippets.
5.2.5 Librairies
Dans le cadre du développement de l’application, nous avons utilisé entre-autres les
librairies suivantes :
• JQuery : bibliothèque JavaScript facilitant l’écriture de scripts côté client dans
le code HTML des pages web ;
• Bootstrap : ensemble d’outils permettant de styliser et rendre responsives les
pages web ;
• Leaflet : bibliothèque JavaScript de cartographie en ligne utilisée par le projet
de cartographie libre et ouverte OpenStreetMap ;
• Highcharts : bibliothèque JavaScript offrant un moyen simple d’ajouter des
graphiques interactifs aux sites web ou applications web ;
• FontAwesome : kit d’icônes et de polices basé sur CSS et LESS.
5.3 Architecture logicielle
5.3.1. Diagramme de packages
Le diagramme de packages permet de structurer un système en plusieurs parties,
chacune représentée par un package. Les packages constituent des regroupements
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 58
fonctionnels de classes et d’associations dans le but de mettre en évidence une
fonctionnalité particulière. Nous avons distingué dans le cadre de ce projet, les
principaux packages Administration, Rapports et Ouvrages représentés ci-après
Figure 10 : Diagramme de packages
5.3.2. Diagramme de déploiement
En UML, un diagramme de déploiement est une vue statique qui sert à représenter
l'utilisation de l'infrastructure physique par le système et la manière dont
les composants du système sont répartis ainsi que leurs relations entre eux. Les
éléments utilisés par un diagramme de déploiement sont principalement les nœuds,
les composants, les associations et les artefacts. Il est couramment utilisé pour
décrire l’architecture technique générale d’un système. La figure 12 représente le
diagramme de déploiement obtenu dans le cadre de ce projet.
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 59
Figure 11 : Diagramme de déploiement
5.4 Conclusion
Dans ce chapitre, nous avons dans un premier temps identifié les composantes
logicielles à utiliser pour la mise en place de l’application. Puis nous avons décrit
l’architecture logicielle à travers le diagramme de packages et le diagramme de
déploiement. Cela nous permet d’aborder avec aisance le chapitre sur la
conception de la solution.
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 60
CHAPITRE 6 : CONCEPTION DE LA
SOLUTION
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 61
6.1 Introduction
Dans ce chapitre, nous présentons l’étude conceptuelle du futur système. Il est
essentiellement constitué de la présentation de quelques diagrammes
fondamentaux du langage de modélisation UML associés à l’application. Ces dits
diagrammes sont le diagramme de classe d’application qui par la suite produit le
schéma logique et physique de données de l’application.
6.2 Diagramme de classes d'application
Il s’agit de raffiner dans un premier temps le diagramme de classes et d’associer
les responsabilités aux différentes classes. Au vu de la complexité du système, il
nous est impossible de représenter ce dit diagramme. Nous donnons alors une
brève description de quelques classes dans les tableaux qui suivent.
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 62
Tableau 15 : Description de la classe Gaeps
Classe : Gaeps
Attributs
Code Type Description
Id Numérique Clé primaire d’une AEPS
Nom Alphanumérique Le nom de l’AEPS (unique)
DateService Date La date de mise en service de l’AEPS
SourceEnergie Alphanumérique Le type d’énergie qui alimente la pompe
Observation Alphanumérique Informations générales sur l’AESP
Etat Booléen Spécifie si l’AEPS est fonctionnel ou pas.
ReseauDistribution Alphanumérique Description du réseau de distribution
ReseauRefoulement Alphanumérique Description du réseau de refoulement
Stockage Alphanumérique Description de la capacité de stockage
Latitude Réel Position du château en latitude
Longitude Réel Position du château en longitude
Méthodes
Nom Type de retour Description
Gaeps() Nul Constructeur d’une nouvelle AEPS
getX () Type de X Méthode permettant d’accéder en lecture à
l’attribut X de cette classe
setX () Nul Méthode permettant d’accéder en écriture à
l’attribut X de cette classe
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 63
Tableau 16 : Description de la classe GIncident
Classe : GIncident
Attributs
Code Type Description
IdIncident Numérique Clé primaire d’un incident
DateIncident Date Date à laquelle l’incident s’est produit
DateEnregistrement Date La date d’enregistrement de l’incident
Element Alphanumérique Nom de l’équipement concerné par l’incident
Description Alphanumérique Description de l’incident
Cause Alphanumérique Cause de l’incident
DateSolution Date La date à laquelle l’incident a été résolue
Solution Alphanumérique Procédure de résolution de l’incident
CoutSolution Numérique Le cout de la solution
EtatFinal Alphanumérique L’état final de l’incident
Méthodes
Nom Type de retour Description
GIncident() Nul Constructeur d’un nouvel incident
getX() Type de X Méthode permettant d’accéder en lecture à
l’attribut X de cette classe
setX() Nul Méthode permettant d’accéder en écriture à
l’attribut X de cette classe
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 64
Tableau 17 : Description de la classe GIndicateur
6.3 Schémas logique et physique des données
Le modèle physique de données résulte de la transformation du modèle relationnel
obtenu à partir du diagramme de classes. Le modèle physique de données est
directement exploitable par le SGBD. La figure 13 décrit le modèle physique de
données obtenu pour ce projet.
GIndicateur
Attribut Type Description
IdIndicateur Numérique Identifiant unique associé à l’indicateur
Idx Alphanumérique Code associé à l’indicateur
Nom Chaîne de caractères Correspond au nom de l’indicateur
Description Chaîne de caractères Description textuelle de l’indicateur
Méthodes
Nom Type de retour Description
GIndicateur() Nul Constructeur d’un nouvel indicateur
getX () Type de X Méthode permettant d’accéder en lecture à
l’attribut X de cette classe
setX () Nul Méthode permettant d’accéder en écriture à
l’attribut X de cette classe
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 65
Figure 12 : Modèle physique de donnée
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 66
6.4 Conclusion
Dans ce chapitre, nous avons présenté le diagramme de classes d’application. Aussi
nous avons décrit les cas d’utilisation à travers les diagrammes de séquences en faisant
ressortir les interactions entre les acteurs et les composantes logicielles du système.
Dans le chapitre suivant, nous allons nous intéresser à l’implémentation de notre
système en se basant sur la conception détaillée de ce chapitre.
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 67
CHAPITRE 7 : REALISATION ET BILAN
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 68
7.1 Introduction
Après les phases d’analyse et de conception, vient à présent celle de la réalisation.
Dans ce chapitre, nous présentons d’abord les modules du logiciel développé à
travers des captures d’écrans. Ensuite, nous expliquons les écarts entre les
résultats attendus et ce qui est réalisé. Enfin, nous exposons la politique adoptée
pour assurer le maximum de sécurité.
7.2 Modules développés
Les modules développés sont les suivants :
• Gestion des AEPS ;
• Gestion des rapports ;
• Gestion des indicateurs de performances ;
• Gestion des statistiques ;
• Gestion des utilisateurs ;
• Gestion de la géolocalisation ;
• Gestion du renouvèlement des équipements.
7.3 Enchaînement des écrans
7.3.1 Interface pour utilisateur non-connecté
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 69
7.3.1.1 Interface d’accueil (1)
La figure suivante présente la page d’accueil réservé à tout internaute non-connecté.
Figure 13 : Interface d’accueil (1)
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 70
7.3.1.2 Interface d’accueil (2)
La figure suivante présente la possibilité pour l’internaute de filtrer la liste des AEPS par région, par commune et d’accéder aux détails d’une
AEPS donnée.
Figure 14 : Interface d’accueil (2)
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 71
7.3.1.3 Information d’une AEPS
La figure suivante présente les informations d’une AEPS donnée.
Figure 15 : Interface détails d'une AEPS
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 72
7.3.1.4 Visualisation des branchements d’une AEPS
Figure 16 : Visualisation des branchements d'une AEPS
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 73
7.3.2 Interface pour utilisateurs principaux du système.
7.3.2.1 Page d’authentification
Tout utilisateur qui dispose d’un compte sur la plateforme et qui veut se connecter
devra spécifier l’URL de la page d’authentification. Cette page se présente comme
suit :
Figure 17 : Formulaire de connexion
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 74
7.3.2.2 Interface d’accueil
Après s’être connecté, l’utilisateur a droit à une page d’accueil en fonction de son profil. Cette page d’accueil lui permet d’accéder aux
différentes fonctionnalités à travers des liens. La figure ci-après nous décrit cela :
Figure 18 : Interface accueil pour utilisateur authentifié
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 75
7.3.2.3 Module « Gestion AEPS »
Une fois connecté en tant qu’opérateur ou délégué communal, l’utilisateur peut accéder à ce module à travers un clic sur la barre de menu. La
figure suivante présente l’interface d’accueil de ce module :
Figure 19 : Accueil du module Gestion AEPS
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 76
7.3.2.4 Module « Gestion AEPS » (Ajout d’une BF)
A partir de la page d’accueil du module Gestion AEPS, l’utilisateur peut gérer les différents ouvrages liés à une AEPS sélectionnée au préalable.
La figure suivante présente l’écran d’ajout d’une borne fontaine à une AEPS.
Figure 20 : Interface d'ajout d'une BF
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 77
7.3.2.5 Volet « Rapports » (Edition)
A partir de la barre de navigation, l’utilisateur accède aussi à la partie édition du rapport où il pourra renseigner pour chacun de ses ouvrages,
les informations nécessaires à l’établissement du rapport semestriel. Cela est ainsi illustré par la figure ci-après :
Figure 21 : Volet édition d'un rapport
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 78
7.3.2.6 Volet « Rapports » (Liste)
Ce volet est accessible par un clic sur l’item « Consultation » du menu déroulant « Rapports » et présente la liste des différents rapports soumis
ou en cours d’édition avec la possibilité de télécharger ou de visualiser les rapports soumis. La figure suivante présente cette liste :
Figure 22 : Liste des rapports
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 79
7.3.2.7 Volet « Visualisation d’un rapport » (1)
A partir du bouton visualiser, l’utilisateur peut parcourir les informations du rapport en ligne. La figure ci-après présente l’évolution des ventes
au niveau des BF dans le mois de janvier 2015.
Figure 23 : Visualisation d'un rapport soumis
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 80
7.3.2.8 Volet « Visualisation d’un rapport » (2)
En plus de la visualisation en chiffres de la figure 24, on a la possibilité de visualiser les données en graphes, afin de pouvoir effectuer des
comparaisons plus aisément.
Figure 24 : Situation des BF sous formes de graphes
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 81
7.3.2.9 Volet « Visualisation d’un rapport » (3)
Il est possible d’en faire de même dans la partie finances du rapport. La figure suivante présente la comparaison des charges entre deux
semestres.
Figure 25 : Visualisation des charges d'exploitation
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 82
7.4 Analyse des écarts
7.4.1 Le Planning réel
Le planning réel du projet présente de façon effective les tâches qui se sont exécutées.
En effet, un retard a été accusé comme le présente la figure 4 qui précise les dates de
début et de fin des différentes tâches.
Figure 26 : Diagramme de GANTT du planning réel
7.4.2 Explication des écarts
Les modules Messagerie et Gestion des commentaires de l’application n’ont pas
été implémentés. Nous donnons les raisons qui ont prévalues :
• L’étude et la compréhension du domaine a pris plus de temps que prévu, car
n’étant pas en contact direct avec les principaux acteurs, nous avons dû nous
inspirer des documents provenant de l’IRC.
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 83
• Il y a aussi la prise en main du Framework Symfony. En effet, même si cette
plate-forme est construite sur le langage PHP, elle y ajoute un grand nombre
d’outils remplissant tout un tas de fonctionnalités que nous avons pris le temps
de comprendre.
7.4.3 Résultats obtenus
Comme résultat, nous avons produit une application web qui fonctionne. Un
utilisateur ayant le profil requis peut ajouter, modifier une AEPS, une BF, une BP et
une PMH. Il peut également s’il s’agit d’un opérateur, créer un rapport semestriel,
l’éditer et le soumettre au moment opportun. Une fois les rapports soumis, les
utilisateurs pourront les consulter, exporter et générer des statistiques.
7.5 Politique de sécurité
7.5.1 Notion de sécurité
Une politique de sécurité a pour but de minimiser les risques de disfonctionnements,
d'éviter l'incohérence des données, les accès non autorisés à la base et la présence de
programmes indésirables dans le réseau. II s'agit donc de prendre toutes les
dispositions utiles afin de réduire au maximum les effets néfastes des pannes
matérielles ou logicielles.
7.5.2 Gestion des mots de passe et de la connexion à l’application
La politique de gestion des mots de passe est à la fois technique et organisationnelle.
Elle vise à réduire les risques pour le système d'information liés à l'emploi de ce
mécanisme.
En effet, tous les paramètres de la gestion des mots de passe sont paramétrables par
chaque organisation. Ici sont présentés les paramètres par défaut :
• Les mots de passe utilisés pour se connecter au système seront chiffrés par
l’algorithme Bcrypt ;
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 84
• Lors de la connexion, si trois tentatives d'accès sont effectuées sans succès, le
compte sera bloqué. Le déblocage interviendra sur demande auprès de
l’administrateur ;
• En ce qui concerne la connexion proprement dite, une seule connexion par
utilisateur est possible ; c’est-à-dire que l’utilisateur ne peut ouvrir plus d’une
session à la fois ;
7.5.3 Gestion des attaques
Une attaque est une action par lequel une entité accède de façon subite et avec
l’intention de nuire ou de prendre le contrôle d’un système.
7.5.3.1 Les virus
Un virus informatique est un logiciel malveillant conçu pour se propager à d'autres
ordinateurs en y causant des dégâts plus ou moins importants. Il peut se répandre à
travers tout moyen d'échange de données numériques comme les réseaux
informatiques les CDROMS, les clefs USB, etc.
La mesure adoptée contre les virus est l’installation sur chaque poste client, d’un
antivirus en vue de mieux protéger les données de la plateforme.
7.5.3.2 Les accès non autorisés
Pour une meilleure sécurité du système d’information, il faudrait un contrôle très
rigoureux de l’identité de toute personne voulant avoir accès au système ou aux
différents serveurs pour y effectuer certaines tâches. L’application à mettre en œuvre
étant une application web, nous proposons des contrôles d’accès à tous les niveaux :
• Une protection au niveau du serveur
Le paramétrage du système d’exploitation du serveur est très important. En effet une
protection du serveur ne peut se faire que lorsque son système d’exploitation est
sécurisé. Pour cela il faut des mesures de sécurité spécifiques, concernant la gestion
des utilisateurs, des processus, des systèmes de fichiers, etc...
• Une protection au niveau du réseau
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 85
Cette protection est réalisée par la mise en place d’un dispositif de FIREWALL pour
limiter les flux réseaux ouverts depuis l’extérieur. Un FIREWALL est un dispositif
permettant d’assurer le filtrage par services des accès entrants et limite ainsi les
risques auxquels est soumis le serveur web ;
• Une protection au niveau de l’application
Tout utilisateur voulant accéder à l’application devra impérativement s’authentifier à
l’aide d’un identifiant et d’un mot de passe. Chaque utilisateur n’accédera qu’aux
données dont il a droit et n’effectuera que les traitements qui lui sont autorisés.
7.5.4 Mise en place de la sauvegarde et de la restauration
En informatique, une sauvegarde ou backup en anglais, est l'opération qui consiste à
dupliquer et à mettre en sécurité les données contenues dans un système
informatique. C’est donc un peu comme les extincteurs dans nos maisons : ils sont
encombrants, coûtent cher et ne sont presque jamais utilisés. Cependant, lorsque
survient l’accident irrémédiable, on se félicite d’y avoir pensé. Dans le choix de la
stratégie de sauvegarde, seuls les trois types de techniques ont été pris en compte :
• La première est la technique de sauvegarde complète. Comme son nom
l'indique, cette méthode consiste à sauvegarder l'intégralité des données ;
• La deuxième est la technique de sauvegarde incrémentale ou incrémentielle.
Elle ne sauve que les données modifiées ou nouvelles depuis la dernière
sauvegarde. La restauration passe obligatoirement par une restauration de la
sauvegarde complète puis de toutes les sauvegardes incrémentales ;
• Et enfin, la technique de sauvegarde différentielle. Elle sauve toutes les
données nouvelles ou modifiées depuis la dernière sauvegarde complète. La
restauration passe par une restauration de la sauvegarde complète puis de la
dernière sauvegarde différentielle.
En ce qui concerne leur mise en œuvre, trois stratégies ont été confrontées afin de
choisir la plus adaptée au système.
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 86
• Première stratégie : sauvegarde incrémentale du lundi au vendredi et
sauvegarde complète le samedi ;
• Deuxième stratégie : sauvegarde différentielle du lundi au vendredi et
sauvegarde complète le samedi.
• Troisième stratégie : sauvegarde complète du lundi au samedi.
D’après la nature et l’importance des données traitées, ce fut la deuxième stratégie
qui fut retenue.
Pour doubler l’assurance, des tables de journalisation ont été placés au sein de la base
de données pour enregistrer toutes les modifications sur les données.
7.5.5 Protection contre les catastrophes
Il n’est pas exclu que les salles contenant les différents serveurs soient soumises à des
catastrophes naturelles telles que la foudre, les incendies, les inondations… Il serait
donc très important d’installer des extincteurs, des paratonnerres dans ces salles pour
éviter une totale perte du matériel, du logiciel et des données enregistrées.
7.6 Conclusion
Dans ce chapitre nous avons exposé les différents éléments concernant la réalisation
de la plateforme. Nous y avons fait ressortir quelques interfaces liées à des
fonctionnalités de l’application. Nous avons expliqué les écarts entre les résultats
attendus et ce qui est réalisé. Nous y avons aussi étalé les aspects liés à la sécurité du
système, notamment l’authentification, la gestion des accès, la politique de gestion
des mots de passe, la politique de sauvegarde/restauration et les moyens de
protection contre les catastrophes.
LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 87
CONCLUSION GENERALE
Le stage de fin de cycle, nous a permis de mieux comprendre les réalités
professionnelles et d’acquérir de nouvelles expériences quant à l’utilisation de
nouvelles technologies. De manière pratique, ce stage de quatre mois, que nous avons
effectué à l’ANPTIC, a consisté à l’analyse, à la conception et à la mise en place d’une
plateforme de suivi de l’exploitation des AEPS.
En effet, le gouvernement du Burkina qui autrefois connaissait des difficultés dans
le suivi des gros ouvrages tels que les AEPS, pourra par cette application améliorer
considérablement le suivi, l’évaluation et la gestion des adductions d’eau potable
simplifiées. A cela s’ajoute l’élaboration des statistiques de manière fiable afin d’aider
à la prise de décision. Pour ce faire, nous avons utilisé le processus de développement
2TUP et le langage de modélisation UML. En ce qui concerne les technologies, nous
avons utilisé entre autres la plateforme PHP 7, le Framework Symfony couplé à
Bootstrap et Doctrine pour le mapping. Le système de gestion de base de données
est Maria DB.
En sommes, nous aimerions que le travail que nous avons entrepris à l’ANPTIC
connaisse son achèvement pour permettre de voir nos efforts couronnés par la mise
en place complète de l’application web.
Rapport sur la mise en plateforme de suivi de l'exploitation des AEPS
Rapport sur la mise en plateforme de suivi de l'exploitation des AEPS
Rapport sur la mise en plateforme de suivi de l'exploitation des AEPS

Contenu connexe

Tendances

présentation de soutenance PFE
présentation de soutenance PFEprésentation de soutenance PFE
présentation de soutenance PFEKarim Labidi
 
Rapport Projet de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatiqueRapport Projet  de fin d'etude sur le parc informatique
Rapport Projet de fin d'etude sur le parc informatiqueHicham Ben
 
Rapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learningRapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learningRouâa Ben Hammouda
 
Projet stage : Mise en place d'un système générique de sauvegarde et de rest...
Projet stage : Mise en place d'un système générique  de sauvegarde et de rest...Projet stage : Mise en place d'un système générique  de sauvegarde et de rest...
Projet stage : Mise en place d'un système générique de sauvegarde et de rest...Gedeon AGOTSI
 
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...Riadh K.
 
mémoire de projet de fin d'études
mémoire de projet de fin d'études mémoire de projet de fin d'études
mémoire de projet de fin d'études MortadhaBouallagui
 
Mémoire de fin de cycle présenté en vue de L’Obtention du Diplôme de Master P...
Mémoire de fin de cycle présenté en vue de L’Obtention du Diplôme de Master P...Mémoire de fin de cycle présenté en vue de L’Obtention du Diplôme de Master P...
Mémoire de fin de cycle présenté en vue de L’Obtention du Diplôme de Master P...Abdallah YACOUBA
 
conception et réalisation d'une application de gestion des rapports téléphoni...
conception et réalisation d'une application de gestion des rapports téléphoni...conception et réalisation d'une application de gestion des rapports téléphoni...
conception et réalisation d'une application de gestion des rapports téléphoni...ismailbou
 
Contribution a la_realisation_dune_plate_forme_de_suivi_de_colis (1)
Contribution a la_realisation_dune_plate_forme_de_suivi_de_colis (1)Contribution a la_realisation_dune_plate_forme_de_suivi_de_colis (1)
Contribution a la_realisation_dune_plate_forme_de_suivi_de_colis (1)zakia saadaoui
 
RAPPORT DE STAGE SSI - Copie.pdf
RAPPORT DE STAGE SSI - Copie.pdfRAPPORT DE STAGE SSI - Copie.pdf
RAPPORT DE STAGE SSI - Copie.pdfJoelChouamou
 
BAYE_O_FALL-SAIDOU_MBODJI-LabUT.pdf
BAYE_O_FALL-SAIDOU_MBODJI-LabUT.pdfBAYE_O_FALL-SAIDOU_MBODJI-LabUT.pdf
BAYE_O_FALL-SAIDOU_MBODJI-LabUT.pdfBayeOusseynouFall
 
ETUDE ET MISE EN PLACE D'UNE SOLUTION DE CLOUD COMPUTING PRIVÉ BASÉE SUR UN ...
ETUDE ET MISE EN PLACE D'UNE SOLUTION DE CLOUD COMPUTING  PRIVÉ BASÉE SUR UN ...ETUDE ET MISE EN PLACE D'UNE SOLUTION DE CLOUD COMPUTING  PRIVÉ BASÉE SUR UN ...
ETUDE ET MISE EN PLACE D'UNE SOLUTION DE CLOUD COMPUTING PRIVÉ BASÉE SUR UN ...Borel NZOGANG
 
Rapport de PFE du Diplôme de Mastère pro en Modélisation, Bases de Données et...
Rapport de PFE du Diplôme de Mastère pro en Modélisation, Bases de Données et...Rapport de PFE du Diplôme de Mastère pro en Modélisation, Bases de Données et...
Rapport de PFE du Diplôme de Mastère pro en Modélisation, Bases de Données et...Sarra LAOUINI
 
éTude et mise_en_place_d'une_solution_voip_sécurisée
éTude et mise_en_place_d'une_solution_voip_sécuriséeéTude et mise_en_place_d'une_solution_voip_sécurisée
éTude et mise_en_place_d'une_solution_voip_sécuriséeSaad Jouhari
 
Concept et réalisation d’un système de communication unifiée multi-sites
Concept et réalisation d’un système de communication unifiée multi-sitesConcept et réalisation d’un système de communication unifiée multi-sites
Concept et réalisation d’un système de communication unifiée multi-sitesAmadou Dia
 
Mémoire de fin de formation pour l'obtention du diplome d'ingénieur des trava...
Mémoire de fin de formation pour l'obtention du diplome d'ingénieur des trava...Mémoire de fin de formation pour l'obtention du diplome d'ingénieur des trava...
Mémoire de fin de formation pour l'obtention du diplome d'ingénieur des trava...Gedeon AGOTSI
 
Rapport PFE: Gestion de Parc Informatique
Rapport PFE: Gestion de Parc InformatiqueRapport PFE: Gestion de Parc Informatique
Rapport PFE: Gestion de Parc InformatiqueEric Maxime
 
ETUDE ET MISE EN PLACE D’UNE SOLUTION DE GESTION DE LA SECURITE DU RESEAU : C...
ETUDE ET MISE EN PLACE D’UNE SOLUTION DE GESTION DE LA SECURITE DU RESEAU : C...ETUDE ET MISE EN PLACE D’UNE SOLUTION DE GESTION DE LA SECURITE DU RESEAU : C...
ETUDE ET MISE EN PLACE D’UNE SOLUTION DE GESTION DE LA SECURITE DU RESEAU : C...Tidiane Sylla
 
Rapport nagios miniprojet
Rapport nagios miniprojetRapport nagios miniprojet
Rapport nagios miniprojetAyoub Rouzi
 

Tendances (20)

présentation de soutenance PFE
présentation de soutenance PFEprésentation de soutenance PFE
présentation de soutenance PFE
 
Rapport Projet de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatiqueRapport Projet  de fin d'etude sur le parc informatique
Rapport Projet de fin d'etude sur le parc informatique
 
Rapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learningRapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learning
 
Projet stage : Mise en place d'un système générique de sauvegarde et de rest...
Projet stage : Mise en place d'un système générique  de sauvegarde et de rest...Projet stage : Mise en place d'un système générique  de sauvegarde et de rest...
Projet stage : Mise en place d'un système générique de sauvegarde et de rest...
 
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
 
mémoire de projet de fin d'études
mémoire de projet de fin d'études mémoire de projet de fin d'études
mémoire de projet de fin d'études
 
Mémoire de fin de cycle présenté en vue de L’Obtention du Diplôme de Master P...
Mémoire de fin de cycle présenté en vue de L’Obtention du Diplôme de Master P...Mémoire de fin de cycle présenté en vue de L’Obtention du Diplôme de Master P...
Mémoire de fin de cycle présenté en vue de L’Obtention du Diplôme de Master P...
 
conception et réalisation d'une application de gestion des rapports téléphoni...
conception et réalisation d'une application de gestion des rapports téléphoni...conception et réalisation d'une application de gestion des rapports téléphoni...
conception et réalisation d'une application de gestion des rapports téléphoni...
 
Contribution a la_realisation_dune_plate_forme_de_suivi_de_colis (1)
Contribution a la_realisation_dune_plate_forme_de_suivi_de_colis (1)Contribution a la_realisation_dune_plate_forme_de_suivi_de_colis (1)
Contribution a la_realisation_dune_plate_forme_de_suivi_de_colis (1)
 
RAPPORT DE STAGE SSI - Copie.pdf
RAPPORT DE STAGE SSI - Copie.pdfRAPPORT DE STAGE SSI - Copie.pdf
RAPPORT DE STAGE SSI - Copie.pdf
 
BAYE_O_FALL-SAIDOU_MBODJI-LabUT.pdf
BAYE_O_FALL-SAIDOU_MBODJI-LabUT.pdfBAYE_O_FALL-SAIDOU_MBODJI-LabUT.pdf
BAYE_O_FALL-SAIDOU_MBODJI-LabUT.pdf
 
ETUDE ET MISE EN PLACE D'UNE SOLUTION DE CLOUD COMPUTING PRIVÉ BASÉE SUR UN ...
ETUDE ET MISE EN PLACE D'UNE SOLUTION DE CLOUD COMPUTING  PRIVÉ BASÉE SUR UN ...ETUDE ET MISE EN PLACE D'UNE SOLUTION DE CLOUD COMPUTING  PRIVÉ BASÉE SUR UN ...
ETUDE ET MISE EN PLACE D'UNE SOLUTION DE CLOUD COMPUTING PRIVÉ BASÉE SUR UN ...
 
Rapport de PFE du Diplôme de Mastère pro en Modélisation, Bases de Données et...
Rapport de PFE du Diplôme de Mastère pro en Modélisation, Bases de Données et...Rapport de PFE du Diplôme de Mastère pro en Modélisation, Bases de Données et...
Rapport de PFE du Diplôme de Mastère pro en Modélisation, Bases de Données et...
 
éTude et mise_en_place_d'une_solution_voip_sécurisée
éTude et mise_en_place_d'une_solution_voip_sécuriséeéTude et mise_en_place_d'une_solution_voip_sécurisée
éTude et mise_en_place_d'une_solution_voip_sécurisée
 
Concept et réalisation d’un système de communication unifiée multi-sites
Concept et réalisation d’un système de communication unifiée multi-sitesConcept et réalisation d’un système de communication unifiée multi-sites
Concept et réalisation d’un système de communication unifiée multi-sites
 
Mémoire de fin de formation pour l'obtention du diplome d'ingénieur des trava...
Mémoire de fin de formation pour l'obtention du diplome d'ingénieur des trava...Mémoire de fin de formation pour l'obtention du diplome d'ingénieur des trava...
Mémoire de fin de formation pour l'obtention du diplome d'ingénieur des trava...
 
Rapport PFE: Gestion de Parc Informatique
Rapport PFE: Gestion de Parc InformatiqueRapport PFE: Gestion de Parc Informatique
Rapport PFE: Gestion de Parc Informatique
 
ETUDE ET MISE EN PLACE D’UNE SOLUTION DE GESTION DE LA SECURITE DU RESEAU : C...
ETUDE ET MISE EN PLACE D’UNE SOLUTION DE GESTION DE LA SECURITE DU RESEAU : C...ETUDE ET MISE EN PLACE D’UNE SOLUTION DE GESTION DE LA SECURITE DU RESEAU : C...
ETUDE ET MISE EN PLACE D’UNE SOLUTION DE GESTION DE LA SECURITE DU RESEAU : C...
 
Rapport nagios miniprojet
Rapport nagios miniprojetRapport nagios miniprojet
Rapport nagios miniprojet
 
Rapport projet pfe
Rapport projet pfeRapport projet pfe
Rapport projet pfe
 

Similaire à Rapport sur la mise en plateforme de suivi de l'exploitation des AEPS

Maintenance equipement info dans un environnement reseau
Maintenance equipement info dans un environnement reseau Maintenance equipement info dans un environnement reseau
Maintenance equipement info dans un environnement reseau JennellyHollywood Shookou
 
Rapport version finale kouakou aboua pokou alexis
Rapport version finale kouakou aboua pokou alexis Rapport version finale kouakou aboua pokou alexis
Rapport version finale kouakou aboua pokou alexis abouaalexis
 
MUKENGE KANKONDE Zack mise en place d'un système de stockage et sauvegarde d...
MUKENGE KANKONDE  Zack mise en place d'un système de stockage et sauvegarde d...MUKENGE KANKONDE  Zack mise en place d'un système de stockage et sauvegarde d...
MUKENGE KANKONDE Zack mise en place d'un système de stockage et sauvegarde d...ZackMukenge
 
Gestion programme moussanada avec openerp
Gestion programme moussanada avec openerpGestion programme moussanada avec openerp
Gestion programme moussanada avec openerpHORIYASOFT
 
Témoignage sur la coordination des applications numériques et du portail dans...
Témoignage sur la coordination des applications numériques et du portail dans...Témoignage sur la coordination des applications numériques et du portail dans...
Témoignage sur la coordination des applications numériques et du portail dans...bdvo
 
MEMOIRE DE FIN DE CYCLE Pour l’obtention du : Master 2 en SIR (REALISATION D...
MEMOIRE DE FIN DE CYCLE Pour l’obtention du : Master 2  en SIR (REALISATION D...MEMOIRE DE FIN DE CYCLE Pour l’obtention du : Master 2  en SIR (REALISATION D...
MEMOIRE DE FIN DE CYCLE Pour l’obtention du : Master 2 en SIR (REALISATION D...Olympe Tchibozo
 
Diaporama journée des correspondants tice en documentation
Diaporama journée des correspondants tice en documentationDiaporama journée des correspondants tice en documentation
Diaporama journée des correspondants tice en documentationDocumentation Rouen
 
OURIREM-SALAH.pdf
OURIREM-SALAH.pdfOURIREM-SALAH.pdf
OURIREM-SALAH.pdfGhezza
 
marcusevans-conference-evolution-architecture-entreprise-programme
marcusevans-conference-evolution-architecture-entreprise-programmemarcusevans-conference-evolution-architecture-entreprise-programme
marcusevans-conference-evolution-architecture-entreprise-programmeEmmanuel Gachet
 
Retour d’expérience sur le déploiement d’uPortal 4.2 responsive à l’UPMC – So...
Retour d’expérience sur le déploiement d’uPortal 4.2 responsive à l’UPMC – So...Retour d’expérience sur le déploiement d’uPortal 4.2 responsive à l’UPMC – So...
Retour d’expérience sur le déploiement d’uPortal 4.2 responsive à l’UPMC – So...Christian Cousquer
 
Application web Gestion RH ASP.NET MVC5
Application web Gestion RH ASP.NET MVC5Application web Gestion RH ASP.NET MVC5
Application web Gestion RH ASP.NET MVC5YounessLaaouane
 
Mise en place d’une application mobile de géolocalisation
Mise en place d’une application mobile de géolocalisationMise en place d’une application mobile de géolocalisation
Mise en place d’une application mobile de géolocalisationCléa Aurianne Leencé BAWE
 

Similaire à Rapport sur la mise en plateforme de suivi de l'exploitation des AEPS (20)

Rapport de fin de stage maintenance info
Rapport de fin de stage  maintenance infoRapport de fin de stage  maintenance info
Rapport de fin de stage maintenance info
 
Maintenance equipement info dans un environnement reseau
Maintenance equipement info dans un environnement reseau Maintenance equipement info dans un environnement reseau
Maintenance equipement info dans un environnement reseau
 
Rapport de fin de stage maintenance info
Rapport de fin de stage  maintenance infoRapport de fin de stage  maintenance info
Rapport de fin de stage maintenance info
 
Rapport version finale kouakou aboua pokou alexis
Rapport version finale kouakou aboua pokou alexis Rapport version finale kouakou aboua pokou alexis
Rapport version finale kouakou aboua pokou alexis
 
MUKENGE KANKONDE Zack mise en place d'un système de stockage et sauvegarde d...
MUKENGE KANKONDE  Zack mise en place d'un système de stockage et sauvegarde d...MUKENGE KANKONDE  Zack mise en place d'un système de stockage et sauvegarde d...
MUKENGE KANKONDE Zack mise en place d'un système de stockage et sauvegarde d...
 
Gestion programme moussanada avec openerp
Gestion programme moussanada avec openerpGestion programme moussanada avec openerp
Gestion programme moussanada avec openerp
 
Témoignage sur la coordination des applications numériques et du portail dans...
Témoignage sur la coordination des applications numériques et du portail dans...Témoignage sur la coordination des applications numériques et du portail dans...
Témoignage sur la coordination des applications numériques et du portail dans...
 
cv_hamidi
cv_hamidicv_hamidi
cv_hamidi
 
gazetier_200612
gazetier_200612gazetier_200612
gazetier_200612
 
MEMOIRE DE FIN DE CYCLE Pour l’obtention du : Master 2 en SIR (REALISATION D...
MEMOIRE DE FIN DE CYCLE Pour l’obtention du : Master 2  en SIR (REALISATION D...MEMOIRE DE FIN DE CYCLE Pour l’obtention du : Master 2  en SIR (REALISATION D...
MEMOIRE DE FIN DE CYCLE Pour l’obtention du : Master 2 en SIR (REALISATION D...
 
Diaporama journée des correspondants tice en documentation
Diaporama journée des correspondants tice en documentationDiaporama journée des correspondants tice en documentation
Diaporama journée des correspondants tice en documentation
 
cv_chaker_jouini_fr
cv_chaker_jouini_frcv_chaker_jouini_fr
cv_chaker_jouini_fr
 
Rapport de stage
Rapport de stageRapport de stage
Rapport de stage
 
OURIREM-SALAH.pdf
OURIREM-SALAH.pdfOURIREM-SALAH.pdf
OURIREM-SALAH.pdf
 
marcusevans-conference-evolution-architecture-entreprise-programme
marcusevans-conference-evolution-architecture-entreprise-programmemarcusevans-conference-evolution-architecture-entreprise-programme
marcusevans-conference-evolution-architecture-entreprise-programme
 
4eme rencontre des EPI
4eme rencontre des EPI4eme rencontre des EPI
4eme rencontre des EPI
 
Retour d’expérience sur le déploiement d’uPortal 4.2 responsive à l’UPMC – So...
Retour d’expérience sur le déploiement d’uPortal 4.2 responsive à l’UPMC – So...Retour d’expérience sur le déploiement d’uPortal 4.2 responsive à l’UPMC – So...
Retour d’expérience sur le déploiement d’uPortal 4.2 responsive à l’UPMC – So...
 
Rapport_PRES__Copy_
Rapport_PRES__Copy_Rapport_PRES__Copy_
Rapport_PRES__Copy_
 
Application web Gestion RH ASP.NET MVC5
Application web Gestion RH ASP.NET MVC5Application web Gestion RH ASP.NET MVC5
Application web Gestion RH ASP.NET MVC5
 
Mise en place d’une application mobile de géolocalisation
Mise en place d’une application mobile de géolocalisationMise en place d’une application mobile de géolocalisation
Mise en place d’une application mobile de géolocalisation
 

Rapport sur la mise en plateforme de suivi de l'exploitation des AEPS

  • 1. Ministère de l’Enseignement Supérieur, de la Recherche Scientifique et de l’Innovation (M.E.S.R.S.I) ------------------ Secrétariat Général ------------------ Université Nazi BONI (U.N.B.) ------------------ ÉCOLE SUPERIEURE D’INFORMATIQUE (E.S.I) Cycle des Ingénieurs de Travaux Informatiques (C.I.T.I) Option : Analyse et Programmation (A.P) RAPPORT DE FIN DE CYCLE Période du 01 Septembre 2016 au 31 Janvier 2017 Auteurs : M. LANKOANDE Yiénouyaba & M. OUEDRAOGO Soufiane Thème : « Mise en place d'une plateforme de suivi de l'exploitation des Adductions d'Eau Potable Simplifiées (A.E.P.S). » Maître de stage M. Malick TAPSOBA Directeur de la Formation et de la Promotion des TIC à l’ANPTIC. Superviseur Dr Borlli Michel Jonas SOME Enseignant Chercheur Ecole Supérieure d’Informatique Année académique 2015-2016
  • 2. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 2 AVANT-PROPOS L’Ecole Supérieure d’Informatique est un institut au sein de l’Université Nazi BONI. Elle propose à ses étudiants deux diplômes, dont le premier, l’Ingéniorat de Travaux Informatiques, marque la fin des études du premier cycle. Ce diplôme du Cycle d’Ingénieurs de Travaux Informatiques n’est accordé qu’aux étudiants ayant validé trois (03) années d’études, et démontré leurs capacités lors d’un stage pratique d’au moins trois mois en entreprise. C’est dans cette logique que nous avons été accueillis, pour notre stage de fin de cycle au sein de l’Agence Nationale de Promotion des Technologies de l’Information et de la Communication, placée sous la tutelle du Ministère du Développement de l’Economie Numérique et des Postes. Le contexte dans lequel nous avons évolué a clairement été défini par un contrat de stage dans lequel étaient décrits entre autres le thème de stage, le règlement intérieur et les conditions de travail dans l’entreprise.
  • 3. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 3 REMERCIEMENTS Nous tenons à remercier dans un premier temps, toute l’équipe pédagogique de l’Ecole Supérieure d’Informatique et les intervenants professionnels pour avoir assuré la majeure partie de notre formation. Nous remercions également toute l’équipe professionnelle de l’Agence Nationale de la Promotion des Technologies de l’Information et de la Communication pour nous avoir accueillis, suivis et encadrés pendant cette période de stage. Nos vifs remerciements particuliers vont à l’endroit de : Dr Borlli Michel Jonas SOME, Enseignant chercheur à l’ESI, notre superviseur ; M. Malick TAPSOBA, Directeur de la Formation et de la Promotion des TIC à l’ANPTIC, notre maître de stage ; Toute l’équipe de l’IRC pour sa brillante collaboration ; M. Moustapha SABA, Ingénieur de Conception à l’ANPTIC pour son assistance et ses multiples conseils. Pour finir, nous témoignons de notre gratitude à tous ceux qui, d’une manière ou d’une autre, ont contribué à notre formation ou à la réussite de ce travail.
  • 4. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 4 RESUME L'accès à l'eau potable et à l'assainissement demeure un enjeu majeur au Burkina Faso. Conscient de cela, le gouvernement à travers le programme national d’approvisionnement en eau potable et d’assainissement a mis en place des adductions d’eau potable simplifiées dans les centres semi-urbains et ruraux, afin d’accroître considérablement le taux d’accès à l’eau potable. L’exploitation de ces adductions d’eau potable simplifiées est confiée à des opérateurs privés qui doivent continuellement rendre compte de leur gestion. Ce compte rendu devrait permettre à l’Etat de suivre l’évolution de ces ouvrages, mais l’on relève des difficultés dans la collecte et l’accessibilité des informations sur l’exploitation des adductions d’eau potable simplifiées. Pour pallier ces difficultés, il s’avère nécessaire de mettre en place une plateforme de suivi de l’exploitation des adductions d’eau potable simplifiées. Ce travail fournit un effort d’analyse, de conception et de développement d’une application web pour résoudre la problématique posée. La conception faite avec Unified Modeling Language et le processus Two Track Unified Process permet de regrouper les fonctionnalités en neuf (09) modules qui sont : gestion des Adductions d’Eau Potable Simplifiées (AEPS), gestion des rapports, gestion des indicateurs de performances, messagerie, gestion des statistiques, gestion des utilisateurs, gestion de la géolocalisation, gestion du renouvèlement des équipements et gestion des commentaires. Ces différents modules ont été développés avec le Framework Symfony et Maria DB comme système de gestion de base de données.
  • 5. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 5 ABSTRACT Access to drinking water and sanitation remains a major challenge in Burkina Faso. Aware of this, the Government through the national program of drinking water supply and sanitation has implemented the simplified drinking water providers in the semi-urban and rural centers, in order to significantly increase the rate of access to safe water. The simplified drinking water providers’ operation is entrusted to private operators who continually are accountable for their management. This account will allow the State to follow the evolution of these structures, however there are difficulties in collecting and the accessibility of the information on the exploitation of the simplified drinking water providers. To surmount these difficulties, it is necessary to set up a platform to follow-up the exploitation of simplified drinking water providers. This document provides an effort of analysis, design and web application development to solve the raised problem. The design made with Unified Modeling Language and Two Track Unified Process allows to group features in nine (09) modules which are: management of simplified drinking water provider, management of reports, indicators of performance, e-mail management, management of Statistics, user’ management, management of geolocation, management of equipment renewal and management of comments. These modules have been developed on the web platform PHP with Symfony Framework and Maria DB the database management system
  • 6. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 6 TABLE DES MATIERES AVANT-PROPOS ............................................................................................................................. 2 REMERCIEMENTS...........................................................................................................................3 RESUME........................................................................................................................................... 4 ABSTRACT........................................................................................................................................5 TABLE DES MATIERES.................................................................................................................. 6 LISTE DES TABLEAUX................................................................................................................... 9 LISTE DES FIGURES......................................................................................................................10 LISTE DES ABREVIATIONS, SIGLES ET ACRONYMES .............................................................11 INTRODUCTION GENERALE......................................................................................................13 CHAPITRE 1 : PRESENTATION DU CONTEXTE DE STAGE....................................................14 1.1 Introduction.......................................................................................................................15 1.2 Présentation de l'ESI ..........................................................................................................15 1.2.1 Présentation générale ......................................................................................................15 1.2.2 Formation......................................................................................................................16 1.2.3 Organigramme de l’ESI...................................................................................................17 1.3 Présentation de l’agence nationale de promotion des TIC .....................................................17 1.3.1 Généralités.....................................................................................................................17 1.3.2 Objectifs et missions.......................................................................................................17 1.3.3 Organes d’administration et de direction ..........................................................................19 1.3.4 Organigramme de l’ANPTIC...........................................................................................20 1.3.5 Présentation de l’IRC......................................................................................................21 1.4 Présentation du projet.........................................................................................................21 1.4.1 Problématique ................................................................................................................21 1.4.2 Objectifs et Résultats attendus.........................................................................................23 1.4.3 Gestion de projet............................................................................................................24 1.4.4 Le Planning prévisionnel.................................................................................................25 1.5 Conclusion........................................................................................................................ 26 CHAPITRE 2 : DEMARCHE ET MOYENS DE REALISATION ....................................................27 2.1 Introduction.......................................................................................................................28 2.2 Exigences fonctionnelles et techniques ................................................................................28 2.3 Méthode de résolution du problème ................................................................................... 29 2.3.1 Choix du langage de modélisation................................................................................... 29
  • 7. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 7 2.3.2 Choix de la méthode d’analyse et de conception ...............................................................30 2.4 Estimation du coût du projet...............................................................................................31 2.4.1 Méthode de calcul du coût...............................................................................................31 2.4.2 Différents coûts..............................................................................................................32 2.5 Conclusion.........................................................................................................................33 CHAPITRE 3 : DOMAINE D'ETUDE.............................................................................................34 3.1 Introduction.......................................................................................................................35 3.2 Etude de l’existant ..............................................................................................................35 3.2.1 Le parc informatique.......................................................................................................35 3.2.2 Les applications réalisées.................................................................................................36 3.2.3 Architecture réseau .........................................................................................................37 3.3 Délimitation et analyse du domaine .....................................................................................37 3.3.1 Identification des concepts clés du domaine. ....................................................................38 3.3.2 Le dictionnaire de données..............................................................................................38 3.3.3 Le diagramme de classes..................................................................................................39 3.4 Conclusion.........................................................................................................................42 CHAPITRE 4 : SPECIFICATIONS DU FUTUR SYSTEME.............................................................43 4.1 Introduction...................................................................................................................... 44 4.2 Identification des acteurs et des cas d'utilisation................................................................... 44 4.2.1 Identification des acteurs du système .............................................................................. 44 4.2.2 Identification des cas d’utilisation ................................................................................... 44 4.2.3 Description textuelle de quelques cas d’utilisation............................................................ 46 4.3 Diagramme des cas d'utilisation...........................................................................................50 4.4 Diagrammes de séquences...................................................................................................51 4.4.1 Authentification..............................................................................................................51 4.4.2 Gérer un incident............................................................................................................52 4.4.3 Gérer un équipement à renouveler...................................................................................53 4.5 Conclusion.........................................................................................................................54 CHAPITRE 5 : ARCHITECTURE DU SYSTEME FUTUR ..............................................................55 5.1 Introduction.......................................................................................................................55 5.2 Identification des composantes logicielles ............................................................................55 5.2.1 Plateforme de développement .........................................................................................55 5.2.2 Système de Gestion de Bases de Données ........................................................................56 5.2.3 Le Framework ORM.......................................................................................................56 5.2.4 Environnement de développement ..................................................................................57
  • 8. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 8 5.2.5 Librairies........................................................................................................................57 5.3 Architecture logicielle .........................................................................................................57 5.3.1. Diagramme de packages..............................................................................................57 5.3.2. Diagramme de déploiement ...............................................................................................58 5.4 Conclusion.........................................................................................................................59 CHAPITRE 6 : CONCEPTION DE LA SOLUTION ...................................................................... 60 6.1 Introduction......................................................................................................................61 6.2 Diagramme de classes d'application .....................................................................................61 6.3 Schémas logique et physique des données ........................................................................... 64 6.4 Conclusion........................................................................................................................ 66 CHAPITRE 7 : REALISATION ET BILAN......................................................................................67 7.1 Introduction...................................................................................................................... 68 7.2 Modules développés .......................................................................................................... 68 7.3 Enchaînement des écrans................................................................................................... 68 7.3.1 Interface pour utilisateur non-connecté........................................................................... 68 7.3.2 Interface pour utilisateurs principaux du système. .............................................................73 7.4 Analyse des écarts...............................................................................................................82 7.4.1 Le Planning réel..............................................................................................................82 7.4.2 Explication des écarts......................................................................................................82 7.4.3 Résultats obtenus............................................................................................................83 7.5 Politique de sécurité............................................................................................................83 7.5.1 Notion de sécurité..............................................................................................................83 7.5.2 Gestion des mots de passe et de la connexion à l’application.................................................83 7.5.3 Gestion des attaques.......................................................................................................... 84 7.5.4 Mise en place de la sauvegarde et de la restauration ..............................................................85 7.5.5 Protection contre les catastrophes ...................................................................................... 86 7.6 Conclusion.............................................................................................................................. 86 CONCLUSION GENERALE...........................................................................................................87 LISTE DES REFERENCES BIBLIOGRAPHIQUES........................................................................88 BIBLIOGRAPHIE........................................................................................................................88 WEBOGRAPHIE........................................................................................................................ 89 ANNEXE 1 SYMFONY.................................................................................................................. 90
  • 9. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 9 LISTE DES TABLEAUX Tableau 1 : Coût de développement...................................................................................................32 Tableau 2 : Coût de formation des utilisateurs....................................................................................32 Tableau 3 : Coût total de réalisation...................................................................................................32 Tableau 4 : Liste de quelques applications..........................................................................................36 Tableau 5 : Description du concept AEPS.........................................................................................38 Tableau 6 : Description du concept Rapport......................................................................................38 Tableau 7 : Description du concept Opérateur...................................................................................39 Tableau 8 : Description du concept Incident......................................................................................39 Tableau 9 : Principales règles de gestion.............................................................................................40 Tableau 10 : Liste des cas d'utilisation................................................................................................45 Tableau 11 : Description du CU Gérer un incident ............................................................................ 46 Tableau 12 : Description du CU Gérer une AEPS..............................................................................47 Tableau 13 : Description du CU S'authentifier................................................................................... 48 Tableau 14 : Description du CU Gérer un équipement à renouveler ................................................... 49 Tableau 15 : Description de la classe Gaeps ...................................................................................... 62 Tableau 16 : Description de la classe GIncident..................................................................................63 Tableau 17 : Description de la classe GIndicateur.............................................................................. 64
  • 10. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 10 LISTE DES FIGURES Figure 1 : Organigramme de l'ESI.......................................................................................................17 Figure 2 : Organigramme de l'ANPTIC...............................................................................................20 Figure 3 : Diagramme de GANTT du planning prévisionnel ............................................................... 26 Figure 4 : Architecture réseau .............................................................................................................37 Figure 5 : Diagramme de classes .........................................................................................................41 Figure 6 : Diagramme de cas d'utilisation.............................................................................................50 Figure 7 : Diagramme de séquences du cas d’utilisation « s'authentifier » ...............................................51 Figure 8 : Diagramme de séquences du cas d'utilisation « Gérer un incident » ........................................52 Figure 9 : Diagramme de séquences du cas d'utilisation « Gérer un équipement à renouveler » ...............53 Figure 10 : Diagramme de packages ....................................................................................................58 Figure 11 : Diagramme de déploiement...............................................................................................59 Figure 12 : Modèle physique de donnée...............................................................................................65 Figure 13 : Interface d’accueil (1) ....................................................................................................... 69 Figure 14 : Interface d’accueil (2) ........................................................................................................70 Figure 15 : Interface détails d'une AEPS.............................................................................................. 71 Figure 16 : Visualisation des branchements d'une AEPS.......................................................................72 Figure 17 : Formulaire de connexion...................................................................................................73 Figure 18 : Interface accueil pour utilisateur authentifié........................................................................74 Figure 19 : Accueil du module Gestion AEPS......................................................................................75 Figure 20 : Interface d'ajout d'une BF..................................................................................................76 Figure 21 : Volet édition d'un rapport ................................................................................................. 77 Figure 22 : Liste des rapports..............................................................................................................78 Figure 23 : Visualisation d'un rapport soumis.......................................................................................79 Figure 24 : Situation des BF sous formes de graphes............................................................................80 Figure 25 : Visualisation des charges d'exploitation ..............................................................................81 Figure 26 : Diagramme de GANTT du planning réel ...........................................................................82
  • 11. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 11 LISTE DES ABREVIATIONS, SIGLES ET ACRONYMES 2TUP Two Track Unified Process AEPS Adduction d’Eau Potable Simplifiée AJAX Asynchronous Javascript And XML ANPTIC Agence Nationale de Promotion des TIC API Application Programming Interface BF Borne Fontaine BODI Burkina Open Data Initiative BP Branchement Privé CAT Cellule d’Appui Technique CITI Cycle d’Ingénieurs de Travaux Informatiques CU Cas d’Utilisation DCT Département de la Comptabilité et de la Trésorerie DDM Département du Développement et de la Maintenance DDRH Département du Développement des Ressources Humaines DE Département des Etudes DEA Département de l’Exploitation des Applications DEAT Département des Equipements et de l’Assistance Technique DEI Direction des Etudes et de l’Ingénierie DESR Département de l’Exploitation et du Support Réseaux DEST Direction de l'Exploitation et du Support Technique DFB Département des Finances et du Budget DFC Direction des Finances et de la Comptabilité DFCO Département de la Formation Continue DFPTIC Direction de la Formation et de la Promotion des TIC DG Direction Générale DGAP Département de Gestion Administrative et de Paie DGEP Direction Générale de l’Eau Potable DIC Département de l’Innovation et de la Certification DICOM Département des Infrastructures de Communication DIG Direction de l’Intranet Gouvernementale DME Département de la Mise en Exploitation DMPI Département des Marchés de Prestations Intellectuelles DMTS Département des Marchés de Travaux et Biens de Services DMZ DeMilitarized Zone DNIS Département de la Normalisation et de l’Intégration des Systèmes DOC Département des Outils de Communication DPA Département du Patrimoine et de l’Approvisionnement
  • 12. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 12 DPOTIC Département de la Promotion des Outils des TIC DREA Direction Régionale de l’Eau et de l’Assainissement DRH Direction des Ressources Humaines DS Département de la Sécurité DSA Direction des Systèmes Applicatifs DVP Département de la Veille et de la Prospective ESI Ecole Supérieure d’Informatique HTML HyperText Markup Language IDE Integrated Development Environment IRC International Water and Sanitation Center JEE Java Enterprise Edition LMD Licence Master Doctorat OMT Object Modeling Technique OOSE Object Oriented Software Engineering PDF Portable Document Format PDF Portable Document Format PHP Php HyperText Preprocessor PMH Pomme à Motricité Humaine PRM Personne Responsable des Marchés RESINA Réseau Informatique Nationale de l’Administration SAI Service d’Audit Interne SAJ Service des Affaires Juridiques SCMRP Service de la Communication, du Marketing et des Relations Publiques SG Secrétariat General SGBD(R) Système de Gestion de Base de Données (Relationnelle) SDWP Simplified Drinking Water Provider SP Secrétariat Particulier SQL Structured Query Language TIC Technologies de l’Information et de la Communication UML Unified Modeling Language UNB Université Nazi BONI
  • 13. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 13 INTRODUCTION GENERALE Le Ministère du Développement de l’Economie Numérique et des Postes a initié en 2013 le Burkina Open Data Initiative. Ce projet vise à encourager les services publics, du secteur privé et de la société civile, à mettre à disposition de façon libre et gratuite, des données électroniques qui constituent un patrimoine immatériel qui pourront être ensuite exploitées pour créer de la valeur ajoutée par le développement de e-services et de startup pour promouvoir le développement de l’économie numérique. C'est dans ce cadre que l'ANPTIC, structure chargée du projet nous a confié l'étude et la mise en place d'une application web devant permettre la collecte et le partage d’informations sur l'exploitation des adductions d'eau potable simplifiées. L’objectif de cette application est de présenter un cas de réutilisation de données ouvertes publiées sur la plateforme officielle de BODI. Dans le présent rapport qui s’articule autour de sept (07) chapitres, il sera question dans un premier temps de faire une présentation succincte de la structure d’accueil et du cadre général du thème, ensuite sera exposée l’analyse du système, puis viendra la conception détaillée et enfin une présentation de la solution implémentée et un bilan du travail.
  • 14. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 14 CHAPITRE 1 : PRESENTATION DU CONTEXTE DE STAGE
  • 15. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 15 1.1 Introduction Le passage du milieu universitaire à celui de l’entreprise n’est pas toujours aisé, encore moins dans le cadre d’un stage. Dans ces conditions il s’avère nécessaire de connaître le fonctionnement interne de l’entreprise ainsi que son mode de communication afin de faciliter son intégration. Le présent chapitre est le lieu de revenir d’abord sur l'organisation administrative de l'école et le dispositif pédagogique. Ensuite il sera question pour nous de présenter notre structure d’accueil l’ANPTIC, son historique et ses domaines d’intervention. Nous évoquerons par la suite, la problématique et les résultats attendus de notre étude pour finir par une proposition de solution aux problèmes posés. 1.2 Présentation de l'ESI 1.2.1 Présentation générale L’Ecole Supérieure d’Informatique a été créée en 1991 à Ouagadougou et transférée en 1995 au sein de l’Université Polytechnique de Bobo-Dioulasso, devenue aujourd’hui Université Nazi BONI. L’ESI a pour mission : • La formation fondamentale, appliquée et/ou professionnelle dans les domaines de l’informatique ; • La formation continue ; • La recherche scientifique et technologique ainsi que la valorisation des résultats de la recherche ; • La diffusion de la culture et de l’information dans les domaines relevant de sa compétence ; • La collaboration avec d’autres structures de formation et/ou de recherche pour la préparation des diplômes ;
  • 16. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 16 • Et la participation à des programmes internationaux de formation et de recherche. 1.2.2 Formation L’ESI a connu deux systèmes d’enseignement, le système classique de 1991 à 2010 et le système Licence Master Doctorat à la rentrée de 2010-2011. La formation à l’ESI est sanctionnée par les diplômes suivants : • Une License d’informatique ; • Un diplôme d’ingénieur de conception informatique. 1.2.2.1 Licence d’informatique Ce cycle a pour objectif de former des cadres moyens, opérationnels et évolutifs dans une diversité de domaine d’applications de l’Informatique. La durée de formation pour ce cycle est de trois (03) ans répartis en deux années de tronc commun et une année de spécialisation dans l’un des domaines suivants : l’ingénierie des systèmes d’information et l’ingénierie des réseaux et systèmes. Les étudiants de ce cycle doivent effectuer à la fin de leur formation un stage pratique obligatoire et réaliser un projet de fin de cycle. Le stage pratique vise à garantir une intégration rapide des futurs diplômés en milieu professionnel et doit s’effectuer en entreprise (publique ou privée) ou dans une administration publique. 1.2.2.2 Cycle des Ingénieurs de Conception Informatique Pour ce cycle, la durée de formation est de deux (02) ans. Elle est ouverte aux titulaires d’un diplôme de niveau BAC+3 en informatique. A ce niveau également, les étudiants doivent effectuer pendant leur formation de première année, un stage en entreprise et réaliser un mémoire de fin de cycle faisant l’objet d’une soutenance publique en deuxième année.
  • 17. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 17 1.2.3 Organigramme de l’ESI L’organisation de l’ESI peut être illustrée par l’organigramme de la figure 1 Figure 1 : Organigramme de l'ESI 1.3 Présentation de l’agence nationale de promotion des TIC 1.3.1 Généralités L’ANPTIC est une agence publique à caractère administratif créée en février 2014 afin de répondre à la volonté politique des autorités burkinabè de faire des TIC un levier de développement de l’économie nationale. Elle est l'autorité technique nationale en matière de réalisation des projets et programmes relatifs aux TIC au Burkina Faso. 1.3.2 Objectifs et missions L’ANPTIC a pour missions d'une part l'opérationnalisation de la stratégie du gouvernement en matière d'administration électronique et d'autre part, la promotion de l'utilisation des TIC dans les autres domaines de développement social, économique, scientifique et culturel. Directeur Directeur des études Directeur des stages Secrétaire Chef de services des affaires financières
  • 18. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 18 A ce titre, elle est chargée : En matière d'administration électronique : • D’assurer l’exploitation, le développement et la maintenance du RESINA ; • D’assurer l'exploitation, le développement et la maintenance des outils de communication ou de collaboration électroniques de l'Administration ; • D’assurer l'exploitation et le développement des data center de l'Administration ; • D’élaborer les normes et référentiels communs pour la mise en œuvre de systèmes d'information et de veiller à leur application ; • D’assurer l'exploitation et la maintenance des applications métiers transversales de l'administration ; • D’assurer l'exploitation et la maintenance des applications métiers sectoriels au besoin ; • D’assurer le développement des services en ligne ; • De réaliser des études d'orientation stratégiques et des missions d'audit informatique des grands systèmes ; • D’élaborer et mettre en œuvre le plan d'équipement de l'Administration ; • D’assurer la sécurité des systèmes d'information de l'Administration ; • D’accompagner les services informatiques de l'Administration dans le cadre de leurs missions. En matière de promotion de l'utilisation des TIC dans les autres domaines de développement social, économique, scientifique et culturel : • D’être un incubateur d'entreprises TIC de pointe et aider à la valorisation et à la diffusion des systèmes et produits des TIC conçus et réalisés localement ;
  • 19. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 19 • De mettre à la disposition des établissements publics et privés des formations en informatique, des spécialistes afin de promouvoir des formations d'excellence ; • D’assurer l'accompagnement des personnes souhaitant développer des capacités professionnelles dans l'utilisation des outils liés aux TIC ; • De promouvoir l'utilisation des logiciels libres ; • De contribuer à améliorer, grâce aux TIC, la compétitivité de l'économie nationale et promouvoir le commerce électronique ; • D’exécuter toute mission de service public confiée par le gouvernement dans le cadre de la mise en œuvre des cybers stratégies sectorielle. 1.3.3 Organes d’administration et de direction Les Organes d'Administration et de Direction de l’ANPTIC sont le Conseil d'Administration et la Direction Générale. 1.3.3.1 Le conseil d’administration L'ANPTIC est présidée par un Conseil d'Administration de neuf (09) membres. Le Conseil d'Administration est l'organe de délibération de l'ANPTIC. 1.3.3.2. La direction générale L'Agence est dirigée par un Directeur Général nommé par décret pris en Conseil de Ministres sur rapport du Ministre de la tutelle technique. Le Directeur Général assiste aux délibérations du Conseil d'Administration avec voix consultative, entouré de ses plus proches collaborateurs. La Direction Générale de l'ANPTIC est organisée autour des structures suivantes : • Le Secrétariat Général (SG) ; • Le Service des Affaires Juridiques (SAJ) ;
  • 20. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 20 • Le Service de la Communication, du Marketing et des Relations Publiques ; • Le Service d'Audit Interne ; • La Cellule d'Appui Technique. 1.3.4 Organigramme de l’ANPTIC L’organisation de l’ANPTIC est illustrée par l’organigramme ci-dessous. Notre stage s’est essentiellement déroulé à la direction de la formation et de la promotion des TIC qui est chargée entre autres : • De mettre au profit des établissements publics et privés de formation en informatique, des spécialistes afin de promouvoir des formations d’excellence ; • De soutenir la formation continue des professionnels des TIC, afin d’aider les entreprises locales du secteur à développer une expertise reconnue, et valoriser cette expertise sur le marché international ; • De promouvoir l’utilisation des logiciels libres et l’accès universel et non discriminatoire aux services offerts sur Internet. Figure 2 : Organigramme de l'ANPTIC DG SP SAJ SAI SCMRP CAT SG DRH DDRH DGAP DFC DPA DPT DFB PRM DMPI DMTS DEI DVP DE DNIS DSA DME DDM DEST DESR DEA DEAT DIG DS DICOM DOC DFPTIC DIC DFOC DFOTIC
  • 21. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 21 1.3.5 Présentation de l’IRC Afin de réussir ce projet, l’ANPTIC a collaboré avec l’IRC. Créé en 1968, IRC est une organisation non gouvernementale néerlandaise qui assure la production, le partage, la promotion et l’utilisation des connaissances afin que les gouvernements, organisations et acteurs individuels puissent améliorer durablement l’accès à l’eau potable, à l’hygiène et à l’assainissement des populations des pays en voie de développement. Au Burkina Faso, IRC et ses partenaires locaux développent et testent des approches innovantes et appuient les changements de politiques et de pratique en stimulant le partage des connaissances. Le programme pays repose sur deux volets. Le premier volet est la recherche-action qui consiste en appuis méthodologiques et conceptuels pour tester des approches visant à améliorer la planification, la gestion et le suivi des services d’eau potable, d’assainissement et d’hygiène. Le second volet qui porte sur le partage des connaissances consiste en activités de formation, de mise en place et de facilitation de plateformes de partage d’informations et de connaissances - notamment via les médias électroniques - et de participation aux processus décisionnels locaux et nationaux. 1.4 Présentation du projet 1.4.1 Problématique Dans sa volonté d’offrir de l’eau potable à tous, le gouvernement du Burkina Faso a pris l’engagement d’équiper les chefs-lieux de communes et les villages de plus de 3500 habitants d’AEPS. Une AEPS est un système constitué d’une station de pompage mécanique, alimenté par énergie thermique ou solaire, d’un château d’eau et d’un mini réseau de distribution d’eau sous-pression desservant des bornes fontaines et parfois des branchements privés. Afin d’assurer une meilleure gestion des AEPS, il a été adopté une politique de gestion décentralisée dont la commune est le maitre d’ouvrage. La commune à son tour peut déléguer la gestion de ses AEPS à un opérateur privé professionnel sur la base d'une offre de service. Ainsi l’opérateur
  • 22. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 22 rend compte semestriellement -à travers un rapport- de la gestion technique et financière des AEPS à la commune avec qui il a signé le contrat. La commune après réception du rapport le transmet à la DREA pour des analyses poussées. Le résultat de ces analyses est transmis à la DGEP qui procède à des prises de décisions devant faciliter la gestion des AEPS. Depuis, aucun retour d’expérience structuré n’a été organisé pour faire l’état de la gestion des AEPS au Burkina Faso. Cela s’explique par un certain nombre de problèmes identifiés par les principaux acteurs impliqués dans la mise en œuvre et le suivi de ces ouvrages. Ces difficultés sont entre autres : • L’absence d’informations sur le fonctionnement des AEPS en temps réels ; • L’absence de données pour des analyses statistiques ; • Les difficultés liées à la rédaction du rapport semestriel de l’exploitant ; • La non-soumission des rapports par les opérateurs privés ; • La lenteur dans les prises de décision due à la remontée tardive de l’information. Ce disfonctionnement entrave le partage d’informations avec les bailleurs de fonds dans le secteur de l’eau et de l’assainissement alors que ces derniers ont besoin de connaître régulièrement la situation afin de comptabiliser ou d’entreprendre des actions. Dans un souci de partage de l’information aux citoyens l’ANPTIC à travers le Burkina Open Data Initiative a mis en place une application de cartographie des points d’eau (CARTEAU). Les informations sur la situation des AEPS devraient alimenter CARTEAU. C’est au vue de tout cela qu’en collaboration avec l’IRC, l’ANPTIC nous a confié le projet de mise en place d’une plateforme de suivi de l’exploitation des AEPS.
  • 23. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 23 1.4.2 Objectifs et Résultats attendus Au regard de toutes ces difficultés précédemment citées, une analyse approfondie s’avère nécessaire afin de proposer une solution qui puisse y remédier. L’objectif de cette analyse est de faciliter le suivi des AEPS à travers : • La pérennisation de l’information ; • La centralisation des données ; • La rédaction et de la soumission rapide du rapport semestriel par les exploitants ; • L’accès rapide aux rapports par les communes, les DREA et la DGEP ; • Le partage d’informations sur les AEPS entre les différents acteurs pour des analyses statistiques et des prises de décisions ; Pour ce qui concerne les résultats attendus, le système devra permettre de : • Recenser l’ensemble des informations techniques et financières sur les AEPS (nombre de bornes fontaines, nombre de branchements privés, recettes …) ; • Localiser sur une carte les AEPS, les bornes fontaines et les branchements privés associés ; • Alimenter l’application CARTEAU conçue dans le cadre du BODI avec les informations sur la localisation des bornes fontaines et des branchements privés des différentes AEPS ; • Consulter l’état de fonctionnement des AEPS, des bornes fontaines et des branchements privés en temps réel.
  • 24. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 24 1.4.3 Gestion de projet 1.4.3.1Acteurs du projet Le Comité de pilotage Le comité de pilotage est un groupe d’encadreurs chargé de veiller au bon déroulement du projet. Son rôle est d’orienter le groupe de projet, de valider les choix méthodologiques, de s’assurer que le projet reste en phase avec les objectifs initiaux et de valider toutes les étapes du projet. Il est constitué de : • Mr TAPSOBA Abdoul Malick Directeur de la DFPTIC, maître de stage ; • Mr BASSONO Richard chargé de recherche action à l’IRC Burkina ; • Dr SOME Borlli Michel Jonas enseignant chercheur à l’ESI, superviseur. Groupe de projet Le groupe de projet est chargé de l’étude, de la conception et de l’implémentation du projet sous la supervision du groupe de pilotage. Il se compose des personnes suivantes : • LANKAONDE Yiénouyaba élève-Ingénieur de travaux en Analyse et Programmation 3ème année à l’ESI ; • OUEDRAOGO Soufiane élève-Ingénieur de travaux en Analyse et Programmation 3ème année à l’ESI. Groupe d’utilisateurs Le groupe d’utilisateurs regroupe l’ensemble des acteurs qui interagissent directement avec le système afin de fournir ou d’obtenir des informations spécifiques. Il est composé : • Du délégué général de l’eau potable ; • Des délégués régionaux de l’eau et de l’assainissement ; • Des délégués communaux ; • Des opérateurs privés ;
  • 25. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 25 • De l’administrateur des données. 1.4.4 Le Planning prévisionnel La bonne gestion d’un projet nécessite une organisation : planification des tâches et activités, suivi des échéances, des ressources affectées. Le diagramme de Gantt est une représentation schématique des tâches à effectuer assorties de leurs durées de réalisation (date de début et date de fin). Un planning prévisionnel a été établi dès le lancement du projet. Le diagramme de GANTT de la figure 3 illustre la planification des différentes tâches qu’il fallait exécuter. Notons cependant que pour des raisons académiques, le stage a été suspendu pendant tout le mois d’octobre.
  • 26. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 26 Figure 3 : Diagramme de GANTT du planning prévisionnel 1.5 Conclusion Dans ce chapitre nous avons en premier lieu présenté l’organisation administrative de l’école, le dispositif pédagogique et la structure d’accueil. Par la suite, nous avons présenté la problématique, les objectifs et les résultats attendus. Pour finir, nous avons présenté les acteurs du projet et proposé un planning prévisionnel d’exécution. Nous pouvons ainsi, conformément à notre méthode de développement entamer la démarche et les moyens de réalisation du projet.
  • 27. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 27 CHAPITRE 2 : DEMARCHE ET MOYENS DE REALISATION
  • 28. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 28 2.1 Introduction La phase de la démarche et du moyen de résolution permet d’identifier exactement ce que le futur système devra réaliser en termes de métier. Ainsi pour réduire le risque d’échec du projet, il est important de bien choisir la démarche à suivre et la méthode à appliquer. Dans cette partie nous énumérerons les exigences fonctionnelles et techniques puis annoncerons la méthode retenue pour la résolution du problème. 2.2 Exigences fonctionnelles et techniques D’après les besoins recueillis auprès des différents acteurs, les fonctionnalités attendues du système peuvent être citées comme suit : • Gestion des utilisateurs : ce module rassemble les fonctionnalités permettant la gestion sécurisée et complète des utilisateurs, partant de l’enregistrement, l’attribution des privilèges jusqu’à la modification d’un compte utilisateur. • Gestion des AEPS : ce module regroupe les fonctionnalités permettant l’enregistrement ou la mise à jour des AEPS ainsi que les ouvrages qui leur sont associés à savoir les BP, les BF et les PMH. • Gestion des rapports : ce module rassemble les fonctionnalités facilitant non seulement le suivi mensuel des différentes BP, BF et des PMH mais aussi du rapport semestriel durant son cycle de vie : de la création, la rédaction continue jusqu’à la soumission. • Gestion des indicateurs de performances : A travers ce module on a la possibilité d’enregistrer, de mettre à jour et de consulter les indicateurs de performances d’une AEPS donnée. • Messagerie : ce module offre la possibilité aux utilisateurs connectés de communiquer entre eux à travers un message texte. Ils pourront donc recevoir, envoyer ou supprimer un message texte.
  • 29. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 29 • Gestion des commentaires : à travers ce module nous donnons l’opportunité à tout utilisateur connecté ou pas, de faire un commentaire au vu des informations qui lui sont présentées. • Gestion des équipements : ce module permet de répertorier pour chaque AEPS, la liste des équipements à renouveler et de la rendre accessible par les ayants droit. • Gestion des statistiques : ce module regroupe les fonctionnalités permettant de générer des statistiques à partir des données de l’exploitation des AEPS. • Gestion de la géolocalisation : ce module permet de visualiser l’ensemble des ouvrages : AEPS, BF, BP et PMH de tout le territoire burkinabè sur une carte géographique. 2.3 Méthode de résolution du problème 2.3.1 Choix du langage de modélisation La réalisation de tout système informatique nécessite une modélisation préalable. Un langage de modélisation est un langage artificiel qui peut être utilisé pour exprimer de l'information dans un formalisme qui est définie par un ensemble cohérent de règles. Dans la conduite de ce projet, nous avons choisi UML comme langage de modélisation. UML est le résultat de la fusion de précédents langages de modélisation objet : Booch, OMT, OOSE. Principalement issu des travaux de Grady Booch, James Rumbaugh et Ivar Jacobson, UML est à présent un standard adopté par l'Object Management Group. Il présente plusieurs avantages en ce sens qu’il permet : • Une modélisation du système, en utilisant les techniques orientées objet ; • Une modélisation de très haut niveau indépendante des langages et des environnements ; • Une communication efficace entre les différents acteurs du projet ;
  • 30. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 30 • Une expression dans un seul modèle de tous les aspects statiques et dynamiques d’un projet ; • Une simulation à travers les scénarii avant de construire un système. 2.3.2 Choix de la méthode d’analyse et de conception La méthode d'analyse et de conception est un procédé ayant pour objectif de permettre la formalisation des étapes préliminaires du développement d'un système, afin de rendre ce développement plus fidèle aux besoins du client. Parmi la panoplie de méthodes d’analyse et de conception, nous avons choisi 2TUP, pour sa simplicité, son itération, sa bonne gestion des risques dans son cycle de développement. 2TUP est un processus proposant un cycle de développement en Y, qui dissocie les aspects techniques des aspects fonctionnels. Il s'articule autour de trois phases essentielles : • Une branche technique ; • Une branche fonctionnelle ; • Une branche de réalisation. 2.3.2.1Branche fonctionnelle Les principales étapes de la branche fonctionnelle se présentent comme suit : • Capture des besoins fonctionnels : Cette phase a pour objectif de définir la frontière fonctionnelle entre le système et son environnement et les activités attendues des différents utilisateurs par rapport au système. • Analyse : consiste à étudier précisément les spécifications fonctionnelles de manière à obtenir une idée de ce que va réaliser le système en termes de métier.
  • 31. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 31 2.3.2.2 Branche technique Les principales étapes de la branche technique se présentent comme suit : ▪ Capture des besoins techniques : Cette étape recense toutes les contraintes sur les choix de technologies pour la conception du système. ▪ Conception générique : Définit les composants nécessaires à la construction de l’architecture technique. Cette conception est complètement indépendante des aspects fonctionnels. Elle permet de générer le modèle de conception technique qui définit les Frameworks. 2.3.2.3 Phase conception – réalisation Les principales étapes de cette branche sont les suivantes : • Conception préliminaire : Cette étape permet de produire le modèle de conception système. Ce dernier organise le système en composants, délivrant les services techniques et fonctionnels. Ce qui induit le regroupement des informations des branches techniques et fonctionnelles. • Conception détaillée : permet d’étudier comment réaliser chaque composant. Le modèle logique y est particulièrement important dans la mesure où c’est dans cette étape qu’on gère le plus grand nombre d’informations. • Codage et tests : permet d’effectuer la production des composants et les tests des unités de code au fur et à mesure de leur réalisation. • Recette : consiste à valider les fonctionnalités du système développé. 2.4 Estimation du coût du projet 2.4.1 Méthode de calcul du coût En ce qui concerne le calcul du coût de développement, la méthode la plus couramment utilisée est la méthode COCOMO (Constructive COst MOdel). Celle- ci permet d’estimer le coût de développement d’un logiciel à partir du type de
  • 32. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 32 projet (qualification des acteurs, maitrise de l’environnement de développement), de la taille de l’application (nombre de lignes de code à écrire) et du salaire moyen d’un informaticien. Cependant, le fait que nous travaillons avec un Framework nous empêche de l’utiliser. En effet, les lignes de codes générées par le Framework viendront gonfler la taille estimée du produit, donnant ainsi un coût de développement erroné. De ce fait, le groupe de réalisation a opté pour la méthode d’estimation propre à lui. Celle-ci permet d’estimer le coût de développement du produit en se basant sur la composition de l’équipe de réalisation, le temps que chacun a passé sur le projet et l’estimation de son salaire horaire moyen. 2.4.2 Différents coûts Le matériel nécessaire dans le cadre de ce projet existe déjà. Il en est de même pour les logiciels utilisés qui sont tous gratuits. Le coût du matériel et logiciel est estimé à 0 FCFA. Les tableaux 1, 2 et 3 présentent les autres coûts relatifs au projet. Tableau 1 : Coût de développement Travailleurs Heures de travail Coût horaire Montant LANKOANDE Yiénouyaba 704 H soit 8 H par jour 1 500 FCFA 1 056 000 FCFA OUEDRAOGO Soufiane 704 H soit 8 H par jour 1 500 FCFA 1 056 000 FCFA Total 2 112 000 FCFA Tableau 2 : Coût de formation des utilisateurs Nombre d’heures Coût horaire Nombre d’utilisateurs Montant 5 H 5 000 FCFA 321 8 025 000 FCFA Tableau 3 : Coût total de réalisation Désignation Montant Coût de développement 2 112 000 FCFA Coût de formation des utilisateurs 8 025 000 FCFA Coût total 10 137 000 FCFA
  • 33. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 33 2.5 Conclusion Après avoir abordé le thème d’étude qui nous a été attribué, nous avons adopté le processus de développement 2TUP et le langage de modélisation UML comme outils d’analyse et de conception pour ce projet. En joignant ceux-ci au plan de travail préétabli, nous sommes dans les conditions pour attaquer le domaine d’étude qui fera l’objet du prochain chapitre.
  • 34. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 34 CHAPITRE 3 : DOMAINE D'ETUDE
  • 35. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 35 3.1 Introduction Comme son nom l’indique, ce chapitre nous permettra de présenter l’existant et d’analyser le domaine. Pour ce faire, nous allons dans un premier temps étudier l’existant et procéder à la délimitation et à l’analyse du domaine. 3.2 Etude de l’existant 3.2.1 Le parc informatique Les éléments qui composent le parc informatique de l’ANPTIC se présentent comme suit : • Une trentaine de postes de travail qui sont les ordinateurs fixes du réseau à partir desquels les utilisateurs accèdent à leurs sessions ; • Une dizaine de serveurs qui sont des ordinateurs dotés d’une très grande puissance de traitement, d’une très grande capacité de stockage et qui sont très robustes. Ils permettent d’assurer la disponibilité des services réseau tels que le web, la messagerie, la sauvegarde de données, le partage de fichiers ; • Des ordinateurs portables utilisés par les stagiaires et quelques agents pour se connecter au réseau ; • Du matériel de téléphonie IP ; • Des imprimantes, scanners, photocopieuses qui constituent les outils bureautiques ; • Des équipements d’interconnexion : ce sont les éléments du réseau qui relient plusieurs nœuds. Ils sont composés de switchs, de routeurs et de pare-feu ; • Des onduleurs pour la protection des équipements ; • Des systèmes d’exploitation linux/cent OS et Unix/Solaris installés sur les différents serveurs ; • Et des systèmes d’exploitation Windows 7, 8 et 10 installés sur les ordinateurs de bureau.
  • 36. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 36 3.2.2 Les applications réalisées L’ANPTIC a mise en place des applications permettant d’améliorer la productivité des services publiques et d’encourager l’utilisation des TIC. Le tableau suivant présente la liste de quelques plateformes qui ont été développées : Tableau 4 : Liste de quelques applications Applications Description DATA.GOV.BF Plateforme Open Data du Gouvernement. Open Elections Application permettant le suivi des résultats des élections présidentielles en temps réel. NENDO Une application qui présente les indicateurs et les statistiques sur les écoles du Burkina Faso CARTEAU-BF Application permettant de localiser les points d’eau au Burkina Faso. eConseil des ministres Application facilitant une meilleure préparation des sessions du Conseil des Ministres et améliorant les communications/collaboration entre Ministres ou entre cabinets ministériels;
  • 37. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 37 3.2.3 Architecture réseau L’architecture réseau du système informatique de l’ANPTIC peut être illustrée par la figure 5. Figure 4 : Architecture réseau 3.3 Délimitation et analyse du domaine L’objectif de l’analyse du domaine est d’obtenir un modèle précis, concis, compréhensible et correcte du monde réel. Cette analyse permet d’avoir une bonne compréhension du domaine d’étude à travers la description des différents concepts.
  • 38. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 38 3.3.1 Identification des concepts clés du domaine. Les concepts clés du domaine d’étude sont les suivants : AEPS, Opérateur, Rapport, Incident et Indicateur. 3.3.2 Le dictionnaire de données Tableau 5 : Description du concept AEPS Tableau 6 : Description du concept Rapport AEPS Attribut Type Description IdAEPS Numérique Clé primaire d’une AEPS Nom Alphanumérique Le nom de l’AEPS (unique) DateService Date La date de mise en service de l’AEPS SourceEnergie Alphanumérique Le type d’énergie permettant l’alimentation de la pompe Observation Alphanumérique Informations générales sur l’AESP Etat Booléen Spécifie si l’AEPS est fonctionnel ou pas. ReseauDistribution Alphanumérique Description du réseau de distribution ReseauRefoulement Alphanumérique Description du réseau de refoulement Stockage Alphanumérique Description de la capacité de stockage Latitude Réel Position du château en latitude Longitude Réel Position du château en longitude Rapport Attribut Type Description IdRapport Numérique Identifie de façon unique le rapport ObservationGenerale Chaîne de caractères Observations liées à l’AEPS EstSoumis Booléen Spécifie l’état du rapport DateSoumission Date Correspond à la date de soumission du rapport
  • 39. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 39 Tableau 7 : Description du concept Opérateur Tableau 8 : Description du concept Incident 3.3.3 Le diagramme de classes Le diagramme de classes exprime la structure statique du système en termes de classes et de relations entre ces classes. Son intérêt est de modéliser les entités du système d’information et permettre de représenter l’ensemble des informations finalisées qui sont gérées par le domaine. Opérateur Attribut Type Description IdOperateur Numérique Clé primaire d’un opérateur privé Nom Alphanumérique Le nom de l’opérateur privé AdresseSiege Alphanumérique L’adresse du siège de l’opérateur privé au Burkina Faso Incident Attribut Type Description IdIncident Numérique Clé primaire d’un incident DateIncident Date Date à laquelle l’incident s’est produit DateEnregistrement Date La date d’enregistrement de l’incident Element Alphanumérique Nom de l’équipement concerné par l’incident Description Alphanumérique Description de l’incident Cause Alphanumérique Cause de l’incident DateSolution Date La date à laquelle l’incident a été résolue Solution Alphanumérique Procédure de résolution de l’incident CoutSolution Numérique Le cout de la solution EtatFinal Alphanumérique L’état final de l’incident
  • 40. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 40 3.3.3.1 Règles de gestion Afin de mieux structurer les données et d’éviter les redondances dans la base de données, nous avons établi des règles de gestion. Certaines découlent du fonctionnement du système actuel et d’autres ont été introduites par le groupe de projet dans le but de corriger les insuffisances du système. Tableau 9 : Principales règles de gestion N° Principales règles de gestion 1 Une commune est située dans une région 2 Une région possède plusieurs communes 3 Une commune possède plusieurs villages 4 Dans un village il y a éventuellement une AEPS 5 Une AEPS possède éventuellement une ou plusieurs BF 6 Une AEPS possède éventuellement un ou plusieurs BP 7 Une AEPS possède éventuellement une ou plusieurs PMH 8 Un BP, BF ou PMH ne peut appartenir qu’à une AEPS 9 La direction générale dispose d’un compte d’utilisateur sur la plateforme 10 Chaque DREA dispose d’un compte utilisateur sur la plateforme 11 Chaque commune dispose d’un compte utilisateur sur la plateforme 12 Un opérateur privé peut gérer plusieurs AEPS dans des communes différentes 13 Un opérateur privé dispose d’un compte d’utilisateur sur la plateforme 14 Les équipements d’une AEPS peuvent être renouvelés 15 Un équipement est caractérisé par son nom et sa catégorie spécifiant sa durée de vie. 16 Une AEPS possède au moins un indicateur de performance 17 Les indicateurs de performance sont mis à jour tous les six mois pour chaque AEPS 18 Un rapport semestriel ne porte que sur la gestion d’une seule AEPS. 19 Un rapport semestriel ne peut être créé et mis à jour que par un opérateur privé 20 Un rapport semestriel ne peut être consulté que par les utilisateurs affectés à la gestion de l’AEPS concerné. 21 Un utilisateur peut envoyer un message texte à un autre utilisateur. 22 Tout internaute y compris les utilisateurs peut poster un commentaire sur la gestion d’une AEPS. 23 Un incident concerne une et une seule AEPS 24 Un opérateur gère une AEPS sous la base d’un contrat 25 Les équipements d’une AEPS peuvent être renouvelés plusieurs fois 3.3.3.2 Représentation La figure 6 présente le diagramme de classes.
  • 41. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 41 Figure 5 : Diagramme de classes
  • 42. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 42 3.4 Conclusion Dans ce chapitre consacré au domaine d’étude, nous avons d’abord identifié l’existant matériel, réseau et logiciel. Par la suite nous avons porté une analyse sur le domaine d’étude. Cela nous permettra maintenant, conformément à notre méthode de développement de passer à la spécification du futur système, ce qui fera l’objet du chapitre suivant.
  • 43. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 43 CHAPITRE 4 : SPECIFICATIONS DU FUTUR SYSTEME
  • 44. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 44 4.1 Introduction. Dans ce chapitre, il s’agira pour nous de présenter les spécifications du futur système. Après avoir identifié les acteurs et les différents cas d’utilisation du système, nous présenterons quelques diagrammes fondamentaux du langage de modélisation UML. Ces dits diagrammes sont le diagramme des cas d’utilisation et le diagramme de séquences. 4.2 Identification des acteurs et des cas d'utilisation 4.2.1 Identification des acteurs du système Un acteur représente un rôle joué par une personne ou une chose qui interagit avec le système. La même personne physique peut donc être représentée par plusieurs acteurs en fonction des rôles qu’elle joue. Les différents acteurs susceptibles d’interagirent avec le système sont : • La DGEP ; • La DREA ; • La commune ; • L’opérateur privé ; • L’administrateur système ; 4.2.2 Identification des cas d’utilisation L’identification des acteurs en interaction avec le système, simplifie grandement la collecte des besoins fonctionnels, car il suffit alors d'analyser acteur par acteur et de vérifier pour chacun qu'il dispose de toutes les fonctionnalités qui lui seront utiles au regard de sa mission et du périmètre du projet. Ainsi après analyse des fonctionnalités souhaitées et de l’environnement du projet, il en ressort les cas d’utilisation énumérés dans le tableau 9.
  • 45. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 45 Tableau 10 : Liste des cas d'utilisation N° Cas d’utilisation CU01 Gérer un utilisateur CU02 Gérer une AEPS CU03 Gérer un indicateur de performance CU04 Gérer un rapport semestriel CU05 Gérer une dépense CU06 Gérer une recette CU07 Gérer une provision CU08 Gérer une BF CU09 Gérer une BP CU10 Gérer une PMH CU11 Gérer un suivi mensuel d’ouvrage CU12 Gérer un incident CU13 Gérer un message CU14 Gérer un équipement à renouveler CU15 Gérer un commentaire CU16 Consulter les statistiques CU17 Exporter/Imprimer des informations CU18 Gérer les affectations des opérateurs privés CU19 Consulter un rapport semestriel CU20 Consulter les indicateurs de performances d’une AEPS CU21 Consulter les équipements à renouveler CU22 Gérer le personnel
  • 46. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 46 4.2.3 Description textuelle de quelques cas d’utilisation La description textuelle d’un cas d’utilisation permet de comprendre son fonctionnement général en précisant clairement son objectif. Les cas d’utilisation Gérer un incident, Gérer une AEPS, S’authentifier et Gérer un équipement à renouveler sont respectivement décrits dans les tableaux 10, 11, 12 et 13 : Tableau 11 : Description du CU Gérer un incident CU : « Gérer un incident » Objectif : ce cas d’utilisation permet d’enregistrer les incidents survenant dans l’exploitation d’une AEPS. Acteurs : opérateur privé Version : 1.0. Date de création : 22/09/2016. Pré conditions : l’utilisateur est connecté, l’utilisateur sélectionne une AEPS. Scénario nominal : 1. L’utilisateur demande à enregistrer ou mettre à jour un incident ; 2. Le système présente le formulaire d’enregistrement ou de mise à jour ; 3. L’utilisateur renseigne les informations puis valide ; 4. Le système vérifie les informations renseignées (A1) ; 5. Le système actualise la liste des incidents puis notifie à l’utilisateur du succès de sa requête ; Enchainements alternatifs : A1 : les informations renseignées sont incorrectes ou incomplètes : l’enchainement commence au point 4 du scénario nominal. 5. Le système notifie à l’utilisateur que les informations sont incorrectes. 6. L’utilisateur corrige ou complètes les informations. L’enchainement continue au point 4 du scénario nominal. Post conditions : un incident a été enregistré ou mis à jour.
  • 47. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 47 Tableau 12 : Description du CU Gérer une AEPS CU : « Gérer une AEPS » Objectif : ce cas d’utilisation permet d’enregistrer ou de mettre à jour une AEPS. Acteurs : la commune Version : 1.0. Date de création : 22/09/2016. Pré conditions : l’utilisateur est connecté, l’utilisateur sélectionne une AEPS. Scénario nominal : 1. L’utilisateur demande à enregistrer ou mettre à jour une AEPS ; 2. Le système présente le formulaire d’enregistrement ou de mise à jour ; 3. L’utilisateur renseigne les informations puis valide ; 4. Le système vérifie les informations renseignées (A1) ; 5. Le système notifie à l’utilisateur du succès de sa requête ; Enchainements alternatifs : A1 : les informations renseignées sont incorrectes ou incomplètes : l’enchainement commence au point 4 du scénario nominal. 7. Le système notifie à l’utilisateur que les informations sont incorrectes. 8. L’utilisateur corrige ou complètes les informations. L’enchainement continue au point 4 du scénario nominal. Post conditions : une AEPS a été enregistrée ou mise à jour.
  • 48. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 48 Tableau 13 : Description du CU S'authentifier CU : « S’authentifier » Objectif : ce cas d’utilisation permet de se connecter au système en fonction de ses droits. Acteurs : Opérateur privé, commune, DREA, DGEP Version : 1.0. Date de création : 22/09/2016. Pré conditions : l’utilisateur n’est pas encore connecté. Scénario nominal : 1. L’utilisateur demande à accéder au système ; 2. Le système demande l’identifiant et le mot de passe ; 3. L’utilisateur renseigne son identifiant et son mot de passe et valide ; 4. Le système vérifie les informations renseignées (A1, E1) ; 5. Le système présente l’interface d’accueil selon les droits de l’utilisateur ; Enchainements alternatifs : A1 : l’identifiant et/ou le mot de passe sont incorrects : l’enchainement commence au point 4 du scénario nominal. 6. Le système notifie à l’utilisateur que l’identifiant et/ou le mot de passe sont incorrects. L’enchainement continue au point 3 du scénario nominal. Enchainements d’exception : E1 : le compte est déjà bloqué 5. Le système notifie à l’utilisateur que le compte est bloqué. 6. Fin du cas d’utilisation. Post conditions : l’utilisateur est connecté en fonction de ses privilèges.
  • 49. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 49 Tableau 14 : Description du CU Gérer un équipement à renouveler CU : « Gérer un équipement à renouveler » Objectif : ce cas d’utilisation permet d’enregistrer les équipements renouvelables d’une AEPS. Acteurs : Opérateur Version : 1.0. Date de création : 22/09/2016. Pré conditions : l’utilisateur est connecté. Scénario nominal : 1. L’utilisateur demande à enregistrer un équipement 2. Le système présente le formulaire d’enregistrement de l’équipement ; 3. L’utilisateur renseigne les informations puis valide ; 4. Le système vérifie les informations renseignées (A1) ; 5. Le système actualise la liste des équipements à renouveler puis notifie à l’utilisateur du succès de sa requête ; Enchainements alternatifs : A1 : les informations renseignées sont incorrectes ou incomplètes : l’enchainement commence au point 4 du scénario nominal. 5. Le système notifie à l’utilisateur que les informations sont incorrectes. 6. L’utilisateur corrige ou complètes les informations. L’enchainement continue au point 4 du scénario nominal. Post conditions : un équipement renouvelable a été enregistré ou mis à jour.
  • 50. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 50 4.3 Diagramme des cas d'utilisation La figure 7 représente le diagramme de cas d’utilisation du futur système. Figure 6 : Diagramme de cas d'utilisation
  • 51. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 51 4.4 Diagrammes de séquences. Le diagramme de séquences permet de représenter les interactions entre objets en précisant la chronologie des échanges de messages, il représente aussi une instance d’un cas d’utilisation et fait ressortir les acteurs, les objets et les messages. 4.4.1 Authentification La figure 8 présente le diagramme de séquences de « S’authentifier ». Figure 7 : Diagramme de séquences du cas d’utilisation « s'authentifier »
  • 52. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 52 4.4.2 Gérer un incident La figure 9 présente le diagramme de séquences du cas d’utilisation « Gérer un incident ». Figure 8 : Diagramme de séquences du cas d'utilisation « Gérer un incident »
  • 53. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 53 4.4.3 Gérer un équipement à renouveler La figure 10 présente le diagramme de séquences du cas d’utilisation « Gérer un équipement à renouveler ». Figure 9 : Diagramme de séquences du cas d'utilisation « Gérer un équipement à renouveler »
  • 54. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 54 4.5 Conclusion Dans ce chapitre consacré à la spécification du futur système, nous avons d’abord identifié les acteurs et les différents cas d’utilisation du système. Par la suite nous avons présenté le diagramme de cas d’utilisation, la description textuelle de certains cas d’utilisation et le diagramme de séquences de certains cas d’utilisation. Cela nous permettra maintenant, conformément à notre méthode de développement de passer à l’architecture du futur système, ce qui fera l’objet du chapitre suivant.
  • 55. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 55 CHAPITRE 5 : ARCHITECTURE DU SYSTEME FUTUR 5.1 Introduction Ce chapitre traite de l’architecture du futur système. L’objectif de l’analyse architecturale est de définir l’architecture de l’application telle qu’elle sera implémentée et déployée. Dans un premier temps nous identifierons les différentes composantes logicielles à utiliser, puis nous décrirons l’architecture logicielle de l’application en présentant le diagramme de package et le diagramme de déploiement. 5.2 Identification des composantes logicielles 5.2.1 Plateforme de développement Une plateforme de développement est une base de travail à partir de laquelle on peut écrire, lire, utiliser, développer un ensemble de logiciels ou de programmes. Dans le cadre de ce projet, nous avons le choix entre une panoplie de plateformes à savoir : JAVA EE, ASP.NET, PHP. Suite à une étude comparative, notre choix s’est porté sur PHP dans sa version 7 parue en Décembre 2015. En effet PHP est gratuit et ne nécessite aucun coût. Elle dispose également d’une documentation détaillée et d’une grande communauté de développeurs actifs qui rendent disponibles de milliers de librairies. De par sa facilité, PHP accélère le temps de développement tout en optimisant le code en permettant sa réutilisation, en toute sécurité à travers ses Frameworks comme Symfony que nous utiliserons d’ailleurs dans ce projet. Le Framework Symfony possède une solide réputation car elle dispose d’un écosystème stable et est de plus en plus reconnu par les professionnels. Il présente plusieurs avantages parmi lesquels nous citons : • Une compatibilité totale avec PHP 7 ;
  • 56. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 56 • Une compatibilité avec la quasi-totalité des systèmes de gestion de base de données ; • Une implémentation du MVC qui est une bonne pratique de programmation recommandant le découpage du code en trois parties que sont le Modèle, la Vue et le Contrôleur ; • Une possibilité d’intégrer de l’AJAX mais aussi de gérer un système de Template. Bien plus qu’un Framework MVC, Symfony réunit les meilleurs outils de développement PHP afin d’aborder avec cohérence la réalisation d’applications web. 5.2.2 Système de Gestion de Bases de Données Un SGBD est une application conçue pour prendre en charge la structuration, le stockage, la mise à jour et la maintenance d'une base de données. Il est l'unique interface entre les informaticiens et les données, ainsi qu'entre les utilisateurs et les données. Pour mieux gérer la persistance des données, nous avons opté pour le SGBD Maria DB dans sa version 10.1.14 parue en Mai 2016, certainement la plus récentes des SGBD. Maria DB est une version améliorée de MySQL qui se donne pour but de fournir une version stable et toujours gratuite d’une branche MySQL, de s’assurer d’une complète compatibilité en phase avec les versions de MySQL (une branche est créée à chaque nouvelle version de MySQL). 5.2.3 Le Framework ORM Un ORM est une technique de programmation informatique qui crée l'illusion d'une base de données orientée objet à partir d'une base de données relationnelle en définissant des correspondances entre cette base de données et les objets du langage utilisé. Dans le cadre de ce projet nous avons utilisé Doctrine dans sa version 2 qui est l’ORM par défaut de Symfony. Doctrine propose son propre langage
  • 57. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 57 d’interrogation DQL orienté objet et permettant ainsi d’effectuer des requêtes assez complexes. 5.2.4 Environnement de développement Notre choix s’est porté sur l’IDE Netbeans en sa version 8.2 pour le développement de l’application. Netbeans est Open Source et intègre toute la puissance d’un IDE moderne (auto-complétion, coloration syntaxique, refactoring, plugins, …). Netbeans est multiplateforme et dispose de plugins pour le développement avec Symfony 3. Au côté de cet IDE, nous avons aussi utilisé Sublime Text qui est l’un des meilleurs éditeurs de texte du moment. Sublime Text est léger, rapide, fluide, facile à personnaliser et offre une possibilité d’automatiser les tâches répétitives à travers des snippets. 5.2.5 Librairies Dans le cadre du développement de l’application, nous avons utilisé entre-autres les librairies suivantes : • JQuery : bibliothèque JavaScript facilitant l’écriture de scripts côté client dans le code HTML des pages web ; • Bootstrap : ensemble d’outils permettant de styliser et rendre responsives les pages web ; • Leaflet : bibliothèque JavaScript de cartographie en ligne utilisée par le projet de cartographie libre et ouverte OpenStreetMap ; • Highcharts : bibliothèque JavaScript offrant un moyen simple d’ajouter des graphiques interactifs aux sites web ou applications web ; • FontAwesome : kit d’icônes et de polices basé sur CSS et LESS. 5.3 Architecture logicielle 5.3.1. Diagramme de packages Le diagramme de packages permet de structurer un système en plusieurs parties, chacune représentée par un package. Les packages constituent des regroupements
  • 58. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 58 fonctionnels de classes et d’associations dans le but de mettre en évidence une fonctionnalité particulière. Nous avons distingué dans le cadre de ce projet, les principaux packages Administration, Rapports et Ouvrages représentés ci-après Figure 10 : Diagramme de packages 5.3.2. Diagramme de déploiement En UML, un diagramme de déploiement est une vue statique qui sert à représenter l'utilisation de l'infrastructure physique par le système et la manière dont les composants du système sont répartis ainsi que leurs relations entre eux. Les éléments utilisés par un diagramme de déploiement sont principalement les nœuds, les composants, les associations et les artefacts. Il est couramment utilisé pour décrire l’architecture technique générale d’un système. La figure 12 représente le diagramme de déploiement obtenu dans le cadre de ce projet.
  • 59. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 59 Figure 11 : Diagramme de déploiement 5.4 Conclusion Dans ce chapitre, nous avons dans un premier temps identifié les composantes logicielles à utiliser pour la mise en place de l’application. Puis nous avons décrit l’architecture logicielle à travers le diagramme de packages et le diagramme de déploiement. Cela nous permet d’aborder avec aisance le chapitre sur la conception de la solution.
  • 60. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 60 CHAPITRE 6 : CONCEPTION DE LA SOLUTION
  • 61. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 61 6.1 Introduction Dans ce chapitre, nous présentons l’étude conceptuelle du futur système. Il est essentiellement constitué de la présentation de quelques diagrammes fondamentaux du langage de modélisation UML associés à l’application. Ces dits diagrammes sont le diagramme de classe d’application qui par la suite produit le schéma logique et physique de données de l’application. 6.2 Diagramme de classes d'application Il s’agit de raffiner dans un premier temps le diagramme de classes et d’associer les responsabilités aux différentes classes. Au vu de la complexité du système, il nous est impossible de représenter ce dit diagramme. Nous donnons alors une brève description de quelques classes dans les tableaux qui suivent.
  • 62. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 62 Tableau 15 : Description de la classe Gaeps Classe : Gaeps Attributs Code Type Description Id Numérique Clé primaire d’une AEPS Nom Alphanumérique Le nom de l’AEPS (unique) DateService Date La date de mise en service de l’AEPS SourceEnergie Alphanumérique Le type d’énergie qui alimente la pompe Observation Alphanumérique Informations générales sur l’AESP Etat Booléen Spécifie si l’AEPS est fonctionnel ou pas. ReseauDistribution Alphanumérique Description du réseau de distribution ReseauRefoulement Alphanumérique Description du réseau de refoulement Stockage Alphanumérique Description de la capacité de stockage Latitude Réel Position du château en latitude Longitude Réel Position du château en longitude Méthodes Nom Type de retour Description Gaeps() Nul Constructeur d’une nouvelle AEPS getX () Type de X Méthode permettant d’accéder en lecture à l’attribut X de cette classe setX () Nul Méthode permettant d’accéder en écriture à l’attribut X de cette classe
  • 63. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 63 Tableau 16 : Description de la classe GIncident Classe : GIncident Attributs Code Type Description IdIncident Numérique Clé primaire d’un incident DateIncident Date Date à laquelle l’incident s’est produit DateEnregistrement Date La date d’enregistrement de l’incident Element Alphanumérique Nom de l’équipement concerné par l’incident Description Alphanumérique Description de l’incident Cause Alphanumérique Cause de l’incident DateSolution Date La date à laquelle l’incident a été résolue Solution Alphanumérique Procédure de résolution de l’incident CoutSolution Numérique Le cout de la solution EtatFinal Alphanumérique L’état final de l’incident Méthodes Nom Type de retour Description GIncident() Nul Constructeur d’un nouvel incident getX() Type de X Méthode permettant d’accéder en lecture à l’attribut X de cette classe setX() Nul Méthode permettant d’accéder en écriture à l’attribut X de cette classe
  • 64. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 64 Tableau 17 : Description de la classe GIndicateur 6.3 Schémas logique et physique des données Le modèle physique de données résulte de la transformation du modèle relationnel obtenu à partir du diagramme de classes. Le modèle physique de données est directement exploitable par le SGBD. La figure 13 décrit le modèle physique de données obtenu pour ce projet. GIndicateur Attribut Type Description IdIndicateur Numérique Identifiant unique associé à l’indicateur Idx Alphanumérique Code associé à l’indicateur Nom Chaîne de caractères Correspond au nom de l’indicateur Description Chaîne de caractères Description textuelle de l’indicateur Méthodes Nom Type de retour Description GIndicateur() Nul Constructeur d’un nouvel indicateur getX () Type de X Méthode permettant d’accéder en lecture à l’attribut X de cette classe setX () Nul Méthode permettant d’accéder en écriture à l’attribut X de cette classe
  • 65. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 65 Figure 12 : Modèle physique de donnée
  • 66. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 66 6.4 Conclusion Dans ce chapitre, nous avons présenté le diagramme de classes d’application. Aussi nous avons décrit les cas d’utilisation à travers les diagrammes de séquences en faisant ressortir les interactions entre les acteurs et les composantes logicielles du système. Dans le chapitre suivant, nous allons nous intéresser à l’implémentation de notre système en se basant sur la conception détaillée de ce chapitre.
  • 67. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 67 CHAPITRE 7 : REALISATION ET BILAN
  • 68. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 68 7.1 Introduction Après les phases d’analyse et de conception, vient à présent celle de la réalisation. Dans ce chapitre, nous présentons d’abord les modules du logiciel développé à travers des captures d’écrans. Ensuite, nous expliquons les écarts entre les résultats attendus et ce qui est réalisé. Enfin, nous exposons la politique adoptée pour assurer le maximum de sécurité. 7.2 Modules développés Les modules développés sont les suivants : • Gestion des AEPS ; • Gestion des rapports ; • Gestion des indicateurs de performances ; • Gestion des statistiques ; • Gestion des utilisateurs ; • Gestion de la géolocalisation ; • Gestion du renouvèlement des équipements. 7.3 Enchaînement des écrans 7.3.1 Interface pour utilisateur non-connecté
  • 69. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 69 7.3.1.1 Interface d’accueil (1) La figure suivante présente la page d’accueil réservé à tout internaute non-connecté. Figure 13 : Interface d’accueil (1)
  • 70. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 70 7.3.1.2 Interface d’accueil (2) La figure suivante présente la possibilité pour l’internaute de filtrer la liste des AEPS par région, par commune et d’accéder aux détails d’une AEPS donnée. Figure 14 : Interface d’accueil (2)
  • 71. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 71 7.3.1.3 Information d’une AEPS La figure suivante présente les informations d’une AEPS donnée. Figure 15 : Interface détails d'une AEPS
  • 72. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 72 7.3.1.4 Visualisation des branchements d’une AEPS Figure 16 : Visualisation des branchements d'une AEPS
  • 73. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 73 7.3.2 Interface pour utilisateurs principaux du système. 7.3.2.1 Page d’authentification Tout utilisateur qui dispose d’un compte sur la plateforme et qui veut se connecter devra spécifier l’URL de la page d’authentification. Cette page se présente comme suit : Figure 17 : Formulaire de connexion
  • 74. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 74 7.3.2.2 Interface d’accueil Après s’être connecté, l’utilisateur a droit à une page d’accueil en fonction de son profil. Cette page d’accueil lui permet d’accéder aux différentes fonctionnalités à travers des liens. La figure ci-après nous décrit cela : Figure 18 : Interface accueil pour utilisateur authentifié
  • 75. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 75 7.3.2.3 Module « Gestion AEPS » Une fois connecté en tant qu’opérateur ou délégué communal, l’utilisateur peut accéder à ce module à travers un clic sur la barre de menu. La figure suivante présente l’interface d’accueil de ce module : Figure 19 : Accueil du module Gestion AEPS
  • 76. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 76 7.3.2.4 Module « Gestion AEPS » (Ajout d’une BF) A partir de la page d’accueil du module Gestion AEPS, l’utilisateur peut gérer les différents ouvrages liés à une AEPS sélectionnée au préalable. La figure suivante présente l’écran d’ajout d’une borne fontaine à une AEPS. Figure 20 : Interface d'ajout d'une BF
  • 77. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 77 7.3.2.5 Volet « Rapports » (Edition) A partir de la barre de navigation, l’utilisateur accède aussi à la partie édition du rapport où il pourra renseigner pour chacun de ses ouvrages, les informations nécessaires à l’établissement du rapport semestriel. Cela est ainsi illustré par la figure ci-après : Figure 21 : Volet édition d'un rapport
  • 78. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 78 7.3.2.6 Volet « Rapports » (Liste) Ce volet est accessible par un clic sur l’item « Consultation » du menu déroulant « Rapports » et présente la liste des différents rapports soumis ou en cours d’édition avec la possibilité de télécharger ou de visualiser les rapports soumis. La figure suivante présente cette liste : Figure 22 : Liste des rapports
  • 79. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 79 7.3.2.7 Volet « Visualisation d’un rapport » (1) A partir du bouton visualiser, l’utilisateur peut parcourir les informations du rapport en ligne. La figure ci-après présente l’évolution des ventes au niveau des BF dans le mois de janvier 2015. Figure 23 : Visualisation d'un rapport soumis
  • 80. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 80 7.3.2.8 Volet « Visualisation d’un rapport » (2) En plus de la visualisation en chiffres de la figure 24, on a la possibilité de visualiser les données en graphes, afin de pouvoir effectuer des comparaisons plus aisément. Figure 24 : Situation des BF sous formes de graphes
  • 81. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 81 7.3.2.9 Volet « Visualisation d’un rapport » (3) Il est possible d’en faire de même dans la partie finances du rapport. La figure suivante présente la comparaison des charges entre deux semestres. Figure 25 : Visualisation des charges d'exploitation
  • 82. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 82 7.4 Analyse des écarts 7.4.1 Le Planning réel Le planning réel du projet présente de façon effective les tâches qui se sont exécutées. En effet, un retard a été accusé comme le présente la figure 4 qui précise les dates de début et de fin des différentes tâches. Figure 26 : Diagramme de GANTT du planning réel 7.4.2 Explication des écarts Les modules Messagerie et Gestion des commentaires de l’application n’ont pas été implémentés. Nous donnons les raisons qui ont prévalues : • L’étude et la compréhension du domaine a pris plus de temps que prévu, car n’étant pas en contact direct avec les principaux acteurs, nous avons dû nous inspirer des documents provenant de l’IRC.
  • 83. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 83 • Il y a aussi la prise en main du Framework Symfony. En effet, même si cette plate-forme est construite sur le langage PHP, elle y ajoute un grand nombre d’outils remplissant tout un tas de fonctionnalités que nous avons pris le temps de comprendre. 7.4.3 Résultats obtenus Comme résultat, nous avons produit une application web qui fonctionne. Un utilisateur ayant le profil requis peut ajouter, modifier une AEPS, une BF, une BP et une PMH. Il peut également s’il s’agit d’un opérateur, créer un rapport semestriel, l’éditer et le soumettre au moment opportun. Une fois les rapports soumis, les utilisateurs pourront les consulter, exporter et générer des statistiques. 7.5 Politique de sécurité 7.5.1 Notion de sécurité Une politique de sécurité a pour but de minimiser les risques de disfonctionnements, d'éviter l'incohérence des données, les accès non autorisés à la base et la présence de programmes indésirables dans le réseau. II s'agit donc de prendre toutes les dispositions utiles afin de réduire au maximum les effets néfastes des pannes matérielles ou logicielles. 7.5.2 Gestion des mots de passe et de la connexion à l’application La politique de gestion des mots de passe est à la fois technique et organisationnelle. Elle vise à réduire les risques pour le système d'information liés à l'emploi de ce mécanisme. En effet, tous les paramètres de la gestion des mots de passe sont paramétrables par chaque organisation. Ici sont présentés les paramètres par défaut : • Les mots de passe utilisés pour se connecter au système seront chiffrés par l’algorithme Bcrypt ;
  • 84. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 84 • Lors de la connexion, si trois tentatives d'accès sont effectuées sans succès, le compte sera bloqué. Le déblocage interviendra sur demande auprès de l’administrateur ; • En ce qui concerne la connexion proprement dite, une seule connexion par utilisateur est possible ; c’est-à-dire que l’utilisateur ne peut ouvrir plus d’une session à la fois ; 7.5.3 Gestion des attaques Une attaque est une action par lequel une entité accède de façon subite et avec l’intention de nuire ou de prendre le contrôle d’un système. 7.5.3.1 Les virus Un virus informatique est un logiciel malveillant conçu pour se propager à d'autres ordinateurs en y causant des dégâts plus ou moins importants. Il peut se répandre à travers tout moyen d'échange de données numériques comme les réseaux informatiques les CDROMS, les clefs USB, etc. La mesure adoptée contre les virus est l’installation sur chaque poste client, d’un antivirus en vue de mieux protéger les données de la plateforme. 7.5.3.2 Les accès non autorisés Pour une meilleure sécurité du système d’information, il faudrait un contrôle très rigoureux de l’identité de toute personne voulant avoir accès au système ou aux différents serveurs pour y effectuer certaines tâches. L’application à mettre en œuvre étant une application web, nous proposons des contrôles d’accès à tous les niveaux : • Une protection au niveau du serveur Le paramétrage du système d’exploitation du serveur est très important. En effet une protection du serveur ne peut se faire que lorsque son système d’exploitation est sécurisé. Pour cela il faut des mesures de sécurité spécifiques, concernant la gestion des utilisateurs, des processus, des systèmes de fichiers, etc... • Une protection au niveau du réseau
  • 85. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 85 Cette protection est réalisée par la mise en place d’un dispositif de FIREWALL pour limiter les flux réseaux ouverts depuis l’extérieur. Un FIREWALL est un dispositif permettant d’assurer le filtrage par services des accès entrants et limite ainsi les risques auxquels est soumis le serveur web ; • Une protection au niveau de l’application Tout utilisateur voulant accéder à l’application devra impérativement s’authentifier à l’aide d’un identifiant et d’un mot de passe. Chaque utilisateur n’accédera qu’aux données dont il a droit et n’effectuera que les traitements qui lui sont autorisés. 7.5.4 Mise en place de la sauvegarde et de la restauration En informatique, une sauvegarde ou backup en anglais, est l'opération qui consiste à dupliquer et à mettre en sécurité les données contenues dans un système informatique. C’est donc un peu comme les extincteurs dans nos maisons : ils sont encombrants, coûtent cher et ne sont presque jamais utilisés. Cependant, lorsque survient l’accident irrémédiable, on se félicite d’y avoir pensé. Dans le choix de la stratégie de sauvegarde, seuls les trois types de techniques ont été pris en compte : • La première est la technique de sauvegarde complète. Comme son nom l'indique, cette méthode consiste à sauvegarder l'intégralité des données ; • La deuxième est la technique de sauvegarde incrémentale ou incrémentielle. Elle ne sauve que les données modifiées ou nouvelles depuis la dernière sauvegarde. La restauration passe obligatoirement par une restauration de la sauvegarde complète puis de toutes les sauvegardes incrémentales ; • Et enfin, la technique de sauvegarde différentielle. Elle sauve toutes les données nouvelles ou modifiées depuis la dernière sauvegarde complète. La restauration passe par une restauration de la sauvegarde complète puis de la dernière sauvegarde différentielle. En ce qui concerne leur mise en œuvre, trois stratégies ont été confrontées afin de choisir la plus adaptée au système.
  • 86. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 86 • Première stratégie : sauvegarde incrémentale du lundi au vendredi et sauvegarde complète le samedi ; • Deuxième stratégie : sauvegarde différentielle du lundi au vendredi et sauvegarde complète le samedi. • Troisième stratégie : sauvegarde complète du lundi au samedi. D’après la nature et l’importance des données traitées, ce fut la deuxième stratégie qui fut retenue. Pour doubler l’assurance, des tables de journalisation ont été placés au sein de la base de données pour enregistrer toutes les modifications sur les données. 7.5.5 Protection contre les catastrophes Il n’est pas exclu que les salles contenant les différents serveurs soient soumises à des catastrophes naturelles telles que la foudre, les incendies, les inondations… Il serait donc très important d’installer des extincteurs, des paratonnerres dans ces salles pour éviter une totale perte du matériel, du logiciel et des données enregistrées. 7.6 Conclusion Dans ce chapitre nous avons exposé les différents éléments concernant la réalisation de la plateforme. Nous y avons fait ressortir quelques interfaces liées à des fonctionnalités de l’application. Nous avons expliqué les écarts entre les résultats attendus et ce qui est réalisé. Nous y avons aussi étalé les aspects liés à la sécurité du système, notamment l’authentification, la gestion des accès, la politique de gestion des mots de passe, la politique de sauvegarde/restauration et les moyens de protection contre les catastrophes.
  • 87. LANKOANDE YIENOUYABA & OUEDRAOGO SOUFIANE 87 CONCLUSION GENERALE Le stage de fin de cycle, nous a permis de mieux comprendre les réalités professionnelles et d’acquérir de nouvelles expériences quant à l’utilisation de nouvelles technologies. De manière pratique, ce stage de quatre mois, que nous avons effectué à l’ANPTIC, a consisté à l’analyse, à la conception et à la mise en place d’une plateforme de suivi de l’exploitation des AEPS. En effet, le gouvernement du Burkina qui autrefois connaissait des difficultés dans le suivi des gros ouvrages tels que les AEPS, pourra par cette application améliorer considérablement le suivi, l’évaluation et la gestion des adductions d’eau potable simplifiées. A cela s’ajoute l’élaboration des statistiques de manière fiable afin d’aider à la prise de décision. Pour ce faire, nous avons utilisé le processus de développement 2TUP et le langage de modélisation UML. En ce qui concerne les technologies, nous avons utilisé entre autres la plateforme PHP 7, le Framework Symfony couplé à Bootstrap et Doctrine pour le mapping. Le système de gestion de base de données est Maria DB. En sommes, nous aimerions que le travail que nous avons entrepris à l’ANPTIC connaisse son achèvement pour permettre de voir nos efforts couronnés par la mise en place complète de l’application web.