Memoire Licence ATTIKPO

MINISTERE DE L’ENSEIGNEMENT REPUBLIQUE TOGOLAISE
SUPERIEUR ET DE LA RECHERCHE Travail-Liberté-Patrie
N° d’ordre : 2022/GL-031
MEMOIRE DE FIN DE FORMATION
pour l’obtention du diplôme de
LICENCE PROFESSIONNELLE
Domaine : Sciences et technologies

Mention : Informatique
Spécialité : Génie Logiciel
Thème :
CONCEPTION D’UNE PLATEFORME DE GESTION

DES KYA-SolarShop
Présenté et soutenu publiquement le 21/12/2022 par

ATTIKPO Ahoéfa Gaëlle-Fernanda
Devant le jury composé de :

Président du jury : M. APEKE Séna, Enseignant à l’EPL
Examinateur : M. ATADEGNON Anani, Enseignant à l’EPL
Directeur de mémoire : M. HOETOWOU Yaovi, Enseignant à l’EPL
Maître de stage : M. MESSAN K. Jean-Claude, Electrotechnicien à KYA-Energy Group
Conception d’une plateforme de gestion des KYA-SolarShop
DEDICACE
À mes parents, ma petite sœur et mes deux (02)

petits frères.
MEMOIRE LICENCE GL-EPL i ATTIKPO A. G.-FERNANDA

REMERCIEMENTS
La réalisation de ce mémoire a été possible grâce au concours de plusieurs personnes à qui je

voudrais témoigner toute ma gratitude.
• Je voudrais tout d’abord adresser toute ma reconnaissance au Directeur du Centre
Informatique et de Calcul (CIC), Dr ATCHONOUGLO Kossi, Maître de Conférences,
enseignant chercheur à l’Université de Lomé, pour sa foi en ce centre de formation et
pour tous les efforts qu’il y déploie ;
• Ma reconnaissance va également au Directeur-Adjoint chargé des études, Dr
BOROZE Tchamye Tcha-esso, Maître de Conférences, enseignant chercheur à
l’Université de Lomé, non seulement pour son dévouement pour la cause estudiantine
ou encore sa culture de l’excellence mais aussi pour sa démarche d’implication des
étudiants dans les prises de décisions.
• Je tiens à exprimer mes plus sincères remerciements et ma gratitude au Directeur de
ce mémoire, M. HOETOWOU Yaovi, Ingénieur informaticien, enseignant à
l’Université de Lomé, pour sa patience, sa disponibilité et surtout ses judicieux
conseils, qui ont contribué à alimenter ma réflexion.
• Je voudrais également exprimer ma reconnaissance envers le Professeur AZOUMAH
Yao K., Directeur Général de KYA-Energy Group, pour ses orientations et surtout sa
rigueur dans le suivi de ce travail.
• Je remercie sincèrement M. MESSAN K. Jean-Claude, Maître de stage de ce projet
pour sa disponibilité et son encadrement.
• Je dis un grand merci à M. ALLAH-ASSOGBA H. Y. Frédéric pour ses conseils, son
encadrement et son soutien.
• Je remercie infiniment toute l’équipe pédagogique du CIC pour la qualité de la
formation.
• Je tiens à témoigner toute ma reconnaissance à toute l’équipe de KYA-Energy Group,
pour l’accueil et la collaboration.
• Enfin, je tiens à exprimer ma reconnaissance à Jean-Claude, Wonda et Barthélémy et
aux collègues qui m’ont apporté leur soutien moral et intellectuel tout au long de ma
démarche.
MEMOIRE LICENCE GL-EPL ii ATTIKPO A. G.-FERNANDA

RÉSUMÉ
En poursuivant l’objectif de réaliser une électrification transcontinentale de manière

écologique et durable et dans le but d’accélérer et d’amplifier les résultats pour l’atteinte des
Objectifs (2, 3, 4, 6, 7, 13) [1] du Développement Durable, KYA-Energy Group a mis en place
des KYA-SolarShop qui sont des boutiques commerciales ayant pour objectifs de
démocratiser l’accès aux services énergétiques durables et innovants en milieu rural. Après
leur construction, les KYA-SolarShop sont confiés à des gestionnaires qui en assurent
l’exploitation et fournissent les services d’achat d’eau, de recharge de téléphone portable,
d’accès à la connexion Wifi et d’impressions et photocopies. C’est dans le but de gérer l’accès
aux services proposés par les KYA-SolarShop que le présent projet naît sous forme d’une
mesure supplémentaire pour contrôler les transactions. Une étude du besoin et la définition
des processus ont permis de scinder le projet en deux volets. Le premier volet est la mise en
place d’une plateforme web permettant de gérer les données transmises par les gestionnaires
et les informations sur les comptes. La plateforme web est destinée à l’entreprise et aux
clients. Le deuxième volet du projet est consacré à la réalisation d’une API pour l’interaction
avec les modules électroniques pour le contrôle et la gestion des services du KYA-SolarShop.
A l’issue de la phase d’analyse et de conception, une modélisation a été effectuée à l’aide du
langage de modélisation UML et ses standards. De ce fait, plusieurs diagrammes ont été
élaborés afin de mieux représenter les différents aspects du logiciel. La technologie Angular
a été choisie pour la réalisation de l’interface utilisateur. L’implémentation des
fonctionnalités du backend est faite avec AdonisJS. Le système électronique avec lequel la
plateforme communique est conçu avec des composants électroniques et des cartes
programmables ESP32. Le Système de Gestion de Bases de Données (SGBD) MySQL a été
utilisé pour le stockage des données. Ces différents choix et implémentations ont permis
d’avoir un produit conforme aux besoins exprimés.
MEMOIRE LICENCE GL-EPL iii ATTIKPO A. G.-FERNANDA

ABSTRACT
In pursuit of the goal of achieving transcontinental electrification in an environmentally

sustainable manner, and with the aim of accelerating and scaling up results towards
Sustainable Development Goals (2, 3, 4, 6, 7, 13) [1], KYA-Energy Group has established
KYA-SolarShop to democratise access to sustainable and innovative energy services in rural
areas. Once built, the KYA-SolarShop are handed over to managers who operate them and
provide services such as water purchases, mobile phone recharging, Wi-Fi access and printing
and photocopying. It is with the aim of managing access to the services offered by the KYA-
SolarShop that the present project is born as an additional measure to control the transactions.
A study of the need and the definition of the processes made it possible to divide the project
into two parts. The first part is the implementation of a web platform to manage the data
transmitted by the managers and the account information. The web platform is intended for
the company and its customers. The second part of the project is the implementation of an
API for interaction with the electronic modules for the control and management of the KYA-
SolarShop services. After the analysis and design phase, a modelling was carried out using
the UML modelling language and its standards. As a result, several diagrams were developed
to better represent the different aspects of the software. The Angular technology was chosen
for the realization of the user interface. The implementation of the backend functionalities is
done with AdonisJS. The electronic system with which the platform communicate is designed
with electronic components and ESP32 programmable boards. The MySQL Database
Management System (DBMS) was used for data storage. These different choices and
implementations have resulted in a product that meets the needs expressed.
MEMOIRE LICENCE GL-EPL iv ATTIKPO A. G.-FERNANDA

LISTE DES TABLEAUX

Pages
Tableau 1 : Liste des participants du projet .......................................................................... 10
Tableau 2 : Planning de réalisation ....................................................................................... 22
Tableau 3 : Tableau des cas d’utilisations regroupés par acteur ........................................... 31
Tableau 4 : Description textuelle du cas « Utiliser un service » ........................................... 37
Tableau 5 : Liste des pages ................................................................................................... 43
Tableau 6 : Caractéristiques de la machine de développement ............................................ 54
Tableau 7 : Évaluation financière de la base de données ...................................................... 59
Tableau 8 : Évaluation financière de l’application web ........................................................ 60
Tableau 9 : Évaluation financière de l'API ........................................................................... 60
Tableau 10 : Évaluation du coût total de la solution ............................................................. 61
Tableau 11 : Erreurs courantes.............................................................................................. 66
MEMOIRE LICENCE GL-EPL v ATTIKPO A. G.-FERNANDA

LISTE DES FIGURES
Pages
Figure 1 : Localisation géographique du CIC sur Google Map .............................................. 4
Figure 2 : Organigramme du CIC ........................................................................................... 7
Figure 3 : Photo du siège social de KYA-Energy Group à Lomé........................................... 8
Figure 4 : Organigramme administratif de KYA-Energy Group .......................................... 10
Figure 5 : KYA-SolWasherKit (kit de lavage des mains) .................................................... 11
Figure 6 : KYA-SoP (Groupe électrosolaire) ....................................................................... 11
Figure 7 : KYA-SolarShop ................................................................................................... 14
Figure 8 : Vérification du solde ............................................................................................ 21
Figure 9 : Processus d’achat.................................................................................................. 22
Figure 10 : Processus minimal [19] ...................................................................................... 27
Figure 11 : Logo draw.io....................................................................................................... 28
Figure 12 : Première phase du processus minimal ................................................................ 29
Figure 13 : Diagramme de contexte statique ........................................................................ 30
Figure 14 : Diagramme de paquetages des cas d’utilisations ............................................... 30
Figure 15 : Premiers diagrammes du processus minimal ..................................................... 32
Figure 16 : Diagramme des cas d’utilisation paquetage « Client » ...................................... 33
Figure 17 : Diagramme des cas d’utilisation paquetage « Gestionnaire » ............................ 34
Figure 18 : Diagramme des cas d’utilisation paquetage « RFID » ....................................... 35
Figure 19 : Diagramme des cas d’utilisation paquetage « Administrateur » ........................ 36
Figure 20 : Deuxièmes diagrammes du processus minimal .................................................. 38
Figure 21 : Modèle du domaine ............................................................................................ 39
Figure 22 : Troisièmes diagrammes du processus minimal .................................................. 40
Figure 23 : Maquette IHM Liste des clients ......................................................................... 41
Figure 24 : Maquette IHM Détails d’un client ...................................................................... 42
Figure 25 : Maquette IHM Enregistrer une carte .................................................................. 43
Figure 26 : Diagramme de la seconde phase du processus minimal ..................................... 45
Figure 27 : Diagramme de séquence système du cas d’utilisation « Utiliser un service (Achat
d’eau) » ................................................................................................................................. 46
Figure 28 : Diagramme de séquence système du cas d’utilisation « Création du compte
client »................................................................................................................................... 47
Figure 29 : Diagramme de classes de conception ................................................................. 48
Figure 30 : Logo Windows ................................................................................................... 50
MEMOIRE LICENCE GL-EPL vi ATTIKPO A. G.-FERNANDA
Figure 31 : Logo de Visual Studio Code............................................................................... 51

Figure 32 : Logo ANGULAR ............................................................................................... 52
Figure 33 : Logo AdonisJS ................................................................................................... 53
Figure 34 : Logo MYSQL ..................................................................................................... 53
Figure 35 : HP EliteBook 8570w .......................................................................................... 54
Figure 36 : Architecture 3-tiers ............................................................................................. 56
Figure 37 : Méthode Agile Scrum......................................................................................... 57
Figure 38 : Structure de l’application ................................................................................... 62
Figure 39 : Page de connexion .............................................................................................. 63
Figure 40 : Tableau de bord .................................................................................................. 63
Figure 41 : Liste des clients .................................................................................................. 64
Figure 42 : Ajout d'un client ................................................................................................. 64
Figure 43 : Liste des cartes ................................................................................................... 65
Figure 44 : Ajout d’une carte ................................................................................................ 65
Figure 45 : Liste des services ................................................................................................ 66
MEMOIRE LICENCE GL-EPL vii ATTIKPO A. G.-FERNANDA

SOMMAIRE
Pages
DEDICACE ............................................................................................................................. i
REMERCIEMENTS ...............................................................................................................ii
RÉSUMÉ .............................................................................................................................. iii
ABSTRACT ........................................................................................................................... iv
LISTE DES TABLEAUX ....................................................................................................... v
LISTE DES FIGURES........................................................................................................... vi
SOMMAIRE ....................................................................................................................... viii
LISTE DES PARTICIPANTS DU PROJET .......................................................................... x
GLOSSAIRE .......................................................................................................................... xi
INTRODUCTION .................................................................................................................. 1
CHAPITRE 1 : PRESENTATION DES CADRES DE FORMATION ET DE STAGE ....... 2
1.1 Présentation du cadre de formation : CIC-UL ............................................................... 3
1.2 Présentation du cadre de stage : KYA-Energy Group ................................................... 8
CHAPITRE 2 : ETUDE PREALABLE DU SUJET ............................................................ 13
2.1 Présentation ................................................................................................................. 14
2.2 Problématique du sujet ................................................................................................ 15
2.3 Intérêts du sujet ........................................................................................................... 15
2.4 Objectifs ...................................................................................................................... 15
2.5 Étude et critique de l’existant ...................................................................................... 16
2.6 Proposition et choix de solution .................................................................................. 17
2.7 Spécifications de la solution ........................................................................................ 18
2.8 Planning de réalisation ................................................................................................ 22
CHAPITRE 3 : ANALYSE ET CONCEPTION .................................................................. 24
3.1 Présentation de la méthode d’analyse.......................................................................... 25
3.2 Présentation du langage de modélisation .................................................................... 26
3.3 Présentation de l’outil de modélisation ....................................................................... 27
3.4 Analyse ........................................................................................................................ 28
3.5 Conception................................................................................................................... 48
CHAPITRE 4 : REALISATION ET MISE EN OEUVRE................................................... 49
4.1 Mise en œuvre ............................................................................................................. 50
4.2 Présentation de l’application ....................................................................................... 62
MEMOIRE LICENCE GL-EPL viii ATTIKPO A. G.-FERNANDA

4.3 Maintenance : actions à mener en cas de certaines erreurs ......................................... 66

CONCLUSION ..................................................................................................................... 68
BIBLIOGRAPHIE ................................................................................................................ 69
TABLE DES MATIERES .................................................................................................... 71
MEMOIRE LICENCE GL-EPL ix ATTIKPO A. G.-FERNANDA

LISTE DES PARTICIPANTS DU PROJET
Ci-dessous un tableau présentant l’équipe technique du projet.
Tableau 1 : Liste des participants du projet
Noms et prénoms Poste Rôle
Mme ATTIKPO Ahoéfa Étudiante en 3ème année Réalisatrice

Gaëlle-Fernanda Génie Logiciel à l’Ecole
Polytechnique de Lomé
M. HOETOWOU Yaovi Enseignant à l’Ecole Directeur de mémoire

Polytechnique de Lomé
M. MESSAN K. Jean-Claude Electrotechnicien à KYA- Maître de stage

Energy Group
MEMOIRE LICENCE GL-EPL x ATTIKPO A. G.-FERNANDA

GLOSSAIRE
API : c’est l'acronyme d'Application Programming Interface, que l'on traduit en français par
interface de programmation applicative ou interface de programmation
d'application. L'API est une solution informatique qui permet à des applications de
communiquer entre elles et de s'échanger mutuellement des services ou des données.
Module électronique : permet de transmettre les instructions de l'utilisateur et d'engager les

programmes correspondants
ESP32 : c’est une série de microcontrôleurs de type système sur une puce (SoC) d'Espressif
Systems, basé sur l'architecture Xtensa LX6 de Tensilica (en), intégrant la gestion du Wi-Fi
et du Bluetooth.
KYA-SolarShop : c’est une composition de KYA-Sop (système énergétique compact

amovible et multiservices) et d’un Shop qui est une boutique pour la vente des services.
Plateforme : est en informatique une base de travail qui permet d'utiliser un ensemble de
logiciels.
Framework : désigne en programmation informatique un ensemble d'outils et de composants

logiciels à la base d'un logiciel ou d'une application ; c’est lui qui établit les fondations d'un
logiciel ou son squelette.
SGBD (Système de Gestion de base de données) : c’est un logiciel système conçu pour créer
et gérer des bases de données. Le SGBD offre aux utilisateurs et aux programmeurs les outils
nécessaires pour mettre à jour leurs données, quelle que soit leur activité.
UML : Unified Modeling Language - en français Langage de Modélisation Unifié.
MEMOIRE LICENCE GL-EPL xi ATTIKPO A. G.-FERNANDA

INTRODUCTION
Les données sur l’épuisement des combustibles fossiles annoncées pour la prochaine décennie
[1], et la fluctuation permanente du prix du baril de pétrole imposent de nouvelles politiques
énergétiques basées sur les énergies renouvelables et l’efficacité énergétique conformément
aux objectifs de développement durable.
Avec l’un des plus grands gisements solaires [2] au monde, l’Afrique n’a pas de meilleure
alternative que la production d’énergie décentralisée par le biais de la technologie solaire.
C’est pourquoi la technologie solaire a connu un remarquable gain d’attention au cours de la
dernière décennie [2] sur le continent et continue de générer des intérêts et des espoirs pour
résoudre le déficit énergétique en Afrique. Ainsi, plusieurs projets donnant accès à l’énergie
ont vu le jour, permettant notamment de répondre aux besoins énergétiques dans les zones
rurales les plus éloignées [3]. Le faible taux d'accès à l’énergie électrique et le faible pouvoir
d’achat des populations situées en milieux ruraux obligent à penser à des systèmes
énergétiques durables et innovants. Pour répondre à cette problématique, l’entreprise a mis en
place des KYA-SolarShop afin de satisfaire leurs besoins. Le KYA-SolarShop est une
composition de KYA-Sop (système énergétique compact amovible et multiservices) et d’un
Shop qui est une boutique pour la vente des services. Ils sont destinés à offrir cinq (05)
principaux services à savoir : fourniture d’électricité, vente d’eau potable, recharge de
téléphone portable, impression et photocopie et l’accès à la connexion Wifi.
Après leur construction, les KYA-SolarShop sont confiés à des gestionnaires qui en assurent
l’exploitation et fournissent les services précités. Dans le but d’assurer une transparence dans
la gestion des différents services des KYA-SolarShop et de faciliter les tâches au gestionnaire
dans la fourniture desdits services, il est impératif de mettre en place un système automatique
de contrôle et de gestion des KYA-SolarShop.
Afin de faciliter le suivi et le contrôle des KYA-SolarShop ainsi que la collecte des
informations liées à la transaction et aux souscriptions sur les différents services par les clients,
KYA-Energy Group souhaite « concevoir une plateforme de gestion des KYA-SolarShop »
installés. La définition des caractéristiques d’une telle plateforme et sa réalisation nous ont été
confiées dans le cadre de notre stage de fin de formation.
MEMOIRE LICENCE GL-EPL 1 ATTIKPO A. G.-FERNANDA

CHAPITRE 1 : PRESENTATION DES CADRES DE FORMATION ET

DE STAGE

Ce chapitre a pour but de présenter le cadre de formation et la structure d’accueil. Le centre

de formation est le Centre Informatique et de Calcul (CIC) de l’Université de Lomé, et la
structure d’accueil dans le cadre du stage est KYA-Energy Group.
1.1 Présentation du cadre de formation : CIC-UL

Le CIC –UL qui a servi de cadre pour notre formation sera présenté dans cette partie.
1.1.1 Historique
Créé en 1988, le Centre Informatique et de Calcul se situe dans l’enceinte de l’Université de
Lomé (UL). Il est localisé entre le Centre de recherche sur le Changement Climatique qui est
parallèle à la Faculté des Sciences (FDS), la Faculté des Sciences et le Département de
Physique. La mission de ce centre est d’offrir des formations dans le domaine informatique,
d’apporter un appui logistique et technique en informatique aux établissements et services
centraux de l’Université de Lomé, d’assurer la diffusion de l’informatique parmi les acteurs
du monde universitaire.
En 1990, a été ouvert le Centre Interafricain de Formation à la Maintenance des Equipements
Micro-informatiques (CAFMICRO) qui avait pour objectif, la formation POST-DUT des
techniciens supérieurs en maintenance informatique. En 1995, une filière DUT en
Informatique destinée à former des techniciens supérieurs en informatique a été créée.
Ce n’est cependant qu’à partir de l’année 2009 avec l’avènement du Système Licence-Master-
Doctorat (LMD), que le CIC commence à former ses étudiants en vue de l’obtention d’une
Licence Professionnelle dans deux principales filières :
• Génie Logiciel,
• Maintenance et Réseaux Informatiques.
Le Directeur actuel du CIC est Monsieur ATCHONOUGLO Kossi (Maître de Conférence à
la Faculté des Science de l’Université de Lomé, le Directeur Adjoint chargé des études est
Monsieur BOROZE Tchamye Tcha-Esso (Maître de Conférence à la Faculté des sciences de
l’Université de Lomé) et le Directeur Adjoint chargé des réseaux est Monsieur TEPE Kossi
(Maître-assistant, Enseignant chercheur à l’Université de Lomé).
En 2022, le CIC fusionne avec l’ENSI pour former l’Ecole Polytechnique de Lomé.

1.1.2 Missions
Le CIC est une institution chargée principalement de la formation et du support en
informatique aux facultés, écoles, instituts et services de l’Université de Lomé. Les objectifs
principaux du CIC sont :
• de résoudre des problèmes technologiques particulièrement dans le domaine du
développement de logiciel et de la maintenance informatique dans les différentes
institutions de l’Université de Lomé ;
• d’assurer la formation académique de ses étudiants ;
• de fournir les ressources informatiques à toute la communauté universitaire ;
• et de former le personnel de l’Université de Lomé en organisant des cours et des
séminaires de formations.
1.1.3 Les activités
1.1.3.1 Diverses interventions (en maintenance, réseaus et

développement)
Le CIC fournit des services en maintenance informatique et en réseaux pour le compte de
l’UL, pour d’autres entreprises, pour des particuliers et pour ses étudiants. Le CIC a participé
à l’installation du réseau informatique de l’Université de Lomé et est chargé de la gestion du
réseau intranet et de l’accès Internet à l’Université de Lomé. Le CIC s’occupe également du
développement de solutions informatiques (applications desktop, sites web, etc.) pour le
compte de l’Université de Lomé et d’autres entreprises.
Figure 1 : Localisation géographique du CIC sur Google Map

1.1.3.2 Les formations

Le CIC est un cadre de formation professionnelle en informatique dont les étudiants sont
acceptés en 1ère année après un concours d’admission. Seuls les titulaires d’un baccalauréat
de séries scientifiques (C, D, E ou F) sont autorisés à concourir. Il s’agit de titulaires dont le
diplôme est vieux d’au plus un an. Cette offre de formation est composée de deux (02) filières
: Génie Logiciel et Maintenance et Réseaux Informatiques.
➢ Le Parcours de Licence Professionnelle
A la fin de six (06) semestres d’études, il est requis de la part des étudiants finissants
d’effectuer un stage dans un milieu professionnel conforme à leur filière, où ils auront à
réaliser un projet professionnel. Ceci est sanctionné par une séance publique de soutenance
dudit projet face à un jury composé de professionnels du métier.
➢ Le Parcours Master
Le Centre Informatique et de Calcul en partenariat avec l’Institut Africain d’Informatique
(IAI) et l’Université Technologique de Belfort-Montbéliard (UTBM) a ouvert pour ses
étudiants en Mars 2016, le parcours de Master Professionnel. Ce parcours offre deux
spécialisations différentes : Génie Logiciel, Systèmes et Réseaux.
En plus de principales formations en vue de l’obtention des diplômes professionnels, le
CIC offre :
• des cours d’initiation aux outils de l’informatique,
• des cours de recyclage,
• l’assistance aux chercheurs de l’Université de Lomé,
• des séminaires de formation.
Par ailleurs, le centre abrite l’Académie CISCO le « Cisco Networking Academy Program »
qui offre des formations dans le domaine des réseaux, de la sécurité informatique, et autres.
Des sessions de formation sont programmées périodiquement. Ce cours prépare à la
certification Cisco Certified Network Associate (CCNA).

1.1.4 Autres activités

Le CIC est le siège de l’Association Togolaise des Utilisateurs de Logiciels libres
(A.T.U.L.L). C’est une association chargée d’animer le LABTIC, qui est un laboratoire des
logiciels libres. Le CIC a abrité également le Centre Virtuel Africain (CVA) destiné au partage
de cours en ligne par les enseignants, et d’autres projets comme TogoRER.
Le CIC conduit également d’autres projets indépendants pour le compte de l’Université de
Lomé.
L’institution envisage par ailleurs de créer :
• un Laboratoire de Recherche en Informatique Appliquée (LRIA) dans le but de
développer la formation et la recherche dans le domaine informatique appliquée à
l’Université de Lomé d’une part, de promouvoir le travail des chercheurs du
laboratoire et valoriser leurs travaux auprès des instances universitaires africaines et
internationales d’autre part,
• le CIC s’est engagé avec l’Ecole Nationale des Ingénieurs (ENSI) dans un projet de
transformation en une structure polytechnique de grande renommée qui va bientôt
démarrer la rentrée universitaire 2022-2023.
1.1.5 Organisation structurelle

Le CIC est un établissement de l’Université de Lomé et en tant que tel, il dépend de la
présidence de ladite université. Mais le centre dispose de sa propre organisation structurelle
interne composée de :
• l’Assemblée d’établissement ;
• la Commission Scientifique et Pédagogique (CSP) ;
• la Commission Pédagogique ;
• la Direction ;
• le collège des chefs de division ;
• le service des examens ;
• la Cellule d’Information Pédagogique (CIP) ;
• la Commission des finances et du budget ;
• la Cellule Assurance Qualité.
Actuellement, le Centre Informatique et de Calcul dispose de 04 divisions :
• Division Etudes : en charge de la formation universitaire au grade Licence et Master ;

• Division Système d’Information : chargée de l’étude, de la conception, de la mise en

œuvre, de la gestion du système d’information global de l’Université de Lomé ;
• Division Développement : chargée des études informatiques nécessaires à
l’informatisation des différentes entités de l’Université de Lomé, de la conception et
du développement des applications informatiques et de la maintenance des logiciels
développés ;
• Division Maintenance Informatique : chargée de la maintenance des équipements
informatiques de l’Université de Lomé, de la mise en œuvre des programmes,
d’assemblage de micro-ordinateurs initiés par le CIC, de la réalisation des différentes
études nécessaires à l’informatisation de toutes les entités de l’Université de Lomé en
collaboration avec les autres divisions.
La Figure 2 présente l’organigramme du Centre Informatique et de Calcul :
Figure 2 : Organigramme du CIC

1.2 Présentation du cadre de stage : KYA-Energy Group

Il s’agit de présenter l’entreprise KYA-Energy Group qui nous a servi de cadre de stage.
1.2.1 Description de l’entreprise

KYA-Energy Group est une entreprise togolaise à vocation internationale. Elle est
spécialisée dans les énergies renouvelables (énergie solaire en particulier) et l’efficacité
énergétique (bâtiments et industries). Elle est une société à responsabilité limitée
unipersonnelle (SARL U), créée en juillet 2015 avec un capital social de dix millions
(10 000 000) F CFA et immatriculée au RCCM : TG-LOM 2015 B 975, NIF n°
1000430317.
Figure 3 : Photo du siège social de KYA-Energy Group à Lomé
1.2.2 Missions de l’entreprise

La société s’engage à contribuer au relèvement du défi de l’électrification en Afrique et de
façon durable avec ses quatre (4) entités :
• KYA-Energy Industry : Conception et assemblage des produits de l’entreprise ;
• KYA-Energy Institute : Renforcements de capacité du personnel de KYA et des
professionnels du solaire ;
• KYA-Energy Engineering & Services : Services de l’entreprise en ingénierie,
installation, suivi-contrôle, expertise, etc.

• KYA-Energy Laboratory : Unité de R&D de l’entreprise, dédiée à l’innovation

technologique et au développement de nouveaux produits, services, logiciels, …
La vision de KYA-Energy Group est de permettre à chaque citoyen africain de disposer d’au
moins une unité énergétique verte, autonome et à un prix abordable pour ses besoins
domestiques et / ou professionnels. Sa mission est de développer des systèmes et services
énergétiques innovants pour mieux répondre aux défis énergétiques actuels et futurs du
continent africain.
1.2.3 Organisation Structurelle de KYA-Energy Group

La direction générale coiffe toutes les directions de l’entreprise et définit les objectifs et les
actions à mener pour la bonne marche et la pérennité de l’entreprise :
• Le DG (Directeur Général) ;
• Le DGA (Directeur Général Adjoint) a sous sa direction les équipes (Audit interne,
HSEQ, Informatique et Approvisionnement, Stock et Logistique) constituant les
ressources de l’entreprise. Chaque équipe a à sa tête un chef ;
• Le CODIR.
Les directeurs d’activités :
• Le DFRI (Directeur de la Formation, de la Recherche et de l'Innovation) est la direction
qui prend en charge les formations et les R&D ;
• Le DTO (Directeur Technique et des Opérations) s’occupe de la production, des
opérations et de la maintenance et des suivis-contrôles-Audits ;
• Le DCM (Directeur Commercial et Marketing) gère le marketing (vente/SAV) et les
filiales de KYA ;
• Le DAAF est la direction qui s’occupe de la comptabilité, des finances, des ressources
humaines et des stages.

Figure 4 : Organigramme administratif de KYA-Energy Group
1.2.4. Quelques réalisations

Leurs produits :
KYA-Energy Group conçoit et assemble plusieurs produits dont les plus phares sont :
• Les KYA-SoP qui ont reçu le premier prix d’innovation de la BOAD en 2018. Ce sont
des unités solaires de transformation appelées groupes électrosolaires. Ils sont des
systèmes solaires compacts, autonomes, hybrides, mobiles, modulaires et
multiservices. Ils sont conçus et assemblés localement pour plusieurs applications
telles que : l’irrigation solaire ; l’électrification de centres de santé / écoles, des
PME/PMI, des ménages ruraux/urbains ; la transformation agroalimentaire…
• Le KYA-SolWasherKit [11] ou le kit de lavage des mains automatique solaire sans
contact.

Quelques images des produits :
Figure 5 : KYA-SolWasherKit (kit de lavage des mains)
Figure 6 : KYA-SoP (Groupe électrosolaire)

1.2.5 Localisation
L’entreprise KYA-Energy Group est située à 08BP 81101, dans le quartier Agoenyivé, Lomé-
Togo. Elle est joignable aux adresses suivantes :
Tél : 228-70 45 34 81 / 91 50 21 49
E-mail : info@kya-energy.com
Site web : https://www.kya-energy.com
Ce document est un mémoire de fin de formation au Centre Informatique et de Calcul. Le CIC

est l’école d’informatique de l’université de Lomé et le centre de ressources informatiques
pour la communauté universitaire. La rédaction de ce document a lieu pendant un stage
académique dans l’entreprise KYA-Energy Group qui est une entreprise spécialisée dans les
énergies renouvelables (énergie solaire en particulier) et l’efficacité énergétique.
La présentation des cadres du travail et de formation étant faite, la suite du document va parler
de l’étude préalable qu’a fait le projet.

CHAPITRE 2 : ETUDE PREALABLE DU SUJET

Ce chapitre aborde l’étude préalable de la pertinence du thème du projet. Nous allons exposer
de façon détaillée notre thème de stage, présenter sa problématique afin d’identifier les
approches et techniques qui aideront à mieux cerner et aborder l’exercice d’analyse et de
conception du projet. Tel est le but de cette partie.
2.1 Présentation
L’accès aux services énergétiques dans les milieux ruraux constitue un fléau majeur. Les
populations parcourent des kilomètres pour chercher de l’eau. Elles font face également aux
problèmes de recharge des téléphones portables et d’accès à la connexion internet. Cette
situation représente un réel problème d’autant plus qu’elle isole de plus en plus les populations
en milieux ruraux des réseaux de communication. On note également une mauvaise visibilité
dans les salles de classe par manque de lumière et des risques de vandalisme autour des écoles.
C’est dans le but de démocratiser l’accès aux services énergétiques durables que KYA-
SolarShop, un système énergétique durable et innovant a été proposé. Le KYA-SolarShop est
une composition de KYA-Sop (système énergétique compact amovible et multiservices) et
d’un Shop qui est une boutique pour la vente des services. Le KYA-SolarShop est conçu
principalement pour alimenter les écoles et les populations environnantes en milieux ruraux.
Il permet d’offrir cinq services aux populations bénéficiaires du projet. Les cinq services du
KYA-SolarShop sont les suivants : fourniture d’énergie, eau potable, recharge de téléphones
portables, photocopies/impressions, accès au WIFI. La définition des caractéristiques d’une
telle plateforme et sa réalisation nous ont été confiées dans le cadre de notre stage de fin de
formation.
Les KYA-SolarShop sont conçus et assemblés localement par l’entreprise KYA-Energy
Group. La figure 7 présente l’image du KYA-SolarShop.
Figure 7 : KYA-SolarShop

2.2 Problématique du sujet

Après leur construction, les KYA-SolarShop sont confiés à des gestionnaires qui en assurent
l’exploitation et fournissent les services. L’entreprise n’a que les informations fournies par les
gestionnaires pour évaluer l’ampleur des services offerts. Faisant face à toute cette situation
et ayant pour but de trouver des solutions permettant de gérer efficacement les ressources
offertes par le KYA-SolarShop ainsi que d'avoir un accès en temps voulu aux informations
fiables, nous avons été amenés à nous poser les questions que voici :
• Comment trouver le moyen de relever à distance, en temps réel ou à la demande, les
données fournies par les équipements, des offres sur le site ?
• Comment vérifier des données et informations sur les transactions effectuées ?
• Comment automatiser le processus de souscription des KYA-SolarShop ?
• Comment suivre le fonctionnement des modules installés ?
L’enjeu du projet est donc d’apporter des solutions aux différentes questions.
2.3 Intérêts du sujet

Afin de mieux comprendre l’intérêt du sujet, nous apporterons des éclaircissements sur les
objectifs (généraux et spécifiques) du projet et préciserons les résultats attendus à la fin.
2.4 Objectifs
Nous présenterons les objectifs généraux et spécifiques du projet.
2.4.1 Objectif général

L’objectif principal de notre plateforme est de doter l’entreprise et les gestionnaires d’un
outil de contrôle et de gérer l’accès aux services fournis par les KYA-SolarShop.
2.4.2 Objectifs spécifiques

Le projet, à la fin de son exécution, devra permettre :
à l’entreprise :
• de connaître les informations précises sur un KYA-SolarShop (contrôle des
informations) ;
• de collecter les données à distance sur les équipements installés ;
• de suivre les transactions depuis la plateforme ;

• de facturer les services avant consommation et de gérer automatiquement l’accès aux

services.
aux gestionnaires :
• de souscrire initialement un client : un gestionnaire crée le compte client et lui fournit
ensuite une carte RFID [7]. Les clients sont enregistrés dans une base de données (ou
le nombre de clients est connu par KYA-SolarShop) ;
• de recharger le compte client.
au client :
• d’avoir un accès permanent aux détails de son compte et de son contrôle ce qui réduit
le risque de fraudes.
2.4.3 Résultats attendus

Une plateforme est envisagée pour toute personne désirant souscrire aux services proposés par
le KYA-SolarShop.
Les résultats attendus sont entre autres :
• Le paiement des services par mobile money [8] ;
• Le conditionnement de l’utilisation des services par un abonnement ;
• Les données sont envoyées aux machines pour couper les services après l’épuisement
de l’abonnement ;
• Offre d’un reporting [9] du fonctionnement des KYA-SolarShop.
L'achat d’eau est le service développé et le prochain point fera l’objet de son étude
approfondie.
2.5 Étude et critique de l’existant

Afin d’atteindre les objectifs visés par le présent projet, nous avons mené des études qui nous
ont permis de faire un état des lieux de ce qui se fait actuellement en matière de vente d’eau
potable. En raison du caractère innovant du projet et de la zone cible, il n’existe pas une
solution toute faite. Les questions qui ont conduit à l’élaboration du projet sont l’absence du

service de vente d’eau potable et le parcours d’une longue distance avant d’accéder à
l’électricité en le milieu rural.
Les besoins en eau augmentent sans cesse à cause de la croissance démographique, du
développement de l‘industrie et l‘accroissement des activités humaines qui à leur tour
engendrent une pollution des ressources disponibles les rendant ainsi impropres à la
consommation.
Il existe plusieurs programmes visant à gérer l’accès à l’eau potable et d’assurer durablement
sa sécurité.
Ces programmes ont pour objectifs de :
• trouver une technologie appropriée pour les services d’approvisionnement en eau ;
• viser la réalisation des projets d’adduction d’eau potable en milieu rural ;
• donner lieu à la fourniture et à la pose de conduites d’eau ;
• réaliser des stations de traitement des eaux usées ;
• atteindre les Objectifs de Développement Durables (ODD), notamment l’ODD6 qui a
pour objectifs de garantir l’accès de tous à l’eau et à l’assainissement et d’assurer une
gestion durable à coût abordable.
Certaines plateformes en béton de gestion d’eau ont été construites pour permettre aux
villageois d’avoir accès à l’eau potable tout en garantissant la salubrité des points d’eau. Elles
permettent :
• D’éviter la stagnation de l’eau ;
• D’acheminer l’eau vers des bacs de sable qui facilitent ainsi l’infiltration de l’eau dans
la terre.
Les populations rurales dépendent souvent de sources d’approvisionnement locales (puits,
pompes manuelles, cours d’eau) qui sont dans bien des cas contaminées.
2.6 Proposition et choix de solution

Après avoir posé la problématique et fait une étude et critique de l’existant, nous ferons
à présent une étude de la solution qui existe pour pallier ces problèmes. Cette étude nous
permettra à la fin de pouvoir choisir la solution adéquate.

2.6.1 Proposition
Quelle solution pour une gestion des KYA-SolarShop fournissant à KYA-Energy Group, un
outil de contrôle ?
Plus précisément :
• Par quel moyen contrôler les données relatives aux services et aux clients ?
• Comment contrôler l’accès au service chez les gestionnaires ?
Faire un nouveau développement est l’approche à considérer. Cette approche va demander

plus d’effort mais elle a le mérite de donner la possibilité de tout analyser et de tout concevoir
de manière à respecter toutes les spécifications du cahier des charges. Cette solution donne la
possibilité de choisir librement la direction à donner au projet.
2.6.2 Choix
L’hypothèse première est de modéliser une solution en se basant sur les questions (ou besoins
exprimés) qui ont conduit à l’élaboration de ce projet. La communication avec le module
électronique et le KYA-SolWasherKit [11] constituent un bon cadre de test pour la solution.
2.7 Spécifications de la solution

Après examen des différentes possibilités, ce projet doit à la fin aboutir à une application web
qui sera le produit fini à présenter. L’application web permettra d’assurer la centralisation des
données qui constitue un élément central de l’expression du besoin. Une application web peut
être utilisée sur tout type d’appareils et fonctionnant sur n’importe quel système
d’exploitation.
En effet, tout ce dont on a besoin, c’est d’un navigateur web et celui-ci est souvent préinstallé
sur les ordinateurs.
Les fonctionnalités de l’application web sont entre autres :
• Elle permet à l’entreprise et donc à l’administrateur :
o d’administrer le système ;
o de pouvoir créer un compte sur la plateforme ;
o de créer un compte client et gestionnaire et d’avoir une vue d’ensemble sur
tous les clients actifs ;

o d’avoir une vue d’ensemble sur les toutes les transactions effectuées et les
souscriptions aux différents services.
• Elle permet au client :
o d’avoir une vue d’ensemble sur les données liées à leur consommation,
o de consulter et recharger son compte.
2.7.1 Les processus suivis

Afin de gérer l’accès à ce service à distance et de manière automatique, un processus propre
a été décrit :
● Création d’un compte client
Un client désireux de souscrire aux services fournis par KYA-SolarShop devra créer
un compte. Le client se présente au kiosque établi dans sa région et s’adresse au
gestionnaire pour effectuer le processus d’inscription :
○ Le gestionnaire ouvre un nouveau formulaire de création de compte sur la
plateforme ;
○ Le client fournit ses informations personnelles pour remplir le formulaire ;
○ Le client choisit les informations d’identification ;
Le gestionnaire vérifie les cartes enregistrées disponibles. Après validation du
compte depuis la plateforme ;
○ Le client reçoit une carte RFID.
● Recharge du compte
Avant de pouvoir accéder aux services, le client doit recharger son compte et s’assurer
qu’il dispose de fonds suffisants pour payer le service proposé. Pour ce faire :
○ Le client se rend au kiosque et consulte le gestionnaire ;
○ Il fournit ses informations d’identification et précise le montant qu’il souhaite
recharger sur son compte ;
○ Le gestionnaire effectue une transaction d’argent mobile en son nom.
Le compte est rechargé après validation par le gestionnaire.

2.7.2 Le module électronique et la plateforme web

La solution proposée englobe plusieurs livrables qui sont :
● Vérification du solde d’un compte client :
○ Le client se rend sur l’écran moniteur situé au kiosque SolarShop ;
○ Il scanne sa carte via le scanner RFID fourni à côté de l’écran ;
○ Il entre ses informations d’identification pour l’authentification sur la
plateforme ;
○ Ses informations de compte sont ensuite affichées sur le moniteur.
● L’achat d’eau potable :

○ Le client se rend au point d’eau ;
○ Le client scanne sa carte au scanner RFID placé au point d’eau.
L'eau coule si le client a suffisamment d’argent sur son compte pour se payer le
service.
○ Après avoir rempli sa bassine, le client scanne de nouveau sa carte pour arrêter
l’écoulement de l’eau.
Avant de permettre à tout client de profiter du service offert, la plateforme web doit
communiquer avec le module électronique. Le fonctionnement des deux (02) systèmes se
présente comme suit :
● Comment relier les deux systèmes ?
○ Lier le module à la base de données
Un protocole de communication a été défini pour interagir avec le module :
URL & Paramètre d'échange.
○ Relier les deux systèmes - Plateforme et module
Le module récupère les données de la base de données depuis la plateforme et
renvoie les données de la transaction à la base de données.
● Simulation :
○ Création d’un compte client ;
○ Affectation d’une carte au client ;
○ Configuration du solde ;
○ Exécution de la transaction ;
○ Calcul du solde après achat.

Pour bénéficier du service d’achat d’eau, tout client ayant un compte doit se rendre au point
d’eau et suivre le processus suivant :
● Le client badge ;
● Le système envoie le numéro de la carte dans la base de données ;
● La base renvoie au système électronique l’identifiant et le nombre de litre que le client
peut puiser avec son solde ;
● Le système décompte en fonction du nombre de litres puisés et envoie le total de litres
d’eau puisée ;
● Le calcul se fait en fonction du volume de litre d’eau puisée dans la base et le compte
client est crédité en fonction ;
● Le montant restant est stocké après que le compte du client ait été crédité.
Figure 8 : Vérification du solde

Figure 9 : Processus d’achat
2.8 Planning de réalisation

Les différentes tâches exécutées ainsi que leurs durées respectives ont été renseignées dans le
tableau qui suit.
Tableau 2 : Planning de réalisation

ID Tâches Début Fin Durée (Jours)
1. Compréhension du thème de stage 07/06/2022 11/06/2022 05
2. Etude de l’existant 12/06/2022 13/06/2022 02
3. Etude préalable 14/06/2022 16/06/2022 03
4. Choix des outils et technologies à 17/06/2022 18/06/2022 02

utiliser
4. Définition des processus de 19/06/2022 23/06/2022 05

souscriptions aux services
5. Elaboration des diagrammes de 24/06/2022 03/07/2022 10

cas d’utilisation, de séquences et
de classes
6. Prise en main des outils et 04/07/2022 08/07/2022 05

technologies choisis

ID Tâches Début Fin Durée (Jours)
7. Conception du backend de la 09/07/2022 18/07/2022 10

plateforme
8. Test des API avec POSTMAN 19/07/2022 20/07/2022 02
9. Conception du frontend de la 21/07/2022 02/08/2022 13

plateforme
10. Test 03/08/2022 04/08/2022 02
11. Connexion avec le frontend et le 05/08/2022 08/08/2022 04

backend
12. Test 09/08/2022 10/08/2022 02
13. Connexion de la plateforme avec 11/08/2022 20/08/2022 10

le module électronique
14. Test 21/08/2022 25/08/2022 05
15. Etape de mise en œuvre 26/08/2022 30/08/2022 05
Tests finaux 31/08/2022 04/09/2022 05
16. TOTAL 07/06/2022 04/09/2022 90
Ce chapitre vient de présenter l’état des connaissances scientifiques actuelles

permettant d’assurer une bonne gestion des KYA-SolarShop. Nous pouvons désormais
mieux positionner notre sujet par rapport aux différents types de solutions. Nous avons
aussi pu nous rendre compte qu’il n’existe pas, à l’état actuel des choses, de solution
pouvant satisfaire les besoins exprimés. Le résultat va donc être une application web.
Les détails sur les différentes méthodes choisies feront l’objet du prochain chapitre.

CHAPITRE 3 : ANALYSE ET CONCEPTION

Ce chapitre va plonger dans la phase principale de son objectif en décrivant les outils et
méthodes utilisés pour concevoir la plateforme de gestion des KYA-SolarShop.
Dans un processus de développement d’une application informatique, il faut suivre différentes
étapes pour assurer l’intégrité et l’évolutivité de l’application. Il est nécessaire, avant d’arriver
à la phase de codage d’une application informatique, de :
• s’assurer de bien comprendre les besoins de l’utilisateur ;
• définir les méthodes d’analyse et de conception : ayant pour objectif de

formaliser les étapes préliminaires du développement du système afin de rendre
ce développement plus fidèle aux besoins du client.
La phase d’analyse permet de lister les résultats attendus, en termes de fonctionnalité, de
sécurité, d’extensibilité, etc.
La phase de conception permet de décrire de manière non ambiguë, le plus souvent en utilisant
un langage de modélisation, le fonctionnement du futur système, afin d’en faciliter la
réalisation.
Le choix d’un langage de modélisation des systèmes logiciels permettra de spécifier, de
construire de façon logique et de déterminer l’organisation de notre système qui s’avère
judicieux pour le développement de notre application. Ce chapitre sera consacré à la
présentation des étapes de cette phase de modélisation
3.1 Présentation de la méthode d’analyse

L’analyse et la conception des solutions informatiques ont connu deux (02) approches
majeures au fil du temps :
• L’approche procédurale ;
• L’approche objet.
L’approche procédurale repose sur un paradigme de programmation considérant les
différents acteurs d’un système comme des objets pratiquement passifs qu’une procédure
centrale utilisera pour une fonction donnée. Cependant, l’évolution et la complexité croissante
des systèmes informatiques font fléchir cette approche devant certaines contraintes
spécifiques qui s’imposent. Pour remédier à ces insuffisances, l’approche objet vit le jour.
L’approche objet s’appuie sur la manipulation des objets à partir de l’ensemble formé par
les langages et les méthodes. Elle présente d'énormes avantages :
• Facilité d'organisation ;

• Réutilisation et méthode plus intuitives ;

• Possibilité d'héritage ;
• Facilité de correction ;
• Facilité de gestion des projets.
L'intérêt principal réside dans le fait que l'on ne décrit plus par le code des actions à réaliser
de façon linéaire mais par des ensembles cohérents appelés objets. L’approche objet offre
d’une part une vision externe définissant les actions qu’il sera possible de mener sur le logiciel
et d’autre part une vision interne dans laquelle seule la structure du logiciel est prise en
compte. L’approche objet sera utilisée pour l’étude détaillée de notre projet.
3.2 Présentation du langage de modélisation

Pour notre système, nous utiliserons Unified Modeling Language (UML). C’est un langage
visuel constitué d’un ensemble de schémas appelés les diagrammes, qui donnent chacun une
vision différente du projet à traiter [4]. UML nous permet d’apprécier un système sous
différents angles notamment les classiques points de vue fonctionnel, structurel et dynamique.
Afin de ne pas nous perdre dans ses différents angles de vues, nous avons choisi d’ajouter un
processus à UML pour combler le besoin d’une démarche progressive allant de l’expression
des besoins aux premiers bouts de code. Il s’agit d’un processus minimal présenté par la figure
suivante.

Figure 10 : Processus minimal [19]
Pour le cadre de ce projet, nous n’allons pas systématiquement produire tous les diagrammes
de cette figure. Nous suivrons la démarche en présentant les diagrammes que nous jugeons
pertinents pour notre système, d’abord en phase d’analyse puis en phase de conception.
3.3 Présentation de l’outil de modélisation

Il existe plusieurs outils de modélisation orientée objet qui supportent le langage UML mais
nous avons choisi l’application desktop Draw.io pour sa gratuité et du fait qu’elle est multi
plateforme. Draw.io est une application gratuite de création de diagrammes entièrement écrit
en JavaScript à base du composant logiciel open source JGraph. Il existe en version en ligne,
disponible depuis un navigateur web, et aussi en version hors ligne. Sa version en ligne permet
de travailler directement avec G Suite/Google Drive et Dropbox pour partager ses
diagrammes.
Avec la version hors ligne l’on peut créer et sauvegarder ses diagrammes en utilisant
l’application desktop disponible pour MacOs, Windows et Linux.

Figure 11 : Logo draw.io
Draw.io fournit une interface intuitive avec la fonctionnalité de drag and drop. Avec Draw.io,
l’utilisateur peut créer et éditer une variété de diagrammes comme :
• des organigrammes ;
• des diagrammes UML ;
• des diagrammes ERD ;
• des Business Process Models ;
• des maquettages d’interfaces.
Il constitue un outil puissant et flexible qui permettra de modéliser notre système
3.4 Analyse
Conformément à la démarche proposée, nous aborderons cette partie en deux itérations que
nous avons appelées phases. Dans la première phase, nous allons réaliser un certain nombre
de diagrammes que nous utiliserons ensuite pour produire ceux de la deuxième phase.
3.4.1 Première phase

Dans cette phase, nous allons aborder la première itération du processus minimal d’UML
décrit au point 3.2. Ainsi nous allons réaliser les diagrammes des cas d’utilisations, les
modèles du domaine et les Interfaces Hommes Machines (IHM) décrit par la figure 12.

Figure 12 : Première phase du processus minimal
Pour bien déterminer le fonctionnement du système et rendre simple celui-ci, nous réaliserons
préalablement le diagramme de contexte statique et le diagramme de paquetage des cas
d’utilisations.
3.4.1.1 Diagramme de contexte statique

Quatre (04) acteurs sont identifiés, il s’agit de :
• Client : l’acteur qui représente les clients,
• Gestionnaire : l'acteur qui s’occupe des shops, les gestionnaires,
• Administrateur : l’acteur qui représente les administrateurs du système,
• Lecteur RFID : l’acteur qui représente la carte RFID qui détient les données du client.
Le module électronique représente le module électronique qui enverra les données sur l’achat
à la plateforme.
Le diagramme de contexte statique ci-dessous donne un aperçu des acteurs autour du système.

Figure 13 : Diagramme de contexte statique
3.4.1.2 Diagramme de paquetage

Les acteurs interagissant avec le système identifié, le diagramme de paquetage peut être
établi pour avoir une vue d’ensemble du système et pour bien structurer l’expression des
besoins.
La figure 14 représente celui de notre système.
Figure 14 : Diagramme de paquetages des cas d’utilisations

Le tableau 3 décrit les différents acteurs du système et leurs actions.
Tableau 3 : Tableau des cas d’utilisations regroupés par acteur
Acteurs Cas d’utilisation Action

Client ● Utiliser un service Le client souscrit au service
● Gérer son compte proposé et dispose d’un
● Consulter son compte compte
Gestionnaire ● Gérer le compte client Le gestionnaire gère les
● Consulter le compte client shops et s’occupe des
● Gérer les services clients
● Gérer les machines
Lecteur RFID ● Identifier un compte client Une carte RFID est donnée
● Permettre de consulter le solde du à chaque client qui dispose
client d’un compte
● Permettre d’envoyer les détails de
consommation
● Donner accès aux consommations
● Permettre de vérifier le solde
Administrateur ● Gérer les gestionnaires L'administrateur
● Gérer les services administre la plateforme
Nous allons cependant réaliser le premier diagramme du processus minimal qui est le
diagramme des cas d’utilisations.
3.4.1.3 Diagrammes de cas d’utilisation

Nous entamons dans cette partie la réalisation du premier diagramme de la première itération
du processus minimal.

Figure 15 : Premiers diagrammes du processus minimal
Pour pouvoir présenter de manière fonctionnelle les différents besoins auxquels notre système
pourra répondre, quatre (04) diagrammes de cas d’utilisations seront présentés en fonction des
paquets : « Client », « Gestionnaire », « Lecteur RFID » et « Administrateur ».

• Paquetage Client
Ce cas d’utilisation décrit les actions d’un client quelconque sur la plateforme
Figure 16 : Diagramme des cas d’utilisation paquetage « Client »

• Paquetage Gestionnaire
Ce cas d’utilisation décrit les opérations du gestionnaire
Figure 17 : Diagramme des cas d’utilisation paquetage « Gestionnaire »

• Paquetage Lecteur RFID

Ce cas d’utilisation détaille les actions d’un lecteur sur la plateforme
Figure 18 : Diagramme des cas d’utilisation paquetage « RFID »

• Paquetage Administrateur
Ce cas d’utilisation décrit les opérations des administrateurs
Figure 19 : Diagramme des cas d’utilisation paquetage « Administrateur »
3.4.1.4 Description textuelle du cas d’utilisation « Utiliser un service »

Ci-dessous le tableau illustrant la description textuelle du cas d’utilisation « Utiliser un
service » :

Tableau 4 : Description textuelle du cas « Utiliser un service »
Sommaire
Titre : Achat d’eau

Résumé : Ce cas d’utilisation permet au client de s’offrir le service d’achat d’eau en
utilisant sa carte RFID.
Acteurs : Lecteur RFID, Système de vérification et l’électrovanne
Précondition
La communication entre le système et le lecteur RFID est fonctionnelle (ou opérationnelle).
Scénario nominal
1. Le client demande à faire une opération
2. Le système attend que le client scanne
3. Le client scanne
4. Le système vérifie qu’il s’agit bien d’une carte enregistrée qui porte un numéro valide et
trouve les informations correspondantes
5. Le système vérifie si le client dispose d’assez de fonds pour effectuer l’achat
6. Le système favorise l’ouverture de l’électrovanne
7. Le système vérifie et calcule toujours le montant et le nombre de litres d’eau puisée
8. Le client scanne de nouveau pour faire arrêter l’eau
9. Le système authentifie le client et envoie le montant correspondant au volume d’eau
puisée
10. Le système procède au calcul du solde, crédite et stocke le montant restant sur le compte
du client
11. Le système met à jour le compte du client
12. Le système bloque l’électrovanne
Scénarios exceptionnels
A1 : Le lecteur RFID utilisé par le client est invalide. Il démarre au point 4

5. Le système rejette la carte

A2 : Le montant est insuffisant. L'opération démarre aux points 5. 7.
6. Le système informe que le fond est insuffisant pour effectuer la transaction
8. Le système bloque l’électrovanne
Scénarios d’erreur
E1 : Le lecteur RFID utilisé par le client est invalide et le client scanne trois fois de suite la
carte. Il démarre au point 4
5. Le système rejette la carte et interrompt l’opération
3.4.1.5 Les modèles du domaine

La réalisation des diagrammes des cas d’utilisations terminée, nous allons à la réalisation du
second diagramme de notre première phase qui est le modèle des domaines.
Figure 20 : Deuxièmes diagrammes du processus minimal
L’élaboration du modèle des classes du domaine permet d’opérer une transition vers une
véritable modélisation objet.
L’analyse du domaine nous a permis de proposer une liste des classes candidates. Afin de
distinguer les classes et les entités qui constitueront le système, un premier diagramme de

classe doit se faire ; les relations évidentes et les classes identifiées sont présentées dans le
modèle de domaine.
Le modèle du domaine propose la liste des classes candidates suivantes :
● Managers,
● Compte_manager,
● KYA SolarShop,
● Admin,
● Equipements,
● Services,
● Souscriptions,
● Clients,
● Compte_client.
Figure 21 : Modèle du domaine

3.4.1.6 Les maquettes IHM

Dans cette partie nous entamons le dernier diagramme de la première phase qui est
l’élaboration des maquettes IHM.
Figure 22 : Troisièmes diagrammes du processus minimal
Après analyse des besoins, les interfaces homme-machine suivantes sont proposées. Précisons
qu’il ne s’agit pas d’un diagramme UML mais nous le jugeons important pour la définition
des diagrammes de séquence système.
Les figures 23, 24 et 25 présentent les prototypes des pages à implémenter. Il s’agit
respectivement d’une page de liste, de détails et d’enregistrement.

Cette interface montre la page de liste des clients enregistrés.
Figure 23 : Maquette IHM Liste des clients

Cette page ressort les détails d’un compte client.
Figure 24 : Maquette IHM Détails d’un client

La figure 25 montre la page d’enregistrement d’une carte.
Figure 25 : Maquette IHM Enregistrer une carte
Ci-dessous le tableau présentant la liste des pages à définir.

Tableau 5 : Liste des pages
Accueil Actions Composants
Tableau de bord ● Overview Les composants sont présentés

● Analytics dans les figures de la partie
présentation de l’application
Clients ● Ajouter Les attributs sont listés dans le

● Lister diagramme des classes
Cartes ● Ajouter Les attributs sont listés dans le


Accueil Actions Composants
Transactions ● Ajouter Les attributs sont listés dans le

Souscriptions ● Ajouter Les attributs sont listés dans le

KYA-SolarShop ● Ajouter Les attributs sont listés dans le

Equipements ● Ajouter Les attributs sont listés dans le

Familles d'équipements ● Ajouter Les attributs sont listés dans le

Types d’équipements ● Ajouter Les attributs sont listés dans le

3.4.2 Deuxième phase

Cette deuxième itération consiste à affiner, un peu plus, les livrables de la première phase.
Nous produirons les diagrammes de séquence système qui nous permettront de comprendre
un peu plus les fonctionnalités mentionnées par les cas d’utilisation. Nous ne réaliserons pas
le diagramme d’activité de navigation car il montre un même aspect du système avec le
diagramme de séquence système.

Diagramme de séquence système
Figure 26 : Diagramme de la seconde phase du processus minimal
Pour cette étape, nous considérons deux (02) cas d’utilisations parmi ceux jugés plus
représentatifs du système. Il s’agit des cas d’utilisation « Utiliser un service » et « Créer un
compte ».
Les figures 27 et 28 présentent les diagrammes de séquence système des cas d'utilisation
« Utiliser un service (Achat d'eau) » et « Créer un compte ».

Figure 27 : Diagramme de séquence système du cas d’utilisation « Utiliser un service (Achat d’eau) »

Figure 28 : Diagramme de séquence système du cas d’utilisation « Création du compte client »

3.5 Conception
L'étape de conception apporte plus de détails sur les diagrammes présentés.
Diagramme de classes de conception

L’objectif de cette étape est de produire le diagramme de classes de conception.
Avec toutes les étapes suivies, nous avons assez d’éléments pour concevoir le diagramme des
classes qui constitue l’étape finale vers le code. Cela suppose qu’on a ciblé l’environnement
dans lequel l’implémentation sera faite pour tenir compte des classes fournies par cet
environnement dans le diagramme.
Figure 29 : Diagramme de classes de conception
Les détails du besoin, les résultats de l’analyse et de la conception et une étude détaillée de la
solution étant terminés, l’objet du prochain chapitre concerne la réalisation et la mise en
œuvre.

CHAPITRE 4 : REALISATION ET MISE EN ŒUVRE

Dans ce chapitre, nous allons présenter les outils et moyens mis en œuvre et les résultats de
l’application de chacune de ces méthodes. Nous montrerons par la suite comment les modèles
élaborés ont été mis en œuvre dans l’environnement de développement choisi. Enfin le produit
fini constitué d’une application web sera présenté.
4.1 Mise en œuvre

Dans cette partie, nous présentons les outils utilisés et implémentations ayant servi à
transformer les modèles présentés dans le chapitre précédent en un produit utilisable. Il sera
ensuite présenté la description de l’architecture logicielle de l’application, de même le système
de sécurité de l’application aussi sera exposé.
4.1.1 Environnement de développement
● Le système Windows
Windows est au départ une interface graphique unifiée produite par Microsoft, qui est
devenue ensuite une gamme de systèmes d’exploitation à part entière, principalement destinés
aux ordinateurs compatibles PC.
Figure 30 : Logo Windows

• Editeur de code
Visual Studio Code (VSCode) est un éditeur dont le code source est open source sous
licence MIT permissive. C’est un logiciel de Microsoft. Il est totalement gratuit et peut
être installé sous n’importe quel système d’exploitation : Linux, Windows ou MacOs.
VSCode permet de coder avec tous les langages de programmation. Il peut faire du codage,
du débogage, de la compilation, du versionning, le Git intégré.
Il offre la possibilité d’ouvrir un terminal dans l’éditeur et les utilisateurs peuvent modifier
le thème, les raccourcis clavier, les préférences et installer des extensions qui ajoutent des
fonctionnalités supplémentaires.
Le plus grand avantage de VSCode est son marché des extensions. Il met à disposition du
développeur une multitude d’extensions codées soit par Microsoft ou par la communauté.
Cette grande communauté est, elle-même, un atout considérable pour cet éditeur de code.
Comme extension de VSCode on peut citer :
o Live Share : il permet de faire de la collaboration avec son équipe de
développeur ; vous pouvez partager un salon vocal, un tableau blanc et des
serveurs.
○ Rest : c’est l’extension qui permet de faire des requêtes https et de tester ses
API...
Figure 31 : Logo de Visual Studio Code

4.1.2. Langages de programmation

La plateforme web sera développée avec le Framework Angular [15] et la partie Backend avec
le Framework AdonisJS [16].
• ANGULAR
ANGULAR est un framework côté client, open source, basé sur le TypeScript maintenu
par par l’équipe du projet Angular à Google. C’est une réécriture complète d’AngularJS.
Il permet la création d’applications web accessibles via une page web qui permet de
fluidifier l’expérience utilisateur et d’éviter les chargements de pages à chaque nouvelle
action. Le Framework est basé sur une architecture du type MVC (Modèle-Vue-
Contrôleur) et permet donc de séparer les données, le visuel et les actions pour une
meilleure gestion des responsabilités.
Angular recommande l’utilisation du langage TypeScript qui se base sur le principe de
classe, à la base de la Programmation Orientée Objet, sur le typage statique et sur les
génériques.
Sa dernière version 14 est mise à jour le 2 Juin 2022. La mise à jour inclut :
○ l’amélioration du support des micro-frontends ;
○ la mise en place des composants autonomes sans ngModule.
La validation des formulaires est maintenant typable...
Figure 32 : Logo ANGULAR
• ADONISJS
AdonisJS est un framework backend pour Node.js, connu pour sa simplicité. Basé sur le
typeScript, AdonisJs est maintenu par Harminder Virk (le créateur et le responsable
principal du framework).

Figure 33 : Logo AdonisJS
• Le Système de Gestion de Base de Données (SGBD)

Un système de gestion de base de données est un logiciel servant à stocker, à manipuler
ou à gérer, et à partager des données dans une base de données, en garantissant la qualité,
la pérennité et la confidentialité des informations, tout en cachant la complexité des
opérations. Il existe plusieurs systèmes de gestion des bases de données. Notre choix est
porté sur le SGBD MySQL [14] du fait de sa simplicité et de sa compatibilité avec les autres
outils utilisés. MySQL est un système de gestion de bases de données relationnelles
(SGBDR). Il est distribué sous une double licence GPL et propriétaire.
Figure 34 : Logo MYSQL
MySQL fait partie des logiciels de gestion de base de données les plus utilisés au monde,
autant par le grand public (applications web principalement) que par des professionnels, en
concurrence avec Oracle, PostgreSQL, et Microsoft SQL Server.
Aussi, c’est la base de données que notre structure d’accueil adopte et nous a recommandé.

4.1.3 Le matériel de développement

Le projet a été réalisé avec un ordinateur portant les caractéristiques suivantes :
Il s’agit d’un EliteBook 8570w sur lequel tourne le système d’exploitation Windows 10.
Figure 35 : HP EliteBook 8570w
Tableau 6 : Caractéristiques de la machine de développement
Caractéristiques Valeurs
Marques et modèles HP EliteBook 8570w
Processeur et fréquence Intel(R) Core(TM) i7-3520M CPU @

2.90GHz, 2901 MHz, 2 cœur(s), 4
processeur(s) logique(s)
Mémoire RAM 16,0 Go
Disque dur 300 Go
Système d’exploitation Windows 10 - 64 bit

4.1.4 Architectures matériels et logiciels de l’application

Le système mis en place est basé sur une architecture trois (3) tiers. L'architecture trois tiers,
aussi appelée architecture à trois niveaux ou architecture à trois couches, est l'application du
modèle plus général qu'est le multi-tiers. Elle est basée sur l’environnement client-serveur.
L'architecture logique du système est divisée en trois niveaux ou couches à savoir :
• Couche de présentation ;
• Couche de traitement ;
• Couche d’accès aux données.
4.1.4.1 La couche de présentation

C'est la première couche qui compose l'infrastructure trois tiers : il s'agit de la partie rendue
logiciel. Son rôle est d’afficher les données et de permettre à l’utilisateur final d’interagir avec
ces dernières.
4.1.4.2 La couche métier

Elle est en charge d’appliquer et de respecter les règles métiers (ou actes de gestion). C’est
dans celle-ci que sont implémentées la logique applicative et la sécurité dans ce modèle
d’architecture.
4.1.4.3 La couche d’accès aux données

C'est la troisième couche qui compose l'infrastructure trois-tiers : elle correspond au serveur
de base de données. Il s'agit de la couche d'accès aux données. Sur ce troisième tiers, un SGBD
(Système de Gestion de Base de Données) est installé et ce serveur est requête par le serveur
applicatif afin d'utiliser un certain nombre de données. Le SGBD utilisé dans notre cas est
MySQL.

Figure 36 : Architecture 3-tiers
4.1.4.4 Approche méthodologique

Nous avons adopté une démarche fortement inspirée de Scrum qui se traduit par l’implication
et la participation active du client tout au long du projet. Le mot SCRUM fait référence à la
mêlée dans le jeu de rugby. En cas de fautes légères, les deux (02) équipes d’un jeu de rugby
se réunissent à l’endroit de la faute pour se disputer la balle. La méthode Scrum s'appuie sur
le découpage d'un projet en boîtes de temps nommées SPRINTS (« pointes de vitesse »). Les
SPRINTS peuvent durer entre quelques heures et un mois (avec un sprint médian à deux (02)
semaines). Chaque sprint commence par une estimation suivie d'une planification
opérationnelle. Le sprint se termine par une démonstration de ce qui a été achevé. Avant de
démarrer un nouveau sprint, l'équipe réalise une rétrospective. Cette technique analyse le
déroulement du sprint achevé, afin d'améliorer ses pratiques. Scrum insiste sur la nécessité de
livrer un produit opérationnel à la fin de chaque Sprint. Le flux de travail de l'équipe de
développement est facilité par son auto-organisation, il n'y aura donc pas de gestionnaire de
projet.

Figure 37 : Méthode Agile Scrum
Dans l’implémentation, les tâches sont découpées en sprints de quatre (04) jours qui vont finir
avec une réunion le 5ème jour et une planification de l’étape suivante. Ces réunions vont à la
fois servir de :
● démonstration de la tâche réalisée,
● séance de rétrospective,
● estimation de ce qui reste à faire dans les sprints qui vont suivre,
● et de planification opérationnelle.
L’équipe Scrum se compose de :

● un Scrum Master (Le coordonnateur),
● un Product Owner (propriétaire du produit),
● une équipe de développement.
Le Scrum Master est responsable de la compréhension, de l’adhésion et de la mise en œuvre

de l’approche méthodologique Scrum qu’il maîtrise parfaitement. Il veille à ce que les
principes et les valeurs de la méthodologie soient respectés. C’est un facilitateur qui aide à
améliorer la communication au sein de l’équipe et cherche à maximiser la productivité et le
savoir-faire de celle-ci. Il est considéré comme le coach de l’équipe de développement.
Le Product Owner porte la vision du produit à réaliser. Il travaille en interaction avec l’équipe
de développement qui doit suivre ses instructions. C’est lui qui établit la priorité des

fonctionnalités à développer ou à corriger, et qui valide les fonctionnalités terminées. Il est

responsable de la gestion du product backlog (ou carnet de produit en français).
L’équipe de développement est chargée de transformer les besoins définis par le Product
Owner en fonctionnalités utilisables. Elle est pluridisciplinaire et possède toutes les
compétences nécessaires pour réaliser le projet, sans faire appel à des prestations externes.
Parmi ses membres, on trouve un architecte, un développeur, un testeur, etc.
4.1.5 Sécurité du système

La plateforme gère les données sur les comptes des clients, les transactions sur le service
d’achat d’eau, et les recharges sur les comptes. Il est important que l’aspect sécurité soit
directement pris en charge par l’authentification, l’autorisation et la gestion des sessions et
que l’accès au compte administrateur soit protégé.
Un certain nombre de mécanismes ont été mis en place afin d’assurer la cohérence, l’intégrité
et la disponibilité des données ainsi que l’intégrité physique des fichiers sources de
l’application sur le serveur.
4.1.5.1 Authentification et droits d’accès

L’administrateur doit entrer son nom d’utilisateur et son mot de passe avant d’accéder au
tableau de bord. Le gestionnaire dispose aussi d’un compte administrateur mais avec des droits
limités car il ne peut pas configurer manuellement le solde sur une carte.
4.1.5.2 Journalisation
Un système de journalisation automatisé de tous les accès à l’application est instauré afin de
tracer les connexions et les opérations des utilisateurs.
4.1.5.3 Protection de la base de données

La base de données est automatiquement et systématiquement sauvegardée à l’aide d’un
système de sauvegarde en temps réel.
L’accès directe à la base de données est restreint à au plus deux personnes. Toutes les actions
sur les données et la base de données sont interfacées par l’application.

4.1.5.4 L’architecture 3 tiers

Elle offre l'amélioration de la sécurité des données, en supprimant le lien entre le client et les
données. Le serveur a pour tâche, en plus des traitements purement métiers, de vérifier
l'intégrité et la validité des données avant de les envoyer dans la couche d'accès aux données.
4.1.6 Evaluation financière

Il sera présenté dans cette section, l’évaluation financière des outils utilisés pour élaborer notre
plateforme web.
4.1.6.1 La base de données

L’établissement d’une base de données MySQL ne demande pas nécessairement l’achat d’une
licence mais nécessite un investissement en heures hommes pour l’élaboration de la base de
données. A raison de 8h par jour, nous réaliserons la base de données en une semaine (étude
de la structure et implémentation). Le résumé de l’évaluation financière est fait dans le tableau
suivant :
Tableau 7 : Évaluation financière de la base de données
MYSQL
Licence 0
Nombre d'heure homme 40
Valeur heure homme 10.000 FCFA
Coût total heure homme 60.000 FCFA
Total 60.000 FCFA

4.1.6.2 L’application web

L’établissement d’une application web avec un Framework nécessite un investissement en
heures hommes. A raison de 8h par jour, nous réaliserons chaque application en un mois à
raisons de 5 jours ouvrables par semaine et de 4 semaines par mois. Le résumé de l’évaluation
financière est fait dans le tableau suivant.
Tableau 8 : Évaluation financière de l’application web
Application web
Valeur heure homme 10.000
Total 480.000 FCFA
4.1.6.3 L’API de communication
Tableau 9 : Évaluation financière de l'API
API
Valeur heure homme 10.000
Total 900.000 FCFA

4.1.6.4 Evaluation du coût total de la solution

Le tableau suivant résume l’évaluation financière du projet
Tableau 10 : Évaluation du coût total de la solution
Désignation Coût (FCFA)
La base de données 60.000 FCFA
L'API de communication 900.000 FCFA
L'application web 480.000 FCFA
Connexion internet 90.000 FCFA
TOTAL 1.530.000 FCFA

4.2 Présentation de l’application
4.2.1 Structure de l’application

La figure 38 illustre la structure de l’application.
Figure 38 : Structure de l’application
4.2.2 Quelques masques de saisies de notre application

L’application web est accessible depuis un navigateur par la saisie de son adresse dans la barre
d’adresse de navigation. Si aucune connexion n’est établie, l’utilisateur est redirigé vers la
page de connexion présentée par la figure 39.

Figure 39 : Page de connexion
La connexion se fait en fournissant son nom d’utilisateur et son mot de passe. Ces deux
paramètres sont obligatoires.
Si les paramètres de connexion sont corrects, l’utilisateur est redirigé vers le tableau de bord.
Figure 40 : Tableau de bord

Les différentes fonctionnalités de l’application autorisées pour le profil de l’utilisateur

connecté sont alors disponibles via le menu gauche présent sur toutes les pages. Les figures
suivantes représentent les pages de certaines de ces fonctionnalités.
Les figures 41 et 42 représentent les pages de liste et d’ajout des clients.
Figure 41 : Liste des clients
Figure 42 : Ajout d'un client

Les figures 43 et 44 représentent les pages de gestion des cartes :
Figure 43 : Liste des cartes
Figure 44 : Ajout d’une carte

La figure 45 liste les services.
Figure 45 : Liste des services
4.3 Maintenance : actions à mener en cas de certaines erreurs
4.3.1 Maintenance des erreurs courantes

Les erreurs courantes et les actions à mener se présentent comme suit :
Tableau 11 : Erreurs courantes

Code d’erreur Description Action à mener
Could not connect to Impossible de se connecter à Redémarrer le serveur et

database la base de données s’assurer que la base de
données est bien en place
(Administrateur)
403 non autorisé Vous n’êtes pas autorisé à Cliquer sur retour pour
accéder à cette page retourner à la page d’accueil
Erreur 404, page non trouvée La page à laquelle vous Vérifier si l’URL est bien
tentez d’accéder n’existe pas saisie
ou n’est pas dans votre
champ d’action

4.3.2 Maintenance des autres erreurs

Pour les autres erreurs, l’utilisateur doit informer l’administrateur de l’application.

CONCLUSION
Ce document de mémoire est écrit dans le cadre de la réalisation d’un projet de fin de
formation. Il fait le bilan de douze (12) semaines de stage couvrant les dates du 07-06-2022
au 04-09-2022.
L’objectif fixé au début du projet est la mise en place d’un outil de contrôle pour gérer l’accès
aux services proposés par les KYA-SolarShop, et permettant à l’entreprise de vérifier les
données et informations transmises, aux gestionnaires de gérer les clients et aux clients de
consulter ou recharger leurs comptes. Ce travail a d’abord demandé un cahier de charges
détaillant les besoins justifiant la naissance du projet. Ensuite, l’approche méthodologique
fortement inspirée de SCRUM a permis de diviser le projet en modules livrables à la fin de
chaque phase. Enfin, les modèles obtenus ont été implémentés avec le framework Angular et
AdonisJS. Grâce à une bonne analyse simplifiée par les outils adéquats, le produit fini issu de
ces implémentations est constitué d’une part, d’une application web destinée à l’entreprise et
aux gestionnaires et d’autre part des modules électroniques pour le contrôle et la gestion des
services.
Une phase de test du produit a été réalisée dans les locaux de KYA-Energy Group qui
dispose de KYA-SolWasherKit, un kit de lavage des mains.
Participer à ce projet nous a permis de mettre en pratique les enseignements acquis aux CIC
et notre séjour à KYA-Energy Group a été une expérience très enrichissante tant sur le plan
professionnel que sur le plan humain car, le travail s’est déroulé au sein d’une équipe très
organisée, laborieuse mais aussi sociable.
Dans la suite du projet, nous envisageons définir un moyen plus sécurisé pour les
souscriptions. Aussi, pour le moment, l’achat d’eau est le seul service implémenté. Il sera
intéressant, comme perspectives, d’implémenter les autres services proposés et de donner la
possibilité aux clients de recharger et consulter à distance leurs comptes.

BIBLIOGRAPHIE
[1] Bodiguel, Jocelyn. « Objectifs de développement durable ». Développement durable,

https://www.un.org/sustainabledevelopment/fr/objectifs-de-developpement-durable/.
[2] « Une nouvelle politique du secteur de l’énergie pour l’Afrique ». L’Afrique des Idées,
21 juillet 2011, https://www.lafriquedesidees.org/une-nouvelle-politique-du-secteur-de-
lenergie-pour-lafrique/
[3] Universalis, Encyclopédie. « population rurale : Universalis Junior ». Encyclopædia
Universalis Junior, https://junior.universalis.fr/encyclopedie/population-rurale/
[4] «coursUML,» [En ligne]. Available: liris.cnrs.fr/csolnon/coursUML.pdf. [Accès le 11
03 2021].
[5] «Framework,» [En ligne]. Available: https://fr.wikipédia.org/wiki/Framework. [Accès
le 11 03 2021].
[6] «Interface de programmation,» [En ligne]. Available:
https://fr.wikipedia.org/wiki/Interface_de_programmation. [Accès le 11 03 2021].
[7] « Lecteur RFID : fonctionnement et types de lecteurs RFID ». Ooreka.fr,
//rfid.ooreka.fr/comprendre/lecteur-rfid.
[8] Mobile money : qu’est-ce que
c’est ? https://www.monisnap.com/fr/blog/article/mobile-money-definition/
[9] LacomptaEnlive.com. « LE REPORTING ET LES DIFFERENTS TYPES DE
REPORTING ». Martin Dieudonné NDENE, http://lacomptaenlive.com/2015/07/le-
reporting-et-les-differents-types-de-reporting.html.
[10] J. ANDREOLI, Proposition pour une synthese des paradigmes de la programmation
logique et de la programmation par objets, Paris, 1990.
[11] « KYA-SolWasherKit ». KYA-Energy GROUP, https://www.kya-energy.com/kya-
solwasherkit.
[12] J. Conallen, Concevoir des applications Web avec UML, Paris, 2000
[13] L. DEKHICI, Programmation Orientée Objet (POO), 2019.
[14] «Mysql,» [En ligne]. Available: https://fr.wikipedia.org/wiki/MySQL. [Accès le 11 03
2021].
[15] « Angular » [En ligne]. Available: https://fr.wikipedia.org/wiki/Angular. [16 janvier
2022].
[16] « ADONIS (Software) » [En ligne]. Available:
https://en.wikipedia.org/wiki/ADONIS_(software) [12 août 2022].
[17] Olivier. « Plateformes de gestion de l’eau ». Humanium, 8 mars 2010,
[18] ttps://www.humanium.org/fr/plateforme-gestion-eau/.
https://plus.google.com/+UNESCO. « La Mise En Valeur Des Eaux
Rurales ». UNESCO, 29 janvier 2015, https://fr.unesco.org/themes/securite-
approvisionnement-eau/hydrologie/eau-etablissements-humains/mise-valeur.

[19] UML 2 - Initiation, exemples et exercices corrigés (3ième édition) - Les cadres
d’interaction (UML 2) | Editions ENI. url : https://www.editions-eni.fr/open/mediabook.
aspx?idR=f7c421aed0818f88a014a3393cc9be0e.

TABLE DES MATIERES

Pages
DEDICACE .............................................................................................................................. i
REMERCIEMENTS ................................................................................................................ii
RÉSUMÉ ............................................................................................................................... iii
ABSTRACT ............................................................................................................................ iv
LISTE DES TABLEAUX........................................................................................................ v
LISTE DES FIGURES ........................................................................................................... vi
SOMMAIRE ........................................................................................................................ viii
LISTE DES PARTICIPANTS DU PROJET ........................................................................... x
GLOSSAIRE ........................................................................................................................... xi
INTRODUCTION ................................................................................................................... 1
CHAPITRE 1 : PRESENTATION DES CADRES DE FORMATION ET DE STAGE ........ 2
1.1 Présentation du cadre de formation : CIC-UL................................................................ 3
1.1.1 Historique ................................................................................................................ 3
1.1.2 Missions .................................................................................................................. 4
1.1.3 Les activités ............................................................................................................. 4
1.1.3.1 Diverses interventions (en maintenance, réseaus et développement) .............. 4
1.1.3.2 Les formations .................................................................................................. 5
1.1.4 Autres activités ........................................................................................................ 6
1.1.5 Organisation structurelle ......................................................................................... 6
1.2 Présentation du cadre de stage : KYA-Energy Group .................................................... 8
1.2.1 Description de l’entreprise ...................................................................................... 8
1.2.2 Missions de l’entreprise .......................................................................................... 8
1.2.3 Organisation Structurelle de KYA-Energy Group .................................................. 9
1.2.4. Quelques réalisations ........................................................................................... 10
1.2.5 Localisation ........................................................................................................... 12
CHAPITRE 2 : ETUDE PREALABLE DU SUJET ............................................................. 13
2.1 Présentation .................................................................................................................. 14
2.2 Problématique du sujet ................................................................................................. 15
2.3 Intérêts du sujet ............................................................................................................ 15
2.4 Objectifs ....................................................................................................................... 15
2.4.1 Objectif général ..................................................................................................... 15
2.4.2 Objectifs spécifiques ............................................................................................. 15
2.4.3 Résultats attendus .................................................................................................. 16

2.5 Étude et critique de l’existant ....................................................................................... 16

2.6 Proposition et choix de solution ................................................................................... 17
2.6.1 Proposition ............................................................................................................ 18
2.6.2 Choix ..................................................................................................................... 18
2.7 Spécifications de la solution ......................................................................................... 18
2.7.1 Les processus suivis .............................................................................................. 19
2.7.2 Le module électronique et la plateforme web ....................................................... 20
2.8 Planning de réalisation ................................................................................................. 22
CHAPITRE 3 : ANALYSE ET CONCEPTION ................................................................... 24
3.1 Présentation de la méthode d’analyse .......................................................................... 25
3.2 Présentation du langage de modélisation ..................................................................... 26
3.3 Présentation de l’outil de modélisation ........................................................................ 27
3.4 Analyse ......................................................................................................................... 28
3.4.1 Première phase ...................................................................................................... 28
3.4.1.1 Diagramme de contexte statique..................................................................... 29
3.4.1.2 Diagramme de paquetage ............................................................................... 30
3.4.1.3 Diagrammes de cas d’utilisation .................................................................... 31
3.4.1.4 Description textuelle du cas d’utilisation « Utiliser un service » ................... 36
3.4.1.5 Les modèles du domaine ................................................................................ 38
3.4.1.6 Les maquettes IHM ........................................................................................ 40
3.4.2 Deuxième phase .................................................................................................... 44
Diagramme de séquence système ............................................................................... 45
3.5 Conception.................................................................................................................... 48
Diagramme de classes de conception ............................................................................. 48
CHAPITRE 4 : REALISATION ET MISE EN ŒUVRE ..................................................... 49
4.1 Mise en œuvre .............................................................................................................. 50
4.1.1 Environnement de développement ........................................................................ 50
4.1.2. Langages de programmation ................................................................................ 52
4.1.3 Le matériel de développement .............................................................................. 54
4.1.4 Architectures matériels et logiciels de l’application ............................................. 55
4.1.4.1 La couche de présentation .............................................................................. 55
4.1.4.2 La couche métier ............................................................................................ 55
4.1.4.3 La couche d’accès aux données...................................................................... 55
4.1.4.4 Approche méthodologique ............................................................................. 56
4.1.5 Sécurité du système ............................................................................................... 58

4.1.5.1 Authentification et droits d’accès ................................................................... 58

4.1.5.2 Journalisation.................................................................................................. 58
4.1.5.3 Protection de la base de données .................................................................... 58
4.1.5.4 L’architecture 3 tiers ...................................................................................... 59
4.1.6 Evaluation financière ............................................................................................ 59
4.1.6.1 La base de données ......................................................................................... 59
4.1.6.2 L’application web ........................................................................................... 60
4.1.6.3 L’API de communication ............................................................................... 60
4.1.6.4 Evaluation du coût total de la solution ........................................................... 61
4.2 Présentation de l’application ........................................................................................ 62
4.2.1 Structure de l’application ...................................................................................... 62
4.2.2 Quelques masques de saisies de notre application ................................................ 62
4.3 Maintenance : actions à mener en cas de certaines erreurs .......................................... 66
4.3.1 Maintenance des erreurs courantes ....................................................................... 66
4.3.2 Maintenance des autres erreurs ............................................................................. 67
CONCLUSION ...................................................................................................................... 68
BIBLIOGRAPHIE ................................................................................................................. 69
TABLE DES MATIERES ..................................................................................................... 71

Memoire Licence ATTIKPO

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Memoire Licence ATTIKPO

Transféré par

Droits d'auteur :

Formats disponibles

MINISTERE DE L’ENSEIGNEMENT REPUBLIQUE TOGOLAISE

SUPERIEUR ET DE LA RECHERCHE Travail-Liberté-Patrie

Domaine : Sciences et technologies

CONCEPTION D’UNE PLATEFORME DE GESTION

Présenté et soutenu publiquement le 21/12/2022 par

Devant le jury composé de :

À mes parents, ma petite sœur et mes deux (02)

MEMOIRE LICENCE GL-EPL i ATTIKPO A. G.-FERNANDA

La réalisation de ce mémoire a été possible grâce au concours de plusieurs personnes à qui je

MEMOIRE LICENCE GL-EPL ii ATTIKPO A. G.-FERNANDA

En poursuivant l’objectif de réaliser une électrification transcontinentale de manière

MEMOIRE LICENCE GL-EPL iii ATTIKPO A. G.-FERNANDA

In pursuit of the goal of achieving transcontinental electrification in an environmentally

MEMOIRE LICENCE GL-EPL iv ATTIKPO A. G.-FERNANDA

LISTE DES TABLEAUX

MEMOIRE LICENCE GL-EPL v ATTIKPO A. G.-FERNANDA

LISTE DES FIGURES

Figure 31 : Logo de Visual Studio Code............................................................................... 51

MEMOIRE LICENCE GL-EPL vii ATTIKPO A. G.-FERNANDA

MEMOIRE LICENCE GL-EPL viii ATTIKPO A. G.-FERNANDA

4.3 Maintenance : actions à mener en cas de certaines erreurs ......................................... 66

MEMOIRE LICENCE GL-EPL ix ATTIKPO A. G.-FERNANDA

LISTE DES PARTICIPANTS DU PROJET

Ci-dessous un tableau présentant l’équipe technique du projet.

Tableau 1 : Liste des participants du projet

Noms et prénoms Poste Rôle

Mme ATTIKPO Ahoéfa Étudiante en 3ème année Réalisatrice

M. HOETOWOU Yaovi Enseignant à l’Ecole Directeur de mémoire

M. MESSAN K. Jean-Claude Electrotechnicien à KYA- Maître de stage

MEMOIRE LICENCE GL-EPL x ATTIKPO A. G.-FERNANDA

Module électronique : permet de transmettre les instructions de l'utilisateur et d'engager les

KYA-SolarShop : c’est une composition de KYA-Sop (système énergétique compact

Framework : désigne en programmation informatique un ensemble d'outils et de composants

UML : Unified Modeling Language - en français Langage de Modélisation Unifié.

MEMOIRE LICENCE GL-EPL xi ATTIKPO A. G.-FERNANDA

MEMOIRE LICENCE GL-EPL 1 ATTIKPO A. G.-FERNANDA

CHAPITRE 1 : PRESENTATION DES CADRES DE FORMATION ET

MEMOIRE LICENCE GL-EPL 2 ATTIKPO A. G.-FERNANDA

Ce chapitre a pour but de présenter le cadre de formation et la structure d’accueil. Le centre

1.1 Présentation du cadre de formation : CIC-UL

MEMOIRE LICENCE GL-EPL 3 ATTIKPO A. G.-FERNANDA

1.1.3 Les activités

1.1.3.1 Diverses interventions (en maintenance, réseaus et

Figure 1 : Localisation géographique du CIC sur Google Map

MEMOIRE LICENCE GL-EPL 4 ATTIKPO A. G.-FERNANDA

1.1.3.2 Les formations

MEMOIRE LICENCE GL-EPL 5 ATTIKPO A. G.-FERNANDA

1.1.4 Autres activités

1.1.5 Organisation structurelle

MEMOIRE LICENCE GL-EPL 6 ATTIKPO A. G.-FERNANDA

• Division Système d’Information : chargée de l’étude, de la conception, de la mise en

Figure 2 : Organigramme du CIC

MEMOIRE LICENCE GL-EPL 7 ATTIKPO A. G.-FERNANDA

1.2 Présentation du cadre de stage : KYA-Energy Group

1.2.1 Description de l’entreprise

Figure 3 : Photo du siège social de KYA-Energy Group à Lomé

1.2.2 Missions de l’entreprise

MEMOIRE LICENCE GL-EPL 8 ATTIKPO A. G.-FERNANDA

• KYA-Energy Laboratory : Unité de R&D de l’entreprise, dédiée à l’innovation

1.2.3 Organisation Structurelle de KYA-Energy Group

MEMOIRE LICENCE GL-EPL 9 ATTIKPO A. G.-FERNANDA

Figure 4 : Organigramme administratif de KYA-Energy Group

1.2.4. Quelques réalisations

MEMOIRE LICENCE GL-EPL 10 ATTIKPO A. G.-FERNANDA