0

REPUBLIQUE DEMOCRATIQUE DU CONGO

MINISTERE DE L'ENSEIGNEMENT SUPERIEUR ET UNIVERSITAIRE
INSTITUT SUPERIEUR PEDAGOGIQUE DE BUKAVU
« ISP-BUKAVU »
SECTION : SCIENCES COMMERCIALES, ADMINISTRATIVES ET INFORMATIQUE
DEPARTEMENT : INFORMATIQUE DE GESTION

B.P. 854/BUKAVU

CONCEPTION ET REALISATION D’UNE

APPLICATION DE RECONNAISSANCE FACIALE
POUR LA GESTION DES PRESENCES : CAS
DES AGENTS DE L’ISP/BUKAVU

Par MURHULA KABI Grâce

Gradué en informatique de gestion

Mémoire présenté et défendu en vue de
l’obtention du titre de licencié en Pédagogie
Appliquée.

Option : Informatique de Gestion

Directeur : TASHO KASONGO Issa

Chef des travaux

Année Académique : 2016 – 2017

 1

INTRODUCTION GENERALE

De l’âge de la pierre à nos jours, l’esprit studieux de l’homme n’a cessé de

lui permettre d’améliorer sa vie machinale. Le chenal de la mécanique aux
domaines d’informatique, d’électronique et de domotique a bouleversé la vie
journalière de l’être humain. Les nouvelles technologies de l’information et
de la communication ornent ce phénomène. Aujourd’hui, vu l’intérêt
croissant de vouloir rafler en temps, de conserver les données, d’améliorer la
gestion et pas mal d’autres raisons, ont poussés petites, moyennes et
grandes entreprises à quérir des solutions informatiques capables de
rétorquer à leurs besoins. Dans ce cadre s’inscrit notre projet de mémoire
qui consiste à concevoir et à réaliser une application de gestion des
présences des agents utilisant la technologie de reconnaissance faciale.
La gestion des ressources humaines étant parfois collationnée à des
multiples embarras, plusieurs entreprises réfléchissent à des solutions
efficaces. Cependant, Comment manager scrupuleusement son personnel
tout en favorisant sa productivité reste une problématique qui est à la une
sans doute avec acuité que ce soit dans l’environnement public que privé.
Ce dernier temps, un grand nombre d’employeurs comprennent la
nécessité de gérer les absences; toutefois, l’absentéisme et l’invalidité
continuent à poser des problèmes importants et entraînent des coûts
substantiels (Shepell.fgi ; 2010, p.2).
Au sein de l’ISP/Bukavu, la gestion de présence des agents est une
pratique qui est artisanale et qui met cette dernière dans une situation de
manque de transparence dans le contrôle d’entrée-sortie de ses propres
agents. Nous évoquons l’aspect de défaillance dans la transparence car, le
système de signer à l’arrivé et à la sortie n’exhibera jamais le véritable retard
de l’agent ; en plus de cela, un agent peut arriver au travail à 08h mais dans
le cahier de présence il signe 07h30 ou soit encore son ami peut s’absenter
et rien ne peut éviter qu’il signe pour lui. Ce problème engendre plusieurs
autres conséquences dont nous avons pris connaissance lors de notre
descente sur terrain et que cela était dû d’une part d’un manque des
matériels et logiciels spécialisés mais aussi d’autre part d’un manque
d’implication d’autorités académique.
 2

Selon le Groupe de recherche Shepell.fgi et divers spécialistes en gestion

des absences et de l’invalidité (Shepell.fgi ; 2010, p.9), Chaque jour
d’absence se traduit par des coûts directs, des pertes de productivité et de
revenu, en plus d’alourdir les conditions de travail des gestionnaires et des
collègues qui doivent assumer la charge de travail de l’employé absent.
Etant donné que les présences, absences et les heures supplémentaires
participent dans la paie des agents, nous constatons une autre conséquence
en nous tablant sur la théorie précitée que, c’est vraiment incontestable que
l’ISP soit entrain de connaitre des pertes de revenu suite aux présences
inexactes ou habillées, ceci étant un signe d’usage irrationnel des finances.
Nous présentons ainsi la synthèse du problème sous forme d’un arbre à
problème (figure N°1) où le problème principal de notre recherche se situe au
centre, les causes majeures en dessous et les conséquences principales au
dessus.

Figure N°1 : L’Arbre à problème de notre projet

Cela étant, suite à l’évolution technologique et à la course sur la
rentabilité, l’ISP-Bukavu est contrée de faire la poursuite d’une solution
efficace pouvant l’accompagner à résoudre tant soit peu ces problèmes liés à
la gestion manuelle des présences de son personnel.
 3

Plongeons- nous donc dans une étude en se posant la question suivante :

La mise en place d’un Logiciel de reconnaissance faciale pour la gestion des
présences serait-elle un outil d’aide à la transparence dans la gestion des
présences et absences du Personnel au sein de l’ISP-Bukavu ?
Vu que les caractéristiques biométriques sont mesurables et uniques, et
que deux personnes ne peuvent pas posséder les mêmes caractéristiques
(BOUDJELLAL Sofiane ; 2010, p.1), ceci nous promet donc de les distinguer
à partir de ces caractéristiques et les utiliser afin de certifier leurs identités.
Nous postulons à priori que la mise en place d’un logiciel de gestion de
présence basé sur la technologie biométrique de reconnaissance faciale
serait un outil d’aide à l’adéquation de la transparence en ce qui concerne
les entrées et les sorties des agents à l’ISP-Bukavu.
Afin d’arriver au terme de notre étude, nous avons obéit à certains
normes appelées méthodes ; lesquelles nous ont éclairé tout au long de nos
processus. C’est dans ce cadre-là que nous avons exploité la méthode
historique pour comprendre l’historique de l’ISP-Bukavu, surtout l’aspect
ressources humaines, en saisissant entre autre les mobiles qui ont présidé à
sa création et son évolution dans le temps. Nous avons exploité également la
méthode informatique UP7 (Unified Processus 7) qui est une méthodologie
on ne peut plus importante dans notre recherche, basée sur les principes
d’UP et beaucoup plus pragmatique pour analyser et comprendre le
problème mais aussi tout ce qui entre en jeu dans la conception et la
réalisation de notre système d’information. Nous avons beaucoup plus
développé cette approche dans les lignes qui vont suivre. Pour déterminer le
coût de notre logiciel, nous avons utilisé la méthode de COCOMO dans son
aspect basique. Un recours aux différentes techniques a été fait pour rendre
ces méthodes réalisables ; il s’agit de techniques suivantes :
Primitivement, une technique sur le brainstorming (Séance de remue
méninge) et interviews que nous avons tenu avec le responsable du service
de gestion du personnel et rémunération mais aussi certains membres du
personnel de l’ISP/Bukavu. Cette technique nous a permis d’avoir de la
lumière sur la conception de notre logiciel. Secondement, une approche
appuyée sur la recherche documentaire, documents existants qui abordent
 4

la reconnaissance faciale, les systèmes de gestion et autres. En définitive,

une approche basée sur la recherche sur Internet qui nous a permis de
moissonner les pistes nécessaires en rapport avec la reconnaissance faciale
et le management des présences des agents dans une entreprise.
La reconnaissance faciale étant un sujet à la une de nos jours, nous ne
sommes pas le premier à aborder cette thématique. Par conséquent, nous
avons essayé d’arborer quelques travaux empiriques qui avaient un javelot
avec notre sujet au niveau de notre revue empirique de la littérature1.
Cependant, la recherche de la transparence en ce qui concerne l’heure
d’arriver et celle de sortie d’un employé dans une entreprise étant une
inquiétude à la une chez plusieurs entrepreneurs, nous avons trouvé ce
sujet pertinent du fait qu’il nous permet de doter aux entreprises un outil de
transparence dans la gestion des présences en se servant des
caractéristiques biométrique des faces des employés. Autrement, ce travail
est réalisé à double intérêt :

Aux entreprises : ce travail le dotera d’un outil efficace de gestion des

présences de leurs employés et réglant ainsi le problème de non
transparence ;
Aux scientifiques : du fait qu’il s’agit d’un sujet moins traité jusqu’à
présent, ce travail constitue une source de documentation aux autres
chercheurs.

Par ailleurs, l’objectif de cette recherche est d’automatiser la gestion

des présences des agents en réalisant un logiciel exploitant les robustesses
de la technologie de reconnaissance faciale pour améliorer cette gestion. Plus
précisément, doter à l’ISP/Bukavu, un logiciel de gestion de présence de ses
agents illustrant avec précision les présences des agents au travail à partir
de la reconnaissance faciale. Ainsi donc, l’objectif de ce travail se traduit par
un arbre à objectif (figure N°2) sur lequel nous présentons l’objectif principal
au centre, les éléments à mettre en place en dessous ainsi que les
conséquences de la réalisation de cet objectif au dessus.

1 Deuxième section du premier chapitre

 5

Figure N°2 : L’arbre à objectif de notre projet

En outre, sur le plan spatial notre étude va porter essentiellement sur
l’ISP/Bukavu, précisément dans le service de gestion des ressources
humaines. Sur le plan temporel, ce travail s’étend de l’an 2016 à 2017, l’an
2016 en est le terminus ante quem et l’an 2017 en est le terminus post
quem.
A l’exception de l’introduction et de la conclusion, ce travail
appréhende cinq chapitres. Il aborde tour à tour, la revue de la littérature, la
présentation du milieu d’étude, l’approche méthodologique, la réalisation du
système d’information, et enfin nous avons parachevé par une discussion
des résultats et recommandations.
 6

CHAPITRE PREMIER

REVUE DE LA LITTERATURE

Deux sections principales bâtissent l’ossature de ce chapitre, une

section traitant de la revue théorique et une autre de la revue empirique.

I. REVUE THEORIQUE DE LA LITTERATURE

Nous proposons dans cette section les différentes définitions des

concepts pouvant faciliter la compréhension du travail, les principales
gaucheries de la reconnaissance de visage et en définitive nous parachevons
par quelques techniques de détection et reconnaissance de visage.

I.1. Définitions des concepts

I.1.1. Un logiciel
Dans son cours d’Ingénierie des systèmes logiciels, Marcelin Jilus
(2013, p.1) définit un logiciel comme étant un ensemble de programmes
informatiques (codes sources, éditables, exécutables) mais également les
données 2 qu’ils utilisent et les différents documents se rapportant à ces
programmes et nécessaires à leur installation, utilisation, développement et
maintenance : spécifications, schémas conceptuels, jeux de tests, mode
d'emploi, etc.
I.1.2. Reconnaissance faciale
La reconnaissance faciale est une opération qui est couramment
effectué sans concentration par l’être humain dans sa vie habituelle afin
d’identifier les autres à partir de leurs faces. La reconnaissance faciale, en
tant qu’une des technologies biométriques de base a pris une part de plus en
plus importante dans le domaine de la recherche, ceci étant dû aux avances
rapides dans des technologies telles que les appareils photo numériques,
Internet et les dispositifs mobiles, le tout associé à des besoins de sécurité
sans cesse en accroissement (BOUDJELLAL Sofiane ; 2010, p.12).

2 Le Jargon Informatique définit les données comme étant des informations de nature
numérique ou alphanumérique, représentées sous forme codée en vue d'y être enregistrées,
traitées, conservées et communiquées et qui sont compréhensibles par la seule machine.
 7

Cette technologie possède plusieurs avantages sur les autres

technologies biométriques car elle est naturelle, non intrusive et facile à
utiliser.

I.2. Système de reconnaissance faciale

Un système de reconnaissance faciale est celui qui est habile
d’identifier des visages présents dans une image ou une vidéo de manière
automatique. Le système peut fonctionner dans les deux modes suivants :
authentification3 ou Identification4.
Un système de reconnaissance de visage peut être considéré comme
composé de 4 lots (figure 3) :

Figure N° 3 : Schéma général d'un système de reconnaissance de visage (Walid Hizem ;

2009, p.10)
I.2.1. Capture
Cette étape consiste acquérir les informations (images) et les transférer
vers l’unité de traitement. Elle est une étape très cruelle dans les systèmes
de reconnaissance. En effet, avoir des images de bonne qualité en référence
améliore les performances de reconnaissance. Il faut réussir à capter
l'information pertinente sans bruit. Il existe plusieurs types de capteurs
pour l'acquisition du visage qui se classe selon leur mode de fonctionnement,
leurs domaines de sensibilité spectrale et leur mode d'acquisition. On trouve
sur le marché les capteurs classiques d'image à 2D 5 tels que : les CCD
(Couple charged device) ou CMOS pour capturer des images dans le spectre
visible et/ou proche-infrarouge, ou les capteurs thermiques qui permettent
une acquisition dans l'infrarouge. Il existe des capteurs qui nous donnent

3 Opération par laquelle le destinataire et/ou l'émetteur d'un message s'assure de l'identité de son interlocuteur
4 Opération par laquelle on transmet son identité pour que le destinateur puisse en faire connaissance
5 Deux dimensions. Caractéristique de ce qui est désespérément plat. Exemple : l'écran d'un ordinateur
 8

une image avec l'information 3D6, cela se fait par des scanners 3D, où la
mesure de la profondeur est réalisée grâce à un rayon laser balayant la
scène ou par stéréo vision. Chaque type de capteur présente des avantages
et des inconvénients. Dans la reconnaissance de visage on peut utiliser les
capteurs 3D par exemple pour s'affranchir des problèmes de pose. Mais leur
prix excessif ne permet pas une utilisation à grande échelle. Les capteurs en
proche infrarouge sont utilisés pour éliminer les problèmes de l'illumination
(Walid Hizem ; 2009, p.10). Dans le cadre de ce travail, nous avons effectué
nos tests de capture avec la webcam de notre ordinateur ;
I.2.2. Détection du visage
Après avoir capturé l’image contenant un visage, la deuxième étape
consiste à l'extraire de l'image. Cela peut se faire par détection de la couleur
de la peau, ou par des méthodes détectant les différentes caractéristiques du
visage par des descripteurs locaux. Cette étape est autant plus délicate
pareillement que l'image acquise contient plusieurs objets de visage ou un
fond non uniforme qui crée une texture perturbant la bonne segmentation
du visage. Cette étape est dépendante de la qualité des images acquise.
Après la segmentation du visage, on peut filtrer ou améliorer la qualité par
des prétraitements qui sont appliqués au visage extrait. On peut effectuer
des normalisations géométrique et photométrique. Ces prétraitements sont
nécessaires pour éliminer ou limiter les variations de pose ou d'illumination.
Un prétraitement photométrique tend à uniformiser l'éclairage dans une
image et ainsi minimiser l'influence de l'illumination. Cela peut être effectué
soit par des méthodes simples telle que l'égalisation d'histogramme, une
correction gamma ou par des méthodes plus complexes tel que le lissage
anisotropique ou la méthode retinex. Une normalisation géométrique est un
ajustement du visage pour qu'il ait une dimension donnée et qu'il soit
horizontal. La taille du visage est généralement donnée par la distance
interoculaire (Walid Hizem ; 2009, p.11). La figure N°4 montre la

6 Trois dimensions. L'espace physique commun, avant Einstein. Quand on parle de quelque chose en « 3D », c'est pour
indiquer que l'image affichée donnant une impression de relief, vue à l'écran, est une projection d'un monde
tridimensionnel calculé... sauf quand il ne s'agit que d'une illusion d'optique, comme pour les contrôles en 3D des
interface graphiques.
 9

normalisation des histogrammes (photométrique) et la figure N°5 nous

montre également la normalisation géométrique.

Figure N°4 : (a) Image RGB (b) Image en gris (c) Egalisation des histogrammes
(BOUDJELLAL Sofiane ; 2010, p.27)

Figure N°5 : Normalisation géométrique du visage (Walid Hizem ; 2009, p.11)

L’objectif de tous ces prétraitements est d’affaiblir le taux de rejet ou
de fausse reconnaissance dans le système.
I.2.3. Extraction des caractéristiques
Après avoir détecter le visage, le système va extraire les
caractéristiques du visage, suivant un algorithme donné, les stocker dans
une base de données ou dans un fichier (tout dépend de l’algorithme utilisé)
afin de s’en servir lors de la prochaine capture. Cette étape est celle qu’on
qualifie d’apprentissage pour le système.
Par ailleurs, plusieurs études ont été menées afin de déterminer
les caractéristiques qui semblent adéquates pour la perception, la
mémorisation et la reconnaissance d’un visage humain. Selon V. Bruce
(1988) cité par SOUHILA GUERFI ABABSA (2008, p.18), les caractéristiques
pertinentes rapportées sont : les cheveux, le contour du visage, les
yeux et la bouche. Cette étude a également démontré le rôle important
que joue le nez dans la reconnaissance faciale à partir des images de
profil. En effet, dans ce cas de figure, il est évident que la forme distinctive
 10

du nez est plus intéressante que les yeux ou la bouche dit V. Bruce. Dans
Studies of cue saliency de J.W. Shepherd et alii (1981) cité par SOUHILA
GUERFI ABABSA (2008, p.18), les auteurs ont particulièrement établi que
la partie supérieure du visage est plus utile pour la reconnaissance
faciale que la partie inférieure ;
I.2.4. Comparaison des caractéristiques
Selon les caractéristiques extraites précédemment, les algorithmes de
comparaison dont nous allons découvrir dans les lignes qui suivent diffèrent.
On trouve dans la littérature plusieurs approches : calcul de distance, calcul
de similarité. D'autres méthodes reposent sur la classification des
caractéristiques par un seul classifieur ou par plusieurs.
La problématique de la reconnaissance de visage est celle des
variations intra classe. En effet, les variations d'illumination, de pose ou
d'expression détériorent les performances d'un algorithme de
reconnaissance. Le visage d'une personne X peut ressembler plus à celui
d'une personne Y qu'à lui-même si l'on change les conditions d'acquisition.
Cela étant, nous allons présenter les principales difficultés de la
reconnaissance de visage.

I.3. Principales difficultés de la reconnaissance de visage

Pour ce qui concerne les humains, la reconnaissance de visage est une
tâche de vision de haut niveau. Bien que les humains puissent détecter et
identifier les visages dans une scène sans beaucoup d’affliges, réaliser une
application informatique de ce genre n’est pas une tâche facile. Cette
difficulté est beaucoup plus grande lorsque les conditions d’acquisition des
images ne sont pas immobiles. Il existe deux types de variations agrégées
aux images de visages : inter et intra sujet. La variation inter sujet est
limitée à cause de la ressemblance physique entre les individus. Par contre
la variation intra sujet est plus complexe. Elle peut être livrée à plusieurs
facteurs que nous analysons ci-dessous (SOUHILA GUERFI ; 2008, p.19).
I.3.1. Changement d’illumination
La variation de l’éclairage lors de la capture des images de visages rend
la tâche de la reconnaissance plus ardue (voir figure N°6). En effet, la
mutation d’apparence d’un visage due à l'illumination, se révèle parfois plus
 11

critique que la différence physique entre les individus, et peut entraîner une
mauvaise classification des images d'entrée (SOUHILA GUERFI ABABSA ;
2008, p.19). Jusque là, l'identification de visage dans un environnement non
contrôlé reste donc un domaine de recherche aéré.

Figure N°6 : Exemple de variation d’éclairage

I.3.2. La variation de pose
Lors qu’une image présente une variation de pose (voir figure N°7)
éminente, le taux de reconnaissance baisse (SOUHILA GUERFI ABABSA ;
2008, p.20). La variation de pose est contemplée comme un problème majeur
pour les systèmes de reconnaissance faciale ; une rotation supérieure à 30°
ne peut même pas permettre à l’application de détecter la face dans la vidéo.
Cette difficulté a été constatée à partir des tests d’évaluation raffinés sur
notre application.

Figure N°7 : Exemple de variation de pose

I.3.3. Expressions faciales
Un autre facteur qui pontifie l’apparence du visage est l’expression
faciale (voir figure N°8). La déformation du visage qui est due aux
expressions faciales est localisée principalement sur la partie inférieure du
visage. L'information faciale se situant dans la partie supérieure du visage
reste quasi invariable. Elle est généralement suffisante pour effectuer une
identification (SOUHILA GUERFI ABABSA ; 2008, p.20). D’après les
expériences que nous avons acquises, les librairies comme OpenCV et
OpenIMAJ que nous avons eu à expérimenter étaient trop sensible sur la
question des expressions faciales tandis que la librairie Luxand FaceSDK
que nous utilisons à présent résout déjà quasiment ce problème.
 12

Figure N°8 : Exemple de variation d’expressions

I.3.4. Présence ou absence des composants structurels
La présence de la barbe, la moustache, ou bien les lunettes peut
modifier énormément les caractéristiques faciales telles que la forme, la
couleur, ou la taille du visage. Le port des lunettes opaques par exemple
pose des difficultés lors de la détection du visage dans un flux vidéo voir
même dans une photo car le système ne saura plus distinguer la forme et la
couleur des yeux (SOUHILA GUERFI ABABSA ; 2008, p.20).
I.3.5. Occultation partielles
On parle de l’occultation partielle lors que le visage est masqué par un
objet dans le flux vidéo ou par le port d’accessoire tels que l’écharpe,
lunette,…. Dans le contexte de la biométrie, les systèmes proposés
doivent être non intrusifs c’est-à-dire qu’on ne doit pas compter sur une
coopération active du sujet. Par conséquent, il est important de savoir
reconnaître des visages partiellement occultés (SOUHILA GUERFI
ABABSA ; 2008, p.21).
Partant de ce qui précède, nous avons remarqué que la reconnaissance
de visage suscite de plus en plus l’intérêt de la communauté scientifique,
car elle présente plusieurs challenges et verrous technologiques. Par ailleurs,
en ce qui concerne notre application, nous essayerons de faire une
coopération avec le sujet sur des aspects comme par exemple la position
devant la caméra, le port des lunettes et certains objets menant vers une
occultation ; car dit-on, nous n’avons pas résolu tous les problèmes de la
reconnaissance faciale. Les techniques7 utilisées aux différentes étapes de la
reconnaissance de visage sont détaillées dans la sous section suivante.

7 Algorithmes
 13

I.4. Algorithmes de détection et de reconnaissance de visage

Dans la présente sous section, nous allons arborer quelques algorithmes
utilisées dans les étapes de la reconnaissance de visage comme nous les
avons détaillés dans la première sous-section. Dans cette dernière, nous
découvrirons un état de l’art sur les techniques de détection de visage et
enfin nous ferons un coût d’œil sur les méthodes de reconnaissance de
visage 2D et 3D.
I.4.1. Détection de visage
Selon BOUDJELLAL Sofiane (2010, p.28), une image du visage est un
signal à deux dimensions acquis par un capteur digital (caméra numérique,
scanneur…). Etant la première étape dans le processus de reconnaissance
faciale, son efficacité a une influence directe sur les performances de ce
système. Il existe plusieurs méthodes pour la détection de visages, certaines
utilisent la technique basée sur la couleur de la peau, la forme de la tête,
l’apparence faciale, alors que d’autres combinent plusieurs de ces
caractéristiques.
Ming-Hsuan Yang et alii (2002) cité par SOUHILA GUERFI
ABABSA (2008, p.22) subdivise les méthodes de détection de visage en cinq
catégorie suivantes :

Approches basées sur les connaissances acquises ;

Approches basées sur le « Template-matching » ;
Approches basées sur l’apparence ;
Approches basées sur des caractéristiques invariantes ;
Détection de visages basée sur l’analyse de la couleur de la peau.

I.4.1.1. Approches basées sur les connaissances acquises

Ces approches sont conçues singulièrement pour la localisation de
visage. Elles s’intéressent aux parties caractéristiques du visage comme le
nez, la bouche et les yeux. Elle est basée sur la définition de règles strictes à
partir des rapports entre les caractéristiques faciales.
 14

I.4.1.2. Approches basées sur le « Template-Matching »

Les Templates peuvent être définis soit "manuellement", soit
paramétrés à l'aide de fonctions. L’idée est de calculer la corrélation entre
l'image candidate et le Template. Ces méthodes rencontrent encore quelques
problèmes de robustesse liés aux variations de lumière, d'échelle, etc. Sinha
(1994, pp.1735-1740) utilise un ensemble d’invariants décrivant le modèle
du visage. Afin de déterminer les invariants aux changements de
luminosité permettant de caractériser les différentes parties du visage (telles
que les yeux, les joues, et le front); cet algorithme calcule ainsi les rapports
de luminance entre les régions du visage et retient les directions de ces
rapports (par exemple, la région 1 est elle plus claire ou plus sombre que la
région 2). La figure N°9 montre un modèle prédéfini correspondant à 23
relations. Ces relations prédéfinies sont classifiées en 11 relations
essentielles (flèches) et 12 relations confirmations (gris). Chaque flèche
représente une relation entre deux régions.
Une relation est vérifiée si le rapport entre les deux régions qui lui
correspond dépasse un seuil. Le visage est localisé si le nombre de relations
essentielles et de confirmation dépasse lui aussi un seuil.

Figure N°9 : Modèle de visage composé de 16 régions (les rectangles) associées à 23

relations (flèches). Sinha (1994)
I.4.1.3. Approches basées sur l’apparence8
Ces approches appliquent généralement des techniques
d'apprentissage automatique. Ainsi, les modèles sont appris à partir d'un
ensemble d'images représentatives de la variabilité de l'aspect facial. Ces
modèles sont alors employées pour la détection. L'idée principale de ces
méthodes est de considérer que le problème de la détection de visage est un

8C’est cette approche qui est utilisée dans la librairie de reconnaissance faciale de notre
projet
 15

problème de classification (visage, non-visage). Une des approches les plus

connues de détection de visage est l’Eigenface (M. Turk and A. Pentland ;
1991, pp.71-86), elle consiste à projeter l’image dans un espace et à calculer
la distance euclidienne entre l’image et sa projection. En effet, en codant
l’image dans un espace, on dégrade l’information contenue dans l’image,
puis on calcule la perte d’information entre l’image et sa projection. Si cette
perte d’information est grande (évaluée à partir de la distance, que l’on
compare à un seuil fixé a priori), l’image n’est pas correctement représenté
dans l’espace : elle ne contient pas de visage. Cette méthode donne des
résultats assez encourageants, mais le temps de calcul est très important.
Une méthode bien connue de détection d’objets complexes tels
que les visages est l’utilisation de « classifieurs de Haar » montés en
cascade (boostés) au moyen d’un algorithme AdaBoost. Cette méthode est
implémentée nativement dans la bibliothèque OpenCV (2005) et a été
présenté initialement dans Viola et Jones (2001). Le principe de cette
méthode est obtenir un algorithme complexe de classification, composé
de classifieurs élémentaires qui éliminent au fur et à mesure les zones de
l’image qui ne sont pas compatibles avec l’objet recherché. Ces classifieurs
binaires reposent sur des primitives visuelles qui dérivent des fonctions de
Haar (Haar- like features). Signalons que la librairie de reconnaissance
faciale utilisée dans ce mémoire utilise cette approche pour détecter les
faces.
I.4.1.4. Approches basées sur des caractéristiques invariantes
Ces approches sont utilisées principalement pour la localisation de
visage. Les algorithmes développés visent à trouver les caractéristiques
structurales existantes même si la pose, le point de vue ou la condition
d'éclairage changent. Puis ils emploient ces caractéristiques invariables pour
localiser les visages. Nous pouvons citer deux familles de méthodes
appartenant à cette approche : Les méthodes basées sur la couleur de la
peau qu’on détaillera dans la section suivante, et les méthodes basées sur
les caractéristiques de visage; elles consistent à localiser les cinq
caractéristiques (deux yeux, deux narines, et la jonction nez/lèvre) pour
décrire un visage typique (SOUHILA GUERFI ABABSA ; 2008, p.27).
 16

I.4.2. Technique 2D de reconnaissance de visage

Comme nous l’avons dit dans les lignes antérieures, la reconnaissance
de visage est un axe de recherche ouvert et qui attire plusieurs chercheurs
venant des disciplines différentes ; c’est ainsi que, durant les 20 dernières
années plusieurs méthodes d’identification de visage ont été proposées. Dans
cette partie, nous présenterons les approches 2D de la reconnaissance de
visage les plus connues. Ces dernières peuvent être subdivisées en trois
catégories : les approches holistiques ou globales, les approches locales et
les approches hybrides.
I.4.2.1. Approches holistiques ou globales
Comme leurs noms l’indiquent, ces méthodes consistent à faire de la
reconnaissance en accomplissant des analyses sur l’image en entièreté.
Chaque image de visage de dimension (n, m) est représentée par un vecteur
simple de dimension n x m, en concaténant les valeurs du niveau de gris de
tous les pixels de l’image du visage.
Par exemple une image 100x100 doit être représentée par un vecteur
de dimension 104 (Duin ; 1995, p.958). Etant donné que le nombre d’images
d’apprentissage pour chaque personne doit être au moins égal à dix fois
la dimension du vecteur (Jain, B. Chandrasekaran ; 1982, pp.835-855), il
faut 105 images par personne, nombre assez exorbitant. En pratique, on
n’a pas besoin de tant de photos pour développer un modèle fidèle pour
l’apparence du visage d’une personne. Des techniques de réduction de
dimension sont généralement employées. Une des techniques les plus
utilisées dans l'identification de visage est l'Analyse en Composantes
Principales (ACP).
Une méthode très populaire, basée sur la technique ACP, est la
méthode « eigenface » (L. Sirovich et M. Kirby ; 1987, pp.519-524). Son
principe est le suivant : étant donné un ensemble d’images de visages
exemples, il s’agit tout d’abord de trouver les composantes principales de ces
visages. Ceci revient à déterminer les vecteurs propres de la matrice de
covariance formée par l’ensemble des images exemples. Chaque visage
exemple peut alors être décrit par une combinaison linéaire de ces vecteurs
propres. Pour construire la matrice de covariance, chaque image de visage
 17

est transformée en vecteur. Chaque élément du vecteur correspond à

l’intensité lumineuse d’un pixel.
Dans Unified subspace analysis for face recognition (X. Wang et X.
Tang ; 2003) cité par SOUHILA GUERFI ABABSA (2008, p.39), les auteurs
ont démontré que la matrice de covariance C peut s’écrire :
= + (eq.3)
C'est-à-dire qu’elle est égale à la somme de la matrice de dispersion
intra-personne CI et la matrice de dispersion inter-personne CE. Dans le cas
d’un seul exemple d'apprentissage par personne, CI= 0, et donc l’équation (3)
se réduit à C=CE.
L'eigenspace estimé à partir de la matrice CE seulement n'est pas
fiable, parce qu’il ne peut pas différencier, de manière efficace, l’erreur
d’identification des autres erreurs dues à la transformation et au bruit (X.
Wang et X. Tang ; 2003) cité par SOUHILA GUERFI ABABSA (2008, p.39).
Pour illustrer l’influence du nombre d’exemples d’apprentissage par
personne sur les performances de la reconnaissance, les auteurs ont
utilisé la base de données ORL (F. Samaria et A. Harter ; 1994) cité par
SOUHILA GUERFI ABABSA (2008, p.39) comme base de test. La base de
données ORL contient des images de 40 individus, chacun étant enregistré
sous 10 vues différentes. Dans leur expérimentation, les auteurs ont fixé le
nombre de visages de test. Par contre, ils ont fait varier le nombre de visages
d'apprentissage. Ainsi, pour chaque personne, ils ont utilisé la dernière
image (Figure N°10) pour le test et ont choisi aléatoirement les n premières
images (n <= 9) pour l'apprentissage.

Figure N°10 : Les 10 vues d’une personne dans la base de données ORL
 18

Figure N°11 : Taux d’identification moyen en fonction du nombre d’exemple

d’apprentissage par personne (X. Wang et X. Tang ; 2003)
Ce graphique nous montre que la performance de la méthode eigenface
baisse avec la diminution du nombre d’exemple d’apprentissage par
personne. C’est ainsi donc, en utilisant un seul exemple d’apprentissage, le
taux d’identification est moins de 65% tandis qu’en utilisant neuf exemples
le taux d’identification est de 95%.

Discussion
Bien que les méthodes holistiques aient eu beaucoup de triomphe, leur
inconvénient majeur réside dans le fait qu’elles utilisent uniquement des
photos 2D d’apparence faciale. Or, on sait qu'une telle représentation est
sensible aux mutations d'expression, d'illumination et de poses. Lors de
l’expérimentation que nous avons accomplie avec la librairie OpenIMAJ en
utilisant eigenface, nous nous sommes heurtés à plusieurs problèmes
attachés à l’illumination, poses et expressions faciales ; une chose qui est
plus tragique pour une application intégrant la gestion des présences. Cela
étant, une manière d’éviter ce problème consiste à utiliser des
représentations faciales locales. En effet, les caractéristiques locales ne sont
généralement pas aussi sensibles aux changements d’apparence que les
caractéristiques globales.
 19

I.4.2.2. Approches locales

Les méthodes locales utilisent les caractéristiques faciales locales pour
la reconnaissance de visage. Elles sont relativement matures comparées
aux méthodes holistique (SOUHILA GUERFI ABABSA ; 2008, p.45). Dans ces
méthodes, le visage est représenté par un ensemble de vecteurs
caractéristiques de dimensions faibles, plutôt que par un seul vecteur de
grande dimension.
Nous pouvons classifier les méthodes locales en deux catégories : les
méthodes basées sur les caractéristiques locales : extractions et localisation
des points caractéristiques, et les méthodes basées sur les apparences
locales : partitions des images de visage en région caractéristiques.
I.4.2.2.1. Méthodes basées sur les caractéristiques locales
Les méthodes basées sur les caractéristiques locales, quant à eux
aussi, sont désynchronisées en deux catégories : les approches géométriques
et les approches basées sur les graphes.
I.4.2.2.1.1. Approches géométriques9
Comme nous l’avons dit antérieurement, elles sont basées sur
l’extraction de la position relative des éléments qui constituent le visage (tel
que le nez, la bouche et les yeux). La multitude des approches
géométriques utilisent des points d'intérêt (comme les coins de la bouche
et des yeux). Au début des années 1990, Brunelli et Poggio (1993) cité par
SOUHILA GUERFI ABABSA (2008, p.45) ont décrit un système de
reconnaissance faciale qui extrait automatiquement 35 caractéristiques
géométriques du visage. La similitude est calculée à l’aide de classifieurs de
Bayes. Un taux d'identification de 90 % sur une base de données de 47
sujets a été rapporté par les auteurs. Par ailleurs, la librairie de
reconnaissance faciale que nous avons utilisé (Luxand FaceSDK) extrait 70
points caractéristiques géométrique du visage (Luxand FaceSDK 6.0 ; 2016,
p.50). Le coût de stockage des techniques géométriques est très bas
comparé à celui des autres techniques. Toutefois, les approches purement
géométriques présentent quelques inconvénients, notamment :

9 Notre application utilise une approche locale géométrique

 20

les caractéristiques géométriques sont généralement difficiles à

extraire, surtout dans des cas complexes : illumination variable,
occultations, etc.
les caractéristiques géométriques seules ne suffisent pas pour
représenter un visage, tandis que d'autres informations utiles comme
les niveaux de gris de l'image ne sont pas du tout exploitées.

I.4.2.2.1.2. Approches basées sur les graphes

Au lieu que d’utiliser des méthodes franchement géométriques,
certains chercheurs ont choisi de représenter les caractéristiques locales du
visage sous forme de graphes. Manjunath et al. (1992) cité par SOUHILA
GUERFI ABABSA (2008, p.46) ont proposé une méthode de détection de
caractéristiques locales du visage, basée sur la décomposition en ondelettes
de Gabor (T.S. Lee ; 1996). L'efficacité de cette méthode a été validée sur un
ensemble de données de visage de 86 sujets, contenant des variations
d'expression et de pose, Un taux de reconnaissance de 90% en moyenne a
été rapporté démontrant la robustesse de cette approche.
Les méthodes basées sur les caractéristiques locales sont
efficaces. Cependant leurs performances dépendent essentiellement de la
précision de la localisation des points caractéristiques. Cette tâche reste
très difficile en pratique, plus particulièrement dans des situations où la
forme et l'apparence du visage peuvent fortement changer. Par exemple, la
sur-illumination peut provoquer une réflexion spéculaire sur le visage.
Pour résoudre ce problème des méthodes basées sur l’apparence locale sont
utilisées. Elles font l’objet de la section suivante.
I.4.2.2.2. Méthodes basées sur l’apparence locale (Local appearance-
based methods)
Ces techniques sont utilisées de manière modulaire pour les
différentes régions faciales. Un modèle global est alors défini à partir de la
combinaison des différents modèles locaux. Ainsi, les différentes régions
faciales ne seront plus affectées de la même manière par les différentes
sources de variabilité. Par exemple, le port de lunettes de soleil change
considérablement l’aspect des yeux, tandis qu’un sourire affecte plus
la région de la bouche. Deux paramètres sont utilisés pour définir les régions
 21

locales du visage : la forme (rectangle, ellipse) et la taille. Les caractéristiques

des régions locales sont déterminées à partir d’une analyse des valeurs de
niveau gris (S.C. Chen ; 2004). Des techniques comme les Ondelettes de
Gabor (B. Kepenekci ; 2002) ou de Harr et l’analyse fractale sont aussi
Utilisées pour l’extraction de caractéristiques. En général, les
caractéristiques à base de valeurs de gris préservent l'information de texture,
tandis que les caractéristiques de Gabor sont plus robustes face aux
changements d’illumination et aux transformations géométriques (B.S.
Manjunath ; 1992).
Discussion
Nous avons passé en inspection les quelques méthodes locales traitant
le problème de la reconnaissance de visages dans le cas d’un seul exemple
d’apprentissage. Nous les avons classifiés en deux catégories principales : les
méthodes à base de caractéristiques et les méthodes basées sur l’apparence
locale. En réalité, ces deux concepts ne sont pas si distincts car les régions
locales sont constituées d’un ensemble de pixels parmi lesquels des points
caractéristiques intéressants peuvent être détectés.
Bien que les méthodes locales aient prouvé leur efficacité dans le cas
d’un seul exemple d’apprentissage, plusieurs problèmes restent toujours non
résolus, comme par exemple le choix des caractéristiques locales qui n’est
pas du tout évident. De plus, les méthodes locales sont robustes uniquement
vis-à-vis d’un nombre restreint de facteurs de variations.
Une voie possible pour améliorer la robustesse d'un système de
reconnaissance de visages peut résider dans les méthodes hybrides qui
combinent différentes techniques de reconnaissance.
I.4.2.3. Approches hybrides
Les méthodes hybrides permettent d’associer les avantages des
méthodes globales et locales en combinant la détection de caractéristiques
géométriques (ou structurales) avec l’extraction de caractéristiques
d’apparence locales. Elles permettent d’augmenter la stabilité de la
performance de reconnaissance lors de changements de pose, d’éclairage et
d’expressions faciales. L’analyse de caractéristiques locales (LFA) (P. Penev
and J. Atick ; 1996) cité par (BOUDJELLAL Sofiane ; 2010, p.16) et les
 22

caractéristiques extraites par ondelettes de Gabor (comme l’Elastic Bunch

Graph Matching, EBGM), sont des algorithmes hybrides typiques.
Plus récemment, l’algorithme Log Gabor PCA (LG-PCA) (V. Perlibakas ;
2005) cité par BOUDJELLAL Sofiane (2010, p.16) effectue une convolution
avec des ondelettes de Gabor orientées autour de certains points
caractéristiques du visage afin de créer des vecteurs contenant la
localisation et la valeur d’amplitudes énergétiques locales ; ces vecteurs sont
ensuite envoyés dans un algorithme PCA afin de réduire la dimension des
données.
I.4.3. Techniques 3D de reconnaissance de visage
Nous avons passé en inspection les méthodes de reconnaissance
2D de visages. Malgré les avancées réalisées ces dernières années, les
techniques de reconnaissance 2D de visages robustes aux différents facteurs
de variabilité (éclairage, pose, occultation) sont loin d’être développées. La
reconnaissance 3D de visages constitue une alternative prometteuse pour
surmonter ces problèmes, surtout depuis l’apparition de dispositifs
d’acquisition 3D performant. L'avantage principal des approches basées
modèle 3D réside dans le fait que le modèle 3D conserve toutes les
informations sur la géométrie de visage, ce qui permet d’avoir une
représentation réelle de ce dernier. Dans le cadre de ce travail, nous ne nous
sommes pas trop passionnés sur la technique 3D car notre travail révèle de
la technique 2D. Nonobstant, il ne serait pas sage d’ignorer leurs existence.

I.5. Conclusion partielle

Dans cette section nous avons évoqués l’ossature de la littérature
relative à la reconnaissance faciale en détaillant les algorithmes qui
interviennent dans chacune des étapes d’un Système de reconnaissance
faciale. Nous avons abordé des algorithmes pour la détection de visage dans
une image sellons différentes approches dont nous avons réussi à
désenvelopper. En plus de cela, nous avons discuté sur les algorithmes
consistant à extraire les caractéristiques du visage ainsi que la
reconnaissance, qui quant à eux étaient scindés en 3 approches. Les
approches holistiques ou globales, les approches locales ainsi que les
approches hybrides. Comme les autres auteurs l’ont certifié, les approches
 23

locales étaient plus prometteuses que les approches globales. Cela étant,
nonobstant le succès qu’ont connu les approches globales et leur
implémentation dans plusieurs API de reconnaissance faciale, dans le cadre
de notre travail, nous avons fait usage d’une librairie utilisant l’approche
basée sur l’apparence pour la détection des visages ainsi que l’approche
locale géométrique pour faire la reconnaissance.
 24

II. REVUE EMPIRIQUE DE LA LITTERATURE

Cette section essaye d’exposer quelques études empiriques qui ont été
menées dans différentes contrées et qui ont trait à ce sujet.

1. SOUHILA GUERFI ABABSA (2008) : Université Evry Val d’Essonne

Dans son travail de thèse, SOUHILA avait mené une étude sur
l’authentification des individus à l’aide de la reconnaissance faciale. Utilisant
la méthode ACP, son étude avait comme objectif de concevoir un système
d’authentification de visage simple et efficace. Il est arrivé au résultat en
développant une technique 2D de reconnaissance de visage basée sur
l’Analyse en Composant Principal qui prend en entrée, non pas l’image
entière du visage, mais les « imagettes » correspondant aux trois régions
caractéristiques du visage (le nez, les yeux et la bouche) et a réussi a
démontré que cette technique donnais des taux de reconnaissance aussi bon
que l’image complète.

2. Walid Hizem (2009) : Université Pierre et Marie currie de France

Dans son travail de thèse, Walid a mené une étude sur le capteur
intelligent pour la reconnaissance de visage. Etant beaucoup plus intéressé
par les problèmes liés à la lumière dans le domaine de reconnaissance
faciale, dans son travail, Walid s’est fixé comme objectif de mettre en place
une solution capable d’éliminer le problème lié à la luminosité. Pour y
arriver, Walid a utilisé l’illumination active avec deux méthodes
d’acquisition : la première avec un capteur CMOS différentiel, la seconde, et
qui a présenté son apport personnel dans son travail, une acquisition avec
réduction du temps d'exposition et un flash synchrone à la période
d'acquisition. Ainsi, comme résultat, il a mise au point une caméra CCD
permettant d'avoir des images de bonne qualité en proche infrarouge et à
moindre coût en éliminant la variation d’illimitation.
 25

3. BOUDJELAL Sofiane (2010) : UMMTO en Algérie

C’est avec la méthode Eigenface que BOUDJELAL Sofiane a travaillé sur

un système de reconnaissance faciale. Son travail avait comme objectif de
mettre en place un système permettant la reconnaissance d’individu et le
contrôle d’accès. Il a fini par développer une application qui malgré des bons
résultats qu’elle a apporté, il signale que certains problèmes comme celui de
pose et d’éclairage restent des challenges qui susciteront les efforts des
chercheurs.

4. Serge KOMANDA BASEMA (2010) : ISP/BUKAVU

Cet auteur a mené une étude sur l’identification des personnes par
reconnaissance de visage pour la sécurité d’une institution bancaire.
L’objectif de ce travail était celui d’offrir aux banques un système de contrôle
par caméras de surveillance et ces dernières assistées par une application de
détection et reconnaissance faciale (des visages) afin que les figures
capturées puissent subir de suivi en cas d'espionnage, d'escroquerie et de
braquage. En utilisant la méthode EigenFace avec la librairie OpenCV, il est
arrivé à un résultat de mise en place d’une application de reconnaissance
faciale qui ne s’est limité qu’au stockage des images sur disque dur à
condition que le visage ne soit pas encore dans la base.

5. Kalghoum ANWAR (2011) : Institut Supérieur d’Informatique et de

Gestion de Kairouan du Tunisie

Dans son travail portant sur la réalisation d’une application de gestion

des présences via la reconnaissance faciale, Kalghoum s’est fixé comme
objectif de faire l’étude, la conception et la mise en œuvre d’un système
informatisé de gestion des présences via la technologie de reconnaissance
faciale pour la société SIEREEN du Tunisie. A l’aide du duo JAVA-Access, Il
avait mis au point un système qui permettait à l’agent, lorsqu’il arrive au
travail, il se présente devant un ordinateur, on lui capture la photo afin de
pointer la présence. Signalons que l’auteur n’a pas été claire sur la
méthodologie utilisée ni au niveau de la reconnaissance faciale qu’au niveau
 26

même de la modélisation informatique. Tout de même nous avons vu

important de lui citer car tout d’abord son travail porte le même titre que le
notre et en plus parce que peut être son travail peut nous servir afin
d’améliorer le notre car on a toujours dit qu’il n’existe pas un travail parfait.

6. Varun JAIN (2011) : Université de GRENOBLE

Varun JAIN a orienté son étude sur la reconnaissance des émotions à

partir du visage. Son travail avait comme objectif de développer des
méthodes et des techniques permettant d’inférer l’état affectif d’une personne
à partir des informations visuelles, c'est-à-dire l’analyse d’expressions du
visage. Dans ses démarches, il avait utilisé l’approche Gaussienne Multi-
Echelle en tant que scripteur d’image pour l’estimation de la pose de la tête,
pour la détection de sourire, puis aussi pour la mesure de l’affect. En plus
de cette approche, il avait tout de même aussi utilisé l’Analyse en
Composant Principal pour la réduction de la dimensionnalité et les machines
à support des vecteurs pour la classification et les régressions. Lors de ses
expérimentations, Varun JAIN a constaté que dans le cas d’un éclairage
partiel du visage, les dérivées Gaussiennes multi-échelle ne fournissaient
pas une description d’image suffisamment discriminante. Pour résoudre ce
problème il avait combiné des dérivées Gaussiennes avec des histogrammes
locaux de type LBP (Local Binary Pattern). Avec cette combinaison il avait
obtenu des résultats à la hauteur de l’état de l’art pour la détection de
sourire dans le base d’images GENKI qui comporte des images de personnes
trouvées "dans la nature" sur internet, et avec la difficile "extended YaleB
database".

7. M.BELAHCENE-BENATIA Mébarka (2014) : Revue science des

matériaux

Dans son article, Mébarka avait le but de concevoir un système

d’authentification d’identité qui serait facile et peux couteux dans
l’implémentation utilisant le visage humain. Cette étude menée avec la
méthode ACP et la classification avec le réseau de neurones avait comme
objectif de vouloir minimiser le TEE (Taux d’erreur égale) afin de renforcer les
 27

capacités d’une application de reconnaissance faciale. Mébarka abouti aux

résultats selon lesquels en utilisant la classification d’ACP il a un taux
d’erreur égale (TEE=11.5%) sur une base de données de 40 sujets avec un
TFA (Taux de Fausse Acceptation) égal à 9% et un TFR (Taux de Faux rejet)
égal à 15.32%. En faisant la classification avec le réseau de neurones, TFA=
5% ; TFR=57 pour une base de données de 60 sujets et avec la
normalisation TFA=12 et un TFR=23 pour la même base de 60 sujets.
Tableau N°1 : Synthèse des résultats empiriques
N° Auteurs Méthode Principaux résultats
1
SOUHILA GUERFI Développement d’une technique 2D de
ABABSA reconnaissance de visage basée sur l’Analyse
(2008) en Composant Principal qui prend en entrée,
ACP non pas l’image entière du visage, mais les
« imagettes » correspondant aux trois régions
caractéristiques du visage (le nez, les yeux et
la bouche).

2 Walid Hizem
(2009) Acquisition avec Il a mise au point une caméra CCD
réduction du permettant d'avoir des images de bonne
temps qualité en proche infrarouge et à moindre
coût en éliminant la variation d’illimitation
3 BOUDJELAL
Sofiane (2010) Eigenface Développement d’une application de
reconnaissance faciale.

4 Serge KOMANDA
BASEMA (2010) Eigenface et Une application d’identification des individus.
Comparative

5 Varun JAIN
(2011) Lors de ses expérimentations, Varun JAIN a
constaté que dans le cas d’un éclairage partiel
L’approche du visage les dérivées Gaussiennes multi-
Gaussienne Multi- échelle ne fournissaient pas une description
Echelle et l’ACP d’image suffisamment discriminante. Pour
résoudre ce problème il avait combiné des
dérivées Gaussiennes avec des histogrammes
locaux de type LBP (Local Binary Pattern).

6 Kalghoum
ANWAR (2011) Méthode non Une application de gestion des présences
spécifiée dans le pour la société SIEREEN.
travail
7 M.BELAHCENE-
BENATIA Analyse en Une application de reconnaissance faciale
Mébarka Composant avec un TEE=11.5%
(2014) Principal et la
classification avec
le réseau de
neurones
Source : nos compilations
 28

Discussion
Nous venons de feuilleter certains travaux relatifs à la reconnaissance
faciale et nous avons eu comme initiale impression que presque tous ces
projets ont utilisés l’approche globale EigenFace pour réaliser leurs
applications. Comme nous l’avons gravé dans la revue théorique, la méthode
Eigenface est trop sensible aux problèmes d’expression faciale, de luminosité
et de pose. Cela étant, notre premier apport par rapport à ces travaux est
que notre travail utilise une approche locale géométrique basée sur 70 points
caractéristiques du visage afin de renforcer la robustesse de la
reconnaissance. Cette méthode est implémentée dans la librairie que nous
avons utilisé « Luxand FaceSDK ».
Par rapport au travail de Monsieur Kalghoum ANWAR qui a travaillé
sur un sujet presque similaire au notre par rapport à son titre ; son système
faisait le pointage de présence en capturant la photo manuellement et il
n’avait pas gérer l’enregistrement des sorties des agents. Une autre
originalité de notre travail se situe au niveau où notre système de pointage
se fait de manière automatique sans mécanisme de la part de l’agent et en
temps réel et qu’après une heure donnée, le système commence à enregistrer
la sortie. En plus, l’autre originalité par rapport au travail d’ANWAR est que
nous gérons même les congés des agents pour éviter qu’un agent qui ne fait
que passer devant la caméra soit considéré comme agent présent alors qu’il
est en congé. Nous avons aussi mis en place un algorithme pour différencier
une vraie personne et une photo devant la caméra (figure N°64) afin d’éviter
que notre système soit trompé plus tard. Indiquons enfin que nous avons
ajoutés dans notre application l’aspect de contrôle des entrées à l’ISP en
instaura un système de stockage des images des visiteurs avec la date et
l’heure d’entrée.
Il revient aussi important de souligner que le problème principal
attaqué dans ce mémoire n’est pas celui de la reconnaissance faciale mais
plutôt un problème de gestion manuelle des présences (figure N°1). Cela
étant, nous n’avons pas apporté des apports en termes de reconnaissance
faciale (exemple : correction d’un algorithme) mais plutôt nos apports ont été
apporté dans le cadre d’une bonne gestion des présences du personnel.
 29

Autrement, nous avons utilisé des algorithmes existants (implémentés dans

Luxand FaceSDK) tout en les adaptant seulement avec notre projet de
gestion des présences.

Conclusion Partielle

Au cours de ce chapitre, nous avons présenté la revue théorique ainsi

que la revue empirique de notre travail. La revue théorique avait comme
finalité de présenter certains concepts clés relatif à notre sujet. Nous avons
ainsi présenté quelques définitions mais aussi un état d’art sur la
reconnaissance faciale. La revue empirique quant à elle, nous a servi de
présentation de quelques travaux déjà réalisés correspondant ainsi avec
notre sujet. Cependant, après avoir présenté ces quelques travaux, nous
avons ensuite exhibé l’originalité de notre travail par rapport à ces travaux
déjà accomplis. Comme nous l’avons évoqué dans l’introduction, l’objectif de
ce travail est de réaliser une application de reconnaissance faciale pour la
gestion des présences des agents de l’ISP; cela étant, nous ne serions pas
capables d’y arriver sans faire recours aux informations relatives à cette
gestion au sein de l’ISP-Bukavu. En revanche, une étude de l’existant est
vraiment nécessaire afin de comprendre le fonctionnement de la gestion des
présences au sein de cette institution.
 30

CHAPITRE DEUXIEME

PRESENTATION DU MILIEU D’ETUDE

Dans le présent chapitre nous essayons de faire une brève
présentation de l’ISP-Bukavu qui est notre milieu d’étude. Nous allons faire
une étude du système existant pour essayer de comprendre le
fonctionnement actuel de la gestion de présence des agents au sein de cette
institution, en suite, nous allons faire une étude des documents utilisés
pour faire enfin une critique et une proposition de solution.

II.1. PRESENTATION DE L’ISP-BUKAVU10

II.1.1. Historique
L’ISP/Bukavu, jadis connu sous le nom d’« ESP » (Ecole Supérieure
Pédagogique), puis sous celui d’« ENM » (Ecole Normale Moyenne), tire ses
origines pendant la période tumultueuse caractérisée par les troubles
politiques où a été fondée l’école supérieure pédagogique, le 10 décembre
1964. Comme il se faisait sentir justement un besoin d’enseignant pour cette
nouvelle ère après l’indépendance de la RDC, où le secteur d’enseignement
ne dépendait que de l’extérieur en besoins des formateurs, le projet était
mieux adapté, mais ne comptait qu’une classe de préparatoire de 23
étudiants et une première année de l’option lettres de 22 étudiants. Poussé
toujours par l’esprit de mieux faire, l’ESP deviendra ENM en 1966 dotée de
deux options : l’option FRANÇAIS et l’option HISTOIRE.

En 1968, l’option Sciences Naturelles Géographie et une Ecole

d’Application vont s’ajouter et apporter un coup de pousse à l’ENM qui
disposera à la rentrée académique 1968-1969 d’un effectif total de 104
étudiants pour les différentes classes de trois options, et une classe de
préparatoire de 80 élèves pour les deux classes de la première année de
Cycle d’Orientation (C.O).

10 Archive de l’ISP-Bukavu
 31

L’année 1969 sera le commencement d’une nouvelle ère de

l’ISP/Bukavu, encore sous l’appellation ENM/BKV. C’est à partir de ce
moment que l’essor de l’ISP/BKV va s’intensifier en termes d’options, mais
aussi en termes d’infrastructures en bâtiments et en matériels didactiques.

Au début de l’année académique 1970-1971, l’ENM optera pour une

nouvelle dénomination, à l’occurrence celle de l’Institut Supérieur
Pédagogique de Bukavu qui demeure jusqu’à nos jours.

Les années 1970 à 1980 seront marquées par l’explosion remarquable dans
son développement. Cependant, l’essor de nouvelles universités privées à
Bukavu au milieu des années 90 n’a fait que diminuer l’hégémonie qu’il
portait dans le temps. Comme conséquence, l’ISP sombrait davantage, les
suspicions d’une fermeture éventuelle prenaient faute d’effectif suffisant
permettant son bon fonctionnement.

Ainsi, la création de deux départements, celui des Sciences

Commerciales et Administratives (SCA) et celui d’Informatique de Gestion
(IG) en 2000, va donner un nouveau souffle à l’ISP. Il y a de ce fait une
émergence en termes d’effectifs d’étudiants, mais aussi en termes de
diversification scientifique sur le nombre de départements.

Aujourd’hui l’ISP dispose de douze départements dont certains sont ajoutés

incessamment :

Français et Linguistique Africaine

Anglais et Culture Africaine

Biologie-Chimie

Chimie-Physique

Mathématique-Physique

Physique-Technologie

Histoire-Sciences-Sociales

Géographie-Sciences naturelles
 32

Psychopédagogie

Sciences Commerciales et Administratives

Informatique de Gestion

Hôtellerie, Tourisme et Accueil.

II.1.2. Missions de l’ISP-Bukavu

L’Institut Supérieur Pédagogique de Bukavu poursuit les missions
suivantes :

Doter le pays en fonction de ses besoins d’enseignants de très hauts

niveaux de formation générale et spécialisée aux qualités morales et
pédagogiques éprouvées ;
Susciter chez le futur enseignant une prise de conscience de son rôle
d’encadreur politique, le convaincre de la noblesse de sa mission et de
la dignité de sa personne ;
Organiser la recherche dans les domaines de la pédagogie en vue de
découvrir les méthodes susceptibles d’améliorer la qualité de
l’enseignement primaire et secondaire ;
Vulgariser les résultats de ces recherches par la rédaction et la
diffusion des manuels scolaires adaptés à ces deux niveaux
d’enseignement ;
Conférer les grades légaux conformément aux dispositions législatives
et réglementaires sur la collation de ces grades. Il livre des diplômes de
Gradué et de Licencié en Pédagogie Appliquée dans les Options qu’il
organise.
 33

II.1.3. Organigramme et Fonctionnement

Figure N° 12 : organigramme de l’ISP-Bukavu

 34

L’ISP/Bukavu dispose cinq organes permettant son bon fonctionnement

notamment :
- Le Conseil de l’Institut ;
- Le Comité de Gestion ;
- Le Directeur Général ;
- Le Conseil de Section ;
- Le Conseil de Département.

II.1.3.1. Le Conseil de l’Institut

Cet organe est chargé d’exécuter la politique académique et

scientifique de faire des propositions sur le développement des activités
académiques de l’ISP. Il peut aussi prendre des décisions relatives au
personnel : nomination, promotion et révocation du personnel académique,
enseignant et non enseignant,…
Ce conseil se réunit trois fois par an et exerce tous les pouvoirs
nécessaires à l’administration et au développement de l’institut. Il est
composé de :
Secrétaire Général Académique ;
Secrétaire Général Administratif ;
Administrateur du Budget ;
Chefs des Services ;
Conservateur en Chef ;
Représentant du Corps Académique ;
Représentant du Corps Scientifique ;
Représentant des Etudiants.

a) Secrétariat Général Académique

Secrétariat

Le secrétariat reçoit et enregistre les courriers, collectionne et

transmet les courriers destinés à la circulation interne de l’institut ; classe
rationnellement les correspondances et tous les autres documents traités ;
accueillie et règlemente les visites au bureau du SGAC et exécute les tâches
lui confiées par le responsable.
 35

Direction des Services Académiques

Bureau : il s’agit de bureau d’inscription, de contrôle de la scolarité et le

bureau unique enseignant, programme et gestion académique du personnel.
Le premier prépare les dossiers d’inscription à soumettre à la commission ad
hoc ; élabore les statistiques des étudiants. Le second gère les dossiers des
étudiants en cours de scolarité et les archives relatives à la scolarité des
étudiants. Vérifie l’authenticité des documents académiques et de tout autre
document à soumettre à la signature de l’instance supérieure ; élabore le
palmarès, rédige les diplômes et prépare les dossiers d’entérinement. Le
dernier élabore les listes du personnel académique et scientifique ; exploite
au premier échelon les PV, les rapports de section et département,…
Division : il y a la division enseignement et gestion du personnel et la
division inscription et scolarité ne sont pas en marche. Seules les directions
des services académiques collaborent avec les DCS pour toutes les activités
du secteur académique,…
Directeur Chef de Service

Assiste le SGAD dans la conception, gestion et contrôle de tout secteur

académique et exploite les rapports de département et sections et en dégage
la régularité des enseignants.

b) Secrétaire Général Administratif

Secrétariat

Reçoit et enregistre les courriers internes et externes au service

administratif ; rédige des lettres, notes de services, décisions et comptes
rendus des réunions du SGAD ; exécute toute tâche lui confiée par le SGAD
en rapport avec le fonctionnement du secrétariat,…

Direction du Personnel

Il s’agit de bureau de rémunération et gestion du personnel et bureau

des œuvres sociales. Le premier prépare les dossiers du personnel
administratif et technique, tient les statistiques de dépenses salariales, les
primes d’indemnités et des prestations supplémentaires et prépare la fiche
 36

de paie et le rapport de paie. Le second tient le registre des analyse

médicales et gère la pharmacie, établit les états des besoins et les soumet au
chef de Division des Affaires Sociales, etc.
Direction des Œuvres Estudiantine

Collabore avec le chef de service dans tous les problèmes concernant

les œuvres estudiantines ; reçoit et planifie l’exécution de tâches dévolues
aux divisions et vérifie la rédaction des rapports faite par les chefs de
division.
Directeur Chef de Service

Assiste l’Administrateur du Budget dans la conception, la gestion et le

contrôle des activités du secteur administration du budget même il assiste
l’autorité dans l’exploitation des rapports transmis par les directions.
c) Administrateur du Budget

Le secrétariat

Accueille et règlements les visites au bureau de l’AB et exécute toute

tâche lui confiée par l’AB.
Finances et budget
1. Direction Budget Contrôle

Assiste le Directeur des Finances et Budget dans les activités du

Budget Contrôle. Apprécie au premier ressort toutes les dépenses jugées
régulières ou irrégulière ainsi que toutes les créances régulières ou
irrégulières. Il signe les ordres de paiement, les mises à disposition des
fonds, les demandes d’achat et les ordonnances de régularisation. Il signe
aussi les bons de retrait et d’entrée des stocks au magasin central et
magasin-dépôt. Il ressemble les éléments pour l’élaboration des prévisions
budgétaires. Procède au contrôle des perceptions à soumettre au DCS via le
Directeur Financier, contrôle diverses régulations, élabore des documents
financiers et perception de prise en charge par le chef de bureau, etc. ;
 37

Bureau de trésorerie

S’occupe de la réception de la prime, de la tenue de la situation de la

caisse, de l’établissement et de la soumission des rapports mensuels de la
gestion financière au DCS via le Directeur Financier. Perçoit les frais divers,
il garde les chéquiers et remplit les chèques. Il délivre les bordereaux de
retrait et de versement à la caisse centrale, exécute le paiement des
ordonnances de paiement et des mises à disposition des fonds. Tient les
fiches comptables de caisse, de banques et celles de positionnement des
comptes en banque, il tient aussi les journaux de caisse, effectue les retraits
et versements des fonds en banque et il établit les bordereaux de retrait pour
les chèques.
Bureau comptable

S’occupe de la réception des loyers des étudiants, de la soumission des

prévisions budgétaires au DCS suivies des avances et des remboursements,
et le comptable fait des imputations et grands-livres et procède au paiement
des agent-bureau.
Caisse

Le caissier perçoit les frais divers : attestions et autres documents

académiques ; procède au versement et retrait caisse et aussi au classement
des documents financiers, paie la prime du personnel et les frais divers.
2. Direction du patrimoine
Elle collabore avec le directeur chef de service dans toutes les
questions relatives au patrimoine et à la production. Les détails voir chapitre
deuxième qui parle du patrimoine de l’ISP/BUKAVU.

II.1.3.2. Le Comité de Gestion

Cet organe comprend :

le Directeur Général (DG) ;
le Secrétaire Général Académique(SGAC) ;
le Secrétaire Général Administratif (SGAD) ;
l’Administrateur du Budget (AB).
 38

Il est chargé d’assurer la gestion courante de l’ISP sous les directives

du chef d’établissement à ce titre, il exécute les décisions du département de
l’Enseignement Supérieur et de la Recherche Scientifique, du Conseil
d’Administration, du Conseil de l’ISP et prend toutes les mesures qui ne
relèvent pas de la compétence d’un autre organe. Il se réunit au moins une
fois par semaine, exerce tous les pouvoirs que les autorités lui attribuent et
assure l’exécution des décisions du Conseil d’Institut.

o Directeur Général

Le DG, nommé par le président de la République, est chargé de

superviser et de coordonner l’ensemble des activités du Conseil
d’Administration, du Conseil de l’ISP et du Comité de Gestion. Il est assisté
dans l’exercice de ses fonctions d’un Secrétaire Général Académique, d’un
Secrétaire Général Administratif ainsi que d’un Administrateur du Budget.
Cet organe comprend :
a) Le Chef de Cabinet

Assiste le DG dans la supervision de tous les services de la direction

générale et joue le rôle de conseiller principal du DG, il coordonne les
activités du secrétariat, des relations publiques et assure la gestion des
dossiers lui confiés par le DG.
b) Le Collège des Conseillers

Joue le rôle de consultant : avis verbaux ou écrits sur toutes les

questions académiques, scientifiques, administratives, ou financières
soumises à son examen par le DG ou le Chef du Cabinet sur instruction du
DG.
 39

c) La Direction Garde et Sécurité

Procédé à l’affectation journalière, hebdomadaire, ou mensuelle des

gardes sur proposition du chef de Bureau Garde et Sécurité : analyse les
renseignements subséquents à l’intention de l’autorité.
d) Le Bureau Audi-Interne
Intervient de toute réquisition de l’autorité en matière d’inspection, il
s’occupe de la vérification des états et rapport de paie, des prix et régularité
des opérations d’achat, des régularités des dépenses, du mouvement des
stocks (entrées-sorties), etc.
e) Le Bureau Informatique

S’occupe de l’information de la gestion des différents secteurs de

l’institut : assure l’initiation à l’information des étudiants et fournis un
appuis aux activités de l’enseignement et de la recherche.
II.1.3.3. Le Conseil de Section

Cet organe est constitué de Professeurs Ordinaires, de Professeurs et

de Professeurs Associés, de deux représentants du personnel scientifique et
de deux représentants des étudiants. Il a comme attribution de gérer et
d’administrer une section qui n’est d’autre qu’un comité d’enseignant, de
recherche et de production jouissant de l’autonomie de gestion.
Le bureau de section est composé d’un Chef de Section et d’un Chef de
Section Adjoint, d’un Secrétaire Académique et des Chefs de Départements
qui veillent à l’exécution des décisions du Conseil de Section.
II.1.3.4. Le Conseil de Département

Cet organe est constitué de Personnel Académique, de Chefs des

Travaux, de deux représentants, des Assistants et de deux représentants des
Etudiants du département. Il a comme attributions d’approuver les
programmes de recherche et d’enseignement et d’organiser les réunions
scientifiques. Il donné aussi des avis concernant la nomination ou la
promotion du personnel académique.
 40

II.2. ANALYSE ET CRITIQUE DE L’EXISTANT

II.2.1. Gestion des présences des agents à l’ISP-Bukavu

Au sein de l’ISP-Bukavu, la gestion de présences des agents est
décentralisée. Normalement, c’est le service de gestion du personnel qui est
chargé de faire cette gestion. Compte tenue de la multiplicité de plusieurs
agents, cette gestion est confiée aux services qui quant à leurs tours vont
envoyer des rapports au service concerné.
Dans chaque service, on y trouve soit un cahier ou une fiche sur
laquelle l’agent doit signer lorsqu’il arrive au travail. A la fin de la semaine, le
service en question va prendre une copie de la fiche et l’envoyer au sein de la
gestion du personnel. Le service de ressource humaine fera un rapport où il
calcule déjà les heures prestées ainsi que les heures supplémentaires pour
chaque agent, un rapport qui sera transmis au niveau de la finance afin
d’effectuer la paie de la prime. Le schéma ci-dessous (figure N°13) représente
de manière synthétique la circulation de l’information sur la gestion des
présences des agents à l’ISP-Bukavu

II.2.1.1. Flux d’information existant

Gestion du
Agent
personnel

2
1 5
4
3

Services Finance

Figure N° 13 : Flux d’information de la gestion des présences des agents

Légende :
1 : L’agent se présente devant le bureau de son service où il va trouver
une fiche sur laquelle il signe à l’arrivée ou la sortie ;
2 : A la fin de chaque semaine, le service de gestion du personnel
demande les rapports des présences à tous les services ;
 41

3 : A la fin de la semaine, chaque service envoie le rapport de

présences de son personnel au niveau de la gestion du personnel ;
4 : Afin de passer aux opérations de paie, le service de finance
demande le rapport des présences de tous les agents ;
5 : Le service de la gestion du personnel envoie le rapport de présences
de tous les agents à la finance.

II.2.2. Les différents documents

Dans la gestion des présences des agents, deux principaux documents
sont utilisés : une fiche de présence et une fiche des absences.

a) la fiche de présence

Au début de chaque semaine, le service de gestion du personnel émet des

fiches de présences dans les différents services pour que les agents signent à
l’entrée et à la sortie. Voici comment ce document se présente :

Figure N° 14 : Fiche de Présence utilisée à l’ISP-Bukavu

Après avoir compléter cette fiche, elle est remise à la fin de chaque semaine
au près du service de gestion du personnel pour centraliser ces
informations. Ainsi donc, à la fin du mois, le service de gestion du personnel
fera un rapport des absences des agents au moyen d’une autre fiche appelée
« Fiche des absences ».
 42

b) La fiche des absences

A l’ISP Bukavu, une absence non justifiée ne passe pas inaperçue.

Cependant, il y a toujours un montant à retrancher sur la prime de l’agent
proportionnellement aux absences encaissées. Tout se fait sur la fiche des
absences qui se présente de la manière suivante :

Figure N° 15 : Fiche des absences utilisée à l’ISP-Bukavu

Sur cette fiche, la formule ci-après est exploitée :

=
26
Où MR est le montant à retrancher, P est la prime de l’agent, 26 est le
nombre des jours de travail et N le nombre d’absences de l’agent au cours
d’une période donnée.
 43

II.2.3. Critique et proposition de solution

II.2.3.1. Critique
Comme nous l’avons déjà dit dans l’introduction générale, le système
de signer à l’arrivée et à la sortie conduit aux problèmes suivant :
Possibilité qu’un agent puisse signer pour un autre agent qui n’est
pas présent ;
Possibilité qu’un agent puisse signer 8h°° alors qu’il est arrivé à
10h°° ;
Possibilité qu’un agent puisse compléter l’heure d’arriver à la
sortie ;
Difficulté de calculer les retards des agents ;
Retard dans l’élaboration des fiches de présences mensuelles par
agent car le système est manuel ;
Indisponibilité de l’information en temps réel dans les services qui
interviennent dans cette gestion.

II.2.3.2. Proposition de solution

Etant donné que l’informatique est de nos jours un outil par excellence
qui procure la rapidité et l’automatisation, source de la précision et de
l’exactitude des résultats, nous proposons à l’ISP-Bukavu de mettre en place
une application de gestion de présence sous réseau basée sur les
caractéristiques biométriques des employés afin de certifier leurs arrivées et
leurs sorties à l’ISP.
 44

Conclusion Partielle

Dans le présent chapitre, il a été question de faire une rétrospective de

notre milieu d’étude qui est l’ISP-Bukavu. Nous avons déclenché par
présenter de manière générale cette institution en donnant son historique,
ses objectifs, son organigramme ainsi que la description des quelques postes
de l’organigramme. Du fait que nous n’avons pas travaillé avec tous les
services de l’ISP-Bukavu, notre étude à été emmené vers le service de gestion
du personnel. Cela nous a conduits à présenter la manière dont se fait la
gestion des présences des agents au sein de ce service à partir d’un
diagramme de flux d’information (figure N°13). En suite, une présentation
des documents utilisés à été fait et par conséquent une critique et une
proposition de solution étaient également bâties. Par rapport à la proposition
que nous avons émise dans le présent chapitre qui était celui de mettre en
place une application informatique de gestion des présences utilisant la
technologie de reconnaissance faciale, sa réalisation ne peut s’accomplir
qu’avec une planification en avance. C’est ainsi que le chapitre suivant
consistera à faire une modélisation de notre futur système informatique.
 45

CHAPITRE TROISIEME

APPROCHE METHODOLOGIQUE
Ce chapitre se subdivise en trois sections. La première section propose
les différentes méthodes de développement informatique, la deuxième essaye
de faire le choix et la description de la méthode utilisée. Enfin, la dernière
section consiste à faire le développement de la méthode utilisée.

III.1. PRESENTATION DES QUELQUES METHODES DE DEVELOPPEMENT

INFORMATIQUE

Dans la présente section, nous présentons quelques méthodes

utilisées en informatique pour le développement des systèmes d’information.
Il s’agit entre autre de notre très chère MERISE, de l’UP, RUP et en fin l’UP7.

III.1.1. MERISE
MERISE est un acronyme signifiant Méthode d’Étude et de Réalisation
Informatique par les Sous-ensembles ou pour les systèmes d’Entreprise.
La méthode Merise a comme objectif d’aider, de guider les concepteurs des
systèmes d’information, dans leurs phases d’analyses, de conception et le
développement de l’applicatif (Jean-Luc BAPTISTE, p.1).
La méthode Merise se caractérise par :

une approche systémique en ayant une vue de l’entreprise en terme de

systèmes (le système de pilotage, le système d’information et le
système opérant) ;
une séparation des données (le côté statique) et des traitements (le
côté dynamique) ;
une approche par niveaux (le niveau conceptuel, le niveau
organisationnel, le niveau logique ainsi que le niveau physique).
 46

III.1.2. UP
UML n’est qu’un langage de modélisation (Joseph Gabay et David
Gabay ; 2008, p.111). Signalons que nous n’avons pas aujourd’hui dans la
norme, de démarche unifiée pour construire les modèles et conduire un
projet mettant en œuvre UML. Cependant les auteurs d’UML, ont décrit,
dans un ouvrage de Jacobson (2000) cité par Joseph Gabay et David Gabay
(2008, p.111), le processus unifié (UP, Unified Process) qui doit être associé
à UML. Nous n’allons pas, dans le cadre de cette section, donner une
présentation détaillée d’UP. Cependant il nous a paru intéressant de dégager
les idées fondatrices d’UP dans le cadre d’une présentation générale. Nous
allons tout d’abord expliciter les principes de la méthode UP. Nous
compléterons ensuite cette présentation générale en décrivant l’architecture
à deux dimensions d’UP, nous passerons aussi en revue les différentes
phases d’UP, et pour finir nous citerons les activités d’UP.
III.1.2.1. Les principes d’UP
Le processus de développement UP, associé à UML, met en œuvre les
principes suivants :
Processus guidé par les cas d’utilisation : L’orientation forte donnée ici
par UP est de montrer que le système à construire se définit d’abord
avec les utilisateurs ;
Processus itératif et incrémental ;
Processus centré sur l’architecture : Les auteurs d’UP mettent en
avant la préoccupation de l’architecture du système dès le début des
travaux d’analyse et de conception ;
Processus orienté par la réduction des risques : L’analyse des risques
doit être présente à tous les stades de développement d’un système;
Ces principes sont à la base du processus unifié décrit par les auteurs
d’UML.
 47

III.1.2.2. Phases et Itérations du processus Unifié

Le processus unifié, organisé en fonction du temps, est divisé en quatre
phases successives.
Inception (Lancement) ;
Élaboration ;
Construction ;
Transition ;
Voici un schéma qui montre les deux dimensions de la démarche UP.

Figure N°16 : Schéma d’ensemble d’UP (Joseph Gabay et David Gabay ; 2008, p.112).

III.1.2.3. Activités du Processus

Dans chaque phase de l’UP, il y a un ensemble de cinq activités qui
doivent être exécutée. Ces activités sont les suivantes :

Expressions des besoins ;

Analyse ;
Conception ;
Implémentation ;
Test.

Disons que la société Rational Software, racheté par IBM, avait mis en place
une autre version d’UP spécifique sous le nom de RUP (Rational Unified
 48

Processus). Dans le point suivant, nous allons beaucoup plus nous atteler
sur les apports de RUP.

III.1.3. RUP
Selon Joseph Gray et David Gray (2008, p.112), RUP est un processus
basé sur une approche disciplinée afin de bien maîtriser l’assignation des
tâches et la responsabilisation des différents acteurs participant au cycle de
développement du logiciel. Cela étant, l’objectif principal de cette approche
est de faire appliquer des bonnes pratiques de développement aux
entreprises.
Nous allons présenter les apports du RUP en essayant d’exploiter les
éléments ci-après :

Les bonnes pratiques ou principes ;

Les phases du processus ;
Les activités du processus.

III.1.3.1. Les bonnes pratiques

En plus des principes de l’UP, la démarche RUP a fait son apport en
augmentant trois autres principes ou bonnes pratiques suivantes :

Modélisation visuelle ;
Vérification continue de la qualité ;
Contrôle des changements du logiciel.

III.1.3.2. Les phases du processus

Pareillement à l’UP, l’approche RUP est un processus à deux
dimensions. Comme nous l’avons vu pour l’UP, l’axe horizontal représente
les phases et itérations et l’axe vertical représente les activités. RUP
maintient les quatre phases de l’UP comme le montre la figure N°17
 49

Figure N°17 : Schéma d’ensemble du RUP (Joseph Gabay et David Gabay ; 2008)
Dans la démarche RUP, il y a un aspect qui s’est ajouté. L’aspect en question
est appelé « jalon ». Un jalon est un ensemble des tests à accomplir à la fin
de chaque phase et qu’on ne peut passer à la phase suivante que si ces
derniers sont vérifiés.
III.1.3.3. Les Activités du processus
Comme vous le voyez dans la figure N°12, RUP organise 9 activités
suivantes :

Modélisation métier ;
Gestion des exigences ;
Analyse et conception ;
Implémentation ;
Test ;
Déploiement ;
Gestion de la configuration et du changement ;
Gestion des projets ;
Environnement.
 50

III.1.4. UP7
La démarche UP7 était proposée par Joseph Gabay, Directeur de projet
informatique au CNRS-Paris et chargé du cours à l’Université de Paris-
Dauphin avec David Gabay, directeur chef de projet chez Cap Gemini une
entreprise informatique se trouvant en France. La démarche est articulée
suivant deux axes : les quatre phases qui correspondent à celles d’UP et sept
activités. Ainsi, ils ont présenté dès ce stade un premier schéma d’ensemble
de la démarche suivant ces deux axes (figure N°18).

Figure N°18 : Schéma d’ensemble de la démarche UP7 (Joseph Gabay et David Gabay ;
2008)
Le grisé sur le schéma représente l’effort à consentir pour chaque
activité durant les phases d’un projet. Ainsi par exemple, pour l’activité 3
(Analyse des cas d’utilisation), l’activité commence légèrement lors de la
phase de lancement puis se déroule principalement lors de la phase
d’élaboration et se termine en phase de construction.
 51

Il est à noter que sur le schéma, la proportion que représente chaque

activité par rapport à l’ensemble de la charge de développement d’un projet a
été respectée graphiquement. Compte tenu de notre expérience et des ratios
habituellement constatés dans la profession, nous avons retenu la
répartition indicative suivante pour les volumes d’effort à consentir sur les
activités d’un projet (Joseph Gabay et David Gabay ; 2008, p.139).
Modélisation métier : 5 % ;
Exigences fonctionnelles : 5 % ;
Analyse des cas d’utilisation : 20 % ;
Synthèse de l’analyse : 5 % ;
Conception : 10 % ;
Implémentation : 40 % ;
Test : 15%.
Il importe bien entendu, de tenir compte pour chaque projet de ses
spécificités en termes par exemple de complexité fonctionnelle, contraintes
techniques, et compétence des ressources affectées. Les activités 6 et 7, «
Implémentation » et « Tests », sont présents sur notre schéma pour couvrir à
ce niveau la totalité des activités en référence à UP. Dans les lignes qui
suivent, nous allons beaucoup plus développer ces différentes activités.

III.2. CHOIX ET DESCRIPTION DE LA METHODE CHOISIE

III.2.1. Choix de la méthode

Notre choix a été porté sur la démarche UP7 du fait qu’elle nous
permet de faire une conception qui est beaucoup plus pragmatique et
détaillée. Cette approche comme nous l’avons vu dans sa présentation est
une amélioration du Processus Unifié (UP) car en plus des cinq activités de
la démarche UP, elle entre en profondeur (en détail) en introduisant 6
activités dans le processus de développement.

III.2.2. Description de la méthode UP7

Dans le cadre de notre travail, pour illustrer la description générale
des activités de la démarche, la figure N°20 présente chaque activité avec ses
différentes sous-activités. Une sous-activité aboutit à l’élaboration d’un ou
 52

plusieurs diagrammes UML ou d’un schéma de support au développement

du système (hors UML).
I. Modélisation Métier
I.1. Elaboration du schéma de contexte du domaine d’étude
I.2. Elaboration du diagramme d’activité
I.3. Elaboration du diagramme de classe Métier

II. Exigences fonctionnelles

II.1. Elaboration du diagramme du DCU système
II.2. Elaboration des diagrammes de séquence système
II.3. Elaboration du schéma de navigation générale

III. Analyse des cas d’utilisation

III.1. Elaboration du diagramme de cas d’utilisation
III.2. Description des cas d’utilisation
III.3. Elaboration des diagrammes de séquence
III.4. Elaboration du diagramme d’Etat-transition
III.5. Elaboration du diagramme de classe

IV. Synthèse de l’analyse

IV.1. Elaboration du diagramme de classe récapitulatif
IV.2. Elaboration de la matrice de validation

V. Conception
V.1. Réalisation des choix techniques
V.2. Elaboration des diagrammes de séquence techniques
V.3. Elaboration du diagramme de classe technique
V.4. Elaboration du diagramme de paquetage

VI. Implémentation
VI.1. Elaboration du diagramme de structure composite
VI.2. Elaboration du diagramme de déploiement

VII. Test
Vérification de l’implémentation des tous les cas d’utilisation
(cfr chapitre 4)
Figure N°19 : Schéma détaillé de la démarche
 53

Signalons que nous avons utilisés la technique de brainstorming afin de

récolter les exigences de l’application que nous avons développé.

III.2.3. Description du brainstorming

Afin de récolter les exigences nécessaires de l’application que nous
avons développée, la technique de brainstorming a été utilisée. Le
brainstorming est une séance de remue méninge qui consiste à faire un
entretien avec les clients dans le cadre de recueillir leurs besoins sur le
projet informatique à mener (Jean Robert KALA ; 2017, p.20). Cette
technique utilise la démarche ci-après :

Recourir à un modérateur expérimenté ;

Disposer l’assistance autour d’une table ;
Lancer une question de départ ;
Demander à chacun des participants d’écrire une réponse et de la
passer à son voisin.

Dans le cadre de notre projet, nous avons fait une descente sur terrain,
précisément dans le bureau du chargé du personnel et rémunération des
agents de l’ISP-Bukavu. Avec cet agent et ses 2 autres collègues, nous avons
eu à leurs poser des questions relatives au fonctionnement de la gestion des
présences des agents au sein de l’ISP-Bukavu, auxquelles ils ont quand
même répondu. Il revient ainsi impérieux de signaler que les exigences que
nous avons spécifiées au niveau du développement de la démarche UP7 ont
été découlées des réponses obtenues lors de la séance de remue méninge
que nous avons eu avec ces agents.
Ainsi donc, plongeons nous dans une étape cruciale qui est celle de la
matérialisation de notre schéma détaillé de la démarche UP7.
 54

II.3. DEVELOPPEMENT DE LA METHODE

III.3.1. MODELISATION METIER

Dans le présent point, nous allons présenter le schéma de contexte
pour situer notre système par rapport aux autres processus de l’entreprise,
en suite nous allons élaborer le diagramme d’activité qui consistera à définir
les processus métier concernés par le système que nous allons développer
ainsi que l’identification des acteurs. En fin, nous allons élaborer le
diagramme de classe métier qui consistera à définir les concepts métiers du
domaine sous forme de classe.

III.3.1.1. Schéma de contexte

Conformément à notre démarche UP7, il nous est recommandé
d’établir en premier un schéma de contexte permettant de situer le domaine
d’étude par rapport aux autres processus de l’entreprise.
Ainsi, nous observons (figure N°20) que notre domaine d’étude est en étroite
relation avec trois processus importants, respectivement le service de
finance, le service de gestion du personnel ainsi que les agents.

Finance Gestion du
Personnel

Logiciel de gestion des

présences

Agents

Figure N°20 : Schéma de contexte du domaine d’étude

 55

A partir du présent schéma, nous venons de voir comment notre système

de gestion des présences des agents interagis directement avec 3 autres
processus entre autre :

Le service de Finance : Qui consistera à faire des requêtes dans le

futur système afin d’avoir les informations comme la totalité des
présences et absences réalisées au cours du mois pour passer à
l’opération de paie ;
Le service de Gestion du Personnel : Quant à ce service, il se tâchera à
se renseigner sur l’évolution des agents en terme de leur présences au
travail ;
Les Agents : Ils interviendront dans le futur système en se présentant
devant la caméra pour une capture afin de certifier leurs présences.

Cependant, le fonctionnement de notre futur système reste un aspect

jusque là non abordé ; le point suivant consistera ainsi à nous faire une
brève description du fonctionnement de notre futur système.

III.3.1.2. Elaboration du diagramme d’activité

Trois acteurs principaux interviendront dans la gestion de présences
des agents (figure N°21).

L’Agent : il est l’acteur principal car c’est lui qui déclenche le début de
toute activité. Il se présente au sein du service chargé de prélevé les
présences pour être enregistré en plus aussi devant la caméra pour
certifier qu’il est présent au travail ;
L’administrateur : Il est chargé d’enregistrer les services dans le
système, les agents, d’enregistrer les congés des agents, d’imprimer les
fiches des présences des agents ainsi que de lancer la caméra pour
débuter le processus de reconnaissance faciale afin de prélever les
présences et sorties. Il sera représenté par le chef du personnel ;
Service : Il pourra enregistrer les agents de son service, imprimer la
liste des agents de son service, visualiser les fiches des présences des
agents de son service, visualiser les fiches des absences des agents de
son service mais aussi lancer la caméra. Il sera représenté par un chef
de service.
 56

Figure N° 21 : Diagramme d’activité

 57

Ainsi, au niveau de la page précédente, nous avons présenté de manière

globale le fonctionnement de notre future application de gestion de présence
via la reconnaissance faciale.

III.3.1.3. Le Diagramme de classe Métier

Comme les disent Joseph Gray et David Gray (2008, p.139), les
concepts métiers correspondent aux informations créées, transformées ou
manipulées par les experts du domaine (Utilisateurs). Ainsi donc, ce
diagramme (figure N°22) consistera à faire une définition des concepts
métiers sous forme des classes. Dans le cadre de notre projet, nous avons
identifié les concepts métiers ci-après :

Agent : ce concept représente les agents de l’ISP (dans le cadre de

notre travail, nous travaillons dans la logique des agents
administratifs) ;
Service : L’administration de l’ISP-Bukavu est partagée en plusieurs
services dans lequel on y trouve des agents, ce concept métier désigne
aussi le responsable du service ;
Administrateur : c’est le chef du personnel qui sera chargé de
centraliser toutes les informations du système ;
Photo : chaque agent possède une photo portant ainsi son matricule
comme nom. Cette dernière sera utilisé afin de l’identifier ;
Présence : ce concept correspond à une information qui sera créée
après une opération de reconnaissance faciale. Chaque agent est
concerné par ce concept ;
Sortie : De même que la présence, ce concept est créé suite à une
condition que nous avons montrés au niveau de la figure N°15 ;
Camera : ce concept correspond à un élément manipulé par les
experts du domaine qui consiste à récupérer les images et envoyer ces
flux dans le système pour être traité ;
Document : c’est l’ensemble de tous les documents qui seront produits
par le système.
 58

Figure N°22 : Diagramme de classe métier

 59

III.3.2. EXIGENCES FONCTIONNELLES

Cette deuxième activité de la démarche UP7 a pour but de définir ce
que doit faire le système d’un point de vue métier. Cette activité permet
d’obtenir trois résultats :
La définition des cas d’utilisation métier et leur description générale
(diagramme de cas d’utilisation système) ;
Les scénarios des cas d’utilisation métier (diagramme de séquence
système) ;
La navigation générale du système à étudier, c’est-à-dire l’interface
homme machine (schéma de navigation générale).

Signalons qu’au terme de ces deux premières activités, l’expression des

besoins (au sens UP) sera couverte.

III.3.2.1. Elaboration du diagramme des cas d’utilisation système

A partir du diagramme d’activité et de la connaissance des besoins des
acteurs, nous élaborons une vision générale des cas d’utilisation métiers du
futur système. Signalons que c’est un diagramme de cas d’utilisation
système du point de vue métier (maître d’ouvrage) et non du point de vue
informatique (qui sera présenté dans une autre activité).
 60

Figure N° 23 : Diagramme des cas d’utilisation système

III.3.2.2. Diagramme de séquence système

Chaque cas d’utilisation décrit ci-dessus (figure N°23) donne lieu à un
diagramme de séquence système. Dans le cadre de notre travail, nous allons
présenter seulement deux diagrammes de séquences systèmes pour deux
cas d’utilisations.

a) DES du CU « Imprimer fiches des présences »

Figure N°24 : Diagramme de séquence système « Imprimer fiche des présences »

b) DS : « Se présenter devant la caméra »

Figure N°25 : Diagramme de séquence système « Se présenter devant la caméra»

 61

III.3.2.3. Schéma de navigation générale

MAJ AGENT

MAJ SERVICE

MENU IMPRESSION

AJOUT

MAJ
MENU PRESENCES

HISTORIQUE MENU CONGES

Figure N°26 : Schéma de navigation générale

III.3.3. ANALYSE DES CAS D’UTILISATION

Cette activité a pour but de fournir une vue informatique de notre
système. Cette activité permet d’obtenir cinq résultats :
La définition de tous les cas d’utilisation (métiers + informatiques) et
leur description détaillée (diagramme des cas d’utilisation) ;
L’identification des scénarios pour chaque cas d’utilisation (diagramme
de séquence) ;
Les différents états des objets étudiés (diagramme d’état-transition).
Cette partie de l’activité est optionnelle et s’applique selon les systèmes
étudiés ;
Les interfaces utilisateur pour chaque cas d’utilisation ;
Les classes pour chaque cas d’utilisation (diagramme de classe).

À l’issue de cette activité, l’analyse des cas d’utilisation est produite mais
non encore consolidée ni validée définitivement.
 62

Dans le cadre de notre travail, nous n’avons pas présenté les interfaces
utilisateurs pour les cas d’utilisation car nous allons les présenter dans le
dernier chapitre au niveau du guide d’utilisateur.

III.3.3.1. Elaboration du diagramme de cas d’utilisation

Figure N°27 : Diagramme des cas d’utilisation

 63

III.3.3.2. Description des cas d’utilisation

Pour la suite de l’étude de cas, nous allons poursuivre l’analyse sur les
trois cas d’utilisation suivants seulement :

S’authentifier ;
Ajout agent ;
Se présenter devant la caméra.
a) Description du DCU « S’authentifier»

CU : S’authentifier
Résumé : Ce CU permet à un utilisateur de se connecter au système et lui
présente une interface.
Acteur : Administrateur, chef de service
Pré conditions : Introduire login et mot de passe
Post-Condition : Le cas démarre après le point 02 de l’enchaînement
nominal, l’utilisateur s’authentifie
Scénario nominal
DESCRIPTION DU SCENARIO NOMINAL
« DEBUT »
01 : Le système invite l’utilisateur à entrer son login et son mot de passe
02 : L’utilisateur saisie son login et son mot de passe
03 : Le système vérifie les paramètres
04 : Le système ouvre l’Espace de travail
« FIN »
Scénario alternatif
DESCRIPTION DU SCENARIO ALTERNATIF
Le login ou le mot de passe est incorrect : ce scénario commence au point 03
du scénario nominal
01 : Le système informe l’utilisateur que les données saisies sont erronées et
le scénario reprend au point 01 du scénario nominal
 64

b) Description du CU « Ajout Agent »

CU : Ajout Agent
Résumé : Ce CU permet à ajouter un agent dans le système.
Acteur : Administrateur, Chef de service
Pré conditions : S’authentifier
Post-Condition : Le cas démarre après le point 03 de l’enchaînement
nominal, l’utilisateur saisie les informations
Scénario nominal
DESCRIPTION DU SCENARIO NOMINAL
« DEBUT »
01 : L’utilisateur demande la page pour ajouter un agent au système
02 : Le système affiche un formulaire d’ajout d’un agent
03 : L’utilisateur saisi les informations et capture la photo de l’agent
04 : Le système vérifie la validité des informations saisies
05 : Le système enregistre ces informations dans la base de données
06 : Le système notifie l’utilisateur du bon déroulement de l’opération
« FIN »
Scénario alternatif
DESCRIPTION DU SCENARIO ALTERNATIF
Les informations sont manquantes ou incorrectes : ce scénario commence
au point 04 du scénario nominal
01 : Le système informe l’utilisateur que les données saisies sont erronées et
le scénario reprend au point 03 du scénario nominal
 65

c) Description du CU « Se présenter devant la caméra »

CU : Se présenter devant la caméra

Résumé : Ce CU permet de certifier l’identité d’un agent afin de consigner sa
présence au travail.
Acteur : Agent
Post-Condition : Le cas démarre après le point 01 de l’enchaînement nominal, Le
système recherche la face dans la vidéo
Scénario nominal
DESCRIPTION DU SCENARIO NOMINAL
« DEBUT »
01 : L’utilisateur se présente devant la caméra
02 : Le système recherche la face dans la vidéo
03 : Le système détecte la face dans la vidéo
04 : Le système compare la face détectée avec les autres faces des agents
disponibles dans la base de données
05 : Le système trouve le correspondant de la face dans la base de données
06 : Le système vérifie l’heure système
07 : Le système enregistre la date et l’heure d’arriver de l’agent
« FIN »
Scénario alternatif
DESCRIPTION DU SCENARIO ALTERNATIF
La face non détectée: ce scénario commence au point 02 du scénario nominal
01 : Le système ne trouve pas de face dans la vidéo et le scénario reprend au point
02 du scénario nominal
La face de la personne devant la caméra n’est pas retrouvée dans la base de
données des agents : ce scénario commence au point 04 du scénario nominal
01 : Le correspondant de la face n’est pas trouvé dans la base de données
02 : Le système enregistre la date et l’heure de la personne devant la caméra
comme visiteur et le scénario reprend au point 02 du scénario nominal
Le système trouve qu’il est après 14h45’ : ce scénario commence au point 06 du
scénario nominal
01 : Le système vérifie si l’agent était présent à cette date
02 : Le système enregistre l’heure et la date de sortie de l’agent
 66

III.3.3.3. Elaboration des diagrammes de séquence

Toujours dans le cadre d’analyse des cas d’utilisation, nous allons
présenter les différents diagrammes de séquence pour les cas d’utilisations
ci-après :

S’authentifier ;
Se présenter devant la caméra ;
a) Diagramme de séquence « S’authentifier »

Figure N°28 : Diagramme de séquence « s’authentifier »

b) Diagramme de séquence « Se présenter devant la caméra »

Figure N°29 : Diagramme de séquence « se présenter devant la caméra »

 67

III.3.3.3. Diagramme d’Etat-transition

Le diagramme suivant montre comment les agents changent d’Etat dès leur enregistrement dans le système jusqu’à
l’Etape d’être jugé présent ou absent avec l’intervention du service d’enregistrement et de la caméra pour la capture.

Figure N°30 : Diagramme d’Etat-transition

 68

III.3.3.4. Diagramme des classes

Le diagramme de classes représente les classes constituant le système
et les associations entre elles. Les diagrammes de classes expriment de
manière générale la structure statique d’un système, en termes de classe
et de relations entre ces classes. De même qu’une classe décrit un
ensemble d’objets, une association décrit un ensemble de liens ; les objets
sont des instances de classes et les liens sont des instances de relations
(ASUMANI NABONIBO ; 2014, p.70).
La description du diagramme de classe est fondée sur :

le concept d’objet ;
le concept de classe comprenant les attributs et les opérations ;
les différents types d’association entre classes.

III.3.3.4.1. Objet
Nous allons donner une première définition du concept d’objet avant
de traiter le concept de classe. La description d’un objet sera complétée
simultanément à la présentation du concept de classe. Un objet est un
concept, une abstraction ou une chose qui a un sens dans le contexte du
système à modéliser. Chaque objet a une identité et peut être distingué des
autres sans considérer a priori les valeurs de ses propriétés (MUSANGU
LUKA ; 2015-2016, p.63).
Exemple : la figure ci-dessous montre des exemples d’objets physiques (une
chaise, une voiture, une personne, un vélo) et d’objets de gestion (la
Commande n° 12, le Client Durand).

Figure N°31 : Exemples d’objets physiques et d’objets de gestion (MUSANGU

LUKA ; 2015-2016, p.63)
 69

III.3.3.4.2. Classe, attribut, opération et association

a) Classe

Une classe décrit un groupe d’objets ayant les mêmes propriétés

(attributs), un même comportement (opérations), et une sémantique
commune (domaine de définition). Un objet est une instance d’une classe. La
classe représente l’abstraction de ses objets. Au niveau de l’implémentation,
c’est-à-dire au cours de l’exécution d’un programme, l’identificateur d’un
objet correspond une adresse mémoire (MUSANGU LUKA ; 2015-2016, p.64).

o Formalisme général et exemple

Une classe se représente à l’aide d’un rectangle comportant

plusieurs compartiments.
Les trois compartiments de base sont :

la désignation de la classe,
la description des attributs,
la description des opérations.

Deux autres compartiments peuvent être aussi indiqués :

la description des responsabilités de la classe,

la description des exceptions traitées par la classe.

Il est possible de manipuler les classes en limitant le niveau de description à

un nombre réduit de compartiments selon les objectifs poursuivis par
le modélisateur. Ainsi les situations suivantes sont possibles pour la
manipulation d’une description restreinte de classe :

description uniquement du nom et des caractéristiques générales de la

classe,
description du nom de la classe et de la liste d’attributs.

La figure N° 32 montre le formalisme général des compartiments d’une

classe et des premiers exemples.
 70

Figure N°32 : Formalisme général d’une classe et exemple (MUSANGU LUKA ;

2015-2016, p.65)

b) Attribut

Un attribut est une propriété élémentaire d’une classe. Pour chaque

objet d’une classe, l’attribut prend une valeur (sauf cas d’attributs multi
values) (Joseph Gabay et David Gabay ; 2008, p.20).

o Formalisme et exemple

La figure N° 33 montre le formalisme général d’attributs d’une classe

et un exemple.

Figure N°33 : Formalisme d’attributs de classe et exemple (Joseph Gabay et David

Gabay ; 2008, p.20)

o Caractéristiques

Le nom de la classe peut être qualifié par un « stéréotype ». La description

complète des attributs d’une classe comporte un certain nombre de
caractéristiques qui doivent respecter le formalisme suivant (Joseph Gabay
et David Gabay ; 2008, p.20):
Visibilité/Nom attribut : type [= valeur initiale {propriétés}]

Visibilité ;
 71

Nom d’attribut : nom unique dans sa classe ;

Type : type primitif (entier, chaîne de caractères…) dépendant des
types disponibles dans le langage d’implémentation ou type classe
matérialisant un lien avec une autre classe ;
Valeur initiale : valeur facultative donnée à l’initialisation d’un objet de
la classe ;
{propriétés} : valeurs marquées facultatives (ex. : « interdit » pour mise
à jour interdite) ;

Ainsi, dans le cadre de notre mémoire, nous avons utilisés un certain

nombre d’attributs présents dans nos classes que nous allons présenter à
partir d’un tableau description d’attributs ci-après :
Tableau N°2 : Tableau descriptif d’attributs
Nom attribut Code Signification Type
Numéro matricule Matricule Matricule de Varchar (25)
l’agent
Nom Nom Nom de l’agent Varchar (25)
Post nom Postnom Post nom de Varchar (25)
l’agent
Prénom Prenom Prénom de l’agent Varchar (25)
Fonction Fonction La fonction Varchar (25)
qu’exerce l’agent
Horaire Horaire L’horaire du début Time
de travail de
l’agent
Grade Grade Le grade de l’agent Varchar (25)
Prime Prime La prime FLOAT
mensuelle de
l’agent
Login Login L’identifiant de Varchar (25)
l’utilisateur
Mot de passe Pw Le mot de passe de Varchar (25)
l’utilisateur
Caractéristiques Caracteristiques Les Varchar (25)
caractéristiques de
la face de l’agent
Photo Photo La photo de l’agent MEDIUMBLOB
Numéro service IdService Le numéro du Int(11)
service
Dénomination Denomination L’appellation du Varchar (50)
service
Responsable Responsable Le nom du chef de Varchar (25)
service
Numéro congé IdConge Le numéro du Int (11)
congé
Date de début dateDebut La date de début Date
 72

du congé
Date de fin DateFin La date de fin du Date
congé
Le numéro de la IdSortie Le numéro d’une Int (11)
sortie sortie
La date de la sortie DateSortie La date de la sortie Date
de l’agent
L’heure de sortie HeureSortie L’heure de sortie Time
de l’agent
Le numéro de la IdPresence Le numéro d’une Int (11)
présence présence
Date de Presence DatePresence La date du jour de Date
présence
L’heure d’arrivée Heure L’heure d’arrivée Time
de l’agent au
travail
Retard Retard Le retard encaissé Int (11)
par l’agent
Consigne Consigne Consigner si Int (11)
l’agent possède des
absences
antérieures
Le numéro du IdVisiteur Le numéro attribué Int (11)
visiteur au visiteur
Date d’entrée DateEntrer La date d’entrée du Date
visiteur
Heure Heure L’heure de la Time
capture
Photo Photo La photo du MEDIUMBLOB
visiteur
Code de la photo CodePhoto L’Identifieur 11 du Int (11)
visiteur
Source : nos propres compilations

c) Opération

Une opération est une fonction applicable aux objets d’une classe. Une
opération permet de décrire le comportement d’un objet. Une méthode est
l’implémentation d’une opération (Joseph Gabay et David Gabay ; 2008,
p.20).

Formalisme et exemple

11Lors de la reconnaissance faciale, le numéro attribué à chaque objet et le différencie des

autres dans le flux vidéo est appelé « Identifieur »
 73

La signature d’une méthode correspond au nom de la méthode et la

liste des paramètres en entrée. La figure N°34 montre le formalisme et
un exemple de représentation d’opérations de classe.

Figure N°34 : Formalisme et exemple d’opérations de classe (Joseph Gabay et David

Gabay ; 2008, p.20)

d) Association

Un lien est une connexion physique ou conceptuelle entre instances de

classes donc entre objets. Une association décrit un groupe de liens ayant
une même structure et une même sémantique. Un lien est une instance
d’une association. Chaque association peut être identifiée par son nom. Une
association entre classes représente les liens qui existent entre les instances
de ces classes (Joseph Gabay et David Gabay ; 2008, p.23).
Formalisme et exemple

Figure N°35 : Formalisme et exemple d’association (Joseph Gabay et David Gabay ;

2008, p.23)
 74

III.3.3.4.3. Identification des classes

Après notre analyse, nous avons recensé les classes ci-après pour le
traitement des présences des agents :

Agent ;
Administrateur ;
Utilisateur ;
Congé ;
Service ;
Photo ;
Sortie ;
Présence ;
Visiteur.

Multiplicité
La multiplicité indique un domaine de valeurs pour préciser le nombre
d’instance d’une classe vis-à-vis d’une autre classe pour une association
donnée. La multiplicité peut aussi être utilisée pour d’autres usages comme
par exemple un attribut multi-valué. Le domaine de valeurs est décrit selon
plusieurs formes (Joseph Gabay et David Gabay ; 2008, pp.24-25):

Intervalle fermé – Exemple : 2, 3..15.

Valeurs exactes – Exemple : 3, 5, 8.
Valeur indéterminée notée * – Exemple : 1..*.
o Dans le cas où l’on utilise seulement *, cela traduit une
multiplicité 0..*.
o Dans le cas de multiplicité d’associations, il faut indiquer les
valeurs minimale et maximale d’instances d’une classe vis-à-
vis d’une instance d’une autre classe.
 75

Exemples

Figure N°36 : Exemple de multiplicités (Joseph Gabay et David Gabay ; 2008, p.25)
Après avoir dégagé le dictionnaire de données épuré (tableau N°2),
nous pouvons dégager les classes, les règles de gestion ainsi que les
multiplicités dans le tableau suivant :
Tableau N°3 : Les règles de gestion ainsi que les multiplicités
N° Association Classe d’objet Multiplicité Règle de gestion
source Cible Source Cible
1 Ajouter Utilisateur Congé 1 0..* Un utilisateur ajoute
zéro ou plusieurs
congés
2 Posséder Agent Photo 1 1..* Un agent possède une
ou plusieurs photos
3 Posséder (2) Visiteur Photo 1 1..* Un visiteur possède une
ou plusieurs photos
4 Appartenir Agent Service 1..* 1 Un ou plusieurs agents
appartiennent dans un
service
5 Est concerné Agent Congé 1 1..* Un agent est concerné
(1) par un ou plusieurs
congés
6 Est concerné Agent Présence 1 1..* Un agent est concerné
(2) par une ou plusieurs
présences
7 Est concerné Agent Sortie 1 1..* Un agent est concerné
(3) par une ou plusieurs
sorties
Source : nos propres compilations
Cependant, après avoir recensé tous ces éléments relatifs au diagramme des
classes, nous pouvons maintenant représenter ce dernier.
 76

III.3.3.4.4. Représentation du diagramme des classes

Figure N° 37 : Diagramme des classes

 77

III.3.4. SYNTHESE DE L’ANALYSE

La quatrième activité de la démarche UP7 consiste à consolider et
valider toute l’analyse des cas d’utilisation. Cette activité permet d’obtenir 2
résultats :

Le regroupement de l’ensemble des classes en un seul diagramme

(diagramme de classe récapitulatif) ;
La validation de l’analyse de chaque cas par le biais d’une matrice de
validation. Celle-ci permet de vérifier que l’analyse des cas est
complète, c’est-à-dire que tous les cas d’utilisation métier ont été
repris dans l’analyse.

En ce qui concerne le cas de notre projet, étant donné que nous n’avons
pas présenté un DCL pour chaque cas d’utilisation, le diagramme de classe
représenté ci-haut représente en même temps le diagramme de classe
récapitulatif. Nonobstant, nous allons présenter le modèle relationnel de
notre projet à la place du diagramme de dernier.

III.3.4.1. Construction du Modèle relationnel

Il revient impérieux de signaler que le diagramme de clase n’est qu’un
schéma qui représente les classes du système et le les différentes
associations entre celles-ci (la généralisation, l’association, composition,
dépendance). Cependant, il est d’une importance capitale de présenter un
modèle relationnel qui sera implémenté dans la base de données.
Dans notre projet, pour passer du diagramme des classes au modèle
relationnel, nous avons utilisé les règles ci-après :

1) Toutes les classes deviennent des tables de la base de données sauf la

classe photo qui sera un fichier à part ;
2) Les identifiants des classes deviennent des clés primaires des tables ;
3) La clé primaire de la table à la cardinalité (X, 1) devient une clé
étrangère dans la table à la cardinalité (X, *), X=1 ou 0.
 78

Présentation du Modèle relationnel

Figure N° 38 : Modèle relationnel

III.3.4.2. Elaboration de la matrice de validation

Cette matrice nous permettra de vérifier si tous les cas d’utilisations
métiers (exprimés par la maitrise d’ouvrage) ont été tous implémentés dans
le diagramme de cas d’utilisation analyse (Informatique).
Cas d’utilisation métier Cas d’utilisation Analyse
Gérer les Agents Ajouter Agent
Gérer les Agents MAJ Agent
Gérer les Services Ajouter Service
Gérer les Services MAJ Service
Gérer les Présences Ajouter Présence
Gérer les Présences MAJ Présence
Gérer les Sorties Ajouter Sortie
Gérer les Sorties MAJ Sortie
Lancer caméra Lancer caméra
Imprimer Fiche des absences Visualiser les fiches des présences
S’authentifier
Capturer photo
Comparer Image
Tableau N°4 : Matrice de validation
 79

III.3.5. CONCEPTION
La cinquième activité de la démarche se concentre sur le « comment
faire ». Elle a pour but de définir et de mettre en place les choix
d’architecture technique, et de compléter la description du système sous
l’angle technique. Cette activité permet d’obtenir quatre résultats :
Les choix techniques retenus ;
Les scénarios techniques par cas d’utilisation (diagrammes de
séquence technique) ;
Les classes techniques par cas d’utilisation (diagrammes de classe
technique) ;
Le regroupement sous forme de paquetage de l’ensemble des classes
techniques en un seul diagramme (diagramme de paquetage).
De ce fait la conception préliminaire est couverte par cette activité. Signalons
qu’au terme de cette activité la conception (au sens UP) sera achevée.

III.3.5.1. Réalisation des choix techniques

Etant donné que les utilisateurs du présent système seront dans les
différents services à l’ISP-Bukavu, nous avons optés pour l’architecture
client-serveur dans la conception de notre logiciel. Le système fonctionnera
sous un réseau local où le serveur des applications sera installé sur chaque
poste concerné et la base de données sera partagée.
Autrement, C’est une architecture 2-tiers appelée aussi architecture
client lourd/serveur. Elle est assez simple dans sa mise en œuvre. Ce type
d'architecture est constitué uniquement de deux parties : le «client lourd»
demandeur de service d’une part et le «serveur de données» qui fournit le
service d'autre part. Nous aurons donc la base de données qui sera
délocalisée sur un serveur dédié appelé le serveur de données qui fournira
les données à exploiter (figure N°38).

Figure N° 39 : Architecture Client/serveur (Phitos Mbaa ; 2014, p.56)

 80

Afin de répondre aux besoins du maitre d’ouvrage, nous avons utilisé

la technologie COMPUTER VISION précisément le FACE RECOGNITION dans
le développement de notre application avec le J2EE. Ainsi donc, pour
matérialiser la technologie, la librairie LUXAND FACE SDK nous a aidés dans
l’implémentation des classes relatives à la reconnaissance faciale. Toutefois,
nous signalons que la reconnaissance en question se fera en temps réel ; par
conséquent l’usage d’une caméra sera indispensable pour réaliser les
captures. C’est pour cela que pour raison de test, nous avons utilisé la
caméra webcam de notre ordinateur.

III.3.5.2. Elaboration des diagrammes de séquence technique

Dans le cadre de notre projet, nous nous sommes limités à représenter
les diagrammes de séquences techniques pour les cas d’utilisations
suivants :

Ajouter service ;
Lancer la caméra.

Cas d’utilisation « Ajouter service »

Figure N°40 : Diagramme de séquence technique du CU « Ajouter service »

Le présent diagramme (figure N°40) représente les interactions entre
l’administrateur et tous les objets du système (incluant les objets
techniques) qui entrent en jeux pour effectuer l’ajout d’un service. Nous
 81

représentons les objets en utilisant la classification d’Ivar Jacobson

(Dialogue, Contrôleur, Entité).
Cas d’utilisation « Lancer la caméra »

Figure N°41 : Diagramme de séquence technique du CU « Lancer Caméra »

L’actuel diagramme (figure N°41) représente les interactions entre
l’utilisateur et tous les objets du système qui entrent en jeux pour réaliser le
cas d’utilisation « lancer caméra ».

III.3.5.3. Elaboration des diagrammes de classes techniques

Afin de représenter les diagrammes de classes, nous allons toujours
utiliser les 2 cas d’utilisations évoqués ci-dessus.
Cas d’utilisation « Ajouter service »
La navigabilité des associations est donnée par le sens de circulation
des opérations du diagramme de séquence (figure N°40). Ainsi, la classe
« Dialogue Ajouter Service» accède à la classe « CTRL Ajouter Service » par le
biais du message ajouter service. La navigabilité des autres associations est
déterminée sur le même principe.
Une relation d’agrégation existe entre la classe « CollectionService » et «
Service » de type « ensemble/élément ».
 82

Figure N°42 : Diagramme de classe technique du CU « Ajouter service »

Cas d’utilisation « Lancer caméra»

En ce qui concerne ce cas d’utilisation, la navigabilité des associations
est donnée par le sens de circulation des opérations du diagramme de
séquence (figure N°41). Ainsi, la classe « Dialogue Lancer caméra» accède
à la classe « CTRL Lancer caméra » par le biais du message lancer caméra.
La navigabilité des autres associations est déterminée sur le même principe
comme nous l’avons dit jadis.
 83

Figure N°43 : Diagramme de classe technique du CU « Lancer caméra »

III.3.5.4. Elaboration du diagramme de paquetage

Un paquetage regroupe des éléments de la modélisation appelés aussi
membres, portant sur un sous-ensemble du système (Joseph Gabay et David
Gabay ; 2008, p.69). Le découpage en paquetage doit traduire un découpage
logique du système à construire qui corresponde à des espaces de nommage
homogènes.
Le futur système que nous allons mettre en place sera collectionné de
9 packages ci-après :
Administrateur : Paquetage regroupant l’ensemble des classes
permettant d’effectuer les actions sur un administrateur :
o Ajouter Administrateur ;
o MAJ Administrateur.
Agents : Paquetage regroupant l’ensemble des classes permettant
d’effectuer les opérations sur un agent :
o Ajouter agent ;
o Liste agents ;
o MAJ Agent ;
o Ajout Congé ;
 84

o MAJ Congé.
Application : Paquetage regroupant l’ensemble des classes
permettant le démarrage du système :
o Menu ;
o Index ;
o Login.
Etats : Paquetage regroupant l’ensemble des classes permettant
d’imprimer les documents du système :
o Fiche Présence ;
o Fiche Visiteurs ;
o Liste des Agents ;
o Menu impression.
Présence : Paquetage regroupant l’ensemble des classes permettant
d’effectuer les opérations sur les présences des agents :
o Ajout présence ;
o Ajout sortie ;
o MAJ présence ;
o MAJ sortie.
Visiteur : Paquetage regroupant l’ensemble des classes permettant
d’effectuer les opérations sur les visiteurs :
o Rechercher visiteur ;
o Consulter l’historique des visites.
Service : Paquetage regroupant l’ensemble des classes permettant
d’effectuer les opérations sur les services :
o Ajouter service ;
o MAJ service.
Images : Paquetage regroupant l’ensemble des images utilisées dans le
système ;
Live Recognition : Paquetage regroupant l’ensemble des classes
permettant d’effectuer la reconnaissance faciale :
o Live Recognition Application ;
o Live Recognition View.
 85

Ainsi donc, le diagramme de paquetage (figure N°36) essaye de

représenter tout ce que nous venons d’énumérer ci-haut.

Figure N°44 : Diagramme de paquetage de notre système

III.3.6. IMPLEMENTATION
Cette phase correspond à la production du logiciel sous forme de
composants, de bibliothèques ou de fichiers. De cela, dans le présent point,
nous allons décrire les collaborations d’instances qui constituent des
fonctions particulières du système à développer (diagramme de structure
composite). Enfin, nous allons présenter l’architecture physique de notre
application sous forme des nœuds et artefacts (diagramme de déploiement).

III.3.6.1. Elaboration du diagramme de structure Composite

Le diagramme de structure composite permet de décrire des
collaborations d’instances (de classes, de composants…) constituant des
fonctions particulières du système à développer.
Une collaboration représente un assemblage de rôles d’éléments qui
interagissent en vue de réaliser une fonction donnée. Il existe deux manières
de représenter une collaboration (Joseph Gabay et David Gabay ; 2008,
p.73) :
représentation par une collaboration de rôles ;
représentation par une structure composite : le diagramme de
structure composite.
 86

Dans le cadre de notre travail, nous avons opté pour la représentation par
une structure composite. En revanche, nous avons représenté quelques
structures composites (figure N°37) de notre application.

Figure N°45 : Diagramme de structure composite de notre système

III.3.6.2. Elaboration du diagramme de déploiement

Pour ce qui concerne le déploiement de notre futur système, nous
aurons trois nœuds à savoir :

Un serveur des applications : dans le cadre de notre travail, le serveur

des applications sera installé sur les postes des utilisateurs (qui sont
les administrateurs des services) ;
Un serveur de base de données : la base de données sera installée sur
une autre machine et sera partagée au moyen d’un réseau LAN ;
La caméra : dispositif qui sera associé aux applications afin d’effectuer
le processus de reconnaissance faciale.
 87

Figure N°46 : Diagramme de déploiement de notre système

III.3.7. TEST
Pour s’assurer d’une démarche qualité et pour être sûr que le produit
correspond aux attentes prédéfinies au départ, des tests ont été réalisés le
long du cycle de vie du projet. Pour bien mener nos tests nous avons
formalisés les procédures de tests avec trois questions prépondérantes :
Quoi ? Quand ? Qui ? Comment ?
III.3.7.1. Quoi ? Qu’est ce qu’on teste ?

L’application: nous avons testé toutes les fonctionnalités et modules

de notre application et ceci sur différents environnements techniques
afin de prévoir des processus d’utilisation sans risque.
Les contenus : nous avons testé le comportement du module avant et
après son intégration dans l’application et ceci même pendant le
développement ce qui nous a permis d’adapter notre méthodologie de
développement.
 88

III.3.7.2. Quand ? A Quel moment tester ?

Les tests doivent être réalisés le long du processus de création de notre
application. Nous avons démarré les tests dès la phase de conception, de
construction et de déploiement.
III.3.7.3. Qui ? Qui est responsable des tests ?
En tant que développeur, j’ai été amené à préparer les procédures de
tests ainsi que veiller a leur bon déroulement. Pour la validation, c’est
l’équipe projet en entier qui s’en est occupée.
III.3.7.4. Comment ? Quels sont les types de tests à faire ?
Pour notre projet, nous avons programmés trois types de tests afin de
pouvoir cerner toutes les facettes du dispositif et sa réalisation.

Tests de fonctionnalités : tests des boutons de navigation, des

menus et sous menus.
Tests d’ergonomie-navigation : tests sur l’interactivité, tests de tous
les scénarios et dans tous les cas possibles, tests de tous les clicks et
les éventuels messages d’erreurs.
Tests techniques : tester la plate forme sur plusieurs configurations
matérielles et logicielles, une gamme variée d’ordinateurs et la montée
en charge sur la plateforme pressentie.
 89

Conclusion partielle

Au cours de ce chapitre, il a été question d’étaler quelques méthodes

de développement informatique ; en suite, nous avons fait un choix de la
méthodologie utilisée et enfin nous avons procéder par le développement
avec la méthode sélectionnée. Pour modéliser notre application, nous avons
utilisés la démarche UP7 qui est un progrès de la démarche UP et qui est
beaucoup plus pragmatique et détaillée. Ainsi donc, au cours de ce chapitre
nous avons présentés toutes les sept activités de la démarche entre autre : la
modélisation métier, l’exigence fonctionnelle, l’analyse des cas d’utilisation,
la synthèse de l’analyse, la conception, l’implémentation et le test.
Au niveau de la modélisation métier, il a été question de pénétrer
l’environnement dans lequel se situera notre futur système, son
fonctionnement ainsi que les processus avec lesquels il concourra au sein de
l’ISP-Bukavu. Après avoir compris cela, une exigence fonctionnelle a s’avéré
importante afin de recueillir les besoins des utilisateurs. Nous avons ainsi
identifié les acteurs et leurs actions telles que demandé par la maîtrise
d’ouvrage en les formalisant par un diagramme de cas d’utilisation système
(figure N°23). Afin d’avoir une vue informatique du système, l’analyse des cas
d’utilisation a été abordé. Par ailleurs, la synthèse de l’analyse nous a
assistés à vérifier si tous les cas d’utilisations métiers (maitrise d’ouvrage)
synchronisaient avec les cas d’utilisations informatiques (maitrise d’œuvre)
au moyen d’une matrice de validation. En revanche, la conception est venue
montrer les aspects techniques des objets représentés dans les autres
activités ; nous avons ainsi élaboré les diagrammes de classes techniques
ainsi que les diagrammes de séquences techniques. L’implémentation quant
à elle est venue nous donner une vision sur la manière dont notre système
sera déployé. Enfin, un plan de test a été raffiné afin de s’assurer du bon
fonctionnement de notre application. Disons que toutes ces manœuvres ont
été menées du point de vue abstrus. Afin maintenant de le matérialiser, le
chapitre suivant essayera de nous montrer comment la réalisation sera faite
du point de vue pratique en nous présentant le résultat bien sûre.
 90

CHAPITRE QUATRIEME

LA REALISATION DU SYSTEME
D’INFORMATION
Ce chapitre se subdivise en cinq sections. La première section propose
le choix et la présentation du langage de programmation utilisée, la
deuxième présente le choix et la présentation du SGBD utilisé, la troisième
essaye de présenter la réalisation de l’application en exposant les structures
des tables, requêtes, formulaires, états de sorties ainsi que les outils utilisés
lors du développement. La quatrième quant à elle consiste à faire une
estimation de la durée et du coût de réalisation du logiciel. En fin, la
dernière section consiste à faire la présentation du guide de l’utilisateur.

IV.1. CHOIX ET PRESENTATION DE LANGAGE DE PROGRAMMATION

IV.1.1. Choix du langage utilisé

Pour réaliser notre logiciel, nous avons opté JAVA comme langage de
programmation car il présente des qualités très nécessaires requises par
notre logiciel de gestion de présences par reconnaissance faciale. Il s’agit
entre autres :
Java est portable : il est indépendant de toute plateforme ;
Java est orienté objet : comme la plupart des langages récents, Java
est orienté objet. Chaque fichier source contient la définition d'une ou
plusieurs classes qui sont utilisées les unes avec les autres pour
former une application. Java n'est pas complètement objet car il définit
des types primitifs (entier, caractère, flottant, booléen,...) ;
Java est multitâche : Il permet l'utilisation de threads qui sont des
unités d'exécutions isolées. La JVM, elle même, utilise plusieurs
threads.
 91

IV.1.2. Présentation du langage JAVA

Depuis sa première diffusion publique le 23 mai 1995, le langage et les
plateformes Java ont été marqués par de nombreux événements
(DOUDOUX ; 2016, p.78). Sun puis Oracle ont toujours fourni gratuitement
un ensemble d'outils et d'API pour permettre le développement de
programmes avec Java. Ce kit, nommé JDK, est librement téléchargeable sur
le site web d'Oracle :
http://www.oracle.com/technetwork/java/index.html
Le JRE (Java Runtime Environment) contient uniquement
l'environnement d'exécution de programmes Java. Le JDK contient lui-même
le JRE. Le JRE seul doit être installé sur les machines où des applications
Java doivent être exécutées. Depuis sa version 1.2, Java a été renommé Java
2. Les numéros de version 1.2 et 2 désignent donc la même version. Le JDK
a été renommé J2SDK (Java 2 Software Development Kit) mais la
dénomination JDK reste encore largement utilisée, à tel point que la
dénomination JDK est reprise dans la version 5.0. Le JRE a été renommé
J2RE (Java 2 Runtime Environment).
Trois plateformes d'exécution (ou éditions) Java sont définies pour des cibles
distinctes selon les besoins des applications à développer :
Java Standard Edition (J2SE / Java SE) : environnement d'exécution
et ensemble complet d'API pour des applications de type desktop.
Cette plate-forme sert de base en tout ou partie aux autres
plateformes ;
Java Enterprise Edition (J2EE / Java EE) : environnement d'exécution
reposant intégralement sur Java SE pour le développement
d'applications d'entreprises ;
Java Micro Edition (J2ME / Java ME) : environnement d'exécution et
API pour le développement d'applications sur appareils mobiles et
embarqués dont les capacités ne permettent pas la mise en œuvre de
Java SE.
La séparation en trois plateformes permet au développeur de mieux cibler
l'environnement d'exécution et de faire évoluer les plateformes de façon plus
 92

indépendante. Avec différentes éditions, les types d'applications qui peuvent

être développées en Java sont nombreux et variés :
Applications desktop ;
Applications web : servlets/JSP, portlets, applets ;
Applications pour appareil mobile (MIDP) : midlets ;
Applications pour appareil embarqué (CDC) : Xlets ;
Applications pour carte à puce (Javacard) : applets Javacard ;
Applications temps réel ;
L’application que nous avons développée au cours de ce travail de mémoire
est de type « Application Desktop ».

IV.2. CHOIX ET PRESENTATION DU SGBD

IV.2.1. Choix du SGBD utilisé

Dans le cadre de notre travail de mémoire, notre choix a porté sur le
Système de Gestion de Base de Données (SGBD) MySQL pour des raisons
suivantes :

Il a un caractère OpenSource ;
Il a des fonctionnalités de plus en plus riches ;
Il est ouvert presque à tous les langages de programmation du
marché ;
Il est fonctionnel sur les systèmes les plus courants (les distributions
classiques de LUNIX, Windows, Mac OS, BSD, Novell et les dérivés
d’UNIX) ;
Il est facile à utiliser si on peut le dire aussi.

IV.2.2. Présentation de MySQL

MySQL est à la fois le nom du SGBD et le nom de la société (qui
se nomme en fait MySQL AB, décrite sur http://www.mysql.com ) dont le
siège se trouve en Suède à Uppsala –compter une cinquantaine de
kilomètres au nord de Stockholm. Selon leurs dires, leur serveur de
données, qui est écrit en C et C++, serait installé de façon opérationnelle sur
plus de six millions de sites. D’un point de vue coût, l’utilisation du SGBD
sur des projets importants (entre 250 000€ et 500 000€) ferait économiser
90 % sur le prix des licences du serveur, 60 % sur les ressources système,
 93

70 % sur le prix du matériel, 50 % sur les tâches d’administration et de

support (C. Soutou ; 2006, p.3).
La figure suivante (merci au passage à http://www.iconarchive.com )
présente la majeure partie des fonctionnalités de MySQL qui se positionnent
au sein du serveur de données(SGBD).

Figure N°47 : Offre MySQL (C. Soutou ; 2006, p.5)

Les API permettent d’intégrer SQL dans des programmes de différents
langages. Le langage SQL sera utilisé par tous ceux (manuellement ou par
un outil) travaillant sur la base de données (administrateur, développeur,
utilisateur). Le langage procédural de MySQL permet d’incorporer
nativement tout ordre SQL dans un programme. Concrètement, une fois
téléchargé et installé, vous avez accès à un SGBD, un client en mode texte
(interface de commande). Les pilotes ODBC, JDBC, API pour les langages C
et C++, et les outils MySQL Administrator, MySQL Query Browser, et MySQL
Migration Toolkit sont à télécharger puis à installer séparément. Pour éviter
de télécharger tous ces outils séparément, nous avons utilisé le serveur
WAMP qui contient déjà toutes les fonctionnalités.
 94

IV.3. REALISATION DE L’APPLICATION

Pour réaliser notre application, nous avons manipulé les objets ci-
après : les tables, les requêtes, formulaires ainsi que les états de sortie.

IV.3.1. Tables
Notre application était doté de 8 tables dont 7 ont été implémenté dans
MySQL et une autre qui était un fichier à part mais accessible par JAVA.
Voici un exemple des codes sources pour la création des tables visiteur et
agent.

Figure N°48 : Codes source de la table « Visiteur »

Figure N°49 : Codes source de la table « Agent »

Signalons qu’il y a aussi des contraintes liées à la table Agent.

IV.3.2. Requêtes
Pour réalisé nos requêtes, nous avons utilisé le langage SQL. Dans
notre application, nous avons utilisé plusieurs requêtes mais nous allons
seulement présenter l’exemple d’une requête qui nous amène la situation de
présence d’un agent au cours d’une période donnée.
 95

Figure N°50 : Requête pour affiche les entrées sorties périodiques

IV.3.3. Formulaires
Afin de réaliser les différents formulaires que vous allez exploiter au
niveau du guide de l’utilisateur, nous avons utilisé les packages Javax.swing
et Java.awt de JAVA.

IV.3.4. Etats
Pour réaliser les Etats de sorties, nous avons utilisé la librairie Java
Dynamic reports. Voici un exemple d’une méthode java qui nous permet
d’afficher la liste des agents avec Dynamic Reports:

Figure N°51 : Méthode java pour générer la liste des agents avec Dynamic Reports
 96

IV.3.5. Outils utilisés

Pour réalisé notre application, nous avons utilisé les outils ci-après :

La librairie Luxand Face SDK ;

La librairie Dynamic Reports ;
Le NetBeans ;
Le serveur WAMP.
a) L’API FaceSDK

Luxand FaceSDK est une plateforme transversale avec sa librairie de

détection et reconnaissance faciale qui peut être facilement intégré dans une
application. Ainsi cet API (Application Programming Interface) nous offre la
possibilité de détecter et capturer les faces dans une photo ou dans une
vidéo, d’en extraire les caractéristiques, de reconnaitre le sexe du sujet, de
reconnaitre l’expression faciale du sujet et de reconnaitre à quelle autre face
elle correspond. FaceSDK est donné avec ce qu’on appel « Tracker API » qui
permet de détecter et reconnaitre les faces dans une vidéo. Il simplifie la
reconnaissance en temps réel en mettant en place des fonctions qui
permettent d’enrôler les faces avec les noms et les reconnaitre plus tard.
Signalons que le Luxand FaceSDK détecte les caractéristiques de 70 points
sur la face et utilise la logique de multiprocesseurs pour booster la
reconnaissance.
Signalons que l’API FaceSDK vient souvent avec des codes sources
exemples pour aider le développeur dans la programmation. Ainsi, nous
présenterons au niveau des annexes un exemple de la classe
LiveRecognitionView que nous avons eu à adapter et améliorer pour la
reconnaissance faciale dans notre application. Nous avons utilisé la version
6.2 disponible sur http://luxand.com.
 97

b) La librairie Dynamic Reports

Le Dynamic Report est un API gratuit (Open Source) pour la production

des rapports en java. Il est basé sur la logique de JasperReport et utilise le
JasperViewer pour afficher l’aperçu avant impression. La version que nous
somme entrain d’utiliser nous permet d’exporter le document vers les
versions suivantes : PDF, RTF, ODT, DOCX, HTML et XLS. La librairie est
disponible sur http://www.dynamicreports.org/.

c) Netbeans

Netbeans est un environnement de développement intégré qui nous a

offert un espace pour écrire les codes sources de notre application. Nous
avons utilisé la version 8.0.1 de Netbeans supportant les technologies ci-
après : Java Standard, javaFX, java web, java EE, HTML5, java ME, java
Card, Maven, PHP, Groovy et C/C++. L’outil est disponible sur
www.netbeans.org.

d) Le serveur WAMP

Windows Apache MySQL PHP est un serveur local qui nous permet de
simuler le rôle d’un serveur sur la machine locale. Nous avons utilisé ce
système afin d’exploiter le serveur MySQL car notre logiciel fonctionnera
sous une base de données partagée. Le système est disponible sur
http://www.wampserver.com/.

e) Environnement matériel

Nous avons utilisé les hardwares suivant lors du développement de notre

application :

Un ordinateur TOSHIBA ;
Capacité de disque dur : 320GB ;
Processeur : Intel(R) Core(TM) i5-2520M CPU @ 2.50GHZ 2.50GHZ ;
Mémoire RAM : 4G0 ;
Caméra Webcam pour Ordinateur.
 98

IV.4. ESTIMATION DU COUT DU LOGICIEL

IV.4.1. Présentation de la méthode COCOMO

COCOMO (Constructive Cost Model) est une méthode qui se base sur
une approche algorithmique pour déterminer l’effort et le temps de
développement d’une application (DELCAMBRE ; 2003, p.2). Il existe
plusieurs versions de COCOMO, notamment la version COCOMO 81-
COCOMO de base, COCOMO 81-intermédiaire, COCOMO 81-détaillé et la
version COCOMO II. Dans le cadre de ce projet de mémoire, nous allons
utiliser la version COCOMO 81 de base.
Cette méthode couvre les phases du cycle de développement suivantes :

Aspect technique
Analyse fonctionnelle
Analyse organique
Programmation
Tests
Documentation
Qualité
Contrôle
Gestion
Encadrement
Suivi du projet
Gestion des configurations
Evolution du produit

Signalons qu’elle ne prend pas en compte les activités concernant les

phases ne faisant pas partie du cycle de développement
- Les études de faisabilité
- La spécification des besoins techniques
- La validation opérationnelle chez le client
- L’exploitation
- La maintenance
Son principe est basé sur le nombre de lignes de code en Kilo (KLOC). Sont
prises en compte :
 99

Les instructions et les déclarations de format ou de données

effectivement produites concernant uniquement le logiciel fournit
au client ;
Les commandes des différentes procédures.

Cette méthode est dotée de 3 modèles de calcul et distingue 3 types de

projets (DELCAMBRE ; 2003, pp.4-5) :

Organique ‘Organic’

Application simple, de routine, réalisée par une équipe expérimentée

ayant l’habitude de travailler ensemble, maîtrisant le langage et
l’environnement de développement.

Semi-Détaché – ‘Semi-detached’

Niveau intermédiaire, le projet n’est ni trop simple ni trop compliqué,

l’équipe de développement a déjà réalisé quelques projets ensemble mais
n’est pas totalement rodée. Les technologies et le domaine d’application sont
un peu flous, mais pas de grosses difficultés.

Imbriqué –‘Embedded’

Techniques innovantes, organisation complexe, couplage fort avec

beaucoup d’interactions. Technologie et domaine nouveau, équipe ‘jeune’.
Notre projet est de type organique car il ne s’agit que d’une application
simple, dont le langage et l’environnement de développement sont maitrisés.

IV.4.2. Estimation du coût du Logiciel

Dans le tableau ci-dessous, nous allons présenter un ensemble
d’équations pour calculer l’effort et la productivité selon le type de projet.
Tableau N°4 : Equations pour calculer l’effort et la productivité
Type de projet Effort Productivité
Organique PM=2,4*(KLOC)1,05 TDEV=2,5*(PM)0,38
Semi-détaché PM=3*(KLOC)1,12 TDEV=2,5*(PM)0,35
Imbriqué PM=3,6*(KLOC)1,20 TDEV=2,5*(PM)0,32
Source : (Bourshis David et alii ; 2002, p.8)
Avec :
PM= Effort en personne mois ;
 100

KLOC= Milliers de ligne de code

TDEV= Temps de développement
P= PM/ TDEV= Nombre de personnes requises
Nous estimons 6000 lignes de codes pour notre application. Afin d’avoir
sa valeur en KLOC, nous allons faire une division par 1000. Ainsi nous
aurons le résultat suivant :
6000
= =6
1000
En ayant déjà une idée sur le kilo code, nous pouvons ensuite calculer
l’effort en personne mois de chacun avec la formule suivante :
, ,
= 2,4 Alors = 2,4 6 = 15,75 .
Nous voyons que dans le développement de ce logiciel, l’effort en
personne sera de 15,75 par mois. Après avoir calculé cet effort, nous
pouvons en suite savoir le temps de développement que va prendre notre
logiciel en appliquant la formule suivante :
, ,
= 2,5 Alors = 2,5 15,75 = 7,13
Partant de ce résultat, nous observons que le temps de développement de
notre logiciel est de 7 mois. Maintenant, calculons le nombre des personnes
qui sera requis pour le développement de notre logiciel par la formule
suivante :
,
= Alors = = 2,2
,

Notre projet aura besoin de 2 personnes pour développer et terminer notre

logiciel au cours d’une période de 7 mois.
Ayant déjà une connaissance sur la durée de développement et le
nombre des développeurs, nous allons ensuite poursuivre par le calcul du
coût total du logiciel. Pour ce qui concerne notre projet, nous avons fixé le
salaire de chaque développeur à 500$ le mois. Ainsi, le coût du logiciel sera
calculé par la formule suivante :
û =
Alors
û = 2,2 7,13 500 = 7 843$
En conclusion, partant de la méthode de COCOMO 81 de base, nous
estimons le coût de notre logiciel à 7 843$.
 101

IV.5. Présentation de quelques interfaces utilisateurs

Dans le présent point, nous allons présenter un guide d’utilisateur qui

permettra à l’utilisateur du système à prendre contact avec notre
application.
Après avoir installé l’application, double-cliquer sur l’icône qui
sera implanté sur votre bureau et l’application se lancera de la manière
suivante :

Figure N°52 : Démarrage de notre application

A la fin du chargement de l’application, la page d’accueil ci-après va
s’afficher :

Figure N°53 : Page d’accueil de notre application

Vous cliquez sur le bouton « START » et la page d’authentification va
s’afficher :
 102

Figure N°54 : Espace d’authentification

L’utilisateur va introduire son login et mot de passe ; une fois que le
login et le mot de passe sont corrects, le système va vérifier le droit de
l’utilisateur et savoir s’il est connecté comme service ou comme
administrateur. En suite leurs sessions seront différentes selon leurs droits.
Ci-dessous, nous présentons un exemple de la session d’un administrateur
et celle d’un chef de service :

Figure N°55 : Menu principal de la session de l’Administrateur

 103

Figure N°56 : Menu principal de la session d’un chef de service

En nous référent sur la session de l’administrateur, le menu principal est
composé des modules ci-après :

La gestion des agents ;

La gestion des services ;
La gestion de la caméra ;
L’impression des documents ;
La recherche des visiteurs ;
La gestion des administrateurs ;
La gestion des présences ;
La gestion des sorties ;
La gestion des congés.

Étant donné que l’application est tellement vaste, nous avons présenté
seulement trois modules entre autre :

La gestion des agents ;

La gestion de la caméra ;
L’impression des documents ;
La recherche des visiteurs.
 104

IV.5.1. La gestion des agents

Le module de gestion des agents comprend les sous modules ci-après :

Ajouter un agent ;
Capturer la photo de l’agent ;
Modifier un agent.

IV.5.1.1. Ajouter un agent

Pour ajouter un agent, à partir du menu principal, on clique sur le
bouton « Gérer les agents » et le formulaire suivant va s’afficher :

Figure N°57 : Formulaire d’ajout agent

Il suffit de compléter les champs du formulaire et appuyer sur le bouton
« Enregistrer » et un message de confirmation d’enregistrement va s’afficher
comme suit :

Figure N°58 : Message de confirmation d’un enregistrement

IV.5.1.2. Capturer la photo de l’agent

Pour capturer la photo de l’agent, vous devez cliquer sur le bouton
« CAPTURER LA PHOTO » (figure N°57) et la fenêtre de capture va s’afficher.
 105

Ci-dessous, nous présentons un exemple d’un agent déjà enregistré, qui se

présente devant la caméra pour capture de la photo.

Figure N°59 : Détection de la face devant la caméra

Une fois la face de l’agent sera détectée, on doit passer par la phase
d’apprentissage en enregistrant la face de l’agent avec comme nom son
numéro matricule. Pour le faire, on clique dans la face concernée et une
boite de dialogue va s’afficher dans laquelle on doit taper le numéro
matricule associé à la face.

Figure N°60 : Exemple d’enrôlement d’un agent dans le système

 106

IV.5.1.3. Modifier l’agent

Toujours à partir du formulaire « Ajout agent », vous cliquez sur le
menu « Modifier » et le formulaire ci-dessous va s’afficher.

Figure N°61 : Formulaire de modification et suppression d’un agent

Après avoir sélectionné un agent, ces informations seront affichées sur le
formulaire et l’utilisateur pourra les modifier et décider soit de supprimer ou
de modifier. Une fois que l’utilisateur clique sur « Modifier », le message de
confirmation suivant s’affichera :

Figure N°62 : Message de confirmation d’une modification

IV.5.2. La gestion de la caméra

Ce module contient les fonctions relatives à la reconnaissance faciale
afin de certifier l’entrée ou la sortie d’un agent. Dans le même module, nous
avons la fonction qui gère aussi le stockage des visages non reconnus devant
la caméra. Pour lancer la fenêtre de reconnaissance, vous cliquez sur le
bouton « Lancer caméra » à partir du menu principal.
 107

a) Exemple d’un agent devant la caméra

Figure N°63 : Processus de reconnaissance de la face d’un agent

Comme nous le constatons, pour un agent dont son image est déjà
enregistrée, son numéro matricule apparait en dessous de sa face. Signalons
que c’est à partir de ce numéro matricule que nous sommes entrain de
passer une requête dans la base de données pour certifier la présence ou la
sortie.

b) Exemple d’un inconnu devant la caméra

Figure N°64 : Exemple d’un inconnu devant la caméra

Dans le cas présent, la face devant la caméra n’est pas reconnue
comme agent ; par conséquent, elle sera enregistrée comme visiteur avec la
date et l’heure d’arrivée.

IV.5.3. L’impression des documents

Notre application produit 4 types de documents :

La fiche de présence de l’agent pendant une période donnée ;

La fiche des absences de l’agent pendant une période donnée ;
La liste des agents ;
 108

La liste des services.

Pour accéder à ces documents ; à partir du menu principal, vous cliquez

sur bouton « Impression des Docs » et le formulaire suivant va apparaître :

Figure N°65 : Menu Impression

Voici l’exemple d’une liste des agents en cliquant sur le bouton
« VISUALISER LA LISTE GLOBALE DES AGENTS » :

Figure N°66 : La liste des agents

 109

Voici un exemple d’une fiche de présence d’un agent :

Figure N°67 : La fiche mensuelle de Présence d’un agent avec un graphique

Voici un exemple d’une fiche des absences d’un agent :

Figure N°68 : La fiche périodique des absences d’un agent

IV.5.4. La recherche des visiteurs

Lors de la conception de notre application, nous avons tenu compte
des visages qui ne pouvaient que passer devant la caméra. Ainsi, ils sont
 110

considérés comme des visiteurs. Cependant, en cliquant sur le bouton

« Rechercher », le formulaire ci-après apparaîtra, vous permettant ainsi
d’effectuer une recherche des visites par date :

Figure N°69 : Exemple d’un visiteur après la recherche

Conclusion partielle
Dans le présent chapitre, il a été question d’expliquer comment la
réalisation (la base de données et la programmation) a été faite. Nous avons
montré comment nous nous sommes servis du duo JAVA-MYSQL afin de
développer notre application de gestion de présence sur laquelle nous avons
associés la librairie Luxand Face SDK pour la reconnaissance faciale. Nous
avons enfin parachevé par une présentation des quelques interfaces
utilisateurs de notre application. Cependant, comme nous l’avons annoncé
au niveau de la revue empirique, nous ne sommes pas le premier à aborder
cette thématique. Par conséquent, le dernier chapitre fera l’objet d’une
discussion entre le travail de Monsieur ANWAR du fait que son sujet est
similaire au notre, mais aussi une discussion par rapport à d’autres
applications de reconnaissance faciale que nous avons découvert sur
internet.
 111

CHAPITRE CINQUIEME

DISCUSSIONS ET RECOMMANDATIONS

Dans le présent chapitre, il sera question de faire des discussions sur

les résultats que nous venons d’obtenir en montrant les aspects résolus
ainsi que quelques challenges restants mais aussi lancer quelques
recommandations.

V.1. DISCUSSIONS DE RESULTAT

V.1.1. Discussions
Nous venons donc de réaliser une application de reconnaissance
faciale pour la gestion des présences des agents de l’ISP/Bukavu. Avec la
dite application, désormais l’agent ne signera plus à la main sa présence
mais plutôt se présentera devant la caméra pour certifier l’entrée et la sortie.
Le gestionnaire du personnel aura la possibilité de visualiser les absences
des agents et savoir ainsi les pénalités à retrancher.
En regardant avec un œil comparatif ce qu’avait fait Monsieur
Kalghoum ANWAR de la Tunisie, la gestion des présences se faisait par un
système de pointage en capturant la photo de l’agent manuellement et il
n’avait pas en plus gérer l’enregistrement des sorties des agents.
Comparativement avec ce que nous avons eu comme résultat, notre système
de pointage se fait de manière automatique sans mécanisme de la part de
l’agent et en temps réel et qu’après une heure donnée, le système
commencera à enregistrer les sorties des agents. Une attention particulière à
été mené sur les absences ainsi que les congés des agents. Nous avons
intégré dans notre application un système de gestion des congés qui
permettra au chef du personnel d’enregistrer un congé d’un agent afin que le
système ne spécifie pas sa présence au travail alors qu’il est en congé.
L’application que nous avons développée est même capable de détecter le
nombre des absences accusées par un agent grâce à un algorithme de
détection des absences que nous avons mis en place et faciliter ainsi le
travail du chef du personnel en calculant même les pénalités mensuelles qui
seront retranchées sur la prime de l’agent.
 112

Nonobstant tout ce que nous avons fait, notre système requiert

toujours une collaboration avec l’agent surtout sur les éléments ci-après :

Ne pas faire une inclinaison de plus de 30° lors de la prise de présence

devant la caméra ;
Ne pas porter des lunettes fumées lors de sa présentation devant la
caméra ;
Eviter toute sorte d’occultation (port des chapeaux par exemple).

Lors du développement de notre application, nous avons trouvé qu’il

était possible de tromper le système en présentant une photo d’un agent
devant la caméra et le système validerait sa présence au travail, un peu
comme on trompe la plus part des systèmes de reconnaissance facial au
monde. Cependant, nous avons quand même réussi à développer un
algorithme pour différencier un vrai visage et une photo devant la caméra.

V.1.2. Algorithme de détection d’une photo devant la caméra

Dans le présent algorithme, nous sommes partis de l’hypothèse selon
laquelle les yeux d’une personne (une personne normale) ne peuvent pas
rester statiques en termes de variation de mouvements. Ainsi, Dans la
boucle de détection des faces qui sera lancée, nous seront entrain de vérifier
le taux d’ouverture des yeux de la face qui sera stocké dans la variable ( ).
Une fois le taux détecté, sa valeur sera stockée dans une variable tempo
( _ ) pour une comparaison ultérieur. En suite, on fera la différence
entre et _ et si la différence est de 0, c'est-à-dire que l’ancienne
valeur de qui était stockée avant dans _ est similaire à la nouvelle
valeur. Autrement, il n’y a pas eu de variation de mouvement des yeux,
chose qui nous conduit à suspecter que la face se trouve sur une photo et
non une face présente en temps réel devant la caméra. Ci-dessous, nous
présentons cet algorithme d’une manière abrégée.
 113

Algorithme : Détection d’une photo devant la caméra

Entrée : I : flux vidéo ;

Déclaration des variables Ve, face, tmp_Ve ;
Initialisation

tmp_Ve 0;

Ve 0;

face 0;

Boucle de détection des faces

Pour itération 1, 2…..., N REPETER

Face Détection face (I) ;
tmp_Ve Ve ;
Ve ouverture yeux (face) ;
SI (Ve - tmp_Ve) = 0

ALORS Afficher Visage suspecté comme photo ;

STOP
SINON CONTINUER
FIN SI
Arrêt de l’exécution
STOP

Figure N° 70 : Algorithme de détection d’une photo devant la caméra

V.1.3. Mesure de la qualité de l’algorithme

Avant de procéder à la mesure de la qualité de notre algorithme, nous

allons donner des exemples de mesure des qualités des logiciels et montrer
la mesure qui sera utilisée pour notre cas.
Exemples des métriques logiciels (JR Kala ; 2017, p.11):
métriques de taille
plus la taille est grande, plus la complexité est haute
e.g. nombre de lignes de code, nombre de paramètres de méthode
métriques de complexité
indiquent les méthodes qui sont difficile de comprendre
e.g. complexité cyclomatique
métriques de couplage
 114

indiquent les éléments qui ont trop d'interdépendances avec

d'autres
métriques de cohésion
métriques de similarité
peuvent indiquer le code dupliqué
Afin de tester notre algorithme, nous avons utilisé la métrique de complexité
notamment la complexité cyclomatique.
1) Construction de l’ordinogramme

i 0

Figure N° 70 : Ordinogramme de l’algorithme de détection d’une photo devant la caméra

 115

2) Calcul de la complexité cyclomatique

complexité cyclomatique =
nombre de chemins indépendants dans le graphe de flux de
commande (control flow graph) d'un programme
limite supérieure pour le nombre de tests nécessaires pour
s'assurer que toutes les instructions ont été exécutées au moins
une fois
Définition formelle (basée sur la théorie de graphe)
CC(G) = nombre de régions dans le graphe G
= nombre de arcs - nombre de noeuds + 2
Afin de déterminer le nombre des jets de données, nous allons utiliser la
formule ci-après :
( )=( )+2
Nombre d’arcs = 11
Nombre de nœuds = 10, alors :
( ) = (11 10) + 2 , ( )=3
C'est-à-dire que nous feront 3 jets de données pour tester notre
algorithme de détection d’une photo devant la caméra.
Le problème de tromper le système de reconnaissance faciale avec une
photo est un problème qu’ont connu même les grandes entreprises depuis
2011. Prenons l’exemple du système « Face Unlock » implémenté dans
androïde 4.0 en 2011 qui était trompé par une simple photo12. Malgré les
autres mécanismes montés plus tard par Google, le système était toujours
trompé. La même erreur a été répétée chez SAMSUNG avec son système de
reconnaissance de visage implémenté dans Galaxy S8. Un de ces trous est
que la reconnaissance faciale de Galaxy S8 peut être trompée avec une
photo. Au moins, c'est ce qu'une vidéo de l'utilisateur de Periscope espagnol
Marcianophone prétend 13 . Environ six minutes dans la vidéo en langue

12https://arstechnica.com/gadgets/2017/03/video-shows-galaxy-s8-face-recognition-can-
be-defeated-with-a-picture/

13http://www.huffingtonpost.fr/2017/04/01/la-video-qui-fait-du-mal-a-la-reconnaissance-
faciale-du-galaxy-s8_a_22021404/
 116

espagnole de 40 minutes, vous pouvez voir le participant prendre un selfie

avec son téléphone personnel, puis le pointer vers le Galaxy S8, qui est
formé pour débloquer son visage. Il ne faut que quelques minutes de violon
avant que le Galaxy S8 entre et déverrouille avec une image, en passant de
l'écran de verrouillage "sécurisé" à l'écran d'accueil. Une fois que l'utilisateur
compose sa technique, il montre que l'astuce est facilement répétable.
Partant de ce qui précède, nous osons croire que nous avons apporté
quand même une petite piste de réflexion afin de mettre fin à ce problème
grâce à notre algorithme que nous avons mise en place.

V.2. RECOMMANDATIONS

Avec le résultat que nous venons de trouver, nous pouvons affirmer

notre hypothèse de départ qui stipule ce qui suit : « La mise en place d’un
logiciel de gestion de présence basé sur la technologie biométrique de
reconnaissance faciale serait un outil d’aide à l’adéquation de la
transparence en ce qui concerne les entrées et les sorties des agents à
l’ISP/Bukavu ». Cependant, nous recommandons à l’ISP/Bukavu de mettre
en place cet outil que nous avons développé afin de résoudre les quelques
problèmes liés à la gestion des présences qu’il connait en ce moment.
Toutefois, afin de bien faire fonctionner notre algorithme de distinction
d’une personne en temps réel et une photo que nous avons développé dans
ce mémoire, nous invitons aux agents de ne pas afficher des comportements
étranges devant la caméra. Cela veut dire qu’on leurs demande de ne pas
s’efforcer à ne pas bouger les yeux.
 117

CONCLUSION

Dans ce mémoire, nous nous sommes intéressés sur le problème de

gestion manuelle des présences des agents au sein de l’ISP-Bukavu. Cela
étant, l’objectif de notre travail était celui de concevoir et développer une
application de gestion des présences des agents basée sur la technologie
biométrique de reconnaissance faciale.
Au cours de ce travail, une analyse des différentes techniques de
reconnaissance développées au cours de ces dernières années a été
présentée, et cela pour mettre en évidence les particularités ainsi que les
avantages et les inconvénients de chacune d’entre elles. Cependant, nous
avons découvert des approches holistiques, locales et hybrides pour la
reconnaissance faciale. Compte tenu de la nature de notre système de
gestion de présence, il nous a fallu utiliser une technique de reconnaissance
qui serait très rapide et robuste du fait que le système fonctionnera à temps
réel. Nous avons d’abord commencé par l’usage de la librairie OPENIMAJ
(Open Intelligence Multimedia Analysis fo Java) qui fonctionnait avec un
système d’apprentissage à plusieurs modèles ; malheureusement le
problème de cette librairie résidait dans les variabilités intra et inter classe
du fait qu’il y avait toujours des confusions des visages dues au non
résistances du système face aux illuminations, expressions faciales et
variations de pose. Compte tenu de ces problèmes, nous avons migré vers
une autre librairie de reconnaissance faciale appelée « Luxand FaceSDK ».
FaceSDK dispose d’un outil qu’on appel « Tracker API » qui permet de
détecter et reconnaitre les faces dans une vidéo. Il simplifie la
reconnaissance en temps réel en mettant en place des fonctions qui
permettent d’enrôler les faces avec les noms et les reconnaitre plus tard. De
cela, à partir de cette API, nous avons développé l’aspect reconnaissance
faciale de notre application de gestion des présences. Une attention
particulière à été mené sur les absences ainsi que les congés des agents.
Nous avons intégré dans notre application un système de gestion des congés
qui permettra au chef du personnel d’enregistrer un congé d’un agent afin
que le système ne spécifie pas sa présence au travail alors qu’il est en congé.
L’application que nous avons développée est même capable de détecter le
 118

nombre des absences accusées par un agent grâce à un algorithme de

détection des absences que nous avons mis en place et faciliter ainsi le
travail du chef du personnel en calculant même les pénalités mensuelles qui
seront retranchées sur la prime de l’agent.
Cependant, à partir de ce résultat, nous pouvons affirmer notre
hypothèse de départ qui stipulait que la réalisation d’une application de
gestion des présences basée sur la technologie de reconnaissance faciale
serait une solution aux problèmes posés par la gestion manuelle des
présences des agents au sein de l’ISP-Bukavu.
 119

BIBLIOGRAPHE

I. OUVRAGES ET THESES
- Gabriela Dinescu (2014), Familiar faces: the effects of experience on
change blindness, thesis for the degree of Master of Cognitive Science,
Carleton University, Ottawa/Ontario
- Hadrien Mélot (2011), Eléments de rédaction scientifique en
Informatique, Faculté des sciences, Université de MONS
- Jean Michel DOUDOUX (2016), Développons en JAVA, GNU Free
Documentation
- Joseph Gabay et David Gabay (2008), UML2 Analyse et Conception :
Mise en œuvre guidée avec études de cas, DUNOD, Paris, ISBN 978-2-
10-053567-5
- Luxand FaceSDK 6.2 (2016), Face Detection and Recognition Library :
Developer’s guide, Luxand
- Randy Milbert et alii (2015), Multi-Camera Immersive Surveillance
System Phase II, Primordial, Inc.
- Sergey Demyanov (2015), Regularization methods for neural networks
and related models, thesis of PhD in the Department of Computing
and Information Systems, The University of Melbourne
- Shepell.fgi (2010), la gestion de l’effectif : réaliser vos objectifs
d’affaires grâce à une bonne gestion des absences, HRCO Inc.
- SOUHILA GUERFI ABABSA (2008), Authentification d’individus par
reconnaissance de caractéristiques biométriques liées aux visages
2D/3D, Thèse de doctorat en Sciences de l’ingénieur, Université Evry
Val d’Essone
- Varun JAIN (2011), Visual Observation of Human Emotions, thèse de
doctorat en Informatique, Université de GRENOBLE
- Walid Hizem (2009), Capteur intelligent pour la reconnaissance de
visage, Thèse de doctorat en électronique et informatique, Université
Pierre et Marie currie
- Yunlian Sun (2014), Advanced Techniques for Face Recognition under
Challenging Environments, A thesis submitted for the degree of Doctor
 120

of Philosophy in Computer Science and Engineering, University of

Bologna

II. MEMOIRES
- ASSUMANI NABONIBO (2014), Conception et mise en œuvre d’un
système trois-tiers de gestion d’un parc informatique cas de la SNEL,
mémoire, Inédit, ISC/Kinshasa
- BOUDJELLAL Sofiane (2010), Détection et identification des personnes
par la méthode biométrique, mémoire, inédit, UMMTO
- Kalghoum ANWAR (2011), réalisation d’une application de gestion des
présences via la reconnaissance faciale, mémoire, inédit, Institut
supérieur d’informatique et de gestion de kairouan, Tunisie
- PHITOS MBAA (2014), Conception et réalisation d’une plate-forme
d’e-Learning : cas de l’Institut Supérieur de Commerce de Kinshasa,
mémoire, Inédit, ISC/Kinshasa
- Serge KOMANDA BASEMA (2010), l’identification des personnes par
reconnaissance de visage pour la sécurité d’une institution bancaire,
mémoire, inédit, ISP/Bukavu
III. COURS
- Marcelin JILUS (2013), Ingénierie des systèmes logiciels, Master II
IASIG, Université de Doula
- MUSANGU LUKA (2015-2016), Cours de Conception des systèmes
d’information d’entreprises, L1 IG, ISP/BUKAVU.
IV. SITES WEB ET ARTICLES
- M.BELAHCENE-BENATIA Mébarka (2014), Authentification et
identification de visages basées sur les ondelettes et les réseaux de
Neurones, Revue science des matériaux
- PAUL VIOLA et MICHAEL J. JONES (2004), Robust Real-Time Face
Detection, International Journal of Computer Vision 57(2), 137–154
- Yun-Che Tsai et Chiou-Shann Fuh (2015), Office entrance control with
face recognition, Dept. of Computer Science and Information
Engineering, National Taiwan University, Taiwan
- http://www.journaldunet.com/management/expert/63059/la-
 121

reconnaissance-faciale---une-nouvelle-alliee-pour-l-entreprise.shtml
consulté le 21/04/2017 à 14h°°

- http://www.lemonde.fr/big-browser/article/2017/03/15/l-
application-de-reconnaissance-faciale-en-lien-avec-votre-profil-
facebook-n-existe-pas-encore_5094984_4832693.html consulté le
21/04/2017 à 14h20

- http://exclusiverh.com/articles/logiciel-gestion-temps/la-
reconnaissance-faciale-s-invite-dans-les-solutions-de-pointage.htm
consulté le 18/03/2017 à 15h°°

- http://cangaroorh.ca/nos-solutions/cangaroo-chrono/collecte-
donnees-presence/ consulté le 16/03/2017 à 16h°°

- https://www.sciencesetavenir.fr/decryptage/decryptage-la-
reconnaissance-faciale-mais-jusqu-ou-ira-t-elle_27964 consulté le
21/04/2017 à 14h30

- http://www.huffingtonpost.fr/2017/04/01/la-video-qui-fait-du-mal-
a-la-reconnaissance-faciale-du-galaxy-s8_a_22021404/ consulté le
21/04/2017 à 14h40

- https://arstechnica.com/gadgets/2017/03/video-shows-galaxy-s8-
face-recognition-can-be-defeated-with-a-picture/ consulté le
21/04/2017 à 14h45
 122

TABLE DES MATIERES

INTRODUCTION GENERALE.................................................................. 1
REVUE DE LA LITTERATURE................................................................ 6

I.REVUE THEORIQUE DE LA LITTERATURE ........................................... 6

I.1. Définitions des concepts .......................................................... 6

I.2. Système de reconnaissance faciale ......................................... 7
I.3. Principales difficultés de la reconnaissance de visage ........... 10
I.4. Algorithmes de détection et de reconnaissance de visage ...... 13
I.5. Conclusion partielle ............................................................. 22

II.REVUE EMPIRIQUE DE LA LITTERATURE ......................................... 24

1.SOUHILA GUERFI ABABSA (2008) ......................................... 24

2.Walid Hizem (2009) ................................................................ 24
3.BOUDJELAL Sofiane (2010) ................................................... 25
4.Serge KOMANDA BASEMA (2010) : ISP/BUKAVU ................... 25
5.Kalghoum ANWAR (2011) ....................................................... 25
6.Varun JAIN (2011) : Université de GRENOBLE ....................... 26
7.M.BELAHCENE-BENATIA Mébarka (2014) ................................ 26
Discussion ..................................................................................... 28

Conclusion Partielle ........................................................................................... 29

PRESENTATION DU MILIEU D’ETUDE ................................................. 30

II.1. PRESENTATION DE L’ISP-BUKAVU ....................................................... 30

II.1.1. Historique ........................................................................ 30

II.1.2. Missions de l’ISP-Bukavu ................................................. 32
II.1.3. Organigramme et Fonctionnement ................................... 33
II.1.3.1. Le Conseil de l’Institut .................................................. 34
II.1.3.2. Le Comité de Gestion .................................................... 37
II.1.3.3. Le Conseil de Section .................................................... 39
II.1.3.4. Le Conseil de Département ........................................... 39

II.2. ANALYSE ET CRITIQUE DE L’EXISTANT............................................... 40

 123

II.2.1. Gestion des présences des agents à l’ISP-Bukavu ............. 40

II.2.2. Les différents documents ................................................. 41
II.2.3. Critique et proposition de solution ................................... 43

Conclusion Partielle .............................................................................. 44

APPROCHE METHODOLOGIQUE ......................................................... 45

III.1. PRESENTATION DES QUELQUES METHODES DE

DEVELOPPEMENT INFORMATIQUE ............................................................... 45

III.1.1. MERISE .......................................................................... 45

III.1.2. UP .................................................................................. 46
III.1.3. RUP ................................................................................ 48
III.1.4. UP7 ................................................................................ 50

III.2. CHOIX ET DESCRIPTION DE LA METHODE CHOISIE ................... 51

III.2.1. Choix de la méthode ....................................................... 51

III.2.2. Description de la méthode UP7 ....................................... 51
III.2.3. Description du brainstorming ......................................... 53

II.3. DEVELOPPEMENT DE LA METHODE ............................................ 54

III.3.1. MODELISATION METIER ................................................ 54

III.3.2. EXIGENCES FONCTIONNELLES ..................................... 59
III.3.3. ANALYSE DES CAS D’UTILISATION ................................ 61
III.3.4. SYNTHESE DE L’ANALYSE ............................................. 77
III.3.5. CONCEPTION ................................................................. 79
III.3.6. IMPLEMENTATION ......................................................... 85
III.3.7. TEST .............................................................................. 87

Conclusion partielle .............................................................................. 89

LA REALISATION DU SYSTEME D’INFORMATION ............................... 90

IV.1. CHOIX ET PRESENTATION DE LANGAGE DE PROGRAMMATION .. 90

IV.1.1. Choix du langage utilisé .................................................. 90

IV.1.2. Présentation du langage JAVA ........................................ 91

IV.2. CHOIX ET PRESENTATION DU SGBD ........................................... 92

IV.2.1. Choix du SGBD utilisé .................................................... 92

 124

IV.2.2. Présentation de MySQL ................................................... 92

IV.3. REALISATION DE L’APPLICATION ................................................. 94

IV.3.1. Tables ............................................................................. 94

IV.3.2. Requêtes ......................................................................... 94
IV.3.3. Formulaires .................................................................... 95
IV.3.4. Etats .............................................................................. 95
IV.3.5. Outils utilisés ................................................................. 96

IV.4. ESTIMATION DU COUT DU LOGICIEL .......................................... 98

IV.4.1. Présentation de la méthode COCOMO ............................. 98

IV.4.2. Estimation du coût du Logiciel ........................................ 99

IV.5. Présentation de quelques interfaces utilisateurs .......................... 101

IV.5.1. La gestion des agents .................................................... 104

IV.5.2. La gestion de la caméra ................................................ 106
IV.5.3. L’impression des documents ......................................... 107
IV.5.4. La recherche des visiteurs............................................. 109

DISCUSSIONS ET RECOMMANDATIONS ............................................ 111

V.1. DISCUSSIONS DE RESULTAT...................................................... 111

V.1.1. Discussions ................................................................... 111

V.1.2. Algorithme de détection d’une photo devant la caméra ... 112
V.1.3. Mesure de la qualité de l’algorithme ............................... 113

V.2. RECOMMANDATIONS ................................................................. 116

CONCLUSION.................................................................................... 117
BIBLIOGRAPHE ................................................................................ 119
TABLE DES MATIERES ..................................................................... 122