RÉPUBLIQUE DU BÉNIN

MINISTÈRE DE L’ENSEIGNEMENT SUPÉRIEUR

ET DE LA RECHERCHE SCIENTIFIQUE

UNIVERSITÉ D’ABOMEY-CALAVI

INSTITUT DE FORMATION ET DE
RECHERCHE EN INFORMATIQUE

BP 526 Cotonou Tel : +229 21 14 19 88

[Link] Courriel : contact@[Link]

MÉMOIRE
pour l’obtention du

Diplôme de Licence en Informatique

Option : Système d’Informations et Réseaux Informatiques

Présenté par :
Rydwane BACHABI

Conception d’une application web de prise de

consentement du bureau d’informations de crédit
dans un environnement de base de données
centralisée: cas de la FECECAM-BENIN

Sous la supervision :
Docteur Nelson SAHO
Ing Komi M. AZIAWA

Année Académique : 2022-2023

Sommaire

Dédicace ii

Remerciements iii

Résumé iv

Abstract v

Liste des figures vi

Introduction 2

1 Revu de littérature 4

2 Analyse, conception et choix technique 12

3 Présentation du prototype de l’application et discussion 24

Conclusion 33

Table des matières 36

i
Dédicace

À mes chers parents, pour tous leurs sacrifices, leur amour, leur soutien et leurs prières tout au long
de mes études.
À mes sœurs, ma grande famille, oncles, tantes, cousins et cousines.
À tous mes chers amis,
Que ce travail soit l’accomplissement de vos vœux tant allégués, et le fruit de votre soutien infaillible

ii
Remerciements

Nos sincères et profonds remerciements :

• A DIEU , pour m’avoir donner la santé, la force, l’inspiration et la perserverance tout au long
de ce travail ;

• A Monsieurr Nelson SAHO, enseignant à l’IFRI, pour avoir librement accepté de diriger ce
projet de mémoire ;

• Au Professeur Eugène C. EZIN, Directeur de l’IFRI, pour son dévouement pour le développe-
ment de l’informatique dans notre pays.

• Au Docteur (M.C.) Gaston EDAH, Directeur Adjoint de l’IFRI, Chargé des affaires académiques,
pour son sens de l’écoute et de la compréhension et à toute l’équipe dirigeante de IFRI

• A Monsieurr Nelson SAHO, enseignant à l’IFRI, pour avoir librement accepté de diriger ce
projet de mémoire ;

• A Monsieur GLELE MODESTE PARFAIT Directeur des Systèmes informatique et technolo-

gique pour son accompagnement ;

• A Monsieur Komi M. AZIAWA, Chargé réseaux et télécoms, notre de stage pour son accompa-
gnement ;

• A Monsieur Nicaise KOUKPONOU, Chef service de gestion des infrastructures et sécurité ré-
seau pour son accompagnement ;

• A Monsieur NATTA N’KOUBOUA KOUAGOU, Chef service support logiciel et développe-

ment des systèmes pour son accompagnement ;

• A Monsieur ZANKPO PASCAL, chargé administration des plateformes digital pour son ac-
compagnement ;

• A ma grande famille, pour tout le soutien et l’encouragement dont elle a fait preuve à mon
égard durant ma formation à l’IFRI et mon stage ;

• À tous mes camarades de promotion, pour leur sens de fraternité ;

• À tous ceux qui, de près ou de loin, ont contribué à l’aboutissement du présent projet, un grand
merci à vous !

iii
 Résumé
Ce mémoire explore le développement d’une application web novatrice destinée à optimiser la ges-
tion des consentements au sein des institutions financières. Notre objectif était de concevoir une so-
lution robuste et sécurisée pour automatiser le processus de collecte et de suivi des consentements
de clients, tout en garantissant la conformité réglementaire. Nous avons adopté une approche basée
sur l’architecture MVC (Modèle-Vue-Contrôleur) pour assurer une organisation structurée du code
et une extensibilité aisée. Les technologies telles que XAMPP, HTML, CSS, PHP et JavaScript ont
été intégrées, et le framework Bootstrap a été utilisé pour créer une interface utilisateur intuitive et
réactive. La sécurité étant une préoccupation majeure, nous avons mis en place des mesures telles
qu’un délai d’inactivité automatique et un système d’authentification sécurisé. De plus, nous avons
envisagé des perspectives d’amélioration, notamment la prise de signature électronique et la gestion
avancée des utilisateurs. Ce mémoire reflète notre engagement envers la qualité, la sécurité et l’effica-
cité dans le développement de solutions logicielles complexes. Il vise à contribuer à l’amélioration des
processus opérationnels de la FECECAM, renforçant ainsi la confiance de leurs clients et leur confor-
mité aux réglementations. Ce projet témoigne de notre capacité à concevoir et à mettre en œuvre des
applications web essentielles tout en répondant aux besoins critiques de la FECECAM-Bénin.

Mots clés :gestion des consentements ,application web, prise de signature électronique

iv
 Abstract
his thesis explores the development of an innovative web application designed to optimize the
management of consents within FECECAM-Bénin. Our goal was to design a robust and secure solu-
tion to automate the process of collecting and tracking customer consents while ensuring regulatory
compliance. We adopted an approach based on the MVC (Model-View-Controller) architecture to
ensure a structured organization of the code and easy extensibility. Technologies such as XAMPP,
HTML, CSS, PHP, and JavaScript were integrated, and the Bootstrap framework was used to create
an intuitive and responsive user interface. Security being a major concern, we implemented mea-
sures such as an automatic inactivity timeout and a secure authentication system. Furthermore, we
considered prospects for improvement, including electronic signature capture and advanced user
management. This thesis reflects our commitment to quality, security, and efficiency in the devel-
opment of complex software solutions. It aims to contribute to the enhancement of operational pro-
cesses within FECECAM, thereby bolstering customer trust and regulatory compliance. This project
demonstrates our ability to design and implement essential web applications while addressing criti-
cal needs withinFECECAM-Bénin.

Key words: management of consents,web application, electronic signature capture

Liste des figures

1.1 Page de prise de consentement de facebook. . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2 Page de prise de monzo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Page d’acceuil du logiciel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4 Page de prise de consentement du logiciel. . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1 Représentation des besoins fonctionnels de l’application. . . . . . . . . . . . . . . . . . 13

2.2 Représentation des besoins non-fonctionnels de l’application. . . . . . . . . . . . . . . 14
2.3 Diagramme de cas d’ulitisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5 Diagramme de séquence du cas d’utilisation prendre un consentement . . . . . . . . . 21
2.6 Diagramme de séquence du cas d’utilisation Activer ou Désactiver un consentement . 22
2.7 Diagramme de séquence du cas d’utilisation Ajouter un utilisateur . . . . . . . . . . . 23

3.1 Page de connexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2 Tableau de bord agent de crédit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Page de prise de consentement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4 Page de la liste des consentements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.5 Page de détails d’un consentement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.6 Tableau de bord administrateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.7 Page du rapport d’audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.8 Page de la liste des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.9 Page d’ajout d’un utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.10 Page de modification d’un utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.11 Page de profil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.12 Page de signature électronique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

vi
LISTE DES FIGURES LISTE DES FIGURES

Sigles et Abrévitions

CMS : Content Management System

CSS : Cascading Style Sheet.
HTML: Hyper Text Markup Language
HTTP: Hypertext Transfer Protocol
IFRI : Institut de Formation et de Recherche en Informatique
PHP : Hypertext Preprocessor
SGBD : Système de Gestion de Base de Données
SQL : Structured Query Language
UAC: Université d’Abomey-Calavi
UML: Unified Modeling Language
URL: Uniform Resource Locator

1
Introduction générale

À une époque où le monde numérique est en perpétuelle transformation, le secteur financier cherche
à découvrir des approches novatrices visant à optimiser ses opérations, tout en préservant la sûreté
et la discrétion des informations confidentielles. Dans cette optique, notre initiative se focalise sur
l’élaboration d’une solution contemporaine dédiée à la gestion des accords de la clientèle au sein
de la FECECAM au Bénin. C’est dans ce contexte que notre projet se focalise sur la création d’une
solution moderne pour la gestion des consentements des clients au sein de la FECECAM-Bénin.

Problématique

La FECECAM-Bénin fait face à des défis quant à la gestion sécurisée des consentements des clients
pour l’utilisation de leurs données. Le processus actuel manque de certification numérique, ce qui
peut conduire à des problèmes de traçabilité et de sécurité des documents. De plus, la décentral-
isation des bases de données rend complexe la gestion des consentements. La problématique au
cœur de cette situation est la suivante : Comment pouvons-nous améliorer la procédure d’obtention
d’approbations au sein de la FECECAM-Bénin? Cela peut être réalisé grâce à l’introduction d’une
plateforme web centralisée et officielle, assurant ainsi une administration transparente, fiable et
conforme des renseignements personnels des clients. Cette problématique soulève l’enjeu crucial
d’intégrer la technologie de manière stratégique pour améliorer la gestion des consentements, en
tenant compte des normes de protection des données et des besoins opérationnels.

Contexte

Lorsqu’il s’agit d’accorder des crédits, il est inévitable de rassembler et d’utiliser des informations
personnelles, et cela requiert le consentement explicite des clients. Cependant, le processus en place
montre certaines limites, en particulier en ce qui concerne l’absence d’une authentification numérique
des accords. Notre but est de pallier ces problèmes en élaborant une plateforme web centralisée.
Celle-ci aurait pour rôle de rassembler, de confirmer et de gérer avec efficacité les consentements, tout
renforçant la sécurité grâce à des signatures électroniques certifiées. Cette initiative vise à moderniser
la manière dont les consentements sont obtenus et gérés, renforçant ainsi la confiance des clients dans
la gestion de leurs données personnelles.

2
LISTE DES FIGURES LISTE DES FIGURES

Objectifs

L’objectif global de notre application est d’offrir aux agents de crédit un outil efficace pour leur facilité
la prise du consentement de leur clients de manière sécurisée et transparente. Pour atteindre l’objectif
principal, les objectifs spécifiques suivants doivent être atteints :

• conçevoir une interface utilisateur conviviale;

• mettre en œuvre la certification numérique des consentements;

• centraliser la gestion des consentements;

• permettre la recherche d’un consentement en particulier;

• faciliter l’activation et la désactivation d’un consentement;

• permettre l’impression ou le téléchargement d’un consentement;

• assurer la sécurité des données;

• mettre en place un rapport d’audit pour suivre les activité sur le site;

• faciliter la génération de rapports;

• garantir une expérience utilisateur transparente.

Organisation du mémoire

Le présent travail est structuré en trois chapitres. Le chapitre 1 présente les généralités liées au con-
cept de prise de consentement dans le domaine financier et une étude de l’existant. Le chapitre 2
expose notre solution à travers sa modélisation, son fonctionnement et les choix techniques liés à sa
réalisation. Les résultats obtenus par rapport à la réalisation de la solution et les insuffisances qui lui
sont liées seront quant à eux présentés dans le chapitre 3.

3
Chapitre 1
Revu de littérature

Introduction

Pour mener à bien la présente étude, il est nécessaire d’effectuer un état de l’art afin de mieux la
situer dans le contexte des solutions existantes s’intégrant dans le même sens. Ainsi, ce chapitre fait
un résumé de l’existant en ce qui concerne la gestion des consentements au sein de la FECECAM-
Bénin. Il consistera à présenter le concept de gestion des consentements, puis à établir une synthèse
de l’application déjà existante dans l’entreprise.

1.1 Généralité sur le Bureau dIinformation de Crédit et importance de la

prise de consentement

1.1.1 Généralité sur le bureau d’information de crédit

Le Bureaux d’Information de Crédit (BIC) est une institution à statut privé guidé d’une part par les
dispositions règlementaires de la réglementation des BIC dans l’UMOA de la loi Uniforme, adoptée
par le Conseil des Ministres de l’UMOA au cours de sa session du 28 juin 2013 pour être insérée
dans l’ordonnancement juridique interne des états membres et, d’autre part, des textes d’application
de ladite loi. Il a été créé dans le but de réduire l’asymétrie d’information sur la solvabilité des em-
prunteurs (qui contribue notablement au rationnement de crédit), d’améliorer l’accès au crédit dans
l’Union à moindre coût, et d’améliorer le climat des affaires dans les états membres de l’Union. Pour
atteindre ces objectifs, plusieurs sont menées.

• Collecte des données : Le bureau d’information de crédit recueil des données financières et
de crédit auprès de nombreuses sources comme les prêteurs, les institutions financières, et les
organismes gouvernementaux. Ces données sont notamment les engagements financiers (vo-
lume des prêts, leur maturité, leurs modalités et conditions, les remboursements, les garanties)
ou de service, la capacité d’emprunt ou de remboursement, les antécédents de crédit, etc.

• Stockage et gestion des données : Les données collectées sont stockées de manière sécurisée et
gérées de manière à garantir leur exactitude. Le bureau d’information de crédit maintien des
bases de données complètes sur les emprunteurs.

4
Chapitre 1. Revu de littérature 1.2. Etude de l’existant

• Fourniture des informations aux prêteurs : Les informations collectées sont fournies aux prê-
teurs, créanciers et institutions financières lorsqu’ils évaluent la demande de crédit d’un indi-
vidu ou d’une entreprise. Ces informations aident les prêteur à prendre des décisions éclairées.

La base de données centralisée du BIC est localisée dans un état membre de l’UMOA. Ces activités
sont mises en œuvre suivant le modèle indirect de collecte des données des assujettis, avec la BCEAO
comme interface entre les assujettis et le BIC. De part ces activités, le BIC offre de nombreux avan-
tages non seulement aux différentes structures avec lesquelles il travail, mais aussi aux clients. Pour
ces structures, le BIC constitue un outil efficace d’évaluation, d’analyse, et de gestion des risques. Il
leurs permette d’augmenter le volume des crédits octroyés (avec une augmentation de la qualité du
portefeuille), de réduire les coûts et les délais d’analyse des dossiers de crédits, d’anticiper le suren-
dettement des emprunteurs et ainsi prévenir les risques de défaillances. Par exemple si une personne
tente d’obtenir un prêt en utilisant de fausses informations, le BIC peut prévenir peut signaler des
incohérences ou des antécédents de fraudes potentielles. Aussi, les informations fournies par le BIC
permettront d’éviter de donner de faire des prêts à des personnes qui pourraient ne pas rembour-
ser. Pour la clientèle des fournisseurs de données, le BIC favorise un meilleur accès au crédit car la
porte est ouverte pour des opportunités financières telles que l’achat d’une maison ou obtention d’un
prêt. Le BIC fait aussi prendre en compte la qualité de leur réputation dans les critères qu’utilises les
organismes de crédit pour faire leurs appréciations, bénéficier d’une meilleure qualité de service.

1.1.2 Généralité sur la prise de consentement

De manière générale, c’est le fait de donner son approbation pour réaliser une action ou un projet.
Dans notre contexte, il s’agit de l’autorisation donnée par un emprunteur pour permettre ou non le
partage ou l’utilisation d’informations sur lui concernant les crédits qu’il a contractés. Le recueil du
consentement de l’emprunteur est requis pour la transmission des informations collectées au BIC, au
regard de la nature privée de cette entité. Ainsi si le client ne donne pas son consentement il ne pourra
pas bénéficier des nombreux avantages du BIC cités plus haut vu que les établissements ne pourront
pas envoyer les informations conformément aux lois sur la protection des informations personnels.
L’absence de consentement peut aussi augmenter le méfiance des prêteurs à son endroit vu que
ces derniers n’auraient aucune historique de son comportement d’emprunteur au niveau des autres
structures de prêts. Un tel refus n’avantage pas non plus les institutions car cela constituerait un frein
à la dissipation de l’asymétrie d’information Face à l’importance cruciale du Bureau d’Information
de Crédit (BIC) dans l’évaluation de la solvabilité des emprunteurs et à l’impératif de recueillir leur
consentement en toute légalité, notre mémoire se penche sur le développement d’une application
web novatrice visant à simplifier et sécuriser le processus de prise de consentement, contribuant ainsi
à renforcer la confiance des emprunteurs tout en répondant aux exigences de l’industrie financière
moderne.

1.2 Etude de l’existant

1.2.1 Page de prise de consentement sur facebook

La page de prise de consentement de Facebook est intégrée de manière stratégique au processus
d’inscription, ce qui permet à la plateforme de collecter le consentement des utilisateurs en matière

5
Chapitre 1. Revu de littérature 1.2. Etude de l’existant

de données personnelles et de confidentialité dès le début de leur expérience sur le réseau social.
Voici une explication de cette intégration .

• Introduction lors de l’Inscription : Lorsqu’un nouvel utilisateur décide de s’inscrire sur Face-
book, il commence par accéder à la page d’inscription. Cette page initiale demande des in-
formations de base telles que le nom, l’adresse e-mail ou le numéro de téléphone, la date de
naissance, etc.

• Inclusion des Conditions Générales d’Utilisation et de la Politique de Confidentialité : Juste

en dessous des champs d’inscription, Facebook intègre des liens vers les Conditions Générales
d’Utilisation (CGU) et la Politique de Confidentialité. Ces liens sont clairement visibles et in-
vitent les utilisateurs à les consulter.

• Saisie des Données Personnelles : L’utilisateur commence à saisir ses données personnelles,
comme son nom et son adresse e-mail. En parallèle, les liens vers les CGU et la Politique de
Confidentialité restent visibles.

• Finalisation de l’Inscription : Une fois que l’utilisateur remplit tous les champs et compris les
conditions, il peut activer le bouton d’inscription pour créer son compte.

En intégrant la prise de consentement de cette manière, Facebook s’assure que les utilisateurs sont
informés des conditions d’utilisation et de la politique de confidentialité dès le début de leur expé-
rience sur la plateforme. Cette approche vise à garantir que le consentement est donné de manière
éclairée et active, conformément aux réglementations sur la protection des données. Avec ce proces-
sus on est assuré que toute personne qui a un compte Facebook a donné son consentement .La figure
1.1 présente la page d’inscription de Facebook avec les politiques de confidentialités

F IGURE 1.1 : Page de prise de consentement de facebook.

6
Chapitre 1. Revu de littérature 1.2. Etude de l’existant

1.2.2 Banniere de consentement aux cookies sur Monzo

Lorsqu’un visiteur accède au site web de la banque en ligne Monzo, il est accueilli par une bannière
de consentement aux cookies bien visible en haut ou en bas de la page d’accueil. Cette bannière a
pour objectif de recueillir le consentement de l’utilisateur concernant l’utilisation de cookies, confor-
mément aux réglementations sur la vie privée et la protection des données. La bannière est conçue
avec une approche épurée et conviviale. Voici les éléments clés de cette bannière.

• Texte Informatif : La bannière de consentement contient un texte informatif concis qui explique
l’utilisation des cookies par Monzo. Ce texte contient un lien pour rediriger les utilisateurs
vers la page de la politique de cookies de Monzo. Ce lien permet aux visiteurs de trouver des
informations plus détaillées sur les types de cookies utilisés et leur finalité.

• Bouton d’Acceptation : En bas du texte informatif, un bouton clairement identifiable est affiché
avec l’option "Accept". Les visiteurs ont la possibilité d’accepter l’utilisation des cookies en
cliquant sur ce bouton.

• Bouton de Gestion des cookies : La bannière comporte aussi un bouton "Manage" qui donne
aux utilisateurs la possibilité de gérer leurs préférences en matière de cookies. En cliquant sur
ce bouton, les visiteurs peuvent accéder à un panneau de contrôle où il peuvent choisir quels
types de cookies autoriser ou refuser.

L’objectif principal de cette bannière de consentement aux cookies est de s’assurer que les visiteurs
sont pleinement informés de l’utilisation des cookies sur le site web de Monzo et de leur donner la
possibilité de prendre une décision éclairée en matière de consentement. Elle vise à garantir la confor-
mité aux réglementations sur la protection de la vie privée tout en offrant une expérience utilisateur
transparente. Par ailleurs, aucune option de refus n’est donner, ce qui fait que pour avoir accès au
site , le visiteur est contraint de donner son consentement. La figure 1.2 présente cette bannière.

F IGURE 1.2 : Page de prise de monzo.

7
Chapitre 1. Revu de littérature 1.3. Intérêt de notre solution

1.2.3 Logicielle de prise de consentement de la FECAM-BENIN

La FECECAM-Bénin elle mème possède un logicielle qu’il utilise pour générer un consentement[?].
Ce logiciel est créé pour faciliter le processus de collecte du consentement des clients concernant
l’utilisation de leurs informations personnelles dans le contexte des activités liées à l’octroi de crédits.
En effet, à partir de ce logiciel, l’agent de crédit entre les informations du client nécessaires à la prise
du consentement. Cette saisie est facilitée par une option de recherche permettant à l’agent de crédit
de rechercher un client à partir de son numéros membre, et les informations relatives au client sont
directement mises dans les champs correspondants. L’agent de crédit n’a donc plus qu’à ajouter les
informations complémentaires et corrigé les informations si nécessaire. Il peut ensuite générer une
fiche de consentement qui est imprimé. Après des explications sur les contours du consentement
au client, ce dernier est invité à poser sa signature sur la fiche pour donner son consentement. A
partir de ce logiciel, l’agent de crédit peut aussi consulter les consentements antérieurs, ce qui permet
d’avoir un rapport sur les consentement prises dans l’entreprise. Par ailleurs, une distinction est faite
entre les consentements actifs, et ceux inactifs, lors de la consultation des consentements. Cependant,
s’agissant d’un logiciel on ne peut pas y accéder à partir de n’importe quel appareil s’il n’est pas
préalablement installé. Un agent de crédit qui a un souci avec son ordinateur sera donc limité dans
la prise des consentements. Par ailleurs, l’environnement de base de données de FECECAM-Bénin
étant décentralisé, chaque caisse possède sa base de données. Le logiciel mis en place ne permet
donc à chaque caisse de ne retrouver que les clients de leur caisse, ne facilitant donc pas la prise de
consentement d’un client en voyage par exemple. Quelques interfaces du logicielle sont présentés
par les figures 1.3 et 1.4.

1.3 Intérêt de notre solution

Déjà, une application web permettra à l’agent de crédit de prendre un consentement à partir de
n’importe quel ordinateur. Ainsi, en cas de perte ou de défaillance de l’ordinateur qu’il a l’habitude
d’utiliser, il ne sera pas bloqué dans son activité. Aussi, dans la mesure où l’entreprise cherche à
centraliser sa base de données, les outils en place doivent s’adapter à ce nouvel environnement,
et notre plateforme est justement fait pour ce genre d’environnement. Par ailleurs, en cas de perte
du document signé par le client, l’institut se retrouverait dans l’incapacité de prouver qu’il a eu le
consentement du client avant d’utiliser et de partager les informations de crédit de ce dernier. Ceci
constitut une faille que des clients mal intentionnés pourraient exploiter de diverses manières. Pour
pallier à cela, nous proposons donc une certification électronique du consentement, ce qui permettra
à l’entreprise d’avoir une sauvegarde électronique de la certification par le client du don de son
consentement.

Conclusion

Au terme de ce chapitre, nous pouvons retenir que l’objectif que vise ce projet est d’offrir à la FE-
CECAM un outil efficace pour l’informatisation de la gestion des consentements. Nous retenons
également qu’il existe une solution dans l’entreprise, mais ne couvrant pas les aspects auxquels nous

8
Chapitre 1. Revu de littérature 1.3. Intérêt de notre solution

nous intéressons ici. Dans le chapitre suivant, nous aborderons les choix techniques qui ont conduit
à la conception de la plateforme.

9
Chapitre 1. Revu de littérature 1.3. Intérêt de notre solution

F IGURE 1.3 : Page d’acceuil du logiciel.

10
Chapitre 1. Revu de littérature 1.3. Intérêt de notre solution

F IGURE 1.4 : Page de prise de consentement du logiciel.

11
Chapitre 2
Analyse, conception et choix technique

Introduction

Dans ce chapitre, nous aborderons les aspects cruciaux de notre projet. Nous commencerons avec
une analyse des besoins approfondie des besoins spécifiques liés à notre contexte, et explorerons la
conception de notre application à travers des diagrammes de cas d’utilisation, de classes et de sé-
quences. Nous aborderons aussi les choix techniques fondamentaux qui ont orienté notre démarche.
En somme, ce chapitre expose comment nous avons transformé la problématique la problématique
en une solution concrète, tout en justifiant nos choix techniques à chaque étape.

2.1 Analyse

2.1.1 Analyse des besoins fonctionnels

Les besoins fonctionnels répondent aux points précis du cahier de charges et sont donc requis par le
client. Ils constituent le besoin primaire du client et définissent une fois résolu l’opérationnalité du
système. La figure 2.1 suivante illustre bien ce que notre application doit permettre de faire.

2.1.2 Analyse des besoins non fonctinnels

La figure 2.2 suivante illustre bien les besoins non fonctionnels

2.2 Conception

2.2.1 Diagramme de cas d’utilisation

Cette partie de notre modélisation consistera à présenter les différents acteurs du système ainsi que
les différentes interactions qu’ils pourront effectuer avec celui-ci.

12
Chapitre 2. Analyse, conception et choix technique 2.2. Conception

F IGURE 2.1 : Représentation des besoins fonctionnels de l’application.

[Link] Identification des acteurs

En UML, on entend par acteur toute idéalisation d’un rôle joué par une personne externe, un pro-
cessus ou une entité qui interagit avec le système. Il existe deux types d’acteurs, à savoir les acteurs
principaux, qui utilisent directement les fonctionnalités du système et les acteurs secondaires qui
contribuent à la réalisation d’un cas d’utilisation. Dans le cadre de notre système nous avons retenu :

• l’agent de crédit ;

• l’administrateur ;

• le client.

[Link] Description textuelle des cas d’utilisation

Nous décrirons trois cas d’utilisations pour notre application :

• prendre un consentement ;

• activer ou désactiver un consentement ;

• créer un nouvel utilisateur.

Cas d’utilisateur 1 : Prendre un consentement

Identification :
Objectif : Détailler les étapes permettant à l’agent de crédit d’établir et de générer un consentement.
Acteur : Agent de crédit

13
Chapitre 2. Analyse, conception et choix technique 2.2. Conception

F IGURE 2.2 : Représentation des besoins non-fonctionnels de l’application.

SEQUENCEMENT : Précondition : Le client est préalablement enregistré dans le système et l’agent

de crédit s’est authentifié.
Enchainement nominal :

• Une fois que l’agent de crédit s’est authentifié, il accède au tableau de bord correspondant aux
agents de crédit.

• L’agent de crédit choisit l’option « Créer un nouveau consentement ».

• L’agent de crédit lance la recherche du client en entrant son numéros membre.

• L’application web présente le formulaire d’édition du consentement contenant déjà des infor-
mations sur le client.

• L’agent de crédit complète, ajuste les informations si nécessaire, et valide la prise de consente-
ment.

• L’agent de crédit visualise, imprime la fiche de consentement.

Enchainement alternatif
Si le numéros membre n’est pas trouvé, l’agent de crédit est averti de l’erreur et invité à recommencer.
Post condition :
Le consentement est enregistré dans le système.

Cas d’utilisateur 2 : Activer ou désactiver un consentement

Identification :

14
Chapitre 2. Analyse, conception et choix technique 2.2. Conception

Objectif : Détailler les étapes permettant à l’administrateur d’inscrire un nouvel utilisateur.

Acteur : Administrateur

SEQUENCEMENT : Précondition : L’administrateurt s’est authentifié.

Enchainement nominal :

• Une fois que l’administrateur s’est authentifié, il accède au tableau de bord correspondant aux
administrateurs.

• L’administrateur choisit l’option « Gérer les utilisateurs ».

• Il choisit ensuite « Ajouter un Utilisateur».

• L’Administrateur renseigne les différents champs du formulaire d’inscription avec les informa-
tions appropriées.

• L’administrateur valide l’enregistrement des informations.

Enchainement alternatif
L’administrateur est contraint de renseigner les champs obligatoires omis et l’enregistrement échoue
si le profile en cours d’enregistrement existe déjà et on est inviter à reprendre. Post condition :
L’utilisateur est enregistré.

Cas d’utilisateur 3 : Créer un nouvel utilisateur

Identification :
Objectif : Détailler les étapes permettant à l’agent de crédit d’établir de modifier un consentement
(statut).
Acteur : Agent de crédit

SEQUENCEMENT : Précondition : Le client est préalablement enregistré dans le système et l’agent

de crédit s’est authentifié.
Enchainement nominal :

• Une fois que l’agent de crédit s’est authentifié, il accède au tableau de bord correspondant aux
agents de crédit.

• L’agent de crédit choisit l’option «Voir la liste».

• L’agent de crédit recherche le consentement dans la liste des consentements dans l’application
web.

• L’agent de crédit choisi « Voir plus » au niveau du consentement.

• Il clique ensuite sur le bouton « Activer » ou « Désactiver » selon le cas puis confirme l’activation
ou la désactivation.

Post condition :
Le statut du consentement est Changé. La figure 2.3 suivante présente le diagramme de cas d’utilisa-
tion.

15
Chapitre 2. Analyse, conception et choix technique 2.2. Conception

F IGURE 2.3 : Diagramme de cas d’ulitisation

2.2.2 Diagramme de classe

Le diagramme de classe montre la structure interne d’un système. Il permet de fournir une repré-
sentation abstraite des objets du système qui vont interagir pour réaliser les cas d’utilisation. Il est
important de noter qu’un même objet peut très bien intervenir dans la réalisation de plusieurs cas
d’utilisation. Une classe décrit les responsabilités, le comportement et le type d’un ensemble d’ob-
jets. Les éléments de cet ensemble sont les instances de la classe. La figure 2.4 suivante présente le
diagramme de classe.

2.2.3 Diagramme de séquence

Le schéma de séquence se révèle être une illustration claire quand on souhaite rendre tangibles les
échanges entre deux entités (qu’il s’agisse de deux sous-systèmes ou de deux catégories dans un futur
logiciel). Il offre à l’architecte ou au concepteur la possibilité de façonner progressivement sa solution.
Cette représentation, intuitive de surcroît, s’avère être un excellent moyen de communication au
sein d’une équipe d’ingénierie pour discuter de cette solution. Elle permet d’exposer comment les
éléments du système interagissent les uns avec les autres et avec les intervenants :

• les objets au cœur d’un système interagissent en s’échangeant des messages ;

• les acteurs interagissent avec le système au moyen d’IHM (Interfaces Homme-Machine).

Les figures 2.5, 2.6 et 2.7 suivants presentent quelques diagrammes de séquences de notre application.

16
Chapitre 2. Analyse, conception et choix technique 2.3. Choix technique

F IGURE 2.4 : Diagramme de classe

2.3 Choix technique

2.3.1 Choix des langages de programmation

Un langage de programmation est un langage informatique que les programmeurs utilisent pour
développer des logiciels, des scripts ou d’autres ensembles d’instructions qui seront exécutés par les
ordinateurs. L’utilisation d’un langage de programmation requiert la maîtrise de concepts spécifiques
et doit être adaptée à l’objectif final. Dans notre cas, nous voulons réaliser une application web, ce qui
signifie que nous devrons utiliser des langages de programmation appropriés à ce type d’application.

[Link] HTML

HTML signifie « HyperText Markup Language » qu’on peut traduire par « langage de balises pour
l’hypertexte ». Il est utilisé afin de créer et de représenter le contenu d’une page web et sa structure.
On peut par exemple organiser le contenu en un ensemble de paragraphes, une liste d’éléments,

17
Chapitre 2. Analyse, conception et choix technique 2.3. Choix technique

utiliser des images ou des tableaux de données. D’autres technologies sont utilisées avec HTML
pour décrire la présentation d’une page (CSS) et/ou ses fonctionnalités interactives (JavaScript). L’«
hypertexte » désigne les liens qui relient les pages web entre elles, que ce soit au sein d’un même site
web ou entre différents sites web.

[Link] CSS

De la même façon que HTML, CSS (Cascading Style Sheets) n’est pas vraiment un langage de pro-
grammation. C’est un langage de feuille de style, c’est-à-dire qu’il permet d’appliquer des styles sur
différents éléments sélectionnés dans un document HTML. Par exemple, on peut sélectionner tous
les éléments d’une page HTML qui sont paragraphes et afficher leurs textes en rouge. Il permet donc
de mettre en forme une page web.

[Link] Javascript

JavaScript (souvent abrégé en « JS ») est un langage de script léger, orienté objet, principalement
connu comme le langage de script des pages web. Mais il est aussi utilisé dans de nombreux environ-
nements extérieurs aux navigateurs web tels que [Link], Apache CouchDB voire Adobe Acrobat.
Le code JavaScript est interprété ou compilé à la volée (JIT). C’est un langage à objets utilisant le
concept de prototype, disposant d’un typage faible et dynamique qui permet de programmer suivant
plusieurs paradigmes de programmation : procédural, fonctionnelle, impérative et orienté objet. Ja-
vaScript a été créé en 1995 par Brendan Eich et intégré au navigateur web Netscape Navigator 2.0.
Contrairement à une conception populaire, JavaScript n’est pas « du Java interprété ».

[Link] PHP

PHP est un acronyme récursif, qui signifie "PHP : Hypertext Preprocessor" : c’est un langage de script
HTML généraliste et Open Source, exécuté côté serveur. Sa syntaxe est empruntée aux langages C,
Java et Perl, et est facile à apprendre. Le but de ce langage est de permettre aux développeurs web
d’écrire des pages dynamiques rapidement, mais vous pouvez faire beaucoup plus avec PHP.

2.3.2 Autres technologies

[Link] Tailwind CSS

Tailwind CSS est un framework CSS open-source qui facilite le développement d’interfaces utilisa-
teur modernes et esthétiques pour les sites web et les applications. Contrairement à d’autres frame-
works CSS qui vous imposent des styles pré-définis, Tailwind CSS vous donne la liberté de construire
des interfaces personnalisées en utilisant des classes utilitaires. Il offre une approche "atomic CSS",
où chaque classe représente une seule règle CSS, ce qui permet une personnalisation fine et une uti-
lisation efficace des styles.

[Link] Bootstrap

Bootstrap est un framework open-source de développement web qui facilite la création d’interfaces
web élégantes, réactives et esthétiquement plaisantes. Il fournit une collection de composants HTML,
de styles CSS pré-conçus et de scripts JavaScript prêts à l’emploi pour accélérer le processus de dé-
veloppement web.

18
Chapitre 2. Analyse, conception et choix technique 2.3. Choix technique

[Link] Ionicons

Ionicons est une bibliothèque open-source d’icônes vectorielles conçues spécifiquement pour une
utilisation dans les applications web et mobiles. Ces icônes sont épurées, modernes et faciles à inté-
grer dans des projets web. Ionicons offre une large gamme d’icônes pour différentes catégories, ce
qui en fait une ressource précieuse pour les développeurs et les concepteurs cherchant à améliorer
l’expérience utilisateur de leurs applications.

[Link] FPDF

FPDF (acronyme de "Free PDF") est une bibliothèque open-source pour la création de documents
PDF en PHP. Elle offre aux développeurs une solution simple et efficace pour générer des fichiers
PDF à partir de leurs scripts PHP, ce qui permet de créer des documents dynamiques, des rapports,
des factures, des étiquettes, et bien plus encore. FPDF est largement utilisé dans le développement
web pour générer des fichiers PDF à la volée.

2.3.3 Choix du SGBD : Système de Gestion des Bases de Données

Un système de gestion de base de données (SGBD) est un logiciel conçu pour stocker, récupérer, dé-
finir et gérer des données dans une base de données tout en garantissant la qualité, la pérennité et la
confidentialité des données, à travers des opérations en apparence simple. MySQL est un système de
gestion de base de données relationnelle (SGBD) open-source très populaire et compatible avec les
normes SQL. Il dispose de pilotes pour de nombreux langages de programmation, ce qui facilite son
intégration dans des applications écrites en PHP, Python, Java, C++, et bien d’autres. Il est couram-
ment utilisé pour des applications web, des systèmes de gestion de contenu (CMS), des applications
d’entreprise, et bien plus encore.

2.3.4 Choix du langage de modélisation

Lors de la conception d’une application, l’une des étapes cruciales est la modélisation. Elle permet de
se faire une représentation virtuelle. Afin donc de modéliser les fonctionnalités de notre application,
nous avons choisi UML comme langage de modélisation. UML fournit une méthode normalisée pour
visualiser la conception d’un système ainsi que les principes associés à l’orienté objet que sont :
l’héritage, la composition et la transition d’état.

2.3.5 Choix de l’architecture logicielle

Notre plateforme est basée sur l’architecture MVC (Model View Controller), un modèle d’architec-
ture logicielle couramment utilisé pour organiser et structurer des applications web. Elle se répartit
comme suit :

• Model : Composant central de l’architecture, il s’agit de la structure de données dynamique de

l’application, indépendante de l’interface utilisateur. Il gère directement les données, la logique
et les règles de l’application.

• View : La vue est responsable de l’interface utilisateur de l’application. Elle affiche les don-
nées au format approprié pour les utilisateurs. La vue est généralement passive et se contente
d’afficher les données qui lui sont fournies par le contrôleur.

• Controller : Il reçoit les entrées et les convertit en commandes pour le modèle ou la vue.

19
Chapitre 2. Analyse, conception et choix technique 2.3. Choix technique

2.3.6 Choix d’autres outils de développement

[Link] L’éditeur de texte

Pour la création de cette application, nous avons fait appel à Visual Studio Code. C’est un éditeur
de texte gratuit et open source développé par Microsoft, disponible sur Windows, Linux et macOS.
Malgré sa légèreté, il offre des fonctionnalités puissantes qui ont fait de lui l’un des environnements
de développement les plus appréciés récemment. Il prend en charge une multitude de langages de
programmation, allant de Java, C++, Python à CSS, Go et Dockerfile. Visual Studio Code vous offre
également la possibilité d’ajouter et même de créer de nouvelles extensions, y compris des débo-
gueurs et le support pour le développement cloud et web. Son interface utilisateur est très interactive
par rapport à d’autres éditeurs de texte.

[Link] Serveur de développement web

XAMPP est un ensemble de logiciels open source qui facilite la création d’un environnement de
développement web local sur votre ordinateur. L’acronyme "XAMPP" signifie "X" (pour n’importe
quel système d’exploitation), "Apache" (un serveur web), "MySQL" (un système de gestion de base de
données), "PHP" (un langage de programmation serveur) et "Perl" (un langage de script).En plus des
composants principaux mentionnés ci-dessus, XAMPP inclut généralement d’autres outils et logiciels
utiles pour le développement web, tels que phpMyAdmin (une interface web pour gérer les bases
de données MySQL), FileZilla (un client FTP), Mercury Mail (serveur de messagerie) et plus encore.
. Nous avons donc utilisé LAMP pour tester le fonctionnement de notre application web

Conclusion

Dans ce chapitre, nous avons fait une analyse et réalisé les diagrammes de classes, de cas d’utilisation
et de séquence qui nous ont permis de dégager l’architecture générale de notre application. Les choix
techniques qui ont été effectués pour développer notre solution, ont également été présentés. Dans
le chapitre suivant, nous allons présenter également les interfaces de notre application.

20
Chapitre 2. Analyse, conception et choix technique 2.3. Choix technique

F IGURE 2.5 : Diagramme de séquence du cas d’utilisation prendre un consentement

21
Chapitre 2. Analyse, conception et choix technique 2.3. Choix technique

F IGURE 2.6 : Diagramme de séquence du cas d’utilisation Activer ou Désactiver un consentement

22
Chapitre 2. Analyse, conception et choix technique 2.3. Choix technique

F IGURE 2.7 : Diagramme de séquence du cas d’utilisation Ajouter un utilisateur

23
Chapitre 3
Présentation du prototype de l’application
et discussion

Introduction

Nous voilà dans le dernier chapitre de notre travail. Les travaux qui ont été effectués tout au long de
la conception de l’application, nous ont permis de concevoir un système répondant plus ou moins
bien aux objectifs initialement fixés. Nous présentons ici les résultats.

3.1 Présentation des interfaces

Lorsqu’un utilisateur visite le site, il est invité à se connecter au niveau de la page de connexion
présenté au niveau au niveau la figure 3.1, en entrant son nom d’utilisateur (Login) et son mot de
passe. Il s’en suit après connexion, l’accès au tableau de bord qui diffère d’un utilisateur à un autre.
Le tableau de bord est en général composé d’un texte de bienvenu, et des options de navigation.
Le tableau de bord de l’agent de crédit (illustré par la figure 3.2) propose comme option de voir la
liste des consentements et de créer un nouveau consentement ; tandis que celui d’un administrateur
(illustré par la figure 3.6) propose comme option la gestion des utilisateurs et la consultation des
rapports d’audit. Lorsque l’agent de crédit choisit l’option "Créer un nouveau consentement", il est
redirigé au niveau de la page de prise de consentement illustrée par la figure 3.3, où l’on retrouve un
formulaire à remplir et un bouton pour valider la prise de consentement. Lorsqu’il choisit l’option
" Voir liste ", il est redirigé vers la page des consentement (figure 3.4) où nous avons la liste des
consentements prises sous forme de carte, chaque carte ayant un bouton "Voir plus" qui permet de
voir les détails du consentement présentées au niveau de la figure 3.5. Quant à l’administrateur, s’il
choisit l’option "Consulter les Rapports", il est redirigé vers la page illustrée au niveau de la figure
3.7. Mais lorsqu’il choisit l’option "Gérer les utilisateurs", il est redirigé vers la liste des utilisateurs
illustrée au niveau de la figure 3.8, avec les options de suppression, d’ajout, et de modification d’un
utilisateur. La page d’ajout est composée d’un formulaire présenté au niveau de la figure 3.9, et la
page de modification est illustrée par la figure 3.10 avec un formulaire pour modifier les informations
de l’utilisateur. Tout utilisateur peut aussi accéder à son profil, illustrée au niveau de la figure 3.11 en

24
Chapitre 3. Présentation du prototype de l’application et discussion 3.2. Discussion

cliquant sur "Profil" au niveau de la barre de navigation. Enfin, la signature électronique se fait sur la
page illustrée sur la figure 3.12.

F IGURE 3.1 : Page de connexion

3.2 Discussion

3.2.1 Limites
La solution développée connaît certaines insuffisances au nombre desquelles nous avons :

• la nécessité pour les utilisateurs d’être connectés à internet ;

• La restriction des activités des agents de crédit à seulement la gestion des consentements, or
leus ractivités ne se limitent pasq seulements aux consentements ;

• Créer un nouvel utilisateur.

3.2.2 Sécurité
Pour un bon fonctionnement de la plateforme, nous avons jugé important de distinguer les utilisa-
teurs en fonction de leurs possibilités d’interaction avec la plateforme. Chaque utilisateur appartient
un groupe d’utilisateur dont les autorisations sont définies. Ainsi nous avons des utilisateurs de type
agent de crédit et des utilisateurs de type Administrateur. Nous avons aussi mis en place un délai
d’inactivité sur le site qui déconnecte les utilisateurs après un certain temps sans activité, et limité le
nombre de tentatives de connexion infructueuse.

25
Chapitre 3. Présentation du prototype de l’application et discussion 3.2. Discussion

F IGURE 3.2 : Tableau de bord agent de crédit

3.2.3 Perspective
La solution que nous présentons actuellement n’est qu’une première version de l’application. Au
vues des limites actuelles et des objectifs à long terme que nous visons, voici quelques perspectives
qu’on prendra en compte dans les prochaines versions de l’application :

• ajouter d’autres activités pour l’agent de crédit en plus de la gestion des consentments ;

• améliorer le processus de prise de signature éléctronique ;

• mettre en place une version mobile.

Conclusion

Ce chapitre nous a permis de présenter les résultats issus de nos travaux. Nous avons, non seulement,
abordé les technologies utilisées, mais aussi présenté les fonctionnalités de notre application ainsi que
quelques-unes de ces limites.

26
Chapitre 3. Présentation du prototype de l’application et discussion 3.2. Discussion

F IGURE 3.3 : Page de prise de consentement

F IGURE 3.4 : Page de la liste des consentements

27
Chapitre 3. Présentation du prototype de l’application et discussion 3.2. Discussion

F IGURE 3.5 : Page de détails d’un consentement

F IGURE 3.6 : Tableau de bord administrateur

28
Chapitre 3. Présentation du prototype de l’application et discussion 3.2. Discussion

F IGURE 3.7 : Page du rapport d’audit

F IGURE 3.8 : Page de la liste des utilisateurs

29
Chapitre 3. Présentation du prototype de l’application et discussion 3.2. Discussion

F IGURE 3.9 : Page d’ajout d’un utilisateur

F IGURE 3.10 : Page de modification d’un utilisateur

30
Chapitre 3. Présentation du prototype de l’application et discussion 3.2. Discussion

F IGURE 3.11 : Page de profil

31
Chapitre 3. Présentation du prototype de l’application et discussion 3.2. Discussion

F IGURE 3.12 : Page de signature électronique

32
Conclusion générale

En conclusion, ce mémoire a exploré en détail la conception, le développement et l’implémentation

d’une application web dédiée à la gestion des consentements pour la FECECAM-Bénin. Tout au long
de ce travail, nous avons adopté une approche rigoureuse axée sur la sécurité, l’efficacité et l’expé-
rience utilisateur. Nous avons commencé par analyser les besoins des utilisateurs et les exigences
fonctionnelles, ce qui nous a permis de définir clairement les objectifs de notre application. Ensuite,
nous avons opté pour une architecture MVC (Modèle-Vue-Contrôleur) pour une organisation struc-
turée du code, favorisant la maintenabilité et l’extensibilité.
Le choix des technologies, notamment l’utilisation de XAMPP comme serveur, HTML, CSS, PHP et
JavaScript pour le développement, et l’intégration du framework Bootstrap, a permis de créer une
interface utilisateur moderne et réactive. La sécurité étant une priorité, nous avons mis en œuvre
plusieurs mesures, telles qu’un délai d’inactivité pour la déconnexion automatique, une distinction
des utilisateurs avec un système d’authentification robuste et des audits de sécurité réguliers.
En outre, nous avons envisagé des perspectives d’amélioration continue, notamment une meilleure
prise de signature électronique, une gestion des utilisateurs et des rôles plus élaborée, une intégration
de bases de données pour une gestion optimale des données, et une attention constante à l’interface
utilisateur. Ce mémoire témoigne du parcours de conception et de développement d’une application
web complexe, destinée à répondre aux besoins critiques des institutions financières en matière de
gestion des consentements. Il reflète également l’engagement envers la qualité, la sécurité et l’effica-
cité, tout en ouvrant la voie à des améliorations futures.
Enfin, ce travail vise à contribuer à l’amélioration des processus opérationnels de la FECECAM-Bénin
en automatisant et en sécurisant la gestion des consentements, renforçant ainsi la confiance de leurs
clients et optimisant leur conformité aux réglementations en vigueur. [?]

33
Bibliographie

FONDAMMENTAUX SUR LES BASES DE DONNEES RELATIONNELLES, Nelson SAHO,2023

Cours PHP, Sébastien ROHAUT
LATEX... pour le prof de maths !, Arnaud GAZAGNES, 11 Janvier 2021
Introduction au Latex, M. Bailly-Bechet,

34
Webographie

https ://[Link]/fr/docs/Web/HTML ; consulté le 21/09/2023à 15h50min

https ://[Link]/manual/fr/[Link] ; consulter le 21/9/2023 à 16h15
https ://[Link]/ ; consulter le 21/09/2023 16h25
http ://[Link] consulter le 22/09/2023 à 11h30
https ://[Link]/fr/taxonomy/term/152 consulter le 24/09/2023 à 15h55
https ://[Link]/ionicons consulter le 24/09/2023 à 15h57

35
Table des matières

Dédicace ii

Remerciements iii

Résumé iv
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv

Abstract v
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v

Liste des figures vi

Introduction 2

1 Revu de littérature 4
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Généralité sur le Bureau dIinformation de Crédit et importance de la prise de consen-
tement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1 Généralité sur le bureau d’information de crédit . . . . . . . . . . . . . . . . . . 4
1.1.2 Généralité sur la prise de consentement . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Page de prise de consentement sur facebook . . . . . . . . . . . . . . . . . . . . 5
1.2.2 Banniere de consentement aux cookies sur Monzo . . . . . . . . . . . . . . . . . 7
1.2.3 Logicielle de prise de consentement de la FECAM-BENIN . . . . . . . . . . . . 8
1.3 Intérêt de notre solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Analyse, conception et choix technique 12

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.1 Analyse des besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.2 Analyse des besoins non fonctinnels . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
[Link] Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . 13
[Link] Description textuelle des cas d’utilisation . . . . . . . . . . . . . . . . . 13
Cas d’utilisateur 1 : Prendre un consentement
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

36
 Cas d’utilisateur 2 : Activer ou désactiver un consentement
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Cas d’utilisateur 3 : Créer un nouvel utilisateur
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.2 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.3 Diagramme de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Choix technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.1 Choix des langages de programmation . . . . . . . . . . . . . . . . . . . . . . . 17
[Link] HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
[Link] CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
[Link] Javascript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
[Link] PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.2 Autres technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
[Link] Tailwind CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
[Link] Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
[Link] Ionicons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
[Link] FPDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.3 Choix du SGBD : Système de Gestion des Bases de Données . . . . . . . . . . . 19
2.3.4 Choix du langage de modélisation . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.5 Choix de l’architecture logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.6 Choix d’autres outils de développement . . . . . . . . . . . . . . . . . . . . . . . 20
[Link] L’éditeur de texte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
[Link] Serveur de développement web . . . . . . . . . . . . . . . . . . . . . . 20
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3 Présentation du prototype de l’application et discussion 24

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1 Présentation des interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.1 Limites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.2 Sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.3 Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Conclusion 33

Table des matières 36

37