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’information et réseaux informatique (SIRI)

Présenté par :
Ostian Stéphane OLANIYAN

Conception d’un système de collecte des

taxes marchandes dans la commune de
Ouidah

Sous la supervision :
Ingénieur Pierre Jérôme ZOHOU (Doctorant)

Membres du jury :
AOGA John Docteur IFRI Président
YARAKOU Dany Ingénieur IFRI Examinateur
ZOHOU Pierre Jérôme Ingénieur IFRI Rapporteur

Année Académique : 2018 - 2019

Sommaire

Dédicace ii

Remerciements iii

Résumé iv

Abstract v

Table des figures vi

Liste des acronymes vii

Introduction 2

1 Revue de littérature 4

2 Analyse, conception et choix techniques 9

3 Résultats et discussions 20

Conclusion 31

Bibliographie 32

Webographie 33

Table des matières 35

i
Dédicace

A l’Eternel DIEU des armées, à ma famille et à tous ceux qui ont contribué d’une manière ou d’une
autre à l’élaboration du présent travail.

ii
Remerciements

La rédaction de ce mémoire a été un travail de concert avec des personnes de bonne volonté qui m’ont
soutenu et m’ont accompagné tout au long de ce travail. Particulièrement nous tenons à remercier :

• L’Eternel DIEU des armées pour son immense grâce sur ma vie, lui qui m’a donné la force et la
volonté nécessaire d’aller de l’avant.

• Mes parents, eux qui m’ont inculqué la persévérance dans mon éducation, eux qui m’ont sou-
tenu tout au long de ce travail.

• Le Professeur Eugène C. EZIN, le Directeur de l’Institut de Formation et de Recherche en Infor-

matique.

• L’ingénieur Pierre Jérôme ZOHOU, superviseur du dit travail, lui qui m’a accompagné avec ses
orientations et toute l’énergie dépensé pour que je puisse produire ce travail.

• Monsieur Gérard Sylvanus TOLODE, enseignant à IFRI, lui m’a aussi accompagné avec ces
orientations.

Nos sincères remerciements aux membres du jury qui ont acceptés d’honorer notre travail par leur
jugements.

iii
 Résumé
L’expansion du développement d’application web et mobile ces dernières années, ne cesse de rendre
la vie plus facile aux utilisateurs finaux. Le présent travail de fin de formation propose un ensemble
d’outils pouvant permettre de collecter les taxes marchandes dans la commune de Ouidah. Pour ce
faire, deux applications s’échangent des données grâce à l’implémentation d’une API REST. Au fur
et à mesure que les collectes se font dans les marchés avec l’application mobile, les données sont en-
voyées en temps réel vers le back-end. La conception de ces outils facilite la vie aux administrateurs
et aux dirigeants de pouvoir faire le point et de visualiser les statistiques en temps réel. L’implé-
mentation de ces plateformes a été possible grâce à une modélisation UML à travers les différents
diagrammes, aux frameworks Laravel et Ionic et au système de gestion des bases de données Post-
greSQL.

Mots clés : API REST, Taxes marchandes, frameworks, Ouidah.

iv
 Abstract
Expansion of web and mobile application development in recent years is making life easier for
end users. The present project proposes a toolset that can be used to collect commercial taxes in
the commune of Ouidah. To do so, two applications exchange data through the implementation of
a REST [Link] collections are made in the markets with the mobile application, the data is sent in
real time to the back-end. The design of these tools makes it easy for administrators and managers
to take stock and view statistics in real time. The implementation of these platforms was possible
thanks to the UML modeling through various diagrams, the Laravel and Ionic frameworks and the
PostgreSQL database management system.

Key words: API REST, Market taxes frameworks, Ouidah.

Table des figures

1.1 Interface de connexion de E-SERVICES . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2 Image de MECeF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1 Diagramme de cas d’utilisation SMART TAX COLLECT . . . . . . . . . . . . . . . . . . 11

2.2 Diagramme de classes de SMART TAX COLLECT . . . . . . . . . . . . . . . . . . . . . 14
2.3 Diagramme de séquence du cas d’utilisation Faire paiement . . . . . . . . . . . . . . . . 15
2.4 Diagramme de séquence du cas d’utilisation Vérifier la solvabilité d’un abonnement . . . 16
2.5 Fonctionnement du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1 Interface de connexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 Interface de la page d’accueil (statistiques par argent) . . . . . . . . . . . . . . . . . . . 21
3.3 Détails des collectes par l’agent ADMIN SYSTEM . . . . . . . . . . . . . . . . . . . . . 22
3.4 Interface de la page d’accueil (statistiques par marché) . . . . . . . . . . . . . . . . . . 22
3.5 Interface de la page d’accueil (statistiques des comptes) . . . . . . . . . . . . . . . . . . 23
3.6 Interface d’insertion d’un marchand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.7 Interface d’enregistrement d’un abonnement . . . . . . . . . . . . . . . . . . . . . . . . 24
3.8 Interface de recherche du marchand avec sa référence . . . . . . . . . . . . . . . . . . . 24
3.9 Interface de la liste des abonnements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.10 Interface du formulaire de paiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.11 Interface d’accueil de l’application mobile . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.12 Interface de connexion de l’application mobile . . . . . . . . . . . . . . . . . . . . . . . 27
3.13 Le tableau de bord de l’application mobile . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.14 Interface de paiement de l’application mobile . . . . . . . . . . . . . . . . . . . . . . . . 29

vi
Liste des acronymes

1, Glossaire :

acronyme :
Def acronyme 1

vii
Glossaire

AJAX :
Architecture informatique qui permet de construire des applications Web et des sites web dyna-
miques interactifs sur le poste client.

HTTP :
est un protocole de communication client-serveur développé pour le World Wide Web. C’est un lan-
gage permettant d’écrire de l’hypertexte, d’où son nom.

UML :
est un langage de modélisation graphique à base de pictogrammes conçu pour fournir une méthode
normalisée pour visualiser la conception d’un système.

1
Introduction Générale

Contexte et justificatif

L’informatique est l’une des disciplines ayant marquée le XXIème siècle tant sur le plan adminis-
tratif que économique. Cette science a rendu capable la machine d’apprendre automatiquement à
partir d’une quantité de données mise à sa disposition pour des prises de décision ou d’accompa-
gner l’humain dans ses tâches quotidiennes. En effet parlant de l’économie, toute personne exerçant
une activité à but lucratif dans un pays doit reverser une taxe sur la valeur ajoutée à l’Etat : c’est le
cas au Bénin où des taxes marchandes sont collectées par commune sur toute l’étendue du territoire.
C’est ainsi que dans le cadre de notre projet, le travail consiste à trouver une solution informatique
permettant la collecte de ces fonds dans la commune de Ouidah.

Problématique

Plusieurs problèmes se sont posés lors de la conception de notre solution. En effet, comment savoir
avec certitude la taxe marchande qui est collectée par jour de marché ou par agent en temps réel ;
comment identifier les marchandes et marchands qui ne payent pas leurs taxes ; comment savoir
si un agent falsifie les reçus pour un non retour des fonds. Plusieurs questions restent posées sans
réponse. Pour répondre donc à ces impératifs, le thème « Conception d’un système de collecte des
taxes marchandes dans la commune de Ouidah » a été soumis à notre réflexion.

Objectifs

L’objectif principal de notre projet est de concevoir une plateforme web et une application mobile
permettant la collecte des taxes marchandes dans la commune de Ouidah. Pour cela, de manière
spécifique nous aurons à :

• créer une plateforme web, permettant la gestion complète des marchand(e)s, des abonnements,
des paiements réalisés et de vérifier la solvabilité des abonnés ;

• créer une application mobile qui communiquera avec l’application web pour la collecte des
fonds en espèce chez les marchand(e)s avec possiblité de scanner des codes QR sur le terrain ;

2
 • faire le point de toutes les recettes par jour, par agent et par marché notamment sur la plate-
forme web.

Organisation du document

Le présent travail est structuré en trois chapitres. Le chapitre 1 présente la généralités sur le système
fiscal au Bénin et une étude de l’existant par rapport aux solutions informatiques qui aborde dans le
même sens que notre présent travail. 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.
Chapitre 1
Revue 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. Ainsi, ce chapitre fait un résumé de l’existant en matière de
collecte des diverses taxes au Bénin. Il consistera à présenter le système fiscal au Bénin puis établir
une synthèse des différents travaux qui ont été réalisés pour la collecte de ces taxes.

1.1 Généralités sur le système fiscal au Bénin

Au Bénin, toute personne (physique ou morale) exerçant une activité à but lucratif est frappée d’une
manière ou d’une autre par une taxe sur ses revenus. Après réforme du système fiscal en 2020 [4] ,
trois type de prélèvement sont applicables à la date d’aujourd’hui en république du Bénin. il s’agit
notamment :

1.1.1 Revenu des personnes physiques

L’Impôt sur le Revenu des Personnes Physiques (IRPP) [5] est un impôt annuel unique qui frappe
le revenu net global du contribuable. Il est exigible de toute personne physique et assimilée dont
le domicile fiscal est situé au Bénin. L’impôt sur le revenu des personnes physiques est également
exigible :

• de toute personne qui transfère en cours d’année son domicile au Bénin ou hors du Bénin ;
L’impôt, dans ce cas est établi suivant les dispositions de l’article 126 et 127 du CGI ;

• des personnes de nationalité béninoise ou étrangère qui ayant ou non une résidence habituelle
au Bénin recueillent des bénéfices ou des revenus dont l’imposition est attribuée, au Bénin par
une convention internationale.

1.1.2 Impôt sur les sociétés

Il est établi un impôt annuel sur l’ensemble des bénéfices réalisés par les sociétés et autres personnes
morales désignées à l’article 145 du CGI. Cet impôt est désigné sous le nom d’Impôt sur les Sociétés

4
Chapitre 1. Revue de littérature 1.2. Étude de l’existant

[6]. L’Impôt sur les sociétés (IS) est appliqué sur les bénéfices nets réalisés au Bénin, ainsi que ceux
dont l’imposition est attribuée au Bénin par une convention internationale visant l’élimination des
doubles impositions.

1.1.3 Taxes sur la consommation

La taxe sur la valeur ajouté (TVA) [7] est l’une des principales taxes sur consommation applicable au
Bénin. En effet, cette taxe qui frappe la dépense est unique et à paiement fractionné. Le mécanisme
de fonctionnement de la TVA oblige tout redevable légal à collecter la taxe lors de ses opérations de
vente de biens et services, à imputer de la TVA collectée, le montant de la TVA supportée en amont
sur ses opérations d’achat de biens et services et à reverser au guichet des impôts la TVA nette qui en
résulte. Hormis la principale taxe sur la consommation qu’est la TVA et qui atteint les dépenses en
général, le système fiscal béninois a prévu des prélèvements indirects qui frappent la consommation
de certains biens.

1.2 Étude de l’existant

En entreprise, la partie la plus importante d’un système de facturation est le recouvrement des fonds à
bonne date. En effet, l’Etat béninois a mise en place quelques solutions informatiques pour la collecte
des fonds fiscaux sur toute l’étendue du territoire. Parmi ces solutions nous pouvons citer SIGTAS
et E-SERVICES, MECeF, etc.

1.2.1 SIGTAS et E-SERVICES

SYSTEME INTEGRE DE GESTION DES TAXES ET ASSIMILES (SIGTAS) [8] est un progiciel qui
intègre des fonctionnalités permettant à la Direction Générale des Impôts (DGI), l’administration de
tout ce qui concerne la fiscalité au Bénin. Comme fonctionnalité, nous pouvons cité :

• la fonction d’immatriculation ;

• la fonction d’assiette ;

• la fonction de contrôle ;

• la fonction de recouvrement ;

• la fonction du contentieux ;

• etc.

La mise en place de SIGTAS permet la transparence dans les opérations de traitement de l’impôt,
l’élargissement de l’assiette de l’impôt et l’automatisation de la gestion de l’assiette et du recouvre-
ment. Le SIGTAS est un système avancé, car la liquidation de la plupart des impôts auxquels les
contribuables sont assujettis est automatique, ce qui réduit considérablement les risques d’erreur
dans l’émission des titres de perception. En outre, le nouveau système admet des interfaces favo-
rables aux téléprocédures, ce qui implique la télé déclaration et le télépaiement.
Le E-SERVICES [8] par contre est une application web qui fonctionne de concert avec la base
SIGTAS. Elle permet aux contribuables enregistrés et aux représentants de ceux-ci, à qui des comptes
sont ouverts, de pouvoir :

5
Chapitre 1. Revue de littérature 1.2. Étude de l’existant

1. effectuer des déclarations sans se rendre dans l’Administration des Impôts ;

2. consulter et au besoin imprimer leur situation fiscale ;

3. échanger des correspondances avec les Services compétents de l’administration fiscale ;

4. demander en ligne certains documents fiscaux.

L’interface web de connexion de E-SERVICES [9] s’affiche de la manière suivante, voir figure 1.1.
L’accès à l’interface du tableau de bord est conditionné par la création d’un compte.
Par ailleurs, les banques partenaires communiquent avec la base SIGTAS, ce qui offre aux contri-
buables la possibilité de télépayer les déclarations soumises sans passer à la caisse du Receveur des
Impôts.

F IGURE 1.1 – Interface de connexion de E-SERVICES

1.2.2 MECeF
La Direction Générale des Impôts (DGI), dans le souci de respecter les exigences de la transition
fiscale, s’est engagée dans une série de réformes visant la modernisation des procédures fiscales. En
outre, elle a opté pour une nouvelle approche de maîtrise de l’assiette fiscale au moyen des factures
normalisées. Ainsi la Machines Electroniques Certifiées de Facturation (MECeF) [10], voir figure 1.2
a été mise en application pour accompagner la direction dans sa collecte de recette. MECeF est un
système informatique mise en place par la Direction Générale des Impôts (DGI), basé sur un Module
de Contrôle de Facturation (MCF) et sur un Système de Facturation d’Entreprise (SFE). Elle permet à
toute entreprise assujettie à la TVA, de faire des requêtes en temps réel via un protocole bien défini,
tout en envoyant, outre les mentions classiques d’une facture, des éléments de sécurité de la DGI
(le numéro d’identification de la machine (NIM), la signature et le code électronique). De plus MCF
est un dispositif électronique connecté au système de facturation d’entreprise (SFE) permettant à ce
dernier de produire des factures normalisées. Une facture normalisée est une facture standardisée

6
Chapitre 1. Revue de littérature 1.3. Forces et limites de l’existant

dont le contenu est prescrit par les autorités et qui comporte des mécanismes de sécurité qui assurent
l’authenticité et l’intégrité des données sur la facture. Les informations de sécurité sur une facture
normalisée sont fournies par MCF.

F IGURE 1.2 – Image de MECeF

1.3 Forces et limites de l’existant

Jusqu’à l’heure actuelle, dans la commune de Ouidah, tout le processus de collecte des taxes mar-
chandes se fait de façon manuelle. En effet, la possession d’une place dans les marchés est condition-
née par un abonnement dont le prix varie selon le type de place. Les agents collecteurs sont envoyés
dans les différents marchés de la place pour délivrer des tickets et récupérer les taxes marchandes.
A la fin de la journée, ces agents une fois de retour à la marie font le point des recettes. Étant donné
donc qu’aucune oeuvre humaine n’est parfaite, des erreurs peuvent donc être présente lors du dérou-
lement de ce processus. C’est ainsi que la mise en place d’un système informatique pour automatiser
tout le processus depuis l’abonnement des marchands jusqu’à la collecte des taxes marchandes dans
la commune de Ouidah s’est avérée nécessaire.

Conclusion

De ce chapitre, nous pouvons dire qu’au Bénin, la DGI a opté pour certaines solutions informa-
tiques (SIGTAS ET E-SERVICES, MECeF) lui permettant de régulariser les recettes fiscales. Mais re-
marquons que ces solutions n’ont pas un module pouvant aider les différentes communes dans la
collecte des taxes marchandes considérées comme taxe sur valeur ajoutée. Pour le présent projet, il

7
Chapitre 1. Revue de littérature 1.3. Forces et limites de l’existant

s’agira donc de concevoir une application pouvant permettre, précisément à la mairie de la commune
de Ouidah de collecter les taxes marchandes. Le chapitre suivant fera l’objet d’une présentation de
notre solution à travers sa conception et les outils utilisés pour sa réalisation.

8
Chapitre 2
Analyse, conception et choix techniques

Introduction

La réalisation d’une application nécessite un regroupement et une hiérarchisation des idées liées à
sa conception et à son développement. Le présent chapitre présente la solution proposée ainsi que
les différentes phases de sa modélisation. Il présente également un aperçu des différents outils et
technologies utilisés pour la réalisation de la solution.

2.1 Description de la solution et méthodologie de développement

2.1.1 Méthodologie de développement

La conduite du projet s’est faite en se conformant à la méthodologie Agile, une approche de déve-
loppement itératif qui permet d’observer concrètement l’évolution du projet. Le choix a été porté
sur Scrum qui est une méthode agile où le développement est découpé en plusieurs phases courtes
appelées itérations ou sprint. Chaque itération inclut des travaux de conception, de spécification
fonctionnelle et technique quand c’est nécessaire, de développement et de test. Dans notre cas, le dé-
veloppement a été découpé en itérations de deux mois. L’ensemble des fonctionnalités prévues pour
notre solution nous a permis d’établir des user stories qui ont été découpées en tâches, afin d’éta-
blir clairement le travail à réaliser. Cette méthode permet de mieux s’adapter aux imprévus pouvant
subvenir pendant le projet et facilite la livraison d’un produit de qualité.

2.1.2 Solution proposée

SMART TAX COLLECT vient répondre à la problématique de collecte des taxes marchandes dans
les différents marchés de la commune de Ouidah, à travers une plateforme web et une application
mobile qui permettront aux agents du service de collecte de la mairie de Ouidah de pouvoir collecter
les redevances concernant les abonnements marchands. Ce système sera conçu de telle manière que
les marchand(e)s seront déjà inscrit avec génération d’un code Qr à la base qui servira aux agents sur
le terrain. Ce code sera scanné et permettra à l’agent d’avoir une idée sur la redevance de l’abonné.
Ainsi ce système permettra également aux administrateurs et au service de collecte de la mairie de

9
Chapitre 2. Analyse, conception et choix techniques 2.2. Modélisation

Ouidah de suivre la recette des agents en temps réel, au fur et à mesure que les paiements des abon-
nements se font sur le terrain.

2.2 Modélisation

Afin de modéliser les fonctionnalités de la plateforme des collectes des taxes marchandes, le choix
a été porté sur UML (Unified Modeling Language) [11] , qui est aujourd’hui un outil de modélisa-
tion incontournable, utilisé sur des centaines de projets de par le monde. UML est un langage de
modélisation graphique conçu pour fournir un ensemble de représentations standardisées afin de
réaliser la conception architecturale et fonctionnelle d’un logiciel. Il est également indépendant du
langage de programmation utilisé pour le développement dudit logiciel. Ainsi, les diagrammes de
cas d’utilisation, de classes et de séquence exposeront la modélisation de la présente application.

2.2.1 Diagramme de cas d’utilisation

Le diagramme de cas d’utilisation regroupe tous les cas d’utilisation possibles d’un logiciel. Il est la
représentation complète des fonctionnalités du système modélisé. La figure 2.1 illustre le diagramme
de cas d’utilisation de SMART TAX COLLECT. IL en ressort que pour ce système nous avons trois
catégories d’utilisateurs : Marchand(e), Service de collecte, Administrateur
En effet, ces trois principaux acteurs intervenant dans l’utilisation de notre application ont un
champs d’action bien défini. Pour n’importe quel type d’utilisateur il est obligatoire de s’authentifier
avant d’effectuer n’importe quelle action dans le système. Cette authentification passe par la saisie
d’un numéro de téléphone et d’un mot de passe qui donne accès aux fonctionnalités de l’application.
De plus, remarquons que l’administrateur est une spécification directe et indirecte respectivement
du Service de collecte et d’un(e) Marchand(e). En d’autre terme, outre les actions que le Service de
collecte ou qu’un Marchand peut faire sur le système, ce dernier pourra gérer les utilisateurs (Agent
et Marchand(e)) à travers l’ajout d’un nouveau utilisateur dans le système avec attribution de rôle,
modification des informations d’un utilisateur existant ou bien supprimer un utilisateur.
Quant au Service de collecte qui est une spécification d’un(e) marchand(e). Ce dernier peut en-
registrer un paiement, faire un dépôt sur le compte d’un marchand, consulter le point des recettes
de la journée et gérer les abonnements marchands. Soulignons que le service de collecte regroupe les
agents présentent ou non sur le terrain.
Enfin le marchand peut vérifier la validité de ses abonnements et consulter le solde de ses divers
comptes.

2.2.2 Description des cas d’utilisation

Nous avons retenu deux (02) cas d’utilisation que nous décrirons :
• Ajouter abonnement

• Faire paiement
Le choix a été porté sur les deux cas d’utilisation parce-qu’ils sont beaucoup plus important que
les autres. En effet, dans le processus de collecte des taxes marchandes, il est important d’avoir une
idée sur comment le processus d’abonnement se déroule et le prix de cet abonnement. De même,
comment les paiements des redevances des abonnements se passent sur les différentes applications.

10
Chapitre 2. Analyse, conception et choix techniques 2.2. Modélisation

F IGURE 2.1 – Diagramme de cas d’utilisation SMART TAX COLLECT

[Link] Cas d’utilisation 1

Nom : Ajouter abonnement

Ce cas représente une succession d’action qui aboutit à ajouter un abonnement pour prendre une
place.

Acteur : Service de collecte et Administrateur

Description : Le Service de collecte et l’administrateur sont les seuls à pouvoir ajouter un abon-
nement pour l’acquisition des places marchandes.

Pré-condition : L’utilisateur doit se connecter au préalable.

Démarrage : Après connexion l’utilisateur doit cliquer sur le menu Abonnement

Scénario :

11
Chapitre 2. Analyse, conception et choix techniques 2.2. Modélisation

1. l’utilisateur vient sur la page qui comporte la liste des abonnements déjà enregistrés dans le
système ;

2. l’utilisateur clique sur le bouton Créer pour être rediriger sur le formulaire d’ajout des abonne-
ments.

3. Une fois sur la page d’ajout, l’utilisateur clique autant de fois sur le bouton Ajouter, tout en
remplissant les informations demandées.

4. une liste de pré abonnement est constituée automatiquement dans un tableau ;

5. après vérification, si il y’a pas d’erreur, l’utilisateur clique sur Sauvgarder

Scénario d’erreur :

1. dans le remplissage du formulaire, l’utilisateur doit choisir un marché avant que la liste des
places disponibles ne soit affichées.

2. si dans la vérification de la liste qui est constituée, l’utilisateur retrouve une erreur, la possibilité
est donnée pour supprimer cette ligne et de reprendre l’ajout de cette seule ligne ;

[Link] Cas d’utilisation 2

Nom : Faire paiement

Ce cas représente une succession d’action qui aboutit à réaliser un paiement sur la plateforme web.

Acteur : Service de collecte et l’administrateur

Description : Le Service de collecte et l’administrateur ont tous la possibilité de réaliser un paie-

ment.

Pré-condition : Les deux catégories d’utilisateurs doivent se connecter au préalable.

Démarrage : Après connexion sur la plateforme web, l’utilisateur clique sur le menu Paiements

Scénario :

1. l’utilisateur vient sur la page de la liste des paiements déjà effectués et clique sur le bouton
Faire un paiement

2. l’utilisateur renseigne la référence du marchand et clique ensuite sur PAYER de l’abonnement

concerné.

3. après avoir renseigner les informations demandées, il clique sur Lancer le paiement

Scénario d’erreur :

1. Après avoir renseigner la référence marchande, si le système ne trouve pas cette référence une
erreur est affichée.

2. si tous les champs du formulaire de paiement ne sont pas renseignés, le bouton Lancer le paie-
ment n’est pas désactivé.

12
Chapitre 2. Analyse, conception et choix techniques 2.2. Modélisation

2.2.3 Diagramme de classes

Afin de spécifier les classes intervenant dans le système et quels liens elles entretiennent entre elles,
nous utiliserons un diagramme de classes. La figure 2.2 présente le diagramme de classes de SMART
TAX COLLECT. Ce diagramme comporte les classes comme Personne, Marchand, ServiceCollecte,
Agent, Utilisateur, Rôle, Permission, Marché, MethodePaiement, CategorieMarchand, TypeAbonne-
ment, Abonnement, Compte, TypePlace, Place, Transaction, Paiement. Mais une attention particulière
sera portée sur les classes suivantes :

1. La classe Abonnement permet d’enregistrer des données liées aux abonnements de chaque
marchand dans le système. Elle est liée en première position à la classe Place, ce qui entraîne
qu’une place donnée peut avoir plusieurs abonnement de même ou de différents types à des
dates différentes. De plus la classe Abonnement est reliée à la classe Compte par une relation de
1 à 1. Ce qui veut dire que par abonnement un compte est systématiquement créé. Cette classe
permettra à une date t d’avoir la liste de tous les abonnements par marchand par place et/ou
par compte.

2. La classe Transaction permet d’enregistrer les informations relatives à toutes les transactions
effectuées dans le système. Une transaction peut faire l’objet d’un dépôt d’argent sur le compte
d’un marchand ou d’un retrait d’argent via le paiement des redevances d’un abonnement. Re-
marquons dans un premier temps que la classe transaction est reliée à classe Agent et à la
classe Marchand, pour permettre d’identifier l’agent qui a effectué la transaction et pour quel
marchand cela a été fait. Dans un second temps elle est aussi reliée à classe Compte et à la classe
Abonnement pour permettre de savoir depuis quel compte la transaction a été effectuée (c’est
le cas d’un paiement de redevance) pour un abonnement ou bien sur quel compte la transaction
à été faite (c’est le cas d’un dépôt d’argent sur un compte concernant un abonnement). La réelle
importance de cette classe est de pouvoir sortir à tout moment le relevé de transaction d’un
compte donné.

3. La classe Paiement permet de sauvegarder toutes les données relatives aux paiements des re-
devances de chaque abonnement. Le paiement d’un abonnement fait référence au calcul de
toute la somme due sur ledit abonnement d’un marchand donné depuis la dernière date de
validité du compte à la date d’aujourd’hui. La classe Paiement est reliée à la classe Agent, ce
qui permet de comprendre qu’un agent peut effectuer plusieurs paiements lié à un abonnement
donné. Ainsi la réelle importance de cette classe est de pouvoir justifier à tout moment toutes
les transactions effectuées et qui ont fait l’objet d’un retrait d’un compte donné.

13
Chapitre 2. Analyse, conception et choix techniques 2.2. Modélisation
F IGURE 2.2 – Diagramme de classes de SMART TAX COLLECT
14
Chapitre 2. Analyse, conception et choix techniques 2.2. Modélisation

2.2.4 Diagramme de séquence

Pour décrire la chronologie d’un cas d’utilisation et les objets intervenant dans sa réalisation, il est
commun d’utiliser un diagramme de séquence. Les diagrammes de séquence permettent donc de
donner une première idée de la manière dont les scénarios des cas d’utilisation se déroulent. Il s’agira
d’exposer le diagramme de séquence des cas Faire paiement voir figure 2.3 et Vérifier validité d’un
abonnement voir figure 2.4.

[Link] Diagramme de séquence Faire paiement 2.3

Lorsqu’un utilisateur à qui les permissions ont été accordés veut enregistrer un paiement, le système
lui demande de renseigner le numéro de référence marchand qui a été généré lors de son inscription
(la plateforme web) ou de scanner le code QR qui sera en possession du marchand (l’application
mobile). Après avoir renseigner le numéro ou scanner le code QR, le système vérifie si un marchand
dans la base de donnée existe avec une telle référence ; si le marchand existe, le système lui affiche
toute la liste de ces différents abonnements (si ce dernier a plusieurs places) avec le numéro de ré-
férence du compte associé a cet abonnement ; dans le cas où le marchand n’existe pas un message
d’erreur est renvoyé. Une fois la liste affichée, un bouton PAYER est sur chaque ligne d’abonnement
permettant de lancer le paiement d’un abonnement donné. De plus, une fois le bouton appuyé, l’uti-
lisateur est redirigé sur un formulaire, lui présentant dans un cadrant le solde actuel du compte, le
montant à payer depuis la dernière date de validité du compte à la date d’aujourd’hui, l’ancienne
date de validité, la nouvelle date de validité après paiement, le nom de l’agent voulant faire l’opéra-
tion, le nom du marchand concerné et la date du paiement. Et dans un autre cadrant les information
à saisir relatives au paiement. Après avoir renseigner les informations demandées, le processus de
paiement est lancé. Ce processus est sanctionné par le prélèvement du montant à payer depuis le
compte.

F IGURE 2.3 – Diagramme de séquence du cas d’utilisation Faire paiement

15
Chapitre 2. Analyse, conception et choix techniques 2.3. Fonctionnement du système

[Link] Diagramme de séquence Vérifier la solvabilité 2.4

Lorsqu’un utilisateur à qui les droits nécessaires ont été accordés pour consulter, il renseigne le nu-
méro de référence du marchand ou scanne le code QR avec l’application mobile et le système se
charge de vérifier si un marchand dans la base de donnée existe avec une telle référence ; si le mar-
chand existe, le système lui affiche toute la liste des différents abonnements non réglés avec les dé-
tails ; mais si la référence est introuvable, un message d’erreur est envoyé à l’utilisateur.

F IGURE 2.4 – Diagramme de séquence du cas d’utilisation Vérifier la solvabilité d’un abonnement

2.3 Fonctionnement du système

SMART TAX COLLECT repose essentiellement sur deux projets. L’un appelé Back office (la partie
web) qui sera principalement utilisé par les administrateurs et les dirigeants du service de collecte
de la mairie et l’autre Front office (la partie mobile) utilisable par les agents sur le terrain et/ou les
marchand(e)s. La réalisation d’un tel système se fera dans la possibilité où les deux projets s’échan-
geront des données via le protocole HTTP (Hypertext Transfer Protocol) grâce à l’implémentation
d’une API REST [19] qui offre des services web. Parmi les multiples types de web service qui existent
aujourd’hui nous avons adopté l’architecture des API REST (Representational State Transfer) [19] qui
est basé essentiellement sur le protocole HTTP. C’est un protocole qui définit la communication entre
les différentes parties du web. L’échange est basée sur des requêtes client-serveur. Un client lance une
requête HTTP, le serveur traite et renvoie une réponse. Ce qui veut dire que une fois sur le terrain,
les agents envoient des requêtes depuis l’application mobile, qui va chercher ensuite les données né-
cessaire sur le serveur (le back office) ; Ce dernier à son tour renvoie une réponse sous un format bien
précis. Le type de format qui est échangé entre les deux plateformes est le JSON (JavaScript Object
Notation)

16
Chapitre 2. Analyse, conception et choix techniques 2.4. Choix techniques

F IGURE 2.5 – Fonctionnement du système

2.4 Choix techniques

2.4.1 Outils et technologies utilisées

La réalisation de notre solution a nécessité l’utilisation de plusieurs technologies. Elles seront regrou-
pées en deux groupes : le Back-end et le Front-end.

[Link] Back-end

Le Back-end représente tout ce que l’utilisateur ne voit pas relativement à l’application. Il s’agit des
traitements logiques et actions effectués pour pouvoir conserver, fournir, ou modifier les données au
sein de l’application. Les technologies que nous avons utilisées à cet effet sont :

• PHP 7.4
PHP (Hypertext Preprocessor) [12] est un langage de scripts généraliste et Open Source, spé-
cialement conçu pour le développement d’applications web. L’ accès à une page PHP se traduit
par le fait que le code est lu ou «analysé» par le serveur sur lequel la page réside. La sortie des
fonctions PHP sur la page est généralement renvoyée sous forme de code HTML, qui peut être
lu par le navigateur. Ce qui distingue PHP des langages de script comme le Javascript, est que
le code est exécuté sur le serveur, générant ainsi le HTML, qui sera ensuite envoyé au client. Le
client ne reçoit que le résultat du script, sans aucun moyen d’avoir accès au code qui a produit
ce résultat. De plus PHP est un langage orienté objet et de haut niveau avec une sémantique
dynamique. Ses structures de données intégrées de haut niveau, combinées à un typage dy-
namique et à une liaison dynamique, le rendent très attrayant pour le développement rapide
d’applications web. Il nous a aidé à travers l’écriture de règles pour la conception de toute la
base du développement du back-office.

• LARAVEL 7
Laravel [13] est un framework web open-source écrit en PHP respectant le principe Modèle-
Vue-Contrôleur et entièrement développé en programmation orientée objet. C’est également un
framework de haut niveau qui encourage le développement rapide et une conception propre

17
Chapitre 2. Analyse, conception et choix techniques 2.4. Choix techniques

et pragmatique. Construit par des développeurs expérimentés, il prend en charge la majeure

partie des problèmes liés au développement Web tels que la scalabilité, la rapidité, la sécurité,
etc. Ainsi il est possible de se concentrer sur l’écriture de l’application sans avoir à réinventer
la roue. Ces raisons nous ont poussé à le choisir pour le développement du back-end.

• PostgreSQL 12
PostgreSQL [15] est un SGBDRO (Système de Gestion de Bases de Données Relationnelles et
Objet) open-source, robuste et puissant, aux fonctionnalités riches et avancées, capable de ma-
nipuler en toute fiabilité de gros volumes de données, mêmes dans des situations critique. Dans
le cadre de notre solution, il a été préféré à MySql un autre SGBDR simple d’utilisation à cause
de sa robustesse.

• Angular 11
Angular [14] est un Framework open source écrit en JavaScript qui permet la création d’appli-
cations Web et plus particulièrement de ce qu’on appelle des « Single Page Applications » :
des applications web accessibles via une page web unique qui permet de fluidifier l’expérience
utilisateur et d’éviter les chargements de pages à chaque nouvelle action. Le Framework est
basé sur une architecture du type MVC. Le choix est porté sur Angular pour l’interaction de la
l’application mobile fait en IONIC avec le back-end.

[Link] Front-end

Le Front-end, par opposition au Back-end fait référence aux éléments que l’on voit à l’écran, avec
lesquels on peut interagir ; il désigne la partie visuelle de l’application. Il s’agit d’éléments comme les
images, les fenêtres, les boutons, les menus déroulants, etc. Les technologies que nous avons utilisées
à cette fin sont :

• HTML 5 et CSS 3
HTML ou HyperText Markup Language est un langage de description et de balisage des pages
Web. Il permet de structurer et de mettre en forme le contenu des pages Web avec des balises
de formatage. Les balises permettent d’indiquer la façon dont la page doit être présentée et les
liens qu’elle partage avec d’autres pages.
CSS ou Cascading Style Sheets (en français feuilles de style en cascade) définit des règles per-
mettant de modifier l’aspect des pages Web dont le contenu a été décrit en HTML (les polices,
les couleurs, les espacements, etc). Le principe des feuilles de style consiste à regrouper dans un
même document des caractéristiques de mise en forme associées à des groupes d’éléments. Ces
deux technologies ont donc été utilisées pour décrire et mettre en forme le contenu des pages
Web de SMART TAX COLLECT

• JavaScript
JavaScript est un langage de programmation qui permet d’implémenter des mécanismes com-
plexes sur une page web. Il peut intervenir lorsque qu’une page web fait plus que simplement
afficher du contenu statique, par exemple afficher du contenu mis à jour à des temps déter-
minés, des cartes interactives, des animations 2D/3D, des menus vidéo défilants, etc. C’est la
troisième couche des technologies standards du web, les deux premières étant HTML et CSS.

18
Chapitre 2. Analyse, conception et choix techniques 2.4. Choix techniques

• Bootstrap 4
Bootstrap est un framework front-end gratuit pour un développement Web plus rapide et plus
facile. Bootstrap comprend des modèles de conception basés sur HTML et CSS pour la ty-
pographie, les formulaires, les boutons, les tableaux, la navigation, les carrousels d’images et
bien d’autres, ainsi que des plugins JavaScript en option. Il permet de faire des interfaces qui
s’adaptent automatiquement à tous les appareils, des petits téléphones aux grands ordinateurs
de bureau. Ces raisons nous ont poussées à choisir cette technologie afin de fournir à l’utilisa-
teur de belles interfaces s’adaptant convenablement à n’importe quel type d’écrans.

• jQuery
jQuery est une bibliothèque JavaScript qui est une collection de routines JavaScript, qui prend
en compte de nombreuses tâches et les encapsule dans de simples méthodes faciles de manipu-
lation. La bibliothèque jQuery englobe des fonctionnalités telles que la manipulation des élé-
ments du DOM (Document Object Model), la manipulation CSS, les méthodes d’événements,
les effets et animations, AJAX (Asynchronous JavaScript and XML), etc. Elle a été utilisée dans
notre solution pour gérer l’interactivité des pages et pour les requêtes AJAX qui permettaient
de communiquer avec le serveur afin de modifier une page sans avoir à la recharger.

• [Link]
[Link] est une bibliothèque JavaScript de représentation de données sous forme de graphes
qui utilise l’élément canvas HTML5, ce qui la rend de ce fait compatible avec la quasi totalité
des navigateurs supportant HTML5. C’est une bibliothèque légère ne nécessitant aucune dé-
pendance, ce qui facilite ainsi son intégration. Les représentations graphiques générées par
[Link] sont de différents types, notamment les courbes, les diagrammes en bâtons, les
ca- memberts, etc et s’adaptent à tout type d’écran. Le choix a été porté sur cet outil pour la
présentation des statistiques.

• IONIC 5
Le framework Ionic [15] est une boîte à outils d’interface utilisateur open source permettant
de créer des applications mobiles et de bureau performantes et de haute qualité à l’aide des
technologies Web telles que HTML, CSS et JavaScript, avec des intégrations Client-Serveur en
utilisant les framework JavaScript tels que Angular, React etc... Le choix a été porté sur IONIC
pour le développement de l’aplication mobile que les agents utiliseront sur le terrain.

Conclusion

Ce chapitre a présenté notre solution à travers sa modélisation, son fonctionnement et les choix tech-
niques liés à sa réalisation. Le prochain chapitre fournira les résultats obtenus suite à l’utilisation de
notre l’application.

19
Chapitre 3
Résultats et discussions

Introduction

Dans ce chapitre nous présenterons les résultats de notre travail à travers les différentes interfaces
de nos applications (web et mobile) ainsi que ses limites. A l’issue de ce chapitre, les différents ob-
jectifs de départ sont atteints et la solution que nous proposons doit être prêt et exploitable par les
utilisateurs finaux.

3.1 Résultat

3.1.1 Les interfaces de l’application web

[Link] La connexion

L’accès à la plateforme web est sanctionné par la saisie d’un numéro de téléphone et d’un mot de
passe ; d’où la création d’un compte à chaque utilisateur.

F IGURE 3.1 – Interface de connexion

20
Chapitre 3. Résultats et discussions 3.1. Résultat

[Link] La page d’accueil de l’application web

Après avoir renseigné les informations de connexion, l’utilisateur est redirigé sur la page d’accueil
montrant les statistiques par argent, les statistiques par marché et les statistiques des comptes
A gauche de l’écran, se trouve le menu de navigation. Cet menu est composé de 6 grandes ru-
briques à savoir :

• MARCHAND(E)S

• MARCHÉS ET PLACES

• ABONNEMENTS ET COMPTES

• TRANSACTIONS ET PAIEMENTS

• SERVICE DE COLLECTE ET AGENTS

• UTILISATEURS ET RÔLES

Comme le montre l’image 3.2, au fur et mesure que que les paiements se font sur le terrain,
l’administrateur verra la liste des agents qui collectent les taxes à cet instant ainsi que le montant
collecté par agent.

F IGURE 3.2 – Interface de la page d’accueil (statistiques par argent)

De plus dans la colonne de Actions qui se trouve sur le tableau, une fois ce bouton cliqué, l’on
est redirigé sur les détails des collectes faites par un argent donné, montrant ainsi le nom des ma-
rhand(e)s chez qui les collectes ont été faites, la référence de l’abonnement, le type d’abonnement, le
montant à payer avant ledit paiement, le montant reçu par l’agent, le reliquat, la méthode de paie-
ment utilisée, la date de paiement, etc.... (voir figure 3.3)

21
Chapitre 3. Résultats et discussions 3.1. Résultat

F IGURE 3.3 – Détails des collectes par l’agent ADMIN SYSTEM

Après cela, comme cité précédemment, la rubrique des statistiques par marché montre le pour-
centage de collecte d’un marché par rapport à un autre ou à plusieurs autres marchés. Le graphique
va jusqu’à préciser combien est collecté par marché (voir figure 3.4).

F IGURE 3.4 – Interface de la page d’accueil (statistiques par marché)

En ce qui concerne les statistiques des compte (voir figure 3.5)., l’image montre le nombre de
compte qui sont valides à la date actuelle et ceux qui sont pas valide (c’est à dire les marchandes qui
doivent au moins une journée de redevance)

22
Chapitre 3. Résultats et discussions 3.1. Résultat

F IGURE 3.5 – Interface de la page d’accueil (statistiques des comptes)

Ce qui nous intéresse le plus c’est de voir comment les paiements sont effectués. Mais avant cela
nous montrerons comment se passe l’enregistrement d’un marchant, comment se passe l’abonnement
d’un marchand pour une place donnée et voir le renseignement des informations lors de paiement.

[Link] Enregistrement d’un marchand

L’enregistrement d’un marchand est conditionné par la saisie des informations demandées sur le
formulaire (voir figure 3.6). Comme l’indique cette figure, nous avons deux sections d’informations
à renseigner informations personnelles (c’est à dire les informations du marchand à l’état civil) et
informations de connexion (les informations de connexion pour les différentes plateformes). Notons
que les information de connexion pour les marchands peuvent être facultative ; ceci est remplie pour
les marchands désirant se connecter pour vérifier la validité de leur abonnement.

F IGURE 3.6 – Interface d’insertion d’un marchand

[Link] Enregistrement d’un abonnement

Pour enregistrer l’abonnement d’un marchand concernant une place donnée, il faut renseigner les
informations qui s’affichent sur le pop-up. Remarquons que plusieurs ligne peuvent être ajouter
si le marchand désire prendre plus d’une place. Les montants total de tous les abonnements sont
automatiquement calculés du coté supérieur gauche du tableau (voir figure 3.7)

23
Chapitre 3. Résultats et discussions 3.1. Résultat

F IGURE 3.7 – Interface d’enregistrement d’un abonnement

[Link] Processus d’un paiement

Pour procéder à un paiement, comme décrit dans les sections plus haut du chapitre 2, il faut rensei-
gner le numéro de référence du marchand (voir figure 3.8), ensuite choisir l’abonnement pour lequel
l’on veut faire le paiement si le marchand en a plusieurs (voir figure 3.9) et pour finir, renseigner les
informations du paiement (voir figure 3.10)

F IGURE 3.8 – Interface de recherche du marchand avec sa référence

24
Chapitre 3. Résultats et discussions 3.1. Résultat

F IGURE 3.9 – Interface de la liste des abonnements

F IGURE 3.10 – Interface du formulaire de paiement

3.1.2 Les interfaces de l’application mobile

[Link] L’accueil de l’application mobile

L’application mobile est l’outil qui accompagne les agents sur le terrain qui leurs permettent de faire
la collecte des divers frais liés aux abonnements des marchand(e)s. Cette partie présente en gros ce
que les agents pourrons faire avec l’application mobile. Voir figure 3.11 pour la page d’accueil de
l’application mobile

25
Chapitre 3. Résultats et discussions 3.1. Résultat

F IGURE 3.11 – Interface d’accueil de l’application mobile

[Link] La connexion

Comme pour l’application web, l’accès à l’application mobile est sanctionné aussi par la saisie d’un
numéro de téléphone et d’un mot de passe ; Ces informations sont connues après l’inscription sur la
plateforme web. En effet, pour accéder à l’application mobile il faut donc cliquer sur le bouton c’est
parti et renseigner les informations de connexion. voir figure 3.12

26
Chapitre 3. Résultats et discussions 3.1. Résultat

F IGURE 3.12 – Interface de connexion de l’application mobile

[Link] Le tableau de bord

Le tableau bord de l’application mobile fait un peu le récapitulatif des collectes qui ont eu lieu les 6
derniers jours de marché par l’agent qui s’est connecté. En bas de l’écran nous avons trois options de
navigation à savoir Accueil, Opérations et Paramètres, voir figure 3.13. L’onglet Opération redirige
vers la page où se trouve l’ensemble des opérations que peut faire un agent et/ou un(e) marchand(e).

27
Chapitre 3. Résultats et discussions 3.1. Résultat

F IGURE 3.13 – Le tableau de bord de l’application mobile

[Link] Le paiement des abonnements

Contrairement au processus de paiement sur la plateforme web qui demande de renseigner tout
d’abord la référence du marchand, celui de l’application de mobile est un tout petit peu différent.
Comme cela a été dit plus haut dans les hypothèses, l’agent qui aimerais faire la collecte, une fois sur
place, lance le scannage du code Qr généré lors de l’inscription du marchand. Ceci renvoie une liste
vide si ce dernier ne possède pas d’abonnement, une erreur si ce code Qr n’a aucune correspondance
dans la base de donnée ou bien une liste d’abonnement si le marchand possède un ou plusieurs
abonnements à la fois (voir figure 3.14).

28
Chapitre 3. Résultats et discussions 3.2. Discussion

F IGURE 3.14 – Interface de paiement de l’application mobile

Une fois la liste affichée, l’agent verra les abonnement dont les comptes sont toujours valide ou
non. Ce dernier aura la main de procéder uniquement aux paiements des abonnements qui ne sont
pas valide, c’est à dire les abonnements dont la date de validité est inférieure à la date à laquelle
l’opération veut être effectuer.

3.2 Discussion

Nos applications permettent de gérer depuis l’inscription d’un marchand passant par son abonne-
ment et pour finir le paiement de ces redevances. Ces deux plateformes donneront la possibilité aux
dirigeants des marchés de la commune de Ouidah de suivre de plus près tout ce qui ce passe sur
le terrain, d’avoir une idée des collectes qui se font par les agents. En outre, dans la pratique nos
applications présentent quelques insuffisances :

• Avoir une bonne connexion est une contrainte rencontré lors du développement puisque l’ap-
plication mobile est censée envoyer des requêtes vers le back-end.

29
Chapitre 3. Résultats et discussions 3.2. Discussion

• Malgré la mise en place de ces outils informatiques pour l’automatisation du processus de

collecte des taxes marchandes, la méthode de paiement en espèce reste la même.

• Le comportement de nos applications sur un serveur distant pour tester la performance de nos
algorithmes ne sont pas encore fait.

Conclusion

En sommes, ce dernier chapitre nous a permit de d’exposer les résultats de nos applications à travers
quelques captures d’écran des applications même si cela n’est pas encore complètement au point. Les
test unitaires ainsi que les test d’intégration nous permettront de mettre en oeuvre la sécurité et la la
rapidité des applications.

30
Conclusion Générale et Perspectives

En somme, l’objectif de notre projet est de concevoir et de réaliser une application web et mobile
pour la collecte des taxes marchandes dans nos différentes communes, notamment dans la commune
de Ouidah. Pour y arriver, nous avions collecté les informations nécessaires pour l’élaboration de
notre existant, puis son analyse nous a permis de dénicher la problématique de notre étude. Par la
suite nous nous sommes intéressé à la conception et aux choix techniques ; ce qui nous a amené de
distinguer les différents acteurs qui interagissent dans nos systèmes et de faire le choix techniques
des outils à utiliser pour la réalisation des deux applications. Au terme des travaux qui ont eu lieu
lors de la réalisation des dits projets, nous avons abouti à la création d’une plateforme web et d’une
application mobile qui répondent globalement aux objectifs qui ont été défini plus haut. En plus de
cela, nous pouvons sortir en fichier PDF et EXCEL plusieurs états et statistiques pouvant aider les
administrateurs du système et les dirigeants de la commune de Ouidah a vite prendre des décisions.
En effet des perspectives intéressantes sont envisagées pour ce travail. Nous pouvons entre autre :

• Ajouter les API de paiement par Mobile Money, Moov Money ou intégrer un agrégateur de
paiement comme KKiaPay, histoire de permettre aux agents d’envoyer directement leurs re-
cettes sur un numéro téléphonique donné et aux marchand(e)s désireux de payer eux-même
leur redevances via l’application mobile ;

• Intégrer une firebase [20] pour permettre de la fluidité des opérations depuis l’application mo-
bile ;

• Étendre cette solution dans les autres communes du Bénin après les multiples tests d’intégra-
tions, permettant d’avoir un outil centralisé de collecte de taxe marchande sur toute l’étendue
du territoire nationale.

31
Bibliographie

[1] Fielding, Roy Thomas, Architectural Styles and the Design of Network-based Software Architectures,
2000

[2] D. Crockford, The application/json Media Type for JavaScript Object Notation (JSON), 2006

[3] Leonard Richardson, Sam Ruby, RESTful Web Services, 2007

32
 Webographie

[4] Système fiscal au Bénin, [Link]

consulté le 15 Mai 2020

[5] Impôt sur le Revenu des Personnes Physiques au Bénin, [Link]

[Link]/impot-sur-le-revenu-des-personnes-physiques-irpp/, consulté le 15 Mai
2020

[6] Impôt sur les Sociétés au Bénin, [Link]

s-societes-is/, consulté le 16 Mai 2020

[7] Taxe sur la Valeur Ajoutée au Bénin, [Link]

la-valeur-ajoutee-tva/, consulté le 20 Mai 2020

[8] Documentation sur SIGTAS et E-SERVICES, [Link]

wp-content/uploads/2018/03/[Link], consulté
le 25 Mai 2020

[9] Interface web de connexion à E-SERVICES, [Link]

consulté le 02 Juin 2020

[10] Réforme fiscale avec MECeF, [Link]

consulté le 02 Mai 2020

[11] Qu’est ce que le langage UML ?, [Link]

l, consulté le 02 Février 2020

[12] Documentation PHP, [Link] consulté le 03 Août 2020

[13] Documentation LARAVEL, [Link] consulté le 03 Août 2020

[14] Documentation Angular 11, [Link] consulté le 08

Août 2020

[15] Documentation IONIC, [Link] consulté le 08 Août 2020

[16] Documentation POSTGRESQL, [Link]

consulté le 06 Mai 2020

33
[17] Laravel Rest API Passport Authentication for Ionic App, [Link]
r/laravel-rest-api-passport-authentication-for-ionic-app-3934713bcdf7,
consulté le 11 Juillet 2020

[18] Ionic 4 User Registration & Login Tutorial, [Link]

registration-login-tutorial/, consulté le 04 Septembre 2020

[19] Les services web de type REST, [Link]

ices-web-de-type-rest, consulté le 29 Mars 2020

[20] Qu’est ce qu’un FIREBASE ?, [Link] consulté le 15

Décembre 2020

34
Table des matières

Dédicace ii

Remerciements iii

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

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

Table des figures vi

Liste des acronymes vii

Introduction 2

1 Revue de littérature 4
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Généralités sur le système fiscal au Bénin . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1 Revenu des personnes physiques . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.2 Impôt sur les sociétés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.3 Taxes sur la consommation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 SIGTAS et E-SERVICES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2 MECeF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Forces et limites de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Analyse, conception et choix techniques 9

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1 Description de la solution et méthodologie de développement . . . . . . . . . . . . . . 9
2.1.1 Méthodologie de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.2 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Modélisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.1 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.2 Description des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
[Link] Cas d’utilisation 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
[Link] Cas d’utilisation 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.3 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

35
 2.2.4Diagramme de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
[Link] Diagramme de séquence Faire paiement 2.3 . . . . . . . . . . . . . . . 15
[Link] Diagramme de séquence Vérifier la solvabilité 2.4 . . . . . . . . . . . . 16
2.3 Fonctionnement du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 Choix techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.1 Outils et technologies utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
[Link] Back-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
[Link] Front-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Résultats et discussions 20
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1 Résultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1.1 Les interfaces de l’application web . . . . . . . . . . . . . . . . . . . . . . . . . . 20
[Link] La connexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
[Link] La page d’accueil de l’application web . . . . . . . . . . . . . . . . . . 21
[Link] Enregistrement d’un marchand . . . . . . . . . . . . . . . . . . . . . . 23
[Link] Enregistrement d’un abonnement . . . . . . . . . . . . . . . . . . . . . 23
[Link] Processus d’un paiement . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1.2 Les interfaces de l’application mobile . . . . . . . . . . . . . . . . . . . . . . . . 25
[Link] L’accueil de l’application mobile . . . . . . . . . . . . . . . . . . . . . . 25
[Link] La connexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
[Link] Le tableau de bord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
[Link] Le paiement des abonnements . . . . . . . . . . . . . . . . . . . . . . . 28
3.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Conclusion 31

Bibliographie 32

Webographie 33

Table des matières 35

36
37