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

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

B.P. 854/BUKAVU

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ées2 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 à 2D5 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

8 C’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 ABABSA (2008)

ACP

Développement d’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).

2 Walid Hizem (2009)

Acquisition avec réduction du temps

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

3 BOUDJELAL Sofiane (2010)

Eigenface

Développement d’une application de reconnaissance faciale.

4 Serge KOMANDA BASEMA (2010)

Eigenface et Comparative

Une application d’identification des individus.

5 Varun JAIN (2011)

L’approche Gaussienne Multi-

Echelle et l’ACP

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).

6 Kalghoum ANWAR (2011)

Méthode non

spécifiée dans le travail

Une application de gestion des présences pour la société SIEREEN.

7 M.BELAHCENE-BENATIA Mébarka (2014)

Analyse en Composant Principal et la classification avec le réseau de neurones

Une application de reconnaissance faciale avec un TEE=11.5%

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

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 ;

Agent

Services

Gestion du

personnel

Finance

1

2

3 4

5

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).

Figure N°19 : Schéma détaillé de la démarche

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)

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.

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

Logiciel de gestion des

présences

Gestion du

Personnel Finance

Agents

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

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.

HISTORIQUE

MAJ AGENT

MAJ SERVICE

MENU IMPRESSION

MENU PRESENCES

MENU CONGES

AJOUT

MAJ

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

l’agent Varchar (25)

Nom Nom Nom de l’agent Varchar (25) Post nom Postnom Post nom de

l’agent Varchar (25)

Prénom Prenom Prénom de l’agent Varchar (25) Fonction Fonction La fonction

qu’exerce l’agent Varchar (25)

Horaire Horaire L’horaire du début de travail de l’agent

Time

Grade Grade Le grade de l’agent Varchar (25) Prime Prime La prime

mensuelle de l’agent

FLOAT

Login Login L’identifiant de l’utilisateur

Varchar (25)

Mot de passe Pw Le mot de passe de l’utilisateur

Varchar (25)

Caractéristiques Caracteristiques Les caractéristiques de la face de l’agent

Varchar (25)

Photo Photo La photo de l’agent MEDIUMBLOB Numéro service IdService Le numéro du

service Int(11)

Dénomination Denomination L’appellation du service

Varchar (50)

Responsable Responsable Le nom du chef de service

Varchar (25)

Numéro congé IdConge Le numéro du congé

Int (11)

Date de début dateDebut La date de début Date

72

du congé Date de fin DateFin La date de fin du

congé Date

Le numéro de la sortie

IdSortie Le numéro d’une sortie

Int (11)

La date de la sortie DateSortie La date de la sortie de l’agent

Date

L’heure de sortie HeureSortie L’heure de sortie de l’agent

Time

Le numéro de la présence

IdPresence Le numéro d’une présence

Int (11)

Date de Presence DatePresence La date du jour de présence

Date

L’heure d’arrivée Heure L’heure d’arrivée de l’agent au travail

Time

Retard Retard Le retard encaissé par l’agent

Int (11)

Consigne Consigne Consigner si l’agent possède des absences antérieures

Int (11)

Le numéro du visiteur

IdVisiteur Le numéro attribué au visiteur

Int (11)

Date d’entrée DateEntrer La date d’entrée du visiteur

Date

Heure Heure L’heure de la capture

Time

Photo Photo La photo du visiteur

MEDIUMBLOB

Code de la photo CodePhoto L’Identifieur 11 du visiteur

Int (11)

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

11 Lors 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é (1)

Agent Congé 1 1..* Un agent est concerné par un ou plusieurs congés

6 Est concerné (2)

Agent Présence 1 1..* Un agent est concerné par une ou plusieurs présences

7 Est concerné (3)

Agent Sortie 1 1..* Un agent est concerné 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 Gérer les Agents Gérer les Services Gérer les Services Gérer les Présences Gérer les Présences Gérer les Sorties Gérer les Sorties Lancer caméra Imprimer Fiche des absences

Ajouter Agent MAJ Agent Ajouter Service MAJ Service Ajouter Présence MAJ Présence Ajouter Sortie MAJ Sortie Lancer caméra 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 :

=60001000 = 6

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

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

i 0

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étend13 . Environ six minutes dans la vidéo en langue

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

13 http://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