UNIVERSITÉ D’ANTANANARIVO

SCIENCES ET TECHNOLOGIES
PHYSIQUE ET APPLICATIONS

MÉMOIRE

Pour l’obtention du diplôme de

MASTER EN PHYSIQUE ET APPLICATIONS

Parcours : MASTER D’INGENIERIE EN SYSTEMES ELECTRONIQUES

INFORMATIQUES

Intitulé :

Conception des applications web et native pour l’administration

du personnel et des matériels de HABAKA

Présenté par

RAMANJATO Kiadinirina Biaza

Devant la commission d’examen composée de :

Président : RANDRIAMANANTANY Zely Arivelo Professeur Titulaire

Examinateur : RAKOTOARIMANANA Liva Graffin Maître de Conférences

Rapporteurs : RAZANAMANAMPISOA Harimalala Maître de Conférences

16 Juillet 2021
 UNIVERSITÉ D’ANTANANARIVO
SCIENCES ET TECHNOLOGIES
PHYSIQUE ET APPLICATIONS

MÉMOIRE
Pour l’obtention du diplôme de
MASTER EN PHYSIQUE ET APPLICATIONS
Parcours : MASTER D’INGENIERIE EN SYSTEMES ELECTRONIQUES
INFORMATIQUES
Intitulé :

Conception des applications web et native pour l’administration

du personnel et des matériels de HABAKA

Présenté par

RAMANJATO Kiadinirina Biaza

Devant la commission d’examen composée de :
Président : RANDRIAMANANTANY Zely Arivelo Professeur Titulaire
Examinateur : RAKOTOARIMANANA Liva Graffin Maître de Conférences
Rapporteurs : RAZANAMANAMPISOA Harimalala Maître de Conférences
REMERCIEMENTS
Je tiens à remercier en premier lieu, Le Seigneur Tout Puissant.

Je tiens également à faire part de ma reconnaissance envers toutes les personnes qui ont
contribué directement ou indirectement à la réalisation de ce Stage de Fin d’Etudes à savoir :
 Monsieur Irrish Parker RAMAHAZOSOA, Maitre de Conférences, Responsable du
Domaine Sciences et Technologies de l’Université d’Antananarivo, pour m’avoir permis de
suivre ma formation au sein de son Institution et pour avoir donné son autorisation pour la
présentation de ce mémoire.
 Madame Eulalie Odilette RAFANJANIRINA, Maitre de Conférences, Responsable de la
Mention Physique et Applications, pour avoir validé mon inscription en tant qu’étudiant
pouvant préparer le grade de Master au niveau de ladite Mention.
 Madame Harimalala RAZANAMAMPISOA, Maître de Conférences, Responsable du
Parcours Master d’Ingénierie en Systèmes Electroniques et Informatiques (MISEI) pour avoir
fait tout son possible en prodiguant des conseils dans l’orientation et l’élaboration du présent
mémoire en dépit de la lourdeur des tâches lui incombent.
 Madame Zely Arivelo RANDRIAMANANTANY, Professeur Titulaire au sein du Domaine
des Sciences et Technologies, pour la considération qu’elle me fait en présidant le jury
d’examen de ce mémoire.
 Monsieur Liva Graffin RAKOTOARIMANANA, Maitre de Conférences au sein du Domaine
des Sciences et Technologies, pour avoir accepté d’examiner ce mémoire de fin d’étude.
 Monsieur Hirina RAZAKAMAMONJY, Technicien Supérieur chez HABAKA pour m’avoir
donné la chance et aidé d’effectuer ce stage de fin d’étude.
 Les membres des Personnels enseignants et administratifs de l’Université d’Antananarivo
 Les membres des Personnels Administratifs et Techniques de HABAKA, pour leurs aides,
conseils, accueils et efforts tout en m’offrant des encadrements théorique et technique de
qualité.

Je tiens aussi à remercier tous les membres de ma famille qui m’ont toujours soutenu pendant
ce stage, ainsi qu’à tous mes amis qui m’ont toujours aidé.
TABLES DES MATIERES
REMERCIEMENTS ........................................................................................................................ i
TABLES DES MATIERES .............................................................................................................ii
LISTE DES FIGURES ................................................................................................................... iv
LISTE DES TABLEAUX .............................................................................................................. vi
LISTE DES ACRONYMES/ABREVIATIONS............................................................................. vii
INTRODUCTION GENERALE...................................................................................................... 1
Chapitre I- GENERALITES............................................................................................................ 2
I.1- PRESENTATION DE CIDST ................................................................................ 3
I.1.1- Centre d’Information et de Documentation Scientifique et Technique ................. 3
I.1.2- Organigramme .................................................................................................... 3
I.1.3- Domaines de compétences .................................................................................. 4
I.1.4- Prestation de service ........................................................................................... 5
I.2- PRESENTATION DE HABAKA ........................................................................... 6
I.2.1- Objectifs ............................................................................................................. 6
I.2.2- Produits .............................................................................................................. 6
I.2.3- Organigramme .................................................................................................... 7
I.3- MODELE CLIENT/SERVEUR .............................................................................. 8
I.3.1- Définition ........................................................................................................... 8
I.3.2- Les caractéristiques des systèmes client/serveur .................................................. 8
I.3.3- La répartition des tâches ..................................................................................... 8
I.3.4- Les middlewares ................................................................................................. 9
I.3.5- Notion de port et protocole.................................................................................. 9
I.4- ADRESSAGE IP .................................................................................................. 10
I.4.1- Définition ......................................................................................................... 10
I.4.2- Les différentes versions des adresses IP ............................................................ 10
I.4.3- Structure d’une adresse IP ................................................................................. 11
I.4.4- Le masque réseau .............................................................................................. 11
I.4.5- Classes d’adresses............................................................................................. 12
I.4.6- Adresses réseaux et adresses de diffusion.......................................................... 12
I.4.7- Adresses déconseillées et réseaux privés ........................................................... 12
I.5- CONCLUSION .................................................................................................... 13
Chapitre II-MATERIELS ET METHODES................................................................................... 14

ii
 II.1- CAHIER DES CHARGES .................................................................................... 15
II.2- CONCEPTION DE L’APPLICATION WEB ....................................................... 16
II.2.1- Choix des matériels ......................................................................................... 16
II.2.2- Design ............................................................................................................. 20
II.2.3- Priorisation des fonctionnalités ........................................................................ 21
II.2.4- Architecture du système................................................................................... 23
II.2.5- Développement du back-end ............................................................................ 26
II.2.6- Développement du front-end............................................................................ 31
II.3- CONCEPTION DE L’APPLICATION NATIVE.................................................. 34
II.3.1- Elaboration du logigramme de l’application native .......................................... 35
II.3.2- Fonctionnement du QR Code........................................................................... 37
II.3.3- Gestion de temps réel ...................................................................................... 38
II.4- CONCLUSION .................................................................................................... 39
Chapitre III- RESULTATS ET INTERPRETATIONS .............................................................. 40
III.1- PRESENTATION DE L’APPLICATION WEB ................................................... 41
III.1.1- Page de connexion.......................................................................................... 41
III.1.2- Liste de personnel........................................................................................... 41
III.1.3- Statistique de fréquentation ............................................................................ 42
III.1.4- Liste des présences ......................................................................................... 42
III.1.5- Liste des matériels .......................................................................................... 44
III.2- PRESENTATION DE L’APPLICATION NATIVE ............................................. 45
III.2.1- Activité principale .......................................................................................... 45
III.2.2- Scan ............................................................................................................... 45
III.2.3- Envoie et affichage du résultat........................................................................ 45
III.3- INTERPRETATIONS .......................................................................................... 46
Chapitre IV- DISCUSSION....................................................................................................... 47
IV.1- SUR LE PLAN MATERIEL................................................................................. 48
IV.2- SUR LE PLAN LOGICIEL .................................................................................. 48
IV.3- DOMAINES D’APPLICATION ........................................................................... 48
IV.4- AVANTAGES ...................................................................................................... 49
CONCLUSION ET PERSPECTIVES ........................................................................................... 50
REFERENCES .............................................................................................................................. 52

iii
LISTE DES FIGURES
Figure 1 : Organigramme du centre de recherche CIDST ................................................................. 3
Figure 2 : Organigramme de fablab au sein de l’organisme Habaka ................................................. 7
Figure 3 : Modèle Client/Serveur ..................................................................................................... 8
Figure 4 : Middlewares .................................................................................................................... 9
Figure 5 : Structure d'une adresse IP .............................................................................................. 11
Figure 6 : Adresse masque ............................................................................................................. 11
Figure 7 : Logo JavaScript ............................................................................................................. 16
Figure 8 : Fonctionnement de la communication Client/Server utilisant JavaScript ........................ 16
Figure 9 : Logo Node.JS ................................................................................................................ 17
Figure 10 : Fonctionnement de Node.js.......................................................................................... 17
Figure 11 : Logo MongoDB .......................................................................................................... 18
Figure 12 : Logo React.JS.............................................................................................................. 19
Figure 13 : Différence entre site web et application web ................................................................ 20
Figure 14 : Logo Android Studio ................................................................................................... 20
Figure 15 : Interface utilisateur de l’application web...................................................................... 20
Figure 16 : Fonctionnalités de l'application web............................................................................. 22
Figure 17 : Schéma synoptique du système .................................................................................... 24
Figure 18 : Logigramme pour sauvegarder une présence ................................................................ 27
Figure 19 : Logigramme pour la création de la liste journalière des matériels utilisés ..................... 28
Figure 20 : Logigramme pour la modification des données d'un matériel ....................................... 28
Figure 21 : Logigramme du middleware ........................................................................................ 29
Figure 22 : Fonctionnement front-end ............................................................................................ 31
Figure 23 : Logigramme de App.js ................................................................................................ 33
Figure 24 : Logigramme de l'application native ............................................................................. 36
Figure 25 : QR Code...................................................................................................................... 37
Figure 26 : Structure du QR Code .................................................................................................. 37
Figure 27 : Page de connexion ....................................................................................................... 41
Figure 28 : Liste du personnel........................................................................................................ 41
Figure 29 : Statistique de fréquentation.......................................................................................... 42
Figure 30 : Liste des présences ...................................................................................................... 43
Figure 31 : Choix des matériels ..................................................................................................... 43
Figure 32 : Liste des matériels ....................................................................................................... 44

iv
Figure 33 : Activité principale ....................................................................................................... 45
Figure 34 : Scan QR Code ............................................................................................................. 45
Figure 35 : Affichage du résultat de scan ....................................................................................... 46

v
LISTE DES TABLEAUX
Tableau 1 : Ports et protocoles ....................................................................................................... 10
Tableau 2 : Classes d'adresses ........................................................................................................ 12
Tableau 3 : Adresse réseau et adresse de diffusion ......................................................................... 12
Tableau 4 : Réseau privé................................................................................................................ 12
Tableau 5 : Comparaison SQL / MongoDB ................................................................................... 19
Tableau 6 : Routes et fonctions respectives .................................................................................... 26

vi
LISTE DES ACRONYMES/ABREVIATIONS
CIDST : Centre d’Information et de Documentation Scientifique et Technique
EPIC : Etablissement Public à caractère Industriel et Commercial
MESupReS : Ministère de l'Enseignement Supérieur et de la Recherche Scientifique
MEF : Ministère de l’Economie des Finances
CATI : Centre d’Appui à la Technologie de l’Innovation
CNARP : Centre National d’Application des Recherches Pharmaceutiques
CNRE : Centre National de Recherches sur l’Environnement
PBZT : Parc Botanique et Zoologique de Tsimbazaza
CIRAD : Centre de coopération Internationale en Recherche Agronomique pour le Développement
BDPA : Bureau du Développement de la Production Agriole
WWF : World Wide Fund
PNUD : Programme des Nations Unies pour le Développement
ONUDI : Organisation des Nations Unies pour le Développement Industriel
UNICEF : United Nations International Children’s Emergency Fund
FNUAP : Fonds des Nations Unies pour la Population
PAM : Programme Alimentaire Mondial
FAO : Food and Agriculture Organization
USAID : United States Agency for International Development
CENRADERU : Centre National de Recherche Appliquée au Développement Rural
ANGAP : association nationale de la gestion des aires protégées
QR Code : Quick Response Code
NoSQL : Not only SQL
API : Application Programming interface
TCP-IP : Transmission Control Protocol/Internet Protocol
FTP : File Transfer Protocol
DNS : Domain Name System
HTTP : Hypertext Transfer Protocol
HTML : Hypertext Markup Language
JSON : JavaScript Objet Notation
SGBD : Système de gestion de base de données
UI : User Interface
URL : Uniform Resource Locator
ID : IDentification
PHP : Hypertext Preprocessor
CSS : Cascading Style Sheets
Wi -Fi : Wireless Fidelity

vii
INTRODUCTION GENERALE
Les technologies de l’information et de la communication ont été l’évolution la plus importante
et innovante qui a marqué ces dernières décennies. Ces technologies ont apporté du confort dans notre
vie quotidienne par leurs capacités à traiter l’information dans des délais raisonnable. En effet, cela
est symbolisé par l’apparition des différents appareils de haute technologie tels que les smartphones
ou les tablettes qui sont dotés de plusieurs applications pratiques.

HABAKA est un Fab Lab destiné à l’innovation de la Communauté technologique à

Madagascar comme : coworking, évènement, formation et développement des startups
technologiques. Ainsi, nombreux sont les personnes qui fréquentent l’entreprise. Afin de satisfaire
ses besoins, l’entreprise dispose de plusieurs matériels informatiques et électroniques.

De ce fait, l’administration du personnel et des matériels est une tâche importante dans
l’entreprise. Le but est de s’occuper de toutes les données relatives au personnel et les matériels
surtout de les mettre à jour. Cependant, cette tâche entraîne des pertes de données et des pertes de
temps considérable car pour y parvenir, le responsable utilise des logiciels moins performant, voire
même prendre des notes sur des papiers.

Tenant compte de cette évolution technologique, et afin d’apporter des améliorations à

l’entreprise d’accueil, nous avons fait une étude sur les applications web et native, leurs techniques
et leurs outils de développement.

L’objectif de ce projet est de développer un système d’administration du personnel et des

matériels de HABAKA. Autrement dit, nous allons concevoir des applications web et native pour
accomplir les missions au niveau de l’administration. Ces applications servent à acquérir les données
pour ensuite les stocker dans une base de données par l’intermédiaire d’un serveur. Cela va faciliter
au responsable de réaliser des tâches telles que l’inscription, les statistiques de fréquentation,
l’inventaire, etc.

Les résultats de ces études comportent quatre chapitres :

 Le premier chapitre présente les lieux d’accueil de stage, le modèle client/serveur et l’adressage
IP d’une manière générale ;
 Le deuxième chapitre montre les matériels et les méthodes pour la conception des applications
web et native ;
 Le troisième chapitre affiche les résultats de ces études et les interprétations ;

1
 Enfin, le quatrième chapitre soulève la discussion concernant autant le plan matériel que logiciel
et les résultats obtenus.

2
Chapitre I- GENERALITES

2
 Ce chapitre va nous aider pour connaitre le contexte dans lequel le thème a été choisi.

I.1- PRESENTATION DE CIDST

I.1.1- Centre d’Information et de Documentation Scientifique et Technique

Le Centre d’Information et de Documentation Scientifique et Technique (CIDST) est l'un des
centres nationaux de recherche à Madagascar, ayant le statut d’Etablissement Public à caractère
Industriel et Commercial (EPIC). Ce centre contribue à la promotion et à la valorisation de la Science
dans tous les domaines d’Enseignement (Agriculture, Economie, Environnement, etc.) à Madagascar.
Il est sous la double tutelle du Ministère de l'Enseignement Supérieur et de la Recherche Scientifique
(MESupReS) et du Ministère de l’Economie des Finances (MEF) de Madagascar.

I.1.2- Organigramme
La structure organisationnelle du CIDST se compose de :
 Un Conseil d’Administration ;
 Un Conseil Scientifique d’Orientation ;
 Une Direction ;
 Des Services et Départements Techniques ;
 Quatre Antennes régionales (situées à Fianarantsoa, Toamasina, Mahajanga, Toliary) ;
 Une Cellule Technologie de l’Information et de Communication ;
 Et depuis Mai 2012, le CIDST héberge et gère le Centre d’Appui à la Technologie de
l’Innovation (CATI).

Conseil
d'Administration
(CA)

Conseil Scientifique
d'Orientation
(CSO)

Direction
Directeur

Département
Département Département Département Département Département Edition,
Administratif et Relations Département Traitement de Banque de Services aux
Acquisitions Impression et
Financier Publiques l'Information données utilisteurs
Diffusion

Antenne Antenne Antenne

Fianaratsoa Mahajanga Toamasina Antenne Toliary Cellule TIC

Figure 1 : Organigramme du centre de recherche CIDST

3
I.1.3- Domaines de compétences
Les domaines de compétence du CIDST sont très diversifiés :
 Fourniture de documents primaires ;
 Edition/impression ;
 Formation en sciences de l’information (bibliothéconomie, techniques documentaires, gestion
de l’information, recherche d’information, informatique documentaire) ;
 Informatisation et/ou réorganisation de systèmes documentaires ;
 Formation en informatique ;
 Formation en secrétariat-bureautique et en organisation administrative ;
 Participation aux foires, séminaires, etc.

La mission principale du CIDST est de satisfaire les besoins en information de n’importe quelle
cible : des décideurs, des chercheurs, des opérateurs économiques, des enseignants et des acteurs du
développement, en général.

Les outils d’information utilisent les bases de données bibliographiques MIREMBY du CIDST
qui est une base agrémentée en coopération. Elle essaie de faire la synthèse du patrimoine
documentaire dans le domaine de l’information et de la documentation scientifique et technique à
Madagascar.

Cette base de données fait état actuellement de 59 000 documents détenus par les organismes
suivants :
 CIDST (17%) ;
 Centres Nationaux de recherche FOFIFA/CENRADERU, CNARP, CNRE, CNRIT ;
 Académie Nationale des Arts, des Lettres et des Sciences ;
 Parc Botanique et Zoologique de Tsimbazaza (PBZT) ;
 Institut Pasteur de Madagascar (IPM) ;
 Organismes bilatéraux IRD, CIRAD, BDPA (France et Madagascar);
 Organisme non gouvernemental WWF ;
 Bibliothèque Nationale ;
 Ministère de l’élevage, de l’Agriculture et de la pêche (Direction des Ressources halieutiques
de la section agriculture) ;
 Programme Engrais Malagasy, EASTA et autres services ;
 Ministère de l’industrie, du commerce et de l’artisanat (Direction des commerces) ;
 ANGAP ;

4
  Laboratoire National de Recherches en Télécommunications ;
 Organismes internationaux PNUD, ONUDI, UNICEF, FNUAP, PAM, FAO ;
 Projet COEFOR (Foresterie-Environnement) ;
 Projets internationaux : SEATS (Planning Familial - USAID) ;
 Réseau IBISCUS du Ministère Français de la Coopération).

Il existe d’autres bases de données telles celle concernant l’Administration publique Malagasy,
celle des chercheurs des Centres Nationaux de Recherches à Madagascar, celles se rapportant aux
données commerciales : informations sur 230 produits agricoles.

Des disques compacts CD-ROM peuvent également être exploités en mode local pour accéder
à des bases de données agricoles (SESAME, CAB, TROPAG et RURAL, AGRICOLA et AGRIS) et
à des bases de données sur les brevets.

I.1.4- Prestation de service

CIDST réalise selon les demandes les prestations suivantes :
 Enquêtes sur les données locales ;
 Organisation d’unité documentaire (inventaire, informatisation du fonds documentaire,
traitements manuel et informatique des documents) ;
 Etude pour la mise en place d’unités de documentation ;
 Mise en place de bases et banques de données ;
 Recherches bibliographiques sur un thème bien déterminé.

5
I.2- PRESENTATION DE HABAKA

HABAKA Madagascar Innovation Hub est un organisme communautaire destiné à l'innovation

et la communauté technologiques à Madagascar au sein du Centre d’Information et de Documentation
Scientifique et Technique (CIDST) sis à Tsimbazaza.

Le nom « Habaka » signifie « espace » en malagasy. Habaka est un espace physique qui
regroupe les talents et les activités technologiques à Madagascar. Le projet met en place un certain
nombre d'initiatives visant à construire un écosystème autour des entrepreneuriats et innovation
technologiques à Madagascar.

Ce nom a été donné par Juliette Ratsimandrava, Directrice des Langues à l'Académie Malgache
pour définir les activités en ligne et virtuelle en langue Malagasy.

Les activités de Habaka gravitent autour de la mise en place d'une organisation d’évènements
sur l'entrepreneuriat et sur les nouvelles technologies, ainsi que l'incubation de startups.

I.2.1- Objectifs
L’ONG Habaka vise à regrouper la communauté technologique malagasy (blogueurs,
entrepreneurs dans les nouvelles technologies, développeurs, technophiles et passionnés, etc.) autour
des activités dont elle fait la promotion.

Habaka est né de la volonté de mettre en commun des compétences pour apporter un nouveau
souffle au secteur des nouvelles technologies à Madagascar mais aussi de celle de diffuser la culture
web et technologique.

I.2.2- Produits
Il existe différents produits conçus par Habaka dont les suivants :
 Le coworking : la gestion d’un espace physique de travail collaboratif de 300 m2, destiné aux
travailleurs indépendants du web et des nouvelles technologies à Antananarivo, sis à
Tsimbazaza (enceinte CIDST). Habaka ambitionne de créer le premier pôle dédié aux nouvelles
technologies à Madagascar appelé officiellement Hay Valley, mais pour l’instant qui reste un
projet ;
 L’évènementiel : l’organisation de rencontres technologiques et d’évènements axés sur les
nouvelles technologies, l'innovation et l'entrepreneuriat technologique (conférences, café TIC,
bar camps, concours/challenges, évènements sous licence internationale, etc.);
 La formation et l'incubation des startups : le développement des compétences dans les
nouvelles technologies et internet par l’organisation de formations thématiques régulières,

6
 formation dès le plus jeune âge cas de CoderDojo Madagascar dirigé par les staffs technique de
HABAKA, un mouvement mondial regroupant des clubs dans toute l'Ile permettant aux jeunes
malgaches d’apprendre à coder et à programmer gratuitement grâce à l'appui des bénévoles.

I.2.3- Organigramme
Notre stage s’est déroulé dans la fabrication laboratory (fablab). Un fablab est un tiers-lieu
cadré par les comités exécutifs où il est mis à leur disposition toutes sortes d'outils, notamment des
machines-outils pilotées par ordinateur pour la conception et la réalisation d'objets.

La figure 2 illustre l’organigramme donnant fablab au sein de l’organisme Habaka.

Conseils
d'Administration

Comités
Entreprenariat Fablab
Exécutifs

Figure 2 : Organigramme de fablab au sein de l’organisme Habaka

7
I.3- MODELE CLIENT/SERVEUR
I.3.1- Définition
Le modèle client-serveur s'articule autour d'un réseau auquel sont connectés deux types
d'ordinateurs le serveur et le client. Le client et le serveur se communiquent via des protocoles. Le
client-serveur représente un dialogue entre deux processus informatiques par l’intermédiaire d’un
échange de messages. Le processus client sous-traite au processus serveur des services à réaliser. Les
processus sont généralement exécutés sur des machines et des OS.
Client Réseau Serveur

Processus A
Requête
Processus B
Réponse
Processus A

Figure 3 : Modèle Client/Serveur

I.3.2- Les caractéristiques des systèmes client/serveur

Les éléments qui caractérisent une architecture client/serveur sont :
 Service : le serveur est un fournisseur de services. Le client est un consommateur de services ;
 Partage de ressources : un serveur traite plusieurs clients et contrôle leurs accès aux
ressources ;
 Protocole : c’est toujours le client qui déclenche la demande de service. Le serveur attend
passivement les requête des clients ;
 Localisation : le logiciel client/serveur masque aux clients la localisation du serveur ;
 Redimensionnement : il est possible d’ajouter et de retirer des stations clientes. Il est possible
de faire évoluer les serveurs ;
 Souplesse et adaptabilité : on peut modifier le module serveur sans toucher au module client.
La réciproque est vraie.

I.3.3- La répartition des tâches

Dans l’architecture client/serveur, une application est constituée de trois parties :
 L’interface utilisateur ;
 La logique des traitements ;
 La gestion des données.
Le client n'exécute que l'interface utilisateur (souvent un interfaces graphique) ainsi que la
logique des traitements (formuler la requête), laissant au serveur de bases de données la gestion
complète des manipulations de données.

8
 La liaison entre le client et le serveur correspond à tout un ensemble complexe de logiciels
appelé middleware qui se charge de toutes les communications entre les processus.

I.3.4- Les middlewares

On appelle middleware ou littéralement « élément du milieu », l’ensemble des couches réseau
et services logiciel qui permettent le dialogue entre les différents composants d’une application
répartie. Ce dialogue se base sur un protocole applicatif commun, défini par l’API du middleware.
Middleware est une interface de communication universelle entre processus. Il représente
véritablement la clef de voûte de toute application client/serveur. L’objectif principal du middleware
est d’unifier, pour les applications, l’accès et la manipulation de l’ensemble des services disponibles
sur le réseau, afin de rendre l’utilisation de ces derniers presque transparente.

Client Middleware Serveur

Figure 4 : Middlewares

I.3.4.1- Les services des middlewares

Un middleware susceptible de rendre les services suivants :
 Conversion : Services utilisé pour la communication entre machine mettant en œuvre des
formats de données différentes.
 Adressage : Permet d’identifier la machine serveur sur laquelle est localisé le service demandé
afin d’en déduire le chemin d’accès. Dans la mesure du possible.
 Sécurité : Permet de garantir la confidentialité et la sécurité des données à l’aide de mécanismes
d’authentification et de cryptage des informations.
 Communication : Permet la transmission des messages entre les deux systèmes sans altération.
Ce service doit gérer la connexion au serveur, la préparation de l’exécution des requêtes, la
récupération des résultats et la déconnexion de l’utilisation.

I.3.5- Notion de port et protocole

I.3.5.1- Port
Lors d'une communication en réseau, les différents ordinateurs s'échangent des informations
qui sont généralement destinées à plusieurs applications (le client mail et le navigateur internet par

9
exemple). Il faut donc savoir pour quelle application une telle information est destinée. On attribue
donc des ports pour chaque application.
Un port est codé sur 16 bits, il y a donc 65536 ports.

I.3.5.2- Protocole
Un protocole est une série d'étapes à suivre pour permettre une communication entre plusieurs
ordinateurs. Internet est un ensemble de protocoles regroupés sous le terme « TCP-IP »
(Transmission Control Protocol/Internet Protocol).

Voici les principaux ports et les protocoles respectifs :

Tableau 1 : Ports et protocoles

Ports Protocoles Rôles

21 FTP Utilisé pour transférer des fichiers

Utilisé pour communiquer avec un serveur distant en échangeant des

23 Telnet
lignes de texte

25 MTP Utilisé pour communiquer avec des appareils mobiles

53 DNS utilisé pour traduire les noms de domaine Internet en adresse IP

80 HTTP Utilisé pour consulter les pages web

110 POP3 utilisé pour recevoir des mails

I.4- ADRESSAGE IP
Puisque l’administration de réseau fait partie de notre étude, alors il est nécessaire d’avoir des
notons de base sur l’adressage IP.
I.4.1- Définition
De manière générale, les adresses forment une notion importante en communication et sont un
moyen d’identification. Dans un réseau informatique, une adresse IP est un identifiant unique attribué
à chaque interface avec le réseau IP et associé à une machine (routeur, ordinateur, etc.). C’est une
adresse unicast utilisable comme adresse source ou comme destination.
I.4.2- Les différentes versions des adresses IP
Il existe deux versions pour les adresses IP :
 Version 4 : les adresses sont codées sur 32 bits. Elle est généralement notée avec quatre
nombres compris entre 0 et 255, séparés par des points (.).

10
  Version 6 : les adresses sont codées sur 128 bits. Elle est généralement notée par groupes de 4
chiffres hexadécimaux séparés par deux points (:). Par exemple :
FE80:0000:0000:0000:020C:76FF:FE21:1C3B
Puisque l’adresse IPv4 est la version que nous allons utiliser, alors la suite de ce chapitre est
basée sur cette version.
I.4.3- Structure d’une adresse IP
L’adresse IP d’un équipement permet de définir précisément :
 le réseau sur lequel est connecté l’équipement ;
 l’adresse de l’équipement sur le réseau.
Pour chaque adresse, une partie des bits représente l’adresse réseau et l’autre partie identifie
l’hôte dans le réseau.

1100000 . 10101000 . 00001010 . 00000001

192 . 168 . 10 . 1
Réseau Hôte
Figure 5 : Structure d'une adresse IP
I.4.4- Le masque réseau
C'est une suite de 32 bits dont la partie des bits qui fixent l'adresse de réseau est une série
continue de 1 et la partie qui correspond aux hôtes est une série continue de 0. Le masque est aussi
exprimé en notation décimale pointée.

11111111 . 11111111 . 11111111 . 00000000

255 . 255 . 255 . 0
Réseau Hôte
Figure 6 : Adresse masque

11
I.4.5- Classes d’adresses
Il existe différents découpages possible que l'on appelle « classes d'adresses ». À chacune de
ces classes correspond un masque réseau différent :
Tableau 2 : Classes d'adresses
Plage du Partie réseau (N) et Masque par Nombre
Classe
1er octet hôte de l’adresse (H) défaut Réseau Hôte/réseau
A 1-127 N.H.H.H 255.0.0.0 128 16 277 214
B 128-191 N.N.H.H 255.255.0.0 16 384 65 534
C 192-223 N.N.N.H 255.255.255.0 2 097 150 254

Actuellement, la détermination du masque ne tient plus compte de la classe d'adresse.

N’importe quelle adresse IP peut ainsi être associée à n’importe quel masque, c’est ce que l’on appelle
l’adressage sans classe (classless).
I.4.6- Adresses réseaux et adresses de diffusion
Une adresse réseau est une adresse IP qui désigne un réseau et non pas une machine de ce
réseau. Elle est obtenue en plaçant tous les bits de la partie machine à zéro.
Une adresse de diffusion ou « broadcast » en anglais est une adresse permettant de désigner
toutes les machines d'un réseau, elle est obtenue en plaçant tous les bits de la partie machine à un. Le
tableau 3 montre un exemple :
Tableau 3 : Adresse réseau et adresse de diffusion
IP (classe) masque Adresse réseau Adresse de diffusion

10.10.10.10 (A) 255.0.0.0 10.0.0.0 10.255.255.255

192.168.150.35 (C) 255.255.255.0 192.168.150.0 192.168.150.255

I.4.7- Adresses déconseillées et réseaux privés

Pour éviter les ambiguïtés avec les adresses de réseau et les adresses de diffusion, les adresses
« tout à zéro » et « tout à un » sont déconseillées pour désigner des machines sur un réseau.
Dans chaque classe d'adresses, certaines adresses réseaux sont réservées aux réseaux privés
Tableau 4 : Réseau privé
Classe Réseau privé

A 10.0.0.0
A 127.0.0.0
B 172.16.0.0 à 172.31.0.0
C 192.168.0.0 à 192.168.255.0

12
 I.5- CONCLUSION
D’un part, pour conduire les lecteurs dans l’étude, la présentation de CIDST et de HABAKA
étaient nécessaire. Ce chapitre nous a aussi aidés pour connaitre le contexte dans lequel le thème a
été choisi.

D’autre part, nous avons présenté d’une manière générale le modèle client/serveur et
l’adressage IP. Ceux-ci nous ont servi à mieux connaître les domaines impliqués dans ce mémoire.
Elle se base sur les connaissances acquises en classe, des explications de professionnels de la
télégestion, mais aussi sur des recherches bibliographiques ou webographiques.

13
Chapitre II- MATERIELS ET METHODES

14
 Ce chapitre montrera l’étude de l’ensemble des méthodes et des matériels utilisés dans ce projet.
II.1- CAHIER DES CHARGES
On rappelle que l’objectif principal de ce projet est l’administration de personnel et des
matériels. Pour ce faire, différents tâches sont nécessaires, à savoir :
 Gestion du personnel : c’est l’ensemble des tâches administratives nécessaires à une bonne
gestion des ressources humaines, telles que :
 Inscription d’une nouvelle personne ;
 Elaboration d’une liste de personnel ;
 Statistiques de fréquentation individuelle ;
 Création de carte de membre ;
 Suivie du paiement du frais (uniquement pour les membres) ;
 Elaboration d’une liste des présences ;
 Rapport mensuel des présences ;
 Gestion des matériels : c’est l’ensemble des actions permettant d’assurer la maintenance des
équipements électroniques et informatiques ainsi que la gestion des stocks :
 Sauvegarde des données d’un matériel ;
 Elaboration d’une liste des matériels ;
 Mise à jour des données concernant les matériels ;
 Statistiques des matériels ;
 Gestion des communautés :
 Elaboration d’une liste des communautés ;
 Elaboration d’une liste des membres d’une communauté ;
 Elaboration d’une liste des conférences d’une communauté ;
 Suivie des conférences des communautés.
 Gestion des visites :
 Sauvegarde des visites d’entreprise ;
 Rapport des visites.
Afin d’accomplir ces tâches, nous avons décidé de créer un serveur avec Node.JS qui va
interagir avec une application web et une application native. Ces différentes tâches seront alors les
fonctionnalités que nous verrons sur l’application web après la conception. Par ailleurs, ces
applications permettront aussi de:
 Economiser de temps car à titre d’exemple : il n’est plus nécessaire de faire des calculs comme
sur Excel pour calculer les statistiques sur le personnel et les matériels ;
 Eviter les pertes de données car tous les données seront numérisées.

15
II.2- CONCEPTION DE L’APPLICATION WEB
II.2.1- Choix des matériels
II.2.1.1- JavaScript
JavaScript est un langage de script orienté objet utilisé pour le
développement d'applications internet. La programmation orientée objet a pour
but de permettre une plus grande flexibilité et maintenabilité du code. Le code
orienté objet est censé être plus simple à développer, plus facile à reprendre, à
analyser et permettre de répondre à des situations complexes en comparaison à Figure 7 : Logo
JavaScript
d'autres méthodes de programmation.
a- Concepts de programmation
Le propos de JavaScript est de manipuler de façon simple des objets, au sens informatique,
fournis par une application hôte. Autrement dit, l'intérêt de ce langage est de pouvoir contrôler
dynamiquement le comportement d'un page web : on peut par exemple vérifier que le code postal
saisi dans la page est correct, faire afficher des menus spéciaux quand la souris approche d'une zone
donnée, afficher des bandeaux publicitaires animés, orienter automatiquement le visiteur sur une autre
page, etc.

b- JavaScript coté client

La charge d'exécuter le code JavaScript incombe au client, c'est-à-dire à un navigateur la plupart
du temps. Le serveur envoie le code HTML et JavaScript au client qui l'interprète dès qu'il est chargé
(client-side). Ce type de fonctionnement s'oppose aux langages orientés serveurs, comme PHP ou
ASP. Dans ce cas, le serveur exécute le programme pour produire du HTML et l'envoie au client
(server-side).
La figure 8 montre un exemple de communication entre un client qui demande une page au
serveur.

Figure 8 : Fonctionnement de la communication Client/Server utilisant JavaScript

16
 c- Critère de choix
Le choix du langage de programmation est alors en fonction de la simplicité à développer
l’application web et de résoudre des situations complexes lors la programmation. La rapidité
d’exécution du code et l’atténuation de la sollicitation du serveur sont aussi des atouts considérables
qui ont déterminé notre choix étant donné que JavaScript est un langage de scripts client-side.

II.2.1.2- Node.JS
Node.js est un environnement permettant l’exécution de
JavaScript côté serveur. Il est utilisé pour développer des applications
faisant largement appel à la possibilité d’exécuter JavaScript à la fois
sur le client et sur le serveur, ce qui permet de profiter de la réutilisation
du code et de l’absence de changement de contexte. Figure 9 : Logo Node.JS

a- Fonctionnement
Node.JS exécute les codes de façon asynchrone. En effet, en Node.js presque toutes les
opérations sont non bloquantes. Les opérations s’exécutent de façon linéaire l’une après l’autre sans
devoir attendre le résultat de l’opération précédente. Une fois que le traitement asynchrone est terminé
ou qu'un événement particulier survient, la callback qui a été fournie en paramètre est insérée dans la
file d'attente des callbacks avant d'être prise en compte par la boucle des événements

Une boucle des événements sert à surveiller l'état de la pile d'exécution. Si cette dernière est
vide d'instruction à exécuter, la boucle des événements déplacera la callback en attente dans la file
vers la pile d'exécution, permettant à cette callback d'être ainsi exécutée. C’est un modèle de
programmation très intéressant en termes de performances

File d’attente

Pile d’exécution Callback

Boucle Callback
Evènement
des évènements
Callback
Evènement
Evènement
Callback

Figure 10 : Fonctionnement de Node.js

Les applications Node.js sont écrites en JavaScript pur et peuvent être exécutées dans
l'environnement Node.js sous Windows, Linux, etc.

17
 b- Rôle
Dans ce projet, Node.Js sert à développer le back-end. On peut dire qu’il est le cœur de notre
projet car c’est lui qui fait la liaison entre les différents matériels utilisés et presque tous les
traitements des informations. Grâce à ses performances hors norme, le choix du serveur n’est pas
difficile à prendre.
c- Exemple de code bloquant et non bloquant
// Code boquant
var content = fs.readFileSync(‘MonFichier.txt’) ; // lire et mettre le contenu de MonFichier.txt
dans la variable content
console.log(content) ; // afficher le contenu
//Code non bloquant
fs.readFile(‘MonFichier.txt’, (err, content) => {
if (err) {
throw err ; // afficher l’erreur s’il y en a pendant la lecture
}
console.log(content) ; // afficher le contenu
}) ;
// autre code à exécuter
Dans le code non bloquant, (err, content) est appelé callback. En attendant d’avoir les avoir
information sur ‘MonFichier.txt’, Node.JS peut exécuter la suite du code.
II.2.1.3- MongoDB
MongoDB est un système de gestion de base de données
orienté documentset ne nécessitant pas de schéma prédéfini des
données (Nosql). Figure 11 : Logo MongoDB

Le serveur MongoDB est organisé en plusieurs bases de données :

 Chaque base de données contient des collections.
 Chaque collection contient des documents.
 Chaque document est au format JSON et contient donc des propriétés.
a- Identification clé / valeur
Chaque document est identifié par un identifiant nommé _id unique pour une collection,
fonctionnant comme une clé primaire artificielle.
b- Architecture
MongoDB fonctionne à minima sous la forme d'un serveur auquel il est possible de se connecter
avec un client textuel (mongo shell). MongoDB peut être distribuée sur plusieurs serveurs et accédée
à travers de multiples couches applicatives (langages, API...)
c- Comparaison SQL / MongoDB
Le tableau 6 montre les différences entre les bases de données SQL et MongoDB

18
 Tableau 5 : Comparaison SQL / MongoDB
SQL MongoDB
Base de données Base de données
Table Collection
Enregistrement Document
attribut propriété (chaîne, entier, tableau, structure)

d- Exemple de document sauvegarder au format JSON

En analysant le code ci-dessous, on constate qu’une propriété (en gras) peut contenir de chaîne,
entier, tableau, structure. Le format JSON a pesé sur notre choix de base de données.
{
"_id" : 1, "nom" : "Travers", "prenom" : "Nicolas",
"domaines" : ["SGBD", "NoSQL", "RI", "XML"],
"emplois" : [
{"id_etablissement" : "100", "qualité" : "Maître de Conférences",
"date" : "01/09/2007"},
{"id_etablissement" : "101", "qualité" : "Vacataire",
"date" : "01/09/2012"}
],
"Habite" : {"adresse" : "292 rue Saint Martin", "ville" : "Paris"}
}
e- Rôles
MongoDB nous servira donc pour collecter des informations et les organiser pour que ces
dernières soient facilement consultables, gérables. Grâce à une base de données, il est possible de
créer, de mettre à jour ou de supprimer des données.
II.2.1.4- React.JS
React.JS est une bibliothèque JavaScript libre développée par Facebook
depuis 2013. Elle est efficace et flexible pour construire des interfaces
utilisateurs (UI). Elle permet de composer des UI complexes à partir de petits
morceaux de code isolés appelés « composants ». Figure 12 : Logo
React.JS
Remarques :
Dans un site web, à chaque fois qu’un navigateur envoie une requête pour changer de page, le
serveur envoie un fichier html et le navigateur s’actualise pour afficher le contenu du fichier. Tout
cela est trop lent et couteux.
Par contre, une application s’agit d’une simple page html qui contient suffisamment de
JavaScript pour pouvoir fonctionner en autonomie une fois que le serveur l’a envoyé au client.
Autrement dit, JavaScript prend le relais pour gérer la navigation en affichant ou en masquant les
éléments du page html pour donner l’impression à l’internaute qu’il navigue sur un site traditionnel.
C’est le cas des applications créées avec React.JS.

19
 Site web
Application web

Serveur Serveur

Figure 13 : Différence entre site web et application web

II.2.1.5- Android Studio
Nous tenons à rappeler que pour sauvegarder une présence, il suffit de scanner le CodeQR de
la personne correspondant. Il faudra alors créer une application native afin de scanner ce CodeQR.
Pour créer cette application, nous avons opté pour Android Studio.
Android Studio est un environnement de développement pour
développer des applications natives Android. Il est indispensable de bien
connaître Java ou XML avant de développer une application Android. Avec
Android Studio, nous pouvons tout réaliser sur mesure. Nous aurons
Figure 14 : Logo
également beaucoup plus de précision dans la manière de réaliser notre Android Studio

application.

II.2.2- Design
Avant tout, il est important de commencer par le design pour se mettre dans le bain. La figure
15 nous montre à quoi ressemble l’interface utilisateur que nous allons créer.

1 2

Figure 15 : Interface utilisateur de l’application web

L’interface se divise en deux zones dont la première (zone 1) appelé sidebar contient les menus
tandis que la deuxième sert à afficher le contenu de la page respective à chaque menu.

20
II.2.3- Priorisation des fonctionnalités
La priorisation des fonctionnalités est une étape très importante dans un développement web
pour éviter de rebrousser le chemin. Dans cette application web, une fonctionnalité peut contenir
d’autres sous-fonctionnalités, à savoir :
 Inscription : pour inscrire une nouvelle personne, on doit remplir des champs, à savoir : photo
de profil, nom, prénom, adresse, établissement, N° CIN, Facebook, tel, email, date de naissance,
sexe et poste.
 Liste de personnel : elle nous permet de faciliter le suivie de tous les personnes qui travaille
dans la société. Dans cette liste, on aura les fonctionnalités suivantes :
 Supprimer : pour retirer une personne dans la liste ;
 Statistique : pour calculer le volume horaire et le statistique de fréquentations
mensuels d’une personne ;
 Payement : pour suivre le payement des frais (uniquement pour les membres) ;
 Plus d’info : pour voir davantage des informations sur la personne. On devra aussi accéder
dans ce menu pour créer la carte membre.
 Liste des présences : cette liste sert non seulement de suivre la présence mais aussi de dresser
une liste journalière des matériels utilisés pour chaque personne. La liste de présence est aussi
indispensable pour calculer la statistique des matériels.
 Nouveau matériel : il en est de même pour créer un matériel. Des champs sont à remplir
obligatoirement, tels que : photo, nom et nombre du matériel.
 Liste des matériels : cette liste nous permet de faire l’inventaire des matériels, vérifier les
matériels non rendus ou défectueux et modifier les données d’un matériels. De plus, on peut
aussi rechercher les personnes qui n’ont pas rendus des matériels.
 Statistique des matériels : l’application permet aussi de faire des statistiques sur les matériels.
Elle permet notamment de calculer la fréquence d’utilisation mensuelle pour chaque matériel
et ainsi de savoir le total des différents matériels utilisés.
 Nouvelle communauté : puisque la société possède plusieurs communautés, il est important
de les insérer dans la base de données afin de suivre ses activités.
 Liste des communautés : elle nous permet de rechercher les communautés, de dresser la liste
des membres d’une communauté, la liste des conférences effectuer par chaque communauté et
la liste des membres qui y ont assisté.
 Nouvelle visite : toutes les visites seront aussi sauvegardées dans la base de données afin de
rédiger un rapport mensuel. Lors d’une visite, les données à sauvegarder sont le nom de la
société et le nombre des visiteurs.

21
 Rapport de visite, rapport de communautés, rapport de présences : puisque des données
comme les visites, une conférence des communautés et des présences étaient sauvegarder dans
la base de données, nous pouvons nous en servir pour rédiger des rapports mensuels.

En résumé, nous pouvons organiser et prioriser les fonctionnalités comme suit :

Recherche Chargement
du CodeQR
Suppression
Inscription Suppression
Plus d'info
Liste de
personnel Modification
Statistique
Création de
Paiement carte
(uniquement
pour les
membres)

Choix des
Liste des
matériels
préseces
utilisés
Rapport des
présences
Recherche
Nouveau d'un
matériel matériel
Modification
de mot de Liste des Suppression
Connexion passe matériels
Modificatio
Page d'accueil Statistiques n
des matériels
Plus d'info
Recherche
Nouvelle
communauté Recherche
Ajout d'un
membre
Liste des
membres
Retrait d'un
membre
Liste des
communautés Conférence

Rapport des
communautés Recherche

Nouvelle visite Nouveau

Liste des conférence
Rapport des conférences
Recherche
visites Liste des
membre de
Deconnexion conférence Ajout d'un
membre

Figure 16 : Fonctionnalités de l'application web

22
II.2.4- Architecture du système
Le système est composé de quatre parties, à savoir :
 Le système de gestion de base de données (SGBD) : système 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.
 Le back-end : c’est la partie la plus importante de l’application car il assure la médiation du
SGBD, le front-end et l’application native. Le back-end prend en charge donc l’ensemble des
fonctionnalités du système.
 Le front-end : c’est l’ensemble des éléments visible directement par les utilisateurs et avec
lesquelles ces derniers peuvent interagir. Il prend en charge l’aspect ergonomique de
l’application.
 L’application native : c’est un logiciel développé pour un smartphone afin de scanner le QR
Code.

Ces quatre parties sont créées grâce aux outils choisis dans le paragraphe II.2.1. Soient
MongoDB pour le SGBD, Node.JS pour le back-end, React.JS pour le front-end et Android Studio
pour l’application native. Cependant, ces outils sont insuffisants pour réaliser le projet notamment
pour assurer la communication entre les quatre parties c’est pourquoi on devra l’associer avec d’autres
technologies.

II.2.4.1- Schéma synoptique

Avant de commencer la démarche la plus importante qui est le développement des quatre parties
présentées précédemment, il est préférable d’élaborer le schéma synoptique afin d’appréhender le
système dans son ensemble.

23
 Front-end Back-end SGBD

Création
des fichiers Création
de configuration du serveur de
l’application
Choix de Détermination web Choix de Base de
Index.html Echange Execution de
la page d’une opération l’opération données
de données l’opération
à afficher à effectuer à effectuer
Ecoute de
App.js Composants BaseService Axios l’application Route MongoDB
web sur Sauvegarde
le port 8080
Router Recherche
Création du
serveur de Modification
Application native l’application
native
Suppression

Création Scan Récupération Echange Ecoute de

du client http du QR Code du résultat de données l’application
native sur
le port 3000
WebSocket

Connexion
Création Etablissement Ecoute de à la base
de la requête de la connexion la réponse Affichage de données
(MongoDB)

Figure 17 : Schéma synoptique du système

24
 II.2.4.2- Communication entre le back-end et le SGBD
Puisque nous avons choisi MongoDB pour faire office de SGBD, nous utiliserons un pilote
compatible à la fois au Node.JS et à MongoDB appelé « Mongoose ». Mongoose est une bibliothèque
JavaScript qui permet de définir des schémas avec des données typées. Une fois qu'un schéma est
défini, Mongoose permet de créer un modèle basé sur ce schéma spécifique.

MongoDB écoute les connexions sur son port 27017. En utilisant la méthode .connect() de
mongoose, nous pouvons établir une connexion entre Node.JS et MongoDB. Nous aurons alors un
code comme celui-ci : mongoose.connect(mongodb://localhost:27017/database) où localhost fait
référence à l’ordinateur sur lequel l’application est exécutée, 27017 est le port de MongoDB et
database est le nom de la base de données.

II.2.4.3- Communication entre le back-end et le front-end

Afin d’établir la connexion entre Node.JS et React.js, nous avons utilisé Axios. C’est une
bibliothèque JavaScript fonctionnant comme un client http. Elle permet de communiquer avec des
API en utilisant des requêtes. Une requête est créée avec l’une des méthodes suivantes :
 Post : envoie des données vers le serveur ;
 Get : demande des données au serveur ;
 Put : modification des données sauvegardées ;
 Delete : suppression des données.

Par exemple, nous avons une code : axios.post(`/personnes`, Data);

Le code signifie que nous avons utilisé « axios » avec la méthode « post » pour envoyer des
données au le serveur. La méthode post contient deux paramètres dont le premier sert à préciser l’url
(/personnes) tandis que le deuxième contient les données (Data) à envoyer.

II.2.4.4- Communication entre le back-end et l’application native

L’application native et le back-end (serveur) se communiquent par Wi-Fi. Elle part du même
principe que celle que nous avons déjà vue dans le paragraphe II.2.4.3, à savoir la création d’un client
http. Cependant, la différence se situe au niveau du choix de la bibliothèque. Etant donné que
l’application s’exécute sur un système Android, on devra choisir une bibliothèque compatible avec le
langage Java, à savoir Okhttp3.

Il est important de noter que la connexion entre l’application native et le serveur s’établie si et
seulement s’ils se trouvent sur un même réseau.

25
II.2.5- Développement du back-end
Le Back-End est la partie du code qui est exécutée par le serveur en fonction de la demande du
client. A part les éléments que nous avons déjà vus sur la figure 17, il existe d’autres éléments pour
former le back-end.
II.2.5.1- routes
C’est ensemble des routes « ou Urls » dont chacune est associées à une fonction dans le
« controllers ». Dès que le back-end reçoit une requête où l’Url est conforme à celle dans le fichier
« route.js », alors il exécute la fonction respective ;

Le tableau 7 montre entre autres les fonctions exécutées par le serveur en fonction des Urls
envoyées par le navigateur.

Tableau 6 : Routes et fonctions respectives

Méthodes URLS Fonctions

Post /personnes Inscrire d’une nouvelle personne

Post /saveqr Sauvegarder le CodeQR

Put /updatepersonne Modifier l’identité d’une personne

Get /personnes Rechercher tous les personnes

Delete /remove/:id&:collection Supprimer une personne par id

Get /getId/:id&:collection Rechercher une personne par id

Get /presence Rechercher tous les présences

Get /stat Calculer la statistique d’une personne

Get /payement Rechercher les paiements par membre

II.2.5.2- controllers :
C’est un fichier contenant l’ensemble des fonctions pour faire des opérations et traitement des
données envoyées ou demandées par le client.

a- Elaboration des logigrammes

Afin de faciliter la création et la compréhension, nous allons d’abord élaborer des
organigrammes de programmation ou logigramme notamment pour les taches complexes avant de les
traduire en programme.

26
  Sauvegarde d’une présence
Quand on scanne un CodeQR correspondant à une personne, le serveur doit sauvegarder
l’identité de la personne avec l’heure d’entrée ou de sortie.

Voici les étapes nécessaires pour sauvegarder une présence :

 Compter le nombre d’occurrence journalier de la présence ;
 Si le résultat est nul, on sauvegarde la présence ;
 Sinon, on vérifie l’heure de sortie ;
 Si l’heure de sortie est vide, on modifie l’heure de sortie ;
 Sinon, on sauvegarde une nouvelle présence.

La figure 18 illustre l’organigramme de programmation pour sauvegarder une présence

Nouvelle
présence

Compter le nombre
d’occurrence
de la présence

Nombre Vérifier l’heure de

d’occurrence journalier de la Aucune heure de sortie
sortie
présence = 0

Sauvegarder la Modifier l’heure

présence de sortie

Figure 18 : Logigramme pour sauvegarder une présence

 Création de la liste journalière des matériels utilisés pour chaque personne

Voici les étapes nécessaires pour cette tâche :
 Compter le reste du matériel choisi ;
 Si le reste est négatif, avertir le client de la réponse et de sélectionner de nouveau un
matériel ;
 Sinon, ajouter le matériel dans la liste journalière et modifier les données du matériel dans
la liste des matériels ;

27
 Figure 19 : Logigramme pour la création de la liste journalière des matériels utilisés

 Modification des données d’un matériel

Parfois, il arrive que des matériels sont hors services et l’entreprise voudra approvisionner les
stocks, il faudra alors mettre à jour les données. Le nombre total du matériel devra être toujours égal
au somme de matériel utilisé, matériel hors service et le reste.
Voici les étapes pour accomplir cette tâche :
 Modifier un matériel en remplissant les champs nécessaires tels que nombre total, nombre
matériel hors service ;
 Calculer le reste ;
 Si le reste est négatif, avertir le client en le demandant de remplir à nouveau les champs ;
 Sinon, envoyer un message affirmatif au client.

Figure 20 : Logigramme pour la modification des données d'un matériel

II.2.5.3- middlewares
C’est un dossier contenant des fichiers qui servent à vérifier les données envoyées par le client
avant que le « Controllers » les traites. Ils sont utiles si les données envoyés par le client contiennent
des fichiers. Trois fonctions attendent donc la validation du middleware avant l’exécution car les
données contiennent des images (photo de profil, photo de matériels, CodeQR).

28
Ces fonctions sont :
 Inscription d’une nouvelle personne ;
 Sauvegarde d’un nouveau matériel ;
 Sauvegarde du CodeQR.

Pour que la requête soit confirmée, trois conditions doivent être réunies :
 Les données comportent le fichier recommandé ;
 L’extension du fichier contenant l’image est : jpeg, jpg, png ou bmp ;
 La taille du fichier ne dépasse pas 3 MB.
La figure 21 illustre le logigramme pour la programmation du middleware.

Figure 21 : Logigramme du middleware

II.2.5.4- config
config est le dossier contenant le fichier « db.config.js » que mongoose recommande pour la
configuration de la base de données. C’est-à-dire le chemin menant à MongoDB avec le nom de la
base de données.
Voici à quoi ressemble le fichier db.config.js :

Remarque : module.exports permet d’exporter le fichier pour l’appeler depuis un autre fichier.

29
 II.2.5.5- models
Le dossier « models » contient les fichiers pour définir un schéma pour chaque collection. Nous
avons besoin de sept (7) collections afin de bien organiser les données, à savoir :
 Personnel ;
 Matériels ;
 Présences ;
 Paiement ;
 Communauté ;
 Conférence ;
 Visite.

II.2.5.6- app.js
« app.js » est le fichier principal permettant d’exécuter l’application lors de la programmation.
Des opérations importantes composent ce fichier, telles que :
 connexion du back-end et le SGBD c’est-à-dire mongoose ;
 Création du serveur de l’application. Ensuite, on le met à l’écoute sur un port, soit 8080 pour
notre cas. C’est le port qui sera précisé sur axios (côté client) pour établir la connexion entre le
back-end et front-end ;
 Création du serveur socket. Ce serveur est réservé pour l’application native que nous créerons
ultérieurement. Il faut aussi le mettre à l’écoute sur un port, soit 3000 ;
 Appel du fichier « routes.js » pour que ce dernier puisse traiter l’url reçu par le serveur de
l’application web. Il en est de même pour le serveur de l’application native, on doit appeler le
fichier « socketServer.js » quand le serveur reçoit une requête.
Remarque : Nous tenons à préciser que les ports du serveur de l’application web et native ne doivent
pas être identiques afin d’éviter les erreurs.

II.2.5.7- uploads
C’est le dossier de destination des fichiers venant du client comme les photos de profils,
CodeQR et photo des matériels ;

II.2.5.8- node.modules
« node.modules » est le dossier qui contient tous les packages installées. Il se crée
automatiquement lorsqu’on installe un package.

II.2.5.9- package.json
C’est un fichier contenant les noms des packages installés. Par exemple mongoose, axios,…

30
 II.2.5.10-Templates
Les Templates nous servent de model pour faciliter l’exportation en PDF. Tous les documents
devant être exportés en PDF doit avoir alors un Template.

II.2.5.11-Dossiers de destination
Les résultats (fichiers) de l’exportation en PDF sont sauvegardés respectivement dans les
dossiers de destinations.

II.2.6- Développement du front-end

Le front-end est la partie du code qui est reçue par le client. Il s’agit des éléments de
l’application web que l’on aperçoit à l’écran et avec lesquels on pourra interagir. Le figure 22 résume
le fonctionnement du front-end dont chaque élément sera détaillé un après les autres.

Index.html

App.js BaseServices
Request
Router Composants Axios
(http)
Response

Figure 22 : Fonctionnement front-end

II.2.6.1- index.html
Lorsque l'application démarre, c'est la première page qui est chargée et ce sera le seul fichier
html de toute l'application. De plus, ce fichier a une ligne de code <div id = ”root”> </div>. Cette
ligne est très significative puisque tous les composants de l'application sont chargés dans ce div.
Voici à quoi ressemble le fichier « index.html ».

II.2.6.1- index.js
Il s'agit du fichier javascript correspondant au fichier index.html. Ce fichier a les codes suivants
qui sont très significative :

31
 A travers ces quelques lignes, on constate qu’il faut utiliser deux librairies :
 react : pour utiliser react ;
 react-dom : pour définir ce que nous souhaitons rendre.

Avec le package react-dom, nous utilisons la fonction render. En premier argument nous
souhaitons rendre le fichier App.js sur l'élément du DOM avec un ID qui est root.
II.2.6.2- App.js
Ceci est le composant principal de React.js qui agit comme un conteneur pour tous les autres
composants.

Puisque celui-ci est le fichier qui sera chargé en premier lors de l’exécution de l’application,
nous allons créer un espace login à l’intérieur de ce fichier. Ainsi, pour raison de sécurité, tous les
utilisateurs devront entrer un « nom d’utilisateur » et un « mot de passe » avant l’utilisation.

Voici les étapes à suivre dès que le fichier « App.js » est chargé :
 Vérification de l’état du compte utilisateur ;
 Si le compte est connecté, le fichier « App.js » affichera les menus de l’application, sinon, il
vérifie si la modification de mot de passe ;
 Si cette dernière est désactivée, l’espace login sera affiché pour saisir le nom d’utilisateur et le
mot de passe. Ensuite, l’application web envoie les données saisies au serveur pour
l’authentification ;
 Si les données saisies sont correctes, App.js affichera les menus de l’application ;
 Sinon, le client sera informé que les données composées sont incorrectes et de remplir à
nouveau le nom d’utilisateur et le mot de passe ;
 Par contre, l’espace de modification sera affiché s’il est activé. Le client sera invité à remplir le
nouveau nom d’utilisateur, l’ancien mot de passe, le nouveau mot de passe et de confirmer ce
dernier ;
 Si le nouveau mot de passe n’est pas confirmé, le client sera informé et invité de remplir à
nouveau les champs précédents ;
 Sinon, l’application web envoie les données composées au serveur. Ce dernier va traiter
ces données et envoyer une réponse de type booléen (true ou false) vers le client ;

32
  Si la réponse est « true », App.js informe le client que le nom d’utilisateur et le mot de
passe sont modifiées, ensuite, le client sera redirigé vers l’espace login ;
 Sinon, le client sera averti que l’ancien mot de passe saisi est incorrect, ensuite il sera invité
de remplir à nouveau les champs dans l’espace de modification.
Vérification
de l’état du compte

Connecté Modification de mot

de passe activée

Affichage de la page Affichage de Affichage de l’espace Avertir

d’accueil l’espace login de modification le client

Vérification Confirmation du
Login nouveau mot de passe

Login correct Nouveau mot de

passe confirmé
Utilisation

Envoie des données

Informer le client
vers le serveur

Réception de
la réponse

Réponse = true

Informer le client

Figure 23 : Logigramme de App.js

33
 II.2.6.3- Router
Router est une bibliothèque de routage dans React.js appelé depuis le fichier App.js. Il définit
une relation entre une URL et un composant. C’est-à-dire que lorsque l'utilisateur visite une URL sur
le navigateur, un composant correspondant doit être rendu sur l'interface. Cela rend l'interface de
l'application synchrone avec l’URL du navigateur.

Par exemple nous allons analyser une portion de code de « App.js » pour l’inscription d’une
nouvelle personne :

Le code signifie que le composant « AddPersonne » sera rendu au navigateur li l’Url sur ce
dernier correspond à l’Url « /creactepersonne » mentionné dans la path.
II.2.6.4- Composants
Les composants sont des fichiers avec une extension JavaScript qui sont appelés depuis le
fichier App.js. Un composant sert notamment à modifier l’affichage sur le navigateur en utilisant des
balises DOM. Le DOM est une interface de programmation normalisée qui permet à des scripts
d'examiner et de modifier le contenu du navigateur web.

L’échange des données entre le front-end et le back-end se fait aussi à partir des composants en
faisant appel à la BaseServices.

II.2.6.5- BaseServices
C’est un fichier contenant l’ensemble des méthodes opérationnelles exécutable via un
composant. Le BaseService va transmettre ensuite la requête vers le back-end à l’aide de « axios ».
Les Urls dans le BaseServices doivent être identiques à ceux dans la route du back-end afin d’assurer
la transmission des données.

II.2.6.6- package.json
Comme le back-end, React.JS dispose aussi un fichier package.json contenant tous les noms
des packages installés.

II.3- CONCEPTION DE L’APPLICATION NATIVE

L’application native sert à scanner le CodeQR afin de sauvegarder les données correspondants
à une personne, telles que : Nom, Prénom, Poste, Jour, Heure d’entrée et de sortie.

34
 Cette application est développée avec Android Studio dont le langage de programmation est
Java. Nous tenons à préciser que JavaScript et Java sont deux langages différents, Java permet de
créer des applications qui sont exécutées sur une machine tandis que le code JavaScript est exécuté
uniquement sur un navigateur.

II.3.1- Elaboration du logigramme de l’application native

En ce qui concerne le développement, deux bibliothèques sont indispensables afin de décoder
le CodeQR ainsi que d’envoyer le résultat au serveur, à savoir :
 zxing : permettant à un appareil Android doté d'un matériel d'imagerie de scanner des codes-
barres ou des CodeQR et de récupérer les données encodées.
 okhttp3 : cette bibliothèque est composée de plusieurs fonctionnalités avancées y compris
WebSocket. Ce dernier est un protocole de communication informatique, fournissant des
canaux de communication en duplex intégral sur une seule connexion TCP. Autrement dit, cette
bibliothèque va nous servir pour créer un client http dont l’échange des données est réalisé grâce
au concept de ports (sockets), c'est-à-dire la combinaison de l’adresse IP du serveur et le port
de l’api (backend), permettant de déterminer de façon unique sur quelle machine ce dernier
tourne.

Pour ce faire, on doit suivre les étapes suivantes :

 Initialisation de la connexion :
 Dès que l’application est lancée, la première étape qu’il exécute est l’initialisation de
la connexion entre le serveur et elle-même. Le but est de créer un client http avec la
bibliothèque okhttp3 ainsi que la requête afin de communiquer avec le serveur ;
 Pour identifier le serveur, la requête doit contenir en paramètre l’adresse IP de ce dernier
et le port de l’api ;
 Vérification de l’état du bouton « Scan » :
 S’il est activé, l’application demande la permission d’utiliser la camera du smartphone
et choisie le format du code à scanner (QR Code ou Code barre) ;
 Quand l’appareil photo est prêt, on le pointe vers le QR Code pour récupérer le résultat ;
 Si le résultat est vide, l’application affichera en notification que le scan est annulé.
Autrement dit, l’utilisateur n’a pas scanner un QR Code mais a décidé de revenir à la
page d’accueil de l’application ;
 Par contre, si l’application récupère un résultat, elle va l’envoyer automatiquement au
serveur par l’intermédiaire de la bibliothèque WebSocket ;
 En même temps, l’application établie la connexion entre le serveur et elle-même.

35
  Si elle n’arrive pas à se connecter au serveur, aucune notification ne sera affichée. Ce
problème peut arriver si le smartphone n’est pas connecté sur le même réseau que le
serveur ;
 En revanche, si elle est connectée au serveur, elle affiche en notification « Connexion
établie ». Ensuite, l’application attendra les réponses du serveur et les affichera sous
forme de notification. Il est important de noter que le serveur transmet une réponse
lorsque l’application native envoie une requête contenant le résultat du scan. La réponse
permettra alors de déterminer l’identité de la personne et de s’assurer que ce dernier est
sauvegarder dans la liste de présence.

Création d’un client http

Création de la requête

Etablissement
Bouton scan activé de la connection

Afficher la page Demande de la

d’accueil de permission d’utiliser Connecté
l’application la camera

Choix de format Afficher Aucune

du code à scanner « Connexion établie » notification

Afficher Récupération Ecoute de

« Scan annulé » du résultat la réponse

Nouvelle
Résultat vide
réponse

Envoie du résultat Afficher la

au serveur réponse

Figure 24 : Logigramme de l'application native

36
II.3.2- Fonctionnement du QR Code
II.3.2.1-Description
Le QR Code permet le stockage d'informations sous forme graphique et la lecture de manière
automatique et rapide des données plus ou moins complexes afin de gagner du temps et surtout réduire
les erreurs de saisie manuelle. Sa lecture se fait via un lecteur de code-barres, une capture laser, une
webcam et même un téléphone portable muni d'une caméra.
x
Un QR Code a la capacité de stocker ses informations horizontalement
et verticalement. En effet, la lecture se fera sur 2 axes. Par conséquent, un
QR Code peut être représenté par une matrice(x,y). La taille maximale de
y
données que peut contenir un QR Code est de 2953 octets. Figure 25 : QR Code

Plus il y a de points dans la matrice, plus il y a de l'information stockée dans le QR Code. Le Qr Code
a également la capacité de pouvoir être lu dans tous les sens (360°) de manière très rapide grâce à des
repères dans la matrice facilement détectables.
II.3.2.2-Structure
Un QR Code est composé de carrés noirs et blancs qui s'appellent modules. Chaque module
représente une valeur binaire, soit 1 pour un module noir et 0 pour un module blanc.
Il existe dans le code 2 principales régions. Le code contenant les données à stocker et le code
correcteur. Le code correcteur permettra, en cas de perte des données stockées, à corriger celles-ci et
récupérer les informations détruites. Il est important de noter que le QR Code reste lisible avec jusqu'à
30% de son code détruit ou manquant car il contient un code correcteur.

Zone de
Zone de
correction
données
d’erreur

Figure 26 : Structure du QR Code

Il existe 40 versions de QR Code. On définit cette version en fonction de la quantité

d'informations à stocker. Plus un QR Code a une version élevée, plus il sera difficile à décoder.
II.3.2.3-Création
Quelques étapes sont nécessaires pour générer un QR Code :
 Analyse des données à encoder et paramétrage du niveau de code correcteur : Si l'utilisateur n'a
pas spécifié le niveau de code correcteur, la plus petite version de QR Code sera sélectionnée
pour accueillir les données ;
 Conversion des caractères de données dans un flux de bytes ;
 Implémenter la correction des erreurs : séparer par blocs les bits de données et de générer leurs
codes correcteurs ;

37
  Insérer les données avec le code correcteur dans la matrice ;
 Générer la matrice ;
 Générer le QR Code au format image : c'est le résultat final qui pourra être lu par un lecteur de
QR Code.

II.3.2.4-Lecture
Voici les étapes nécessaires pour la lecture d’un QR Code :
 Reconnaître les bits 1 ou 0 ;
 Identifier le taux de code correcteur ;
 Identifier la version du QR Code ;
 Découvrir la région à décoder ;
 Lire les données et le code correcteur ;
 Détecter et corriger s’il contient des erreurs ;
 Décoder les données ;
 Afficher le résultat.

II.3.3- Gestion de temps réel

Le temps réel est une notion qui prend de plus en plus d'importance. Un système de gestion qui
exploite les données en temps réel fournit des résultats plus précieux qu’auparavant. Pour la gestion
de la présence, il nous permet notamment d’obtenir des résultats plus détaillées sur l’identité de la
personne, l’heure d’entrée ou de sortie, tout en exécutant la tâche avec le minimum de temps possible.
II.3.3.1-Tâche
Considérons une tâche Ai. Soit Si le début de la tâche Ai et Di la date d'échéance de Ai, c'est à
dire la date à laquelle les résultats doivent être disponibles. Le délai de réaction du système spécifié
sera donc Di – Si. Soit Ci la durée du traitement.
Soit Ti sa période si la tâche Ai est périodique. La durée du traitement Ci = Di – Si doit être
strictement inférieur à Ti pour que le système est faisable.
II.3.3.2-Avantages d’un système en temps réel
Voici quelques avantages d’un système exploitant des données en temps réels :
 Amélioration de la précision : aucun erreur sur l’identité de la personne et le temps
d’entrée/sortie lors du sauvegarde ;
 Confiance et transparence : l’administrateur est confiant de l’exactitude des données qu’il
manipule. Le système ne permet pas de sauvegarder la présence d’une personne inconnue ou
absente ;
 Meilleure rapidité d’exécution : la tâche est exécutée avec le minimum de temps possible ;

38
II.4- CONCLUSION
Bref, nous constatons que nous avons conçu un système composé de quatre parties, à savoir le
système de gestion de base de données, le back-end, le front-end et l’application native. Chaque partie
joue un rôle très important dans le système. En particulier, nous avons choisi MongoDB qui est un
système de gestion de base de données orienté documents (Nosql). Cela nous a facilité la tâche
pendant la conception car contrairement à un SGBD sql, MongoDB ne nécessite pas de schéma
prédéfini des données. A part les outils présentés dans le choix des matériels, nous avons adopté
d’autres technologies pour assurer la communication entre les différentes parties. Grâce à ses
technologies, les applications web et native pourront interagir avec le back-end par Wi-Fi. Cette
communication à distance est l’une des méthodes qui nous a permis de résoudre les pertes de temps.
Enfin, lors du développement, nous avons préféré d’élaborer des logigrammes plutôt que de
présenter des suites d’instructions dans le but de faciliter la compréhension.

39
Chapitre III- RESULTATS ET INTERPRETATIONS

40
 Ce dernier chapitre présentera les résultats obtenus après la conception des applications web et
natives.

III.1- PRESENTATION DE L’APPLICATION WEB

Après le développement, voyons maintenant quelques aperçus des différents pages de

l’application web ainsi que ses fonctionnalités.

III.1.1- Page de connexion

Après le déploiement, l’application sera fournie avec
un login à l’administrateur. Le login est un identifiant qui
lui permet de s’identifier sur l’application web. Un login est
composé par un nom d’utilisateur et un mot de passe. C’est
aussi une mesure de sécurité pour garder des informations
privés. Figure 27 : Page de connexion

La page de connexion est la page correspondant à l'adresse racine de l’application. C'est la

première page visitée par l’administrateur qui entre par l'adresse de l’application. Une fois
l’administrateur connecté, il sera redirigé vers les hyperliens des principaux services et informations.
III.1.2- Liste de personnel
La liste de personnel permet à l’administrateur de s’occuper de toutes les données relatives au
personnel. Elle permet notamment de simplifier tous les processus qui s’articulent autour des
employés de l’entreprise, tels que la mise à jour, le calcul de la statistique de fréquentation, paiement
de frais, création de la carte de membre,…

Figure 28 : Liste du personnel

41
III.1.3- Statistique de fréquentation
La statistique de fréquentation permet de calculer facilement le nombre de fréquentation et le
cumul des heures de travail mensuel d’un employé.

Pour accéder à la statistique de fréquentation, on clique sur « Détails >> Statistique » depuis la
liste de personnel.

Figure 29 : Statistique de fréquentation

III.1.4- Liste des présences

Cette page permet de suivre facilement la présence de tous les personnels par jour car elle
contient un champ de recherche et un calendrier pour trier les résultats de la recherche.

Dès qu’on scanne un QR Code, c’est-à-dire si une personne est arrivée ou partie, les résultats
seront affichés automatiquement dans cette page dont le nom, prénom, poste, jour, heure d’entrée ou
de sortie.

De plus, en cliquant sur le bouton « Détails », on accède à une autre page pour dresser une liste
des matériels utilisé par une personne chaque jour. Cette liste nous permet d’avoir une bonne gestion
sur les matériels car elle contient non seulement la photo, et le nombre de matériels utilisés mais aussi
une observation afin de mentionner si ce dernier est rendu ou non rendu.

42
Figure 30 : Liste des présences

Figure 31 : Choix des matériels

43
III.1.5- Liste des matériels
Comme le montre la figure 44, nous pouvons rechercher les matériels en fonction de leurs
catégories (électronique ou informatique) et leurs états (utilisés ou défectueux). Cette page sert aussi
à mettre à jour les données concernant un matériel et de rechercher les personnes qui n’ont pas rendu
des matériels.

En résumé, cette page sert à effectuer l’inventaire des matériels et à déterminer le nombre de
matériel à approvisionner.

Figure 32 : Liste des matériels

44
III.2- PRESENTATION DE L’APPLICATION NATIVE

III.2.1- Activité principale

Une application contient en générale plusieurs activités. En analogie avec le monde des
applications web, on peut dire qu’une activité est une page web. Elle représente une chose que
l'utilisateur peut faire à un moment donné.

L’activité principale est la première interface

utilisateur que l’application affiche dès son exécution. A ce
moment, nous savons déjà que l’application établie la
connexion entre le serveur et elle-même. Pour s’en rendre
compte, nous avons affiché le résultat en bas de l’écran
comme le montre la figure 34.

Figure 33 : Activité principale

III.2.2- Scan
Une fois la connexion établie, l’utilisateur peut
commencer à scanner. Pour ce faire, il suffit de pointer la
camera du smartphone vers le QR code afin de récupérer le
résultat.

Figure 34 : Scan QR Code

III.2.3- Envoie et affichage du résultat

D’une part, après la récupération, l’application envoie le résultat au serveur qui va à son tour
envoyer une réponse au client pour informer ce dernier sous forme de notification si une personne est
entrée ou sortie.

45
 D’autre part, l’application change d’activité pour afficher le résultat. Cette deuxième activité
contient la photo, nom, prénom et poste de la personne et surtout un « bouton » qui sert à scanner de
nouveau des autres QR code.

Figure 35 : Affichage du résultat de scan

III.3- INTERPRETATIONS
En examinant les résultats présentés dans les paragraphes III.1 et III.2, on constate qu’ils
répondent aux objectifs globales et spécifiques mentionnées dans le cahier de charge.
D’ailleurs, les pages sont riches en informations comme on peut le voir sur les figures 28, 31 et
32. Ainsi, nous avons habituellement utilisé des tableaux et des images sur ces pages pour permettre
au responsable d’avoir un regroupement visuel des informations. Cela lui permet d’accélérer la
recherche des informations.
L’utilisation des formulaires et des boutons sur les pages web sont bénéfiques car cela permet
de réaliser les tâches avec le minimum d’intervention humaine.
L’application native que nous avons développée avec Android Studio permettant de scanner un
Code QR est aussi très primordiale dans notre système. En effet, elle nous permet d’avoir une
transparence dans l’entreprise. D’une part, un intrus ne pourra jamais entrer au sein de l’entreprise.
D’autre part, les membres n’aura plus aucun doute sur leurs statistiques de fréquentation car
l’application native fournit des informations très précises qui seront ensuite sauvegarder dans une
base de données.
En somme, après avoir réalisé les tests, nous constatons que nos études ont abouti aux résultats
voulus.

46
Chapitre IV- DISCUSSION

47
IV.1- SUR LE PLAN MATERIEL
Sur le choix des matériels, nous sommes conscients qu’il existe d’autre solution pour assurer la
gestion de présence telle que l’utilisation d’une carte RFID en lieu et place du Code QR. Pourtant,
nous avons opté pour ce dernier car il est le plus avantageux.

En effet, le QR Code est très résistants car il suffit que 30% du QR Code soit intact pour qu’il
puisse être flashé. De plus, son faible coût est aussi un atout considérable. Il peut être fourni
gratuitement sur de nombreux sites web ou sur des générateurs de QR Code. Enfin, il suffit de les
imprimer pour que nous puissions les utiliser.

IV.2- SUR LE PLAN LOGICIEL

En premier lieu, il est essentiel de préciser que le rôle d’un site web est de fournir et présenter
de l’information aux visiteurs. Par contre, une application web est tout site web mais permet à ses
utilisateurs d’accomplir des tâches spécifiques.

Par conséquent, connaissant les différentes fonctionnalités que doivent avoir le système
d’administration du personnel et des matériels, nous avons décidé de concevoir une application web
plutôt qu’un site web. Nous sommes donc tournés vers JavaScript pour créer cette application. En
revanche, si nous étions déterminés à concevoir un site web, il fallait adopter d’autre langage
approprié pour concevoir ce dernier tel que PHP.

Puisque l’objectif principal de ce projet est de gérer le personnel et les matériels de la société
HABAKA à travers un outil informatique, on peut dire que ce projet est une informatique de gestion.
Ce projet peut donc s’appliquer sur plusieurs domaines, mais toutefois on doit l’adapter en fonction
du domaine qu’il s’applique.

IV.3- DOMAINES D’APPLICATION

L’informatique de gestion a de nombreuses applications pratiques dans plusieurs domaines, tels
que :
 Domaine de gestion :
 Gestion comptable : établissement des factures, établissement des comptes annuels,
enregistrement des opérations comptables ;
 Gestion commerciale : création de devis, gestion des comptes clients, gestion des ventes,
émission de factures et autres documents commerciaux, suivi des livraisons ;
 Gestion de stock : organisation de la chaîne d’approvisionnement, planification des
livraisons avec les fournisseurs, préparation des commandes, réalisation des inventaires,
surveillance des marchandises entrantes et sortantes, établissement des factures ;

48
  Gestion des ressources humaines : établissement du bulletin de salaire, contrôle des paies
spécifiques, mise à jour des dossiers du personnel ;
 Domaine industriel :
 Gestion de Maintenance Assisté par Ordinateur : gestion des équipements, gestion des
actions de maintenances, gestion des coûts et budget ;
 Domaine pédagogique :
 Expérimentation Assistée par Ordinateur : automatisation de l’acquisition des données,
sauvegarde et traitement des résultats de mesure, représentation graphique des résultats.
 Enseignement Assisté par Ordinateur : développement d'un didacticiel ;

IV.4- AVANTAGES
L’informatique de gestion permet à l’entreprise de bénéficier les avantages suivants :
 Accomplir les tâches dans les délais : l’exécution des tâches est effectuée par l’ordinateur ;
 Simplifier la tâche : la tâche est aussi exécutée avec le minimum d’intervention possible ;
 Faire plus dans un même laps de temps ;
 Identifier et anticiper les problèmes : nous pouvons repérer rapidement les problèmes qui
affectent l’entreprise et ainsi anticiper les problèmes qui pourraient subvenir ;
 Améliorer la sécurité des données : les données sont sauvegardées dans une base donnée qui
est protégée par un mot de passe.

49
CONCLUSION ET PERSPECTIVES
L’objectif général de cette étude est d’améliorer l’administration du personnel et les matériels
de HABAKA à travers l’informatique. HABAKA est un organisme communautaire au sein du Centre
d’Information et de Documentation Scientifique et Technique (CIDST) sis à Tsimbazaza. La
présentation de cet organisme et de ce centre sont alors nécessaire pour conduire les lecteurs dans
l’étude.

L’introduction nous a permis de connaître l’importance de l’administration du personnel et des

matériels au sein de HABAKA. L’entreprise a utilisé des méthodes peu fiables telles que la prise des
informations sur papier et l’utilisation des logiciels inappropriés pour assurer cette mission.
Connaissant les problèmes que celles-là provoque et en tenant compte de l’évolution de la
technologie, nous avons pu constater que ces méthodes ne sont pas les meilleurs solutions et nous
avons conçu des applications web et native pour améliorer l’administration du personnel et des
matériels.

Les matériels et méthodologie est le chapitre le plus important dans cette étude. En premier
lieu, nous avons listé les objectifs généraux et spécifiques dans un cahier de charge. La connaissance
parfaite des missions a été indispensable pour l’amélioration de l’administration. En second lieu, la
conception de l’application web et l’application native nous ont permis d’accomplir une grande partie
des objectifs mentionnés dans le cahier de charge.

Par conséquent, des matériels ont été choisis. Pour le développement du front-end de
l’application web, nous avons opté pour React JS tandis que pour le développement du back-end,
nous avons choisi Node.JS. Le choix des matériels notamment JavaScript s’est fait alors en fonction
de la simplicité à développer l’application web et de résoudre des situations complexes lors de la
programmation. D’autre part, le développement de l’application native est un atout considérable pour
l’administration étant donné sa facilité à sauvegarder les présences du personnel dans la base de
données.

La communication entre les différentes parties du système est aussi primordiale c’est pourquoi
nous étions obligés de faire des choix technologiques. A ce propos, nous avons utilisé des
technologies telles que mongoose, axios et Okhttp3 pour assurer respectivement la communication
entre le back-end et le SGBD, le front-end et le back-end, le back-end et l’application native.

Par ailleurs, ce stage de fin d’étude de Master II que nous avons effectué au sein de la société
HABAKA nous a permis d’acquérir des compétences essentielles tant sur le plan personnel que
professionnel. La fréquentation avec des professionnels qui œuvrent dans le domaine informatique et

50
électronique nous a donné un bon développement personnel surtout dans les travails d’équipe et
d’approfondir nos connaissances sur les différents technologies.
En conclusion, la conception des applications web et native procure des avantages tels que la
réduction des temps perdus et l’amélioration de la sécurité des données. De plus, nous avons su
exploiter le QR Code qui apporte beaucoup plus pour l’entreprise vu son efficacité et sa rapidité à
accomplir une tâche sur un seul geste. En outre, ce projet est très intéressant puisqu’il peut s’adapter
dans plusieurs domaines différents.
Connaissant que l’application web nous permet de gérer une grande activité, il est envisageable
de procéder à une maintenance évolutive tout en maintenant la cohérence de l’application avec les
besoins de l’entreprise. Afin d’optimiser l’application web, l’intégration d’un système de sécurisation
de données plus fiable et performant que celui mis en place est aussi concevable.

51
REFERENCES

BIBLIOGRAPHIQUES

[1] Liva Graffin RAKOTOARIMANANA, Maitre de Conférences

Informatique de réseaux

Note de cours MISEI 2017-2018

WEBOGRAPHIQUES

[2] https://docs.mongodb.com/manual/, The MongoDB 4.4 Manual, 13 Mai 2020

[3] https://mongoosejs.com/docs/queries.html/, Mongoose v5.13.2 : Queries, 15 Juillet 2020

[4] https://www.w3schools.com/nodejs/nodejs_mongodb.asp, Node.js MongoDB Query , 14

Septembre 2020

[5] https://reactjsexample.com/, React.js Examples, 20 Novembre 2020

[6] https://square.github.io/okhttp/4.x/okhttp/okhttp3/-ok-http-client/, Package okhttp3 – OkHttp

– OkHttp – Square Open Soure, 11 Janvier 2021

52
ANNEXES
 LISTE DES ANNEXES
Annexe 1 : Extrait de programme sur le fichier « controllers.js » côté serveur………………………III

Annexe 2: Extrait de programme sur le fichier « Materiels.js » côté front-

end……………………...IV

Annexe 3 : Extrait de code sur l’application native…………………………………………………V

Annexe 4 : Evolution de la programmation asynchrone en JavaScript………………………………VI

II
 Annexe 1 : Extrait de programme sur le fichier « controllers.js » côté serveur

exports.createPersonne = async (req, res) => {

const day = moment().format('ddd Do MMM YYYY, HH:mm:ss')
var ddn = req.body.ddn.split(' 00:');
const personne = new Personne({
imagename: req.body.name,
imagesrc: req.file.path,
qrimagename: '',
qrimagesrc: 'aucun',
nom: req.body.nom,
prenom: req.body.prenom,
ddn: ddn[0],
sexe: req.body.sexe,
adresse: req.body.adresse,
etablissement: req.body.etablissement,
cin: req.body.cin,
facebook: req.body.facebook,
tel: req.body.tel,
email: req.body.email,
poste: req.body.poste,
community: [],
created: day
})
try {
const data = await personne.save(personne)
res.send(data);
} catch (err) {
console.log(err.message)
res.status(500).send({
message: err.message || 'Some error occurred while saving person.'
});
}
}

exports.saveQR = async (req, res) => {

try {
const update = { $set: { qrimagename: req.body.name, qrimagesrc: req.file.path
}}
const data = await Personne.findByIdAndUpdate(req.body.id, update)
res.send({ message: 'Code QR sauvegardé !' });
} catch (err) {
console.log(err.message)
res.status(500).send({
message: err.message || 'Some error occurred while saving person.'
});
}
}

III
 Annexe 2 : Extrait de programme sur le fichier « Materiels.js » côté front-end

const Materiel = props => {

const [collection, setCollection] = useState('Materiels')
const [materiel, setMateriel] = useState({
id: null,
imagename: '',
imagesrc: '',
materiel: '',
nombre: '',
utilise: '',
hs: ''
});

useEffect(() => {
getMateriel(props.match.params.id);
}, [props.match.params.id]);

const getMateriel = async (id) => {

try {
const response = await BaseServices.getId(id, collection)
setMateriel(response.data);
} catch (err) {
console.log(err);
}
};

const handleInputChange = event => {

const { name, value } = event.target;
setMateriel({ ...materiel, [name]: value });
};

const deleteMateriel = async () => {

try {
const response = await BaseServices.remove(materiel.id, collection)
props.history.push('/materiels');
} catch (err) {
console.log(err);
}
};

const modifier = async () => {

try {
const response = await BaseServices.updateMateriel(materiel)
if (response.data.status === false) {
alert(response.data.message);
}
getMateriel(materiel.id, collection);
} catch (err) {
console.log(err);
}
};

IV
 Annexe 3 : Extrait de code sur l’application native

private void initiateSocketConnection() {

OkHttpClient client = new OkHttpClient();
Request request = new Request.Builder().url(SERVER_PATH).build();
webSocket = client.newWebSocket(request, new SocketListener());
}

private class SocketListener extends WebSocketListener {

@Override
public void onOpen(WebSocket webSocket, Response response) {
super.onOpen(webSocket, response);
runOnUiThread(() -> {
Toast.makeText(MainActivity.this, "Connexion établie !",
Toast.LENGTH_LONG).show();
});
}

@Override
public void onMessage(WebSocket webSocket, String text) {
super.onMessage(webSocket, text);
runOnUiThread(() -> {
Toast.makeText(MainActivity.this, text, Toast.LENGTH_LONG).show();
});
}
}

@Override
protected void onActivityResult(int requestCode, int resultCode, @Nullable Intent data) {
super.onActivityResult(requestCode, resultCode, data);
IntentResult intentResult = IntentIntegrator.parseActivityResult(requestCode,
resultCode, data);
if (intentResult.getContents() != null){
webSocket.send(intentResult.getContents());
String result = intentResult.getContents();
Intent otherActivity = new Intent(getApplicationContext(), ShowData.class);
otherActivity.putExtra("response", result);
startActivity(otherActivity);
} else {
Toast.makeText(this, "Vous avez annulé le scan", Toast.LENGTH_LONG).show();
}
}

V
 Annexe 4 : Evolution de la programmation asynchrone en JavaScript

Rappelons au préalable que par design, Node.js est asynchrone. Le standard est basé sur des
callbacks, qui ont vite été supplantées par les promesses, une manière plus élégante et efficace d’écrire
du code asynchrone.
Cependant, l’utilisation de promesses mène souvent à du code verbeux et qui s’éloigne des
pratiques habituelles. C’est pourquoi Node.js nous offre une nouvelle méthode pour éviter ces
ambiguïtés, à savoir async/await.
Considérons un exemple pour voir de près la différence entre ces trois méthodes. L’exemple
montre qu’on lit un fichier « input.txt », puis on affiche son contenu dans le terminal.

Callback
var fs = require("fs");
fs.readFile('input.txt', function (err, data) {
if (err) return console.log(err);
console.log(data.toString());
});

Promise
var fs = require("fs");
fs.readFile('input.txt')
.then(data => {
console.log(data.toString());
})
.catch(err => {
console.log(err);
})

Async/await
var fs = require("fs");
try {
const data = await fs.readFile('input.txt')
} catch (err) {
console.log(err);
}

Il est important de noter que le mot clé « await » ne peut être utilisé que dans une fonction
« async ».
VI
VII
TITRE : CONCEPTION DES APPLICATIONS WEB ET NATIVE POUR
L’ADMINISTRATION DU PERSONNEL ET DES MATERIELS DE HABAKA

RESUME
L’administration du personnel et des matériels est une mission très importante au niveau
de la direction. Cependant, l’entreprise utilise des méthodes inefficaces pour accomplir cette
mission, ce qui entraine beaucoup de pertes de temps et de pertes de données. La conception
des applications web et native sont alors les solutions proposés pour résoudre ces problèmes
afin d’assurer les fonctions pour administrer le personnel et les matériels. De plus, ces
applications sont conçues avec des technologies avancées telles que Mongo DB, Node.JS,
React.JS et QR Code afin d’apporter des améliorations pour l’entreprise. En outre, cette
recherche est très intéressante puisqu’elle peut s’adapter dans plusieurs domaines différents.
Connaissant que l’application web nous permet de gérer une grande activité, il est
envisageable de procéder à une maintenance évolutive tout en conservant la cohérence de
l’application avec les besoins de l’entreprise.

Mots clés : administration, application web, native, technologie, JavaScript, QR Code.

ABSTRACT
The administration of personnel and materials is a very important mission at the
management level. However, the company uses inefficient methods to accomplish this mission,
resulting in a lot of waste of time and loss of data. The design of web and native applications
are then the solutions proposed to solve these problems in order to provide the functions to
administer personnel and materials. Additionally, web and native applications are built with
advanced technologies such as Mongo DB, Node.JS, React.JS, and QR Code to deliver
improvements for the business. In addition, this project is very interesting since it can be
adapted in several different fields.
Knowing that the Web application enables us to manage a large activity, it is possible to
carry out an evolving maintenance while preserving the consistency of the application with the
needs of the company.

Keywords: administration, web application, native, technology, JavaScript, QR Code.

Rapporteur Impétrant
RAZANAMANAMPISOA Harimalala Nom : RAMANJATO
Maître de Conférences Prénom : Kiadinirina Biaza
Tel : 032 21 765 05 / 034 31 633 26
Lieu de stage Email : kiadibiazaramanjato@gmail.com
HABAKA TSIMBAZAZA Adresse : Lot II N 102 A Analamahitsy