Université Cadi Ayyad

Ecole Supérieur de Technologie-Safi

Département : Informatique
Filière : Génie Informatique

Rapport PFE

Conception et Développement d’une Application Web du

Gestion des Factures

Réaliser par : Encadrer par :

khadija Daoubari Mr. Hamzane Ibrahim

Wafae Jouhal Tuteur :

Malak Znadi Azeddine Nadif

Année universitaire 2024/2025

Dédicace

À ALLAH avant tout

À nos très chers parents
Aucune dédicace ne saurait exprimer l’amour, l’estime, le dévouement et
le respect que nous avons pour vous.
Rien au monde ne vaut les efforts que vous avez fournis jour et nuit pour notre
éducation et notre bien-être.
Ce travail est le fruit des sacrifices que vous avez faits pour notre éducation
et notre formation. « Nous vous aimons très fort »

À nos chers frères et chères sœurs

Pour tout ce que vous avez fait pour nous,
Vous étiez toujours à nos côtés pour nous soutenir et nous motiver,
Nous vous souhaitons une vie pleine de bonheur et de succès.

À nos chers tantes, oncles et toute notre grande famille

Pour votre gentillesse, votre soutien, vos encouragements et votre
confiance en nous.

À nos chers amis

Pour votre gentillesse, votre compréhension, pour les beaux moments
que nous avons passés ensemble, ...bref pour votre amitié.
À notre trinôme Malak et Wafae.
À toutes les personnes qui nous sont chères.
À tous ceux qui nous aiment.
À tous les musulmans

grand merci à vous.

Khadija DAOUBARI
Malak ZNADI
Wafae JOUHAL

1
Remerciements

Au terme de ce travail, nous tenons à exprimer notre profonde gratitude et nos sincères remerciements
à tous ceux qui nous ont aidés de près ou de loin pendant la réalisation de notre projet.

Nous tenons également à remercier Monsieur Hamzane, professeur à l’EST Safi, pour son encadrement,
son enthousiasme vis-à-vis de notre projet et ses encouragements. Nos sincères remerciements vont égale-
ment à Azeddine Nadif, qui a eu l’honneur de nous encadrer tout au long de ce travail. Nous lui sommes
très reconnaissants pour ses fructueux conseils, ses précieuses directives, et pour le grand intérêt qu’elle
porte à notre sujet.

Nous adressons des remerciements spéciaux à tout le corps professoral de l’EST Safi pour la formation
de qualité qu’ils nous ont prodiguée durant ces deux années. Que tous ceux et celles qui ont contribué de
près ou de loin à l’accomplissement de ce travail trouvent ici l’expression de nos remerciements les plus
chaleureux.

2
Table des Matières

Introduction 7

1 Etude Préalable 8

1.1 Introductions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.2 Besoins Fonctionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.3 Besoins non Fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Etude Conceptuel 10

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2 Description et choix des outils techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.1 Choix des outils de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 Architecture de systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3.1 Spécifications ou conception générale . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3.2 Les modèles de cycle de vie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4 Choix du langage de conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4.1 Choix d’uml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4.2 Notions UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4.3 Pourquoi une méthode objet ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.5 Conception de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.5.1 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.5.2 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Réalisation 18

3
 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2 Environnements de travail et choix techniques . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2.1 Environnements de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2.2 Langage de programmation et technologies utilisés . . . . . . . . . . . . . . . . . . 19

3.2.3 Plan de Réalisation du Projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 Présentation de l’application 24

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.2 Interface d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.3 Interface d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.4 Tableau de Bord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.5 Les Produits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.6 Les Factures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.7 Interfaces Utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.8 Les Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.9 Les Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.10 Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.11 Rapport Finnanciere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Conclusion Générale 40

Webographie 41

4
Table des figures

2.1 Architecture Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2 Modèle du cycle de vie en cascade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3 Vue Statique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.4 Vue dynamique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.5 Diagramme de cas d’utilisation generale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.6 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1 visual studio code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2 plateforme overleaf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3 Adobe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.4 Star UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.5 Power AMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.6 Laravel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.7 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.8 Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.9 bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.10 XAMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.11 Laragon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.1 Interface d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2 Interface d’inscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.3 Login de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.4 Interface des Statistique de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.5 L’ajout des produits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5
4.6 Ajout des produit et generation automatique de TVA . . . . . . . . . . . . . . . . . . . . 28

4.7 la modification des produits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.8 La suppression des produits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.9 Parametre des produits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.10 La Liste des factures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.11 Exportation de la facture en XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.12 La facture Payee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.13 La facture impayee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.14 La facture partiellement payee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.15 l’ajout des users selon leur roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.16 la liste des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.17 Ajouter des roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.18 la modifications des roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.19 la liste des roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.20 les informations sur les roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.21 la liste des permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.22 L’Ajout de permission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.23 Notifications de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.24 rapport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.25 Chercher appartient du type de facture et la date . . . . . . . . . . . . . . . . . . . . . . . 38

4.26 Chercher appartir du numero de la facture . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6
Introduction

Ce projet de fin d’études se concentre sur la création d’une solution complète de gestion des factures pour
les entreprises, en utilisant Laravel PHP et Bootstrap pour l’application web. En outre, l’utilisation de
Git pour le contrôle de version garantit une collaboration efficace et une gestion du code source optimale.

Cette introduction offre un aperçu des défis associés à la gestion des factures dans les entreprises, ainsi
qu’une justification de l’approche technologique choisie pour notre projet. Nous débuterons par une ana-
lyse des problèmes courants rencontrés dans la gestion des factures, en mettant en lumière les risques
de sécurité potentiels liés aux processus manuels et aux systèmes obsolètes. Ensuite, nous présenterons
notre solution proposée, en mettant en avant les avantages de l’utilisation de Laravel PHP, Bootstrap et
Git dans le développement d’une plateforme robuste, intuitive et sécurisée.

Certes, le bon fonctionnement de l’application et le respect du cahier des charges sont très importants,
mais la sécurisation de cette dernière est d’une importance majeure. Pour cela, elle a été prise en consi-
dération tout au long de la réalisation.

Ce rapport détaillera les différentes phases par lesquelles nous sommes passés afin d’aboutir à une ap-
plication fiable et satisfaisante. Le rapport définit le travail que nous avons effectué. Il est composé de
trois grandes parties. La première partie présente le contexte du projet et la spécification des besoins, la
deuxième est consacrée à la conception, et la dernière partie comporte les résultats obtenus.

7
Chapitre 1

Etude Préalable

1.1 Introductions

Un projet d’application de gestion de factures vise à développer une plateforme logicielle permettant aux
utilisateurs de gérer efficacement toutes les étapes liées à la gestion des factures, depuis leur création
jusqu’au suivi des paiements.

1.2 Besoins Fonctionnel

L’application doit permettre et fournir les fonctionnalités suivantes :

• Chaque comptable et financier peut gerer les factures ,les fournisseurs, les clients et
la listes des produits.

• Chaque comptable, financier et gestionnaire d’entreprise peut créer une nouvelle fac-
ture.

• Chaque comptable, financier et gestionnaire d’entreprise peut modifier une facture.

• Chaque comptable, financier et gestionnaire d’entreprise peut modifier l’ état de

chaque facture.

• Chaque comptable et financier peut consulter et lister l’historique de l’ état de chaque

facture.

• Chaque comptable et financier peut ajouter un nouveau client.

• Chaque comptable et financier peut modifier les informations d’un client.

• Chaque comptable et financier peut supprimer un client .

• Chaque comptable, financier et gestionnaire d’entreprise peut consulter la liste des

clients.

• Chaque comptable, financier et gestionnaire d’entreprise peut ajouter un nouveau

8
 fournisseur.

• Chaque comptable et financier peut modifier les informations d’un fournisseur.

• Chaque comptable et financier peut supprimer un fournisseur.

• Chaque comptable, financier et gestionnaire d’entreprise peut consulter la liste des

fournisseurs .

• Chaque comptable, financier et gestionnaire d’entreprise peut consulter les diagrammes

des statistiques génerer à propos les factures .

• Chaque Gestionnaire d’Entreprise peut accéder au interface gérer par les Comptables
et les financiers.

• Chaque Gestionnaire d’Entreprise peut Ajouter de nouveaux utilisateurs (comp-

tables/financiers).

• Chaque Gestionnaire d’Entreprise peut Modifier les droits d’accès privilèges d’un
comptable/financier.

• Chaque Gestionnaire d’Entreprise peut Modifier les droits d’accès privilèges d’un
comptable/financier.

• Chaque comptable, financier et gestionnaire d’entreprise recoie des notifications .

1.3 Besoins non Fonctionnels

Les besoins non fonctionnels sont indispensables et permettent l’amélioration de la qualité logicielle de
notre système. Ils agissent comme des contraintes sur les solutions, mais leur prise en considération fait
éviter plusieurs incohérences dans le système. Ce dernier doit répondre aux exigences suivantes :

• Un temps de réponse minimal.

• Un contrôle d’accès aux utilisateurs.

• Une interface conviviale et facile à utiliser.

• La mise à jour instantanée de la base de données.

• La disponibilité et minimisation des blocages et plantages.

1.4 Conclusion

Dans ce chapitre j’ai presente les taches de l’application.

9
Chapitre 2

Etude Conceptuel

2.1 Introduction

Dans ce chapitre nous présentons les méthodologies de conception que nous avons utilisée dans la concep-
tion de notre projet Donc nous présentons une spécification et une analyse des besoins en décrivant les
différents outils qui nous avons utilisés dans la conception de notre application web suivit d’une analyse
détaillé de besoins explicites et implicites du travail demandé ainsi les différents besoins opérationnel.
Nous enchainons alors avec l’architecture de notre application et par suite nous présentons les différents
diagrammes, à savoir les, de cas d’utilisation , de classe, afin de spécifier de façon détaillée les aspects
fonctionnels, dynamiques et statiques du système.

2.2 Description et choix des outils techniques

2.2.1 Choix des outils de développement

Dans le milieu du développement web, il existe plusieurs outils et langage de programmation. Nous
avons les Framework PHP (Laravel, Symfony, . . .), JAVA (Java Server Face, Google Web Kit, . . .), Py-
thon (Django, . . .). Le choix de l’outil de développement va beaucoup influer sur le projet et la manière
dont celui-ci sera développé, en fonction des avantages et des inconvénients des langages. Il convient
donc de les choisir en considérant la maîtrise de outils et les objectifs et fin du projet, pour éviter de
devoir changer de langage au cours du développement du projet, ce qui constituera une perte considé-
rable de temps. De plus des langages optimisés et facile à apprendre permettront d’avoir une meilleure
optimisation de la charge du CPU, ce qui aura pour conséquence de préserver le matériel et facilité la
maintenance. Après plusieurs recherche et réflexion nous avons décidé d’utiliser comme langage front-end
HTML , JavaScript (JQuery), CSS(Bootstrap) et comme langage de programmation back-end PHP.

L’Hyper Text Markup Language, généralement abrégé HTML, est le langage de balisage qui va nous
aider à représenter les pages web et d’écrire de l’hypertexte, d’où son nom. JavaScript est un langage de
programmation de scripts principalement employé dans les pages web interactives. Les feuilles de style
en cascade, généralement appelées CSS de l’anglais Cascading Style Sheets, forment un langage infor-
matique qui décrit la présentation des documents HTML et XML. Bootstrap est une collection d’outils
utiles à la création du design (graphisme, animation et interactions avec la page dans le navigateur,
etc.) de sites et d’applications web. PHP : Hypertext Preprocessor, plus connu sous son sigle PHP (sigle
auto-référentiel), est un langage de programmation libre, principalement utilisé pour produire des pages

10
Web dynamiques via un serveur HTTP.

Notre choix s’est porté sur ses outils de développement parce que nous les maîtrisons très bien déjà et
elles sont les mieux adapté pour notre projet.

2.3 Architecture de systeme

L’objectif de la modélisation constituer de mieux comprendre le fonctionnement du système. Qui est une
application pour la gestion des factures.

2.3.1 Spécifications ou conception générale

L’architecture d’une application web présente traditionnellement trois niveaux (on parle d’architecture
à trois tiers) :

Tiers client qui correspondent à la machine sur laquelle l’application cliente est exécutée.

Tiers métiers qui correspondent à la machine sur laquelle l’application centrale est exécutée.

Tiers accès aux données qui correspondent à la machine gérant la stockage des données.

Chaque tiers doit être indépendant des autres et peut, par conséquent, être remplacé sans engendrer des
modifications dans les autres tiers.

Figure 2.1 – Architecture Systeme

2.3.2 Les modèles de cycle de vie

Le « cycle de vie d’une application web »désigne toutes les étapes de développement d’une application,
de sa conception à sa disparition.

11
Ces modèles consistent en une succession de phases dont chacune est méthodiquement vérifiée avant de
passer à l’étape suivante :

• Conception détaillée Cette étape consiste à définir précisément chaque sous-ensemble de notre
application Web.

• Codage C’est la traduction dans un langage de programmation des fonctionnalités définies lors
de phases de conception.

• Tests Unitaires Ils permettent de vérifier individuellement que chaque sous-ensemble de l’appli-
cation Web est implémenté conformément aux spécifications.

• Intégration L’objectif est de s’assurer de l’interfaçage des différents éléments (modules) de l’ap-
plication Web. Elle fait l’objet de tests d’intégration consignés dans un document.

• Qualification (ou recette) C’est-à-dire la vérification de la conformité de l’application Web

aux spécifications initiales.

• Documentation Elle vise à produire les informations nécessaires pour l’utilisation de l’applica-
tion Web et pour des développements ultérieurs.

• Mise en production C’est le déploiement sur l’espace de l’application Web.

• Maintenance Elle comprend toutes les actions correctives (maintenance corrective) et évolutives
(maintenance évolutive) sur l’application Web.

Figure 2.2 – Modèle du cycle de vie en cascade

12
2.4 Choix du langage de conception

2.4.1 Choix d’uml

Par rapport à toutes les méthodes orientées objets qui sont en utilisation, seule UML a la capacité de
satisfaire tous les besoins de conceptions requises par les entreprises et les sociétés informatiques.

En effet, Il unifie les notations nécessaires aux différentes activités d’un processus de développement et
offre en plus de ça les moyens d’établir le suivi des décisions prises depuis les spécifications jusqu’au
codage.

2.4.2 Notions UML

UML :(Unified Modeling Language) ou « Langage de Modélisation Unifié » Standardisé par l’OMG
(Object Management Group) est une notion basée principalement sur les méthodes des BOOCH (de
BOOCH), OMT de Rumbaugh et OOSE de Jacobson.UML a été proposé afin de standardiser les produits
de développement (modèle, notation, diagramme) sans standardiser le processus de développement qui
dépend des personnes, des applications, des cultures, etc.

UML se propose de créer un langage de modélisation utilisable à la fois par les humais (forme graphique)
et les machines (syntaxe précise). L’utilisation des modèles « UML » sert à :

• Décomposer le processus de développement.

• Mettre en relation les experts des métiers et les analystes.
• Coordonner les équipes d’analyse de la réalisation.
• Séparer l’analyse de la réalisation.
• Prendre en compte l’évolution de l’analyse et du développement.
• Migrer facilement vers une architecture objet d’un point de vue statique.

2.4.3 Pourquoi une méthode objet ?

Les langages orientés objet constituent chacun une manière spécifique d’implémenter le paradigme objet.
Ainsi, une méthode objet permet de définir le problème à haut niveau sans rentrer dans les spécificités
d’un langage. Il représente ainsi un outil permettant de définir un problème de façon graphique, afin par
exemple de le présenter à tous les acteurs d’un projet (n’étant pas forcément des experts en un langage
de programmation).

UML comporte 9 diagrammes standards représentant autant de "vues" d’un système d’information. Ces
diagrammes se répartissent en deux catégories : quatre représentent la structure statique de l’application ;
cinq représentent son comportement dynamique.

13
Vue Statique

Figure 2.3 – Vue Statique

Vue Dynamique

Figure 2.4 – Vue dynamique

2.5 Conception de l’application

2.5.1 Diagramme de cas d’utilisation

Definition :

Ce diagramme est destiné à représenter les besoins des utilisateurs par rapport au système. Il constitue
un de diagrammes le plus structurants dans l’analyse d’un système.

Acteur : représente un rôle joué par une personne qui interagit directement avec le système
étudié.

14
Cas d’utilisation (use case) : représente un ensemble des séquences d’actions qui sont
réalisées par le système et qui produisent un résultat observable intéressant pour un
acteur particulier. L’utilisation d’un diagramme de cas d’utilisation s’avère indispensables
pour décrire les besoins fonctionnels. Ces diagrammes permettent de décrire l’interaction
entre l’acteur et le système. C’est l’image d’une fonctionnalité de système déclenchée en
réponse à la stimulation d’un acteur externe.

Concepts de base :

Notre application fait intervenir quatre acteurs compte tenu du déroulement et de com-
plémentarité des opérations qui sont :

Figure 2.5 – Diagramme de cas d’utilisation generale

15
2.5.2 Diagramme de classe

Un diagramme de classe est un type de diagramme utilisé dans l’ingénierie logicielle pour
représenter la structure statique d’un système logiciel orienté objet. Il met en évidence les
classes du système, ainsi que leurs attributs, leurs méthodes et les relations entre elles. Les
diagrammes de classe sont essentiels pour la conception et la modélisation des systèmes
logiciels, car ils permettent aux développeurs de visualiser et de comprendre la structure
du système, ce qui facilite la communication et la collaboration entre les membres de
l’équipe de développement.

Figure 2.6 – Diagramme de classe

16
2.6 Conclusion

Dans ce chapitre j’ai présenté mon application Web par deux modèles(cas d’utilisa-
tion,classe) et diagrammes pour donner une idée globale pour rendre notre projet plus
claire et compréhensive sur les différentes cotés. Toutes ces taches vont être traduites sur
des interfaces qu’on va représenter dans le chapitre suivant.

17
Chapitre 3

Réalisation

3.1 Introduction

La phase de réalisation met en valeur les interfaces graphiques de l’application. Donc

nous allons commencer tout d’abord par l’identification des langages et des outils de
développement Puis nous allons présenter les différentes phases d’implémentation.

3.2 Environnements de travail et choix techniques

Cette section met l’accent sur les logiciels utilisés durant ce travail. Puis nous abordons
les différentes technologies mises en place.

3.2.1 Environnements de travail

Les principaux logiciels utilisé durant la conception de l’application pour la gestion des
factures sont :

• Visual studio code : Afin d’avoir une bonne aide au développement ainsi qu’une
bonne intégration des différents outils de python Visual Studio Code fut utilisé tout
au long du développement, c’est un éditeur de code extensible ses fonctionnalités
incluent la prise en charge du débogage, la mise en évidence de la syntaxe, la
complétion intelligente du code, les snippets, la refactorisation du code et Git intégré
et des extensions qui ajoutent des fonctionnalités supplémentaires.

Figure 3.1 – visual studio code

18
 • overleaf : Overleaf est une plateforme pratique pour les utilisateurs de LaTeX,
offrant des fonctionnalités de collaboration et une expérience d’édition en ligne
sans tracas.

Figure 3.2 – plateforme overleaf

• Adobe : utilisé pour le traitement des images utilisées tout le long du projet que
ce soit dans la conception du logo dans le rapport élaboration du cahier de charge
ou le développement de l’application.

Figure 3.3 – Adobe

• Star UML : StarUML est un outil de modélisation UML (Unified Modeling Lan-
guage) largement utilisé dans le domaine du développement logiciel. Il permet aux
développeurs de créer des diagrammes UML pour concevoir, visualiser et documen-
ter des systèmes logiciels.

Figure 3.4 – Star UML

• PowerAMC : Power AMC, anciennement connu sous le nom de Sybase PowerDe-

signer, est un outil de modélisation et de conception de bases de données. Il permet
aux concepteurs de bases de données de créer des modèles conceptuels, logiques et
physiques de bases de données, ainsi que de générer du code SQL pour différentes
plates-formes de base de données.

3.2.2 Langage de programmation et technologies utilisés

Durant notre travail, on a utilisé plusieurs outils et technologies :

19
 Figure 3.5 – Power AMC

Laravel

Laravel est un framework web open-source écrit en PHP, conçu pour le développement
rapide et la création d’applications web modernes et évolutives. Il fournit une structure
robuste et des fonctionnalités puissantes pour simplifier le processus de développement
tout en maintenant la flexibilité et la maintenabilité du code.

Figure 3.6 – Laravel

PHP

PHP, acronyme de "Hypertext Preprocessor", est un langage de programmation open-

source largement utilisé pour le développement web. Il est spécialement conçu pour être
intégré dans des pages HTML et est souvent utilisé pour créer des sites web dynamiques
et interactifs.

Figure 3.7 – PHP

Git

Pour la gestion de version, étant habitué à Git. Cet outil nous a permis tout au long du
PFE de garder trace des différentes évolutions de celui-ci. L’un des avantage de Git est
sa gestion aisée des branches. Cette fonctionnalité est très utile pour tester sans crainte
certaines approches et d’en garder une trace même si en l’état ces modifications ne sont
prêtes pour rejoindre le tronc commun.

20
 Figure 3.8 – Git

bootstrap

Bootstrap est un framework front-end open-source développé par Twitter. Il fournit des
outils et des modèles pour la création d’interfaces web réactives et mobiles conviviales.
Bootstrap utilise HTML, CSS et JavaScript pour faciliter le développement de sites web
responsive et attrayants.

Figure 3.9 – bootstrap

XAMP

XAMPP est un logiciel gratuit et open-source qui facilite la création et la gestion de

serveurs web locaux. Il comprend des composants tels que Apache, MySQL, PHP et Perl,
ce qui en fait une solution tout-en-un pour développer des applications web sur votre
propre ordinateur.

Figure 3.10 – XAMP

Laragon

Laragon est une plateforme de développement local qui facilite la création et la gestion
d’environnements de développement web sur votre ordinateur. Contrairement à d’autres
solutions telles que XAMPP ou WAMP, Laragon est conçu pour être simple à installer
et à utiliser, tout en offrant des fonctionnalités avancées pour les développeurs.

21
 Figure 3.11 – Laragon

3.2.3 Plan de Réalisation du Projet

• Phase de planification (1 semaine) :

Définition des objectifs du projet de gestion de projet.
Identification des fonctionnalités clés de l’application.
Élaboration de la structure de l’application.
Planification des ressources nécessaires.

• Phase de conception (2 semaines) :

Création des maquettes et des prototypes de l’interface utilisateur.
Définition de l’architecture logicielle.
Identification des technologies et des outils nécessaires.
Élaboration de la base de données et du schéma de données.

• Phase de développement (10 semaines) :

Création du tableau de bord principal de gestion de projet.
Fonctionnalités de création et de gestion de projets.
Fonctionnalités de création et de gestion de tâches.
Fonctionnalités de gestion des ressources et de l’affectation des tâches.
Fonctionnalités de suivi du temps et des dépenses.
Fonctionnalités de collaboration et de communication entre les membres de l’équipe.
Tests unitaires et intégration continue.

• Phase de tests et de correction des bugs (2 semaines) :

Exécution de tests fonctionnels et non fonctionnels.
Identification et correction des bugs et des problèmes de performance.
Validation de l’application par les utilisateurs finaux.

• Phase de déploiement (1 semaine) :

Préparation de l’environnement de production.
Configuration des serveurs et des bases de données.
Déploiement de l’application sur les serveurs de production.

22
 • Phase de formation et de documentation (1 semaine) :
Élaboration de la documentation technique et des guides d’utilisation.
Formation des utilisateurs finaux sur l’application de gestion de projet.
Support post-déploiement.
• Phase de suivi et de maintenance (en cours) :
Suivi des performances de l’application en production.
Correction des bugs et des problèmes signalés.
Ajout de nouvelles fonctionnalités et améliorations selon les besoins des utilisateurs.

À la fin de notre projet, nous avons obtenu une application ’Scanf’ responsive, simple et
très accessible qui permet à l’utilisateur l’accès facile à des factures avec la possibilité de
les transférer et exporter la facture.
Après plusieurs tests réalisés par différents utilisateurs, nous avons corrigé tous les bugs
identifiés lors de nos tests.

3.3 Conclusion

Dans ce chapitre j’ai présenté la planification de la projetpour la gestion des factures et

Nous avons utilisé une combinaison d’outils et de technologies appropriés pour répondre
aux besoins du projet, en mettant l’accent sur la fonctionnalité..

23
Chapitre 4

Présentation de l’application

4.1 Introduction

Dans ce chapitre nous allons présenter quelques interfaces de notre application web pour
décrire leurs fonctionnements.

4.2 Interface d’accueil

Ces interfaces représentent Home de notre application web.

24
25
 Figure 4.1 – Interface d’accueil

4.3 Interface d’authentification

L’interface ci-dessous présente le formulaire d’inscription client, dans le cas ou le client

oublie de saisir les champs obligatoires, un message d’erreur s’affiche pour la vérification.

Figure 4.2 – Interface d’inscription

La figure ci-dessous représente la page d’authentification de l’administrateur. En effet,

L’authentification est la première tâche qu’un administrateur doit effectuer pour accéder
au menu administrateur approprié. Dans le cas ou il saisit des informations erronées un
message d’erreur lui sera affiché à fin de corriger les informations : son nom d’utilisateur
ou mot de passe.

26
 Figure 4.3 – Login de l’application

4.4 Tableau de Bord

L’interface ci-dessous présente les statistiques des Factures selon l’état de paiement paye
ou non paye ou partiellemnt paye.

Figure 4.4 – Interface des Statistique de l’application

4.5 Les Produits

Cette interface permet à l’administrateur de l’application d’ajouter,modifier ou supprimer

un nouveau produit.

27
 Figure 4.5 – L’ajout des produits

Figure 4.6 – Ajout des produit et generation automatique de TVA

Les produits que nous avons inclus ont déjà été intégrés, et en ce qui concerne la Taxe
sur la Valeur Ajoutée (TVA), elle peut être calculée de manière automatique.

28
 Figure 4.7 – la modification des produits

Figure 4.8 – La suppression des produits

4.6 Les Factures

Cette interface nous présente la liste des listes de facture ainsi les différents opérations
que l’admin peut faire telles que l’ajout, la modification, la suppression des factures.

29
 Figure 4.9 – Parametre des produits

Cette Interface ci-dessous represente la liste des factures ajouter par l’administrateur ou
par le fournisseure.

Figure 4.10 – La Liste des factures

30
 Cet image represente le code en xml pour exporter une facture.

Figure 4.11 – Exportation de la facture en XML

Cette interface montre une facture qui a été entièrement payée. Tous les montants figu-
rant sur la facture ont été réglés, ce qui est indiqué par le statut "Payée" sur la facture.

Figure 4.12 – La facture Payee

Cette interface représente une facture qui n’a pas encore été payée. Le montant total
de la facture reste dû, comme indiqué par le statut "Impayée". Cela peut être dû à
diverses raisons, telles que le retard de paiement du client ou des problèmes financiers de
l’entreprise cliente.

31
 Figure 4.13 – La facture impayee

Cette Interface la facture est partiellement payée, ce qui signifie qu’une partie du montant
total a été réglée, mais qu’il reste encore un solde impayé. Le statut "Partiellement Payée"
indique que le paiement partiel a été effectué, et le montant restant dû est spécifié sur la
facture.

Figure 4.14 – La facture partiellement payee

32
4.7 Interfaces Utilisateurs

Cette interface l’administrateur est présenté avec un formulaire permettant d’ajouter de

nouveaux utilisateurs à l’application. Le formulaire inclut des champs pour saisir le nom,
l’adresse e-mail et le rôle de l’utilisateur. Il offre également la possibilité de définir les
autorisations spécifiques associées à chaque rôle, ce qui permet à l’administrateur de
contrôler l’accès des utilisateurs à différentes fonctionnalités de l’application.

Figure 4.15 – l’ajout des users selon leur roles

Cette liste permet à l’administrateur de visualiser rapidement tous les utilisateurs et de

filtrer les résultats par rôle ou par d’autres critères pertinents. De plus, il offre des options
pour modifier ou supprimer les utilisateurs existants, offrant ainsi un contrôle total sur
la gestion des utilisateurs de l’application.

Figure 4.16 – la liste des utilisateurs

33
4.8 Les Roles

Ces interfaces nous présente la liste des listes des roles ainsi les différents opérations que
l’admin peut faire telles que l’ajout, la modification et les informations necessaire des
roles.
Cette Interface ci-dessous represente la liste des roles ajouter par l’administrateur ou par
l’utilisateur.

Figure 4.17 – Ajouter des roles

Figure 4.18 – la modifications des roles

34
 Figure 4.19 – la liste des roles

Figure 4.20 – les informations sur les roles

4.9 Les Permissions

A partir de cet interfaces les différentes permissions disponibles dans l’application sont
affichées, permettant aux administrateurs de voir rapidement les autorisations accordées
à chaque rôle d’utilisateur.

35
 Figure 4.21 – la liste des permissions

Cette inteface les administrateurs peuvent ajouter de nouvelles permissions en spécifiant

un nom de permission et une brève description, offrant ainsi un moyen simple de person-
naliser les autorisations pour répondre aux besoins spécifiques de l’application.

Figure 4.22 – L’Ajout de permission

36
4.10 Notifications

Dans cette interface des notifications de l’application, les utilisateurs peuvent voir une
liste claire et organisée des différentes notifications qu’ils ont reçues. Chaque notification
peut être accompagnée d’un message informatif ou d’une action à prendre, offrant ainsi
une vue d’ensemble pratique des événements importants ou des mises à jour dans l’ap-
plication.

Figure 4.23 – Notifications de l’application

4.11 Rapport Finnanciere

Dans cette interface les utilisateurs peuvent visualiser un rapport financier détaillé pré-
sentant diverses données telles que les revenus, les dépenses, les bénéfices et d’autres
indicateurs financiers clés, permettant ainsi une analyse approfondie de la santé finan-
cière de l’entreprise.

37
 Figure 4.24 – rapport

Cette interface les utilisateurs ont la possibilité de rechercher des données spécifiques
dans le rapport financier en fonction du type de facture et de la date, offrant ainsi une
fonctionnalité de filtrage précise pour cibler les informations pertinentes.

Figure 4.25 – Chercher appartient du type de facture et la date

Cette interface les utilisateurs peuvent également effectuer une recherche dans le rapport
financier en saisissant simplement le numéro de la facture, ce qui leur permet de trouver
rapidement des informations spécifiques sur une transaction particulière.

38
Figure 4.26 – Chercher appartir du numero de la facture

39
Conclusion Générale

Le projet de gestion des factures offre de nouvelles perspectives pour les entreprises en
termes d’organisation du travail et de qualité de service. Cette étude met en évidence que
la transition vers la gestion électronique des documents, notamment des factures papier,
nécessite des ajustements dans les processus et procédures des entreprises. Il est ainsi pri-
mordial de pouvoir gérer efficacement ces documents pour garantir une nouvelle manière
de travailler et d’atteindre des rendements améliorés.

Les résultats de cette étude sont bénéfiques tant pour les entreprises que pour les pro-
fessionnels des technologies de l’information et de la communication (TIC). Ces derniers
disposent désormais d’un outil pour répondre à l’une de leurs principales préoccupations,
à savoir la question du scan dans un environnement web.

En conclusion, il apparaît que la gestion des scanners reste d’actualité et que plusieurs
solutions ont été proposées pour sa mise en œuvre. Malgré quelques défis rencontrés, le
thème de cette étude offre l’avantage d’apporter aux entreprises une solution de gestion
des documents axée sur la réduction de l’utilisation du papier et capable de s’intégrer
aisément dans des solutions existantes, telles que l’utilisation d’un service web.

40
Webographie

1. Installation et configuration de Tesseract logiciel de reconnaissance de caractère

URL :https://packagist.org/packages/thiagoalessio/tesseracto cr
2. Installation et configuration de composer
URL :https://getcomposer.org/download/
3. Installation et Documentation de laravel :
URL :https://laravel.com/docs/11.x/installation
4. configuration de laravel :
URL :https://laravel.com
5. Installation et utilisation pour construire les diagramme :
URL :https://astah.net/downloads/
6. Instalation et configuration des diagramme :
URL :https://staruml.io/download/
7. Installation et configuration de git
URL :https://git-scm.com/book/en/v2/Getting-Started-Installing-Git
8. Installation et configuration de la base de donnees
URL :https://www.apachefriends.org/fr/index.html
9. installation et configuration par bootstrap
URL :https://getbootstrap.com
10. Installation des icons
URL :https://www.flaticon.com
11. le soutien de le projet
URL :https://chatgpt.com/?temporary-chat=true
12. Installation et configuration de flutter pour application mobile
URL :https://docs.flutter.dev/get-started/install
13. Organisation de le projet
URL :github.com

41