République Tunisienne Cycle de Formation d’Ingénieurs

Ministère de l’Enseignement Supérieur dans la Discipline

et de la Recherche Scientifique Génie informatique et
Mathématiques Appliquées
Université de Sfax
École Nationale d’Ingénieurs de Sfax Projet de Fin d’Etudes
N° d’ordre: 2019 / DIMA-027

MEMOIRE
Présenté à

L’Ecole Nationale d’Ingénieurs de Sfax

(Département de Génie informatique et Mathématiques Appliquées)

En vue de l’obtention

Du Diplôme National d’Ingénieur en Génie informatique

Par

Moufida Salah

Application de gestion de comptabilité

pour un ERP

soutenu le 30/11/2019 , devant la commission d'examen:

Mme. Fatma Ben Said Présidente

Mme. Fadoua Drira Examinatrice
Mme. Sonda Bousnina Encadrante académique

Mme. Boudour Ammar Encadrante académique

M. Mohamed Ben Amor Encadrant industriel
ii
Dédicaces

Je dédie ce travail à tous mes êtres chers :

A mes parents Hsan et Fatma, merci pour votre support tout au long de mon parcours
universitaire et votre confiance infinie. Je vous dédie ce travail en signe d’amour, de
reconnaissance et de gratitude pour le dévouement et les sacrifices dont vous avez
fait toujours preuve à mon égard.

A mes adorables frères Ali, Hafed, Mohamed, Hedi, Lotfi, Habib, Sadek et ma belle-
sœur Halima, merci pour votre encouragement et soutien. En témoignage de l’amour
et de l’affection que je porte pour vous, je vous dédie ce travail en vous souhaitant
un avenir radieux, plein de bonheur.

A mon fiancé Mansour : Aucun mot ne saurait t’exprimer mon profond attachement
pour l’amour et la gentillesse dont tu m’as toujours entouré. J’aimerai bien que tu
trouves dans ce travail l’expression de mes sentiments de reconnaissance les plus
sincères.

À tous les membres de ma famille, qu’ils trouvent ici l’expression de mes sentiments
d’amour et de respect pour leurs encouragements et leur soutien moral. À tous mes
amis qu’ils trouvent ici l’expression de mon amitié la plus sincère.

iii
Remerciement

« Dieu merci de m’avoir donné la force d’accomplir mes études »

C’est avec un grand plaisir que je réserve ces lignes en signe de gratitude et de
reconnaissance à tous ceux qui ont voulu m’encadrer convenablement et nous
assurer les conditions favorables pour réaliser ce travail.

Je tiens tout d’abord à exprimer mes vifs remerciements à Mme.Boudour Ammar,

Mme.Sonda Bousnina, M.Mohamed Ben Amor, M.Ahmed Meftah, M.Khalil Charfi
pour ses efforts, ses motivations, son encouragement incessant, ses conseils précieux
et son suivi continu tout au long de ce stage.

Je tiens à remercier aussi mes enseignants pour votre soutien moral et vos précieux
conseils durant les trois années d’études passées à l’école. Je voudrais notamment
remercier :
Tous les membres de l’équipe de société All Soft Multimedia pour l’ambiance amicale,
l’aide et l’extrême serviabilité qu’ils m’ont fourni.

Tous les membres du jury. Je suis très affecté par l’honneur que vous me faites en
acceptant de juger ce travail.

J’espère que vous trouverez dans ce travail tout le témoignage de ma gratitude et de

mon profond respect.

iv
Table des matières

Introduction générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1 Cadre général du projet 3

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . 3
1.3 Présentation du ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.1 Contexte du projet . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.3 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.4 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.5 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5.1 Méthode Agile . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5.2 Méthodologie choisie : Scrum . . . . . . . . . . . . . . . . . . 9
1.5.2.1 Le product owner . . . . . . . . . . . . . . . . . . . 10
1.5.2.2 L’équipe de développement . . . . . . . . . . . . . . 10
1.5.2.3 Le Scrum Master . . . . . . . . . . . . . . . . . . . . 10
1.5.3 Méthodologie de modélisation . . . . . . . . . . . . . . . . . . 11
1.6 Planification du projet . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 Analyse et spécification des besoins 14

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.1 Les besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . 14
2.2.2 Les besoins non fonctionnels . . . . . . . . . . . . . . . . . . . 15
2.3 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . 16

v
 2.4 Diagrammes de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . 16
2.4.1 Diagramme des cas d’utilisation global . . . . . . . . . . . . . 16
2.4.2 Analyse de quelques cas d’utilisation . . . . . . . . . . . . . . 18
2.4.2.1 Cas d’utilisation «S’authentifier» . . . . . . . . . . . 18
2.4.2.2 Cas d’utilisation «Gérer les journaux» . . . . . . . . . 19
2.4.2.3 Cas d’utilisation «Gérer les plans comptables» . . . . 23
2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3 Conception 27
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2 Architecture logicielle de l’application . . . . . . . . . . . . . . . . . 27
3.3 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4 Diagrammes de séquence . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4.1 Diagramme de séquence«S’authentifier» . . . . . . . . . . . . 30
3.4.2 Diagramme de séquence «Gérer les journaux» . . . . . . . . . 31
3.4.2.1 Diagramme de séquence«Ajouter journal» . . . . . . 31
3.4.2.2 Diagramme de séquence«Modifier journal» . . . . . 32
3.4.2.3 Diagramme de séquence«Supprimer journal» . . . . 33
3.4.2.4 Diagramme de séquence«Afficher journal» . . . . . . 34
3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4 Réalisation 35
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . 35
4.2.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . 35
4.2.2.1 Visual Paradigm for UML . . . . . . . . . . . . . . . 35
4.2.2.2 Visual Studio Code . . . . . . . . . . . . . . . . . . . 36
4.2.2.3 Postman . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3 Technologies et Framework utilisés . . . . . . . . . . . . . . . . . . . 37
4.3.1 Angular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3.2 TypeScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.3 Laravel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.4 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

vi
 4.4 Serveur et base de données . . . . . . . . . . . . . . . . . . . . . . . 42
4.4.1 Le serveur Rest . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.4.2 Base de données :SQLServer . . . . . . . . . . . . . . . . . . . 43
4.5 Les interfaces de l’application . . . . . . . . . . . . . . . . . . . . . . 43
4.5.1 Authentification . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.5.2 Gérer les journaux . . . . . . . . . . . . . . . . . . . . . . . . 44
4.5.2.1 Ajout journal . . . . . . . . . . . . . . . . . . . . . . 45
4.5.2.2 Lister les journaux . . . . . . . . . . . . . . . . . . . 46
4.5.2.3 Suppression journal . . . . . . . . . . . . . . . . . . 48
4.5.2.4 Modification journal . . . . . . . . . . . . . . . . . . 49
4.5.3 Gérer les écritures . . . . . . . . . . . . . . . . . . . . . . . . 50
4.5.3.1 Ajout d’écriture . . . . . . . . . . . . . . . . . . . . . 50
4.5.3.2 Afficher les écritures . . . . . . . . . . . . . . . . . . 51
4.5.3.3 Modification d’écriture . . . . . . . . . . . . . . . . . 51
4.5.3.4 Suppression d’écriture . . . . . . . . . . . . . . . . . 52
4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Conclusion générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Netographie 55

vii
Table des figures

1.1 Logo ASM [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Composants d’ERP [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Logo Kiwili [3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Logo Momenteo [4] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 Compta Clementine [5] . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.6 Le processus du Scrum [7] . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.7 Logo UML [9] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.8 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . 17

3.1 Architecture logicielle de notre application web . . . . . . . . . . . . . 27

3.2 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3 Diagramme de séquence «S’authentifier» . . . . . . . . . . . . . . . . . 30
3.4 Diagramme de séquence «Ajouter un journal» . . . . . . . . . . . . . . 31
3.5 Diagramme de séquence «Modifier un journal» . . . . . . . . . . . . . 32
3.6 Diagramme de séquence «Suppression de journal» . . . . . . . . . . . 33
3.7 Diagramme de séquence «Lister les journaux» . . . . . . . . . . . . . . 34

4.1 Logo Visual Paradigm For UML [11] . . . . . . . . . . . . . . . . . . . . 35

4.2 Logo Visual Studio Code [12] . . . . . . . . . . . . . . . . . . . . . . . 36
4.3 Logo Postman [13] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4 Logo Angular7 [15] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.5 Logo TypeScript [17] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.6 Evolution de l’intérêt entre Laravel et Codeigniter [18] . . . . . . . . . 40
4.7 Logo Laravel [19] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.8 Logo PHP [20] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.9 Architecture de web service Restful [21] . . . . . . . . . . . . . . . . . 43

viii
4.10 Logo de Microsoft SQL Server [22] . . . . . . . . . . . . . . . . . . . . 43
4.11 Interface d’authentification . . . . . . . . . . . . . . . . . . . . . . . . 44
4.12 Contrôle de saisie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.13 Interface d’ajout journal . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.14 Interface des journaux . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.15 Suppression d’un journal . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.16 Confirmation de modification de journal . . . . . . . . . . . . . . . . . 49
4.17 Interface d’ajout écriture . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.18 Interface des écritures . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.19 Interface de modification écriture . . . . . . . . . . . . . . . . . . . . . 52
4.20 Interface de suppression d’écriture . . . . . . . . . . . . . . . . . . . . 53

ix
Liste des tableaux

1.1 Avantages et inconvénients des applications existantes . . . . . . . . . 7

1.2 Description des méthodologies . . . . . . . . . . . . . . . . . . . . . . 9
1.3 Arrangement des fonctions . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4 Les tâches du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1 Description du cas d’utilisation « S’authentifier » . . . . . . . . . . . . 18

2.3 Description du cas d’utilisation « Consultation des journaux » . . . . . 19
2.5 Description du cas d'utilisation « Ajouter un journal » . . . . . . . . . . 20
2.7 Description du cas d'utilisation « Modifier un journal » . . . . . . . . . 21
2.9 Description du cas d'utilisation « Supprimer un journal» . . . . . . . . . 22
2.11 Description du cas d’utilisation « Consultation des plans » . . . . . . . 23
2.13 Description du cas d'utilisation « Ajouter un plan » . . . . . . . . . . . 24
2.15 Description du cas d'utilisation « Modifier un plan » . . . . . . . . . . . 25
2.17 Description du cas d'utilisation « Supprimer un plan» . . . . . . . . . . 26

4.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.2 Comparaison entre Angular et React . . . . . . . . . . . . . . . . . . . 37
4.3 Les points forts et faibles d’Angular . . . . . . . . . . . . . . . . . . . . 38
4.4 Comparaison entre Laravel et CodeIgniter . . . . . . . . . . . . . . . . 40
4.5 Comparaison entre REST et SOAP . . . . . . . . . . . . . . . . . . . . 42

x
Liste des acronymes

ASM : All Soft Multimédia

ERP : Enterprise Ressource Planning
DUX : Leader (en latin)
XP : Extreme Programming
DSDM : Dynamic System Development Method
CU : Cas d’Utilisation
HTTP : HyperText Transfer Protocol
CLI : Command Line Interface
JS : JavaScript
PHP : Hypertext Preprocessor
MVC : Model-View-Controller
ORM : Mapping Object Relationnel
SQL : Structured Query Language
SGBDR : Système de gestion de base de données relationnels
DOM : Document Object Model
REST : Representational State Transfer
SOAP : Simple Object Access Protocol
API : Application Programming Interface
UML : Unified Modeling Language
SSL : Secure Sockets Layer

xi
Introduction générale

De nos jours, nous vivions dans un monde numérique où l’information digitale a

sa valeur et son influence par tout. C’est le résultat de plusieurs années de collecte
de données par différents systèmes qui les traitent et les stockent pour obtenir les
résultats attendues.
Avec la mondialisation technologique et le besoin croissant des sociétés en matière
d’information, ce soutien a évolué grâce à l’amélioration des systèmes et matériels
informatiques.
Pour cela chaque entreprise ne peut pas rester loin de ce domaine à cause de ses
bénéfiques qui permettent de faciliter beaucoup des services dans la société lui même
ou bien avec ses clients et fournisseurs.
En effet, les entreprises ont pris conscience que les clients devenaient de plus en plus
exigeants : désormais un client insatisfait devient infidèle à une marque. La qualité a
dès lors été jugée comme un levier de développement.
Donc quelques soient les secteurs du la société : achat, vente, relation clients ou
comptabilité, ils ont leurs applications informatisées pour gérer et simplifier les
tâches. Tout ça pour augmenter sa chance d’être toujours la plus performante à ses
clients.
Et puisque la satisfaction et la fidélisation des clients représentent un majeur enjeu
pour toute entreprise, cette dernière va maintenir et améliorer sa compétitivité.
L’amélioration des services joue un rôle très important pour chaque société parce
qu’elle cherche toujours à devenir à la première place dans son domaine par rapport
aux autres entreprises. D’où elle est obligée d’être à jour grâce à l’amélioration et
l’évolution de son service informatique.
Dans ce contexte, notre organisme d’accueil cherche à rendre meilleur la qualité de
ses services et à plus satisfaire ses clients. Alors pour notre projet qui est un sprint
parmi les autres sprints des processus de l’ERP, nous sommes intéressés au domaine

1
de comptabilité de la société. Le travail effectué est présenté à travers les quatre
chapitres du présent rapport qui sont organisés comme suit :
Le premier chapitre est consacré à la présentation de l’organisme d’accueil, mise
en contexte du projet et l’analyse de l’existant et de la solution proposée. C’est
également à ce niveau que nous présentons la méthodologie de travail pour ce
projet.
Dans le deuxième chapitre, nous faisons l’étude des besoins fonctionnels et non
fonctionnels ainsi que la modélisation des ces besoins par les recours aux diagrammes
de cas d’utilisation.
Le troisième chapitre détaille l’architecture logicielle de notre application. Aussi,
dans ce chapitre nous faisons la conception détaillée grâce à le diagramme de classes
et quelques diagrammes de séquences.
Enfin dans le dernier chapitre, nous étalerons la phase de réalisation de l’application,
en détaillant l’environnement matériel et logiciel mis en place pour l’implémentation
de notre projet. En second lieu, nous exposerons les technologies utilisées. Par la
suite, nous finissons par présenter certaines interfaces graphiques développées tout
en définissant leurs fonctionnalités. Finalement, nous clôturons ce rapport par une
conclusion générale et quelques perspectives de notre travail.

2
Cadre général du projet
1
1.1 Introduction
La constitution d’une idée à propos du projet, l’organisme et les choix méthodolo-
gique vise à clarifier les phases postérieures. Une étude complète de chaque partie est
considérée la première étape à établir. D’où le premier chapitre sera pour présenter
l’organisme d’accueil, identifier le projet et la méthodologie adoptée.

1.2 Présentation de l’organisme d’accueil

L’organisme "All Soft Multimédia" est une société informatique créée en 2007. Elle est
spécialisée dans l’ingénierie logicielle, la création des sites web et le développement
des applications mobile et les systèmes de vente. Elle est présentée en Tunisie, Algérie
et au Sénégal.
Son but depuis sa création conçoit à réaliser et maintenir des services informatiques
sur mesure. C’est pourquoi, elle assure que son travail soit effectué par une ressource
humaine certifiée en ingénierie informatique. Son travail est basé sur un ensemble
des services tels que :

— Développement Web

— Développement Intranet et applications

— Plateformes mobiles

En effet, ASM analyse et spécifie les besoins et les exigences de ses clients. Par
ailleurs, elle cherche toujours à les accompagner dans la création et l’exploitation de
nouveaux services tel que le nouveau module ERP.

Fig. 1.1: Logo ASM [1]

3
1.3 Présentation du ERP
L’ERP (Enterprise Ressource Planning) est un progiciel qui gère un ensemble des
processus opérationnels d’une entreprise en intégrant plusieurs fonctions de gestion
tel que la comptabilité, les ressources humaines, la distribution, l’achat et vente,
etc.

Fig. 1.2: Composants d’ERP [2]

Pour être qualifiée de « Progiciel de Gestion Intégré », une solution logicielle ERP
doit couvrir au moins deux principes fondamentaux :

— La construction des applications informatiques sous forme de modules in-

dépendants mais elles sont compatibles sur une base de données unique et
commune.

— L’usage d’un moteur de Workflow permet de définir l’ensemble des tâches d’un
processus et de gérer leur réalisation dans tous les modules du système qui ont
besoin.

En effet, notre organisme d’accueil a une application desktop d’ERP qui gère les
services suivants : achat, vente, gestion de stock, comptabilité, relation avec les
clients. Notre projet se focalise sur un module de l’ERP qui est la comptabilité.
Comme un ERP est modulaire dans le sens où il est possible de n’avoir qu’une ou
plusieurs applications en même temps qui fonctionnent entre elles. De même dans
notre cas, l’application de comptabilité doit fonctionner avec les autres services et
partageant la même base de données.

4
1.4 Présentation du projet

1.4.1 Contexte du projet

Le présent projet intitulé « Application de gestion de comptabilité pour un ERP » est
réalisé dans le cadre de la préparation du projet de fin d’études en vue de l’obtention
du « Diplôme National d’Ingénieur en Génie Informatique » à l’ « École Nationale
d’Ingénieurs de Sfax » pour l’année universitaire 2018/2019.

1.4.2 Problématique
Actuellement la gestion de comptabilité à la société ASM se fait à l’aide d’une
application desktop. Le but de ce projet est de migrer vers une application web
pour assurer cette gestion. En fait, le comptable passe beaucoup de temps pour
configurer l’application desktop avec la base de données. Certains moments, cette
application ne fonctionne pas à cause de quelques caractéristiques de la machine.
Afin de remédier les différents problèmes cités, la société ASM a besoin de migrer
vers une application web pour surmonter le défi et améliore son service.

1.4.3 Étude de l’existant

De nos jours, chaque secteur de comptabilité de n’importe quelle société dans le
monde utilise une application desktop pour sa gestion.
Dans ce contexte, nous pouvons citer les applications web suivantes "Kiwili", "Mo-
menteo" et "Compta Clementine".
Kiwili est destiné à l’ensemble des petites entreprises et freelancers qui évoluent au
quotidien.

Fig. 1.3: Logo Kiwili [3]

5
Momenteo est un moyen simple pour créer et envoyer des factures. Il gère les diffé-
rentes tâches de comptable nécessaires.

Fig. 1.4: Logo Momenteo [4]

Compta Clementine vous permet de consulter votre comptabilité à chaque instant.

Aussi, il garantit une meilleure prestation.

Fig. 1.5: Compta Clementine [5]

1.4.4 Critique de l’existant

L’amélioration de la performance est l’un des défis actuels majeurs pour les
entreprises. Pour cela toujours nous cherchons l’application la plus adéquate.
Cela nous mène à comparer les applications web existantes pour développer une
application web efficace et qui évite les problèmes que l’ont vu avec les autres
applications web.

6
 Tab. 1.1: Avantages et inconvénients des
applications existantes

Applications Avantages Inconvénients

Kiwili - Permet d’améliorer l’efficacité de la -Pas de gestion des commandes et
gestion des finances, des dépenses, factures fournisseurs.
du budget ou encore des déclara- -Pas de plan, journal comptable.
tions de votre société ou de votre
association.
- Obtiendrez à temps réel les données
comptables.

Momenteo - Permet de créer, personnaliser et - Pas de paiement en ligne.

de suivre une facture, de l’envoi jus-
qu’au paiement
- Créez, personnalisez et suivez les
devis.
Compta Cle- - Permet de gérer la comptabilité de - Pas de grand livre, journaux comp-
mentine base édition des factures et des devis, tables.
gestion des articles, des clients et des
documents.
- Un tableau de bord en ligne, pour
suivre en temps réel, à tout moment,
l’état de comptabilité.

Après avoir présenté les différentes applications de comptabilité web existantes, nous
visons améliorer notre application desktop ERP par la migration vers une application
web ayant le même principe que ces applications de gestion de comptabilité.

1.4.5 Solution proposée

Dans le présent projet, nous proposons de développer une application web qui
permet de gérer les tâches nécessaires pour un comptable. Notre mission consiste
à assurer la gestion des modules de comptabilité suivants : les écritures, les plans

7
comptables et les journaux. Notre objectif est de garantir l’efficacité des services et
donc gagner la satisfaction et la fidélité de client.

1.5 Méthodologie de travail

Pour effectuer notre projet dans le bon état, nous sommes intéressés à étudier
les méthodes les plus populaires, pour choisir la plus adéquate entre elles. Toute
démarche de développement nécessite un modèle de développement d’une méthode
qui doit fournir les résultats attendus et dans les bons délais. En effet, le choix d’une
méthode pour la démarche du projet est une décision assez importante. Donc nous
allons présenter dans ce qui suit une étude sur laquelle nous choisissions notre
méthodologie du travail.

1.5.1 Méthode Agile

Les méthodes agiles sont des méthodologies essentiellement dédiées à la gestion des
projets informatiques. Elles reposent sur des cycles de développement itératifs et
adaptatifs en fonction des besoins évolutifs du client. Elles permettent notamment
d’impliquer l’ensemble des collaborateurs ainsi que le client dans le développement
du projet. Ces méthodes permettent généralement de mieux répondre aux
attentes du client en un temps limité tout en faisant monter les collaborateurs en
compétences. Ces méthodes constituent donc un gain en productivité ainsi qu’un
avantage compétitif tant du côté client que du côté fournisseur [6].
Les méthodes agiles se reconnaissent toutes dans les valeurs suivantes :
• Équipe et communication avant outils et processus.
• L’application avant la documentation.
• La collaboration avant la négociation.
• L’acceptation du changement et la flexibilité avant la planification.
Dans le tableau ci-dessous, nous présentons les différentes méthodes pour mieux les
comprendre.

8
 Tab. 1.2: Description des méthodologies

Methodes Description Avantages Inconvénients

XP(Extreme -Ensemble des bonnes -Développement piloté. -Maintenance
Program- pratiques de développe- -Programmation en bi- -Absence de phase d’ana-
ming) ment nôme. lyse.
-Cible des projets de
moins de dix personnes.
Scrum Pratiques de manage- -Gestion de temps. - Ges- Aucune pratique de dé-
ment et d’organisation tion de l’équipe. - Parta- veloppement.
du travail ger le projet suivant des
sprints
DSDM( Il donne la direction du -Exigence approche prio- Ne peut pas être la so-
dynamic projet à travers les objec- ritaire. -Gestion efficace lution à tous les types
system tifs métiers. de projet de projets. - Communi-
developme cation de l’équipe basée
nt method) sur la documentation.

1.5.2 Méthodologie choisie : Scrum

Après cette étude des modèles de développement des méthodes agiles nous choisis-
sions le modèle Scrum pour suivre les démarches de notre projet parce qu’il est le
plus adéquat à notre travail.
C’est un cadre de travail dans lequel les personnes peuvent aborder des problèmes
complexes et adaptatifs tout en livrant de manière efficace et créative des produits
de la plus grande valeur possible [6].
Notre choix de Scrum comme une méthodologie pour notre projet est basé sur les
bénéfiques de ce dernier qui sont :
• Plus de souplesse et de réactivité.
• La grande capacité d’adaptation au changement grâce à des itérations courtes.
• Simple à comprendre.
• Léger.
La figure suivante illustre le processus du Scrum :

9
 Fig. 1.6: Le processus du Scrum [7]

Comme c’est déjà montré dans la figure 1.6 Scrum a trois équipes importantes qui
sont :

1.5.2.1 Le product owner

Le Product Owner est responsable de maximiser la valeur du produit résultant
du travail de l’équipe de développement. La façon de jouer ce rôle peut varier
grandement selon les organisations, les équipes Scrum et les individus [8].
1.5.2.2 L’équipe de développement
L’équipe de développement se compose de professionnels qui fournissent un incré-
ment « Fini » potentiellement publiable à la fin de chaque Sprint. Un incrément « Fini
» est requis à la revue de sprint. Seuls les membres de l’équipe de développement
créent l’incrément [8].
1.5.2.3 Le Scrum Master
C’est la personne qui doit assurer le bon déroulement des différents sprints du
release, et qui doit impérativement maitriser Scrum [8].
La méthodologie "Scrum" est utilisée pour notre projet ERP qui englobe les
différentes gestions d’ERP suivantes :
- Gestion d’achat et vente.
- Gestion de comptabilité.
- Gestion des relations avec les clients.
- Gestion de production.

10
Par conséquent, notre projet de fin d’études qui est un module du projet ERP
obit aussi à cette méthodologie. Pour ce module, notre méthodologie "Scrum" est
rythmée par des itérations de quelques semaines "sprints". Notre sprint englobe les
activités d’analyse et conception, de développement et de test. Chaque partie de ces
dernières va une durée de vie bien déterminée et celle-ci va être expliquer dans la
partie planification du projet.
Dans ce que suit, nous allons présenter l’arrangement des fonctionnalités qui nous
allons réaliser tout au long de ce projet.

Tab. 1.3: Arrangement des fonctions

1.5.3 Méthodologie de modélisation

Pour concevoir l’application, UML a été choisi pour plusieurs raisons. Parmi ces
raisons, nous pouvons citer le fait que c’est un langage qui rend possible de visualiser,
spécifier, construire et documenter les objets fabriqués de notre projet dans une

11
façon standard. Il permet aussi d’obtenir un dessin qui est indépendant des langues
et des environnements. En plus, UML est un pont qui raccorde l’architecte et le client.
Grâce à cela, l’architecte a une vision claire de que le produit devrait fournir. En
même temps, le client peut exprimer qu’il pense sans devoir savoir toutes les notions
rattachées à cette langue [9].

Fig. 1.7: Logo UML [9]

1.6 Planification du projet

Le diagramme de Gantt est un outil de planification des tâches nécessaires pour
la réalisation d’un projet quel que soit le secteur d’activité. Il permet de visualiser
l’avancement des tâches d’un projet de manière simple et concise, de planifier et
suivre les besoins en ressources humaines et matérielles et donc de pouvoir suivre
l’avancement du projet [10].
Le tableau ci-dessous détaille les tâches à réaliser dans notre projet :

Tab. 1.4: Les tâches du projet

Alors que la figure suivante présente le diagramme de gantt qui modélise la

12
planification de notre projet.

Fig. 1.8: Diagramme de Gantt

1.7 Conclusion
Dans ce chapitre introductif, nous avons présenté l’organisme d’accueil ainsi que
notre projet et sa méthodologie de travail. Cette étude nous permet de présenter
notre concept de base et nous aide à être sur le bon chemin dans les autres chapitres
d’analyse et conception.

13
Analyse et spécification des 2
besoins

2.1 Introduction
Dans ce chapitre nous allons détailler une analyse des besoins fonctionnels et non
fonctionnels avant le démarrage du développement. Puis nous allons définir les
acteurs de notre application et le diagramme général de cas d’utilisation.

2.2 Spécification des besoins

2.2.1 Les besoins fonctionnels
Les besoins fonctionnels expriment une action qui doit effectuer le système pour
répondre à une demande de l’utilisateur. Ces besoins doivent être qualifié afin qu’il
n’y ait pas d’ambiguïté. Les fonctions sont transformées à des services offerts au client-
utilisateur. En effet, quand l’analyse du besoin est bien réalisée en conséquent elle
laisse un grand champ de possibles pour couvrir le besoin. Et pour notre application,
il y a trois besoins fonctionnels principaux qui sont :
Gérer les plans comptables :

• Ajout d’un nouveau plan

• Modification de données relatives à un plan

• Suppression d’un plan

• Consultation des plans

Gérer les écritures comptables :

• Créer des modèles d’écritures comptables (écriture d’achat de marchandises,

écriture de loyer immobilier, écriture d’abonnement téléphonique etc.)

• Éditer de données relatives à une écriture

• Suppression d’un modèle d’écriture

• Consultation des écritures

14
 Gérer les journaux :

• Créer un nouveau journal (journal des achats, journal des ventes, journal de
banque etc.)

• Mettre à jour les journaux

• Suppression d’un journal

• Consultation des journaux

2.2.2 Les besoins non fonctionnels

Les besoins non fonctionnels sont des exigences qui ne spécifient pas le comporte-
ment du système mais ils identifient les contraintes internes et externes du celui-ci. Il
s’agit d’une définition des critères techniques imposées à l’application. Les principaux
besoins non fonctionnels de notre application ces sont les points suivants :
c Fiabilité :
Notre code doit être clair pour permettre des futures évolutions ou améliorations.
c L'ergonomie :
l’application offre une interface conviviale et facile à utiliser.
c La sécurité :
l’application doit respecter la confidentialité des données.
c L'intégrité :
Garantir l’intégrité et la cohérence des données à chaque mise à jour et à chaque
insertion.
c L'autonomie :
le système s’exécute entièrement sans avoir recours à d’autres application.
c Navigabilité :
L’application doit être navigable en donnant la possibilité à l’utilisateur l’accès aux
différentes rubriques à partir n’importe quelque page grâce à la barre du menu.
c Gestion des erreurs :
Il faut que les erreurs doivent être signalées par des messages explicites.
c Compatibilité :
Il est nécessaire d’assurer le bon fonctionnement de cette application web sur
différentes versions de navigateurs.

15
2.3 Identification des acteurs
Dans cette partie, nous allons présenter les acteurs du système. Ces derniers sont les
responsables des tâches à réaliser par notre application. En effet, notre application a
deux acteurs qui sont :

L’administrateur : L’administrateur du système est accessible par un login et un mot

de passe enregistré dans une base de données. L’administrateur est le gestionnaire
du système qui va contrôler les fiches remplis par le comptable et les confirmer.

Le comptable : C’est l’acteur qui va gérer les écritures, les journaux et les plans
comptables.

2.4 Diagrammes de cas d’utilisation

Le diagramme de cas d’utilisation est utilisé pour montrer les interactions fonction-
nelles entre les acteurs et le système. Les diagrammes de cas d’utilisation décrivent
ce qu’un système fait du point de vue d’un observateur externe.

2.4.1 Diagramme des cas d’utilisation global

Nous présentons dans la figure suivante le diagramme de cas d’utilisation global de
notre application. Il définit une vue générale des fonctionnalités du système et les
relations entre eux.

16
Fig. 2.1: Diagramme de cas d’utilisation global

17
2.4.2 Analyse de quelques cas d’utilisation
2.4.2.1 Cas d’utilisation «S’authentifier»
La description des scénarios du cas d’utilisation "S’authentifier" est décrite par le
tableau suivant :

Tab. 2.1: Description du cas d’utilisation « S’authentifier »

Titre : S’authentifier
Acteur : Comptable
Sommaire
Résumé : L’utilisateur saisit ses identifiants afin que le
d’identification
système vérifie son identité et lui autorise l’accès.
Préconditions : L’utilisateur est déjà créé.
Description des
Postconditions : L’utilisateur est connecté.
scénarios
1. Le système affiche le formulaire d’authentification.
2. L’utilisateur saisit ses identifiants et demande l’accès au
Scénario système.
nominal 3. Le système vérifie les identifiants et autorise l’accès de
l’utilisateur.
1) Identifiant(s) non saisi(s).
L’enchaînement « 1 » démarre au point « 3 » du scénario
nominal.
3. Le système indique à l’utilisateur qu’il doit saisir ses deux
identifiants.
Le scénario nominal reprend au point « 2 ».
Scénario alterna-
2) Utilisateur inconnu.
tif :
L’enchaînement « 2 » démarre au point « 3 » du scénario
nominal.
3. Le système indique à l’utilisateur qu’il doit vérifier ses
identifiants.
Le scénario nominal reprend au point « 2 ».

18
2.4.2.2 Cas d’utilisation «Gérer les journaux»
Le cas d’utilisation gérer les journaux englobe quatre cas d’utilisation tel que l’ajout,
la modification, la suppression et la consultation.
Le tableau suivant va détailler le cas de «consultation les journaux».
Description du cas d'utilisation « consulter les journaux »

Tab. 2.3: Description du cas d’utilisation « Consultation des

journaux »

Titre : consulter ses journaux

Acteur : Comptable
Sommaire
Résumé : Le comptable pourra consulter tous les journaux
d'identification
enregistrés dans la base de données.
Préconditions : L'utilisateur est authentifié.
Description des
Postconditions : L'utilisateur consulte ses journaux.
scénarios
1. Le système montre une interface qui contient un tableau
Scénario nomi- des journaux.
nal 2. Le client consulte ses journaux .

Scénario alterna- Si l’authentification est invalide alors la page de login est affichée.
tif :

19
Description du cas d'utilisation « Ajouter un journal »

Tab. 2.5: Description du cas d'utilisation « Ajouter un journal »

Titre : Ajouter un journal

Acteur : Comptable
Sommaire
Résumé : Le comptable va ajouter un nouveau
d'identification
journal avec ses détails selon ses besoins.
Préconditions : L'administrateur est authentifié.
Description des
Postconditions : Nouveau journal ajouté
scénarios
Ce C.U débute quand le comptable demande de créer
un journal.
1. Le système affiche l'interface de l'ajout d'un journal.
2. Le comptable remplit ces champs et clique sur le
Scénario bouton ajouter.
nominal 3. Le système vérifie les champs.
4. Le système sauvegarde les informations dans la base
de données.
5. le système affiche un message de confirmation.
1) Données manquantes.
L'enchaînement « 1 » démarre au point « 3 » du scénario
nominal.
Scénario alterna-
1. Un message d'erreur s'affiche : Veuillez saisir toutes les
tif :
données.
le scénario nominal reprend au point 2.

20
Description du cas d'utilisation « Modifier un journal »

Tab. 2.7: Description du cas d'utilisation « Modifier un journal »

Titre : Modifier un journal

Acteur : Comptable
Sommaire
Résumé : Le comptable va modifier un journal
d'identification
selon son besoin.
Préconditions : L'comptable est authentifié.
Description des
Postconditions : journal modifié .
scénarios
1. Le système affiche la liste des
journaux.
2. Le comptable choisit un journal à modifier parmi
la liste.
3. Une fois le journal est sélectionné, le comptable
clique sur le bouton modifier.
Scénario
4. Toutes les données du journal s'affichent sur une
nominal
autre interface.
5. Le comptable modifie le journal et valide.
6. Le système vérifie la validité des champs.
7. L'opération est considérée terminée lorsque le système
affiche un message de confirmation.
1) Données manquantes.
L'enchaînement « 2 » démarre au point « 6 » du scénario
nominal.
Scénario alterna-
1. Un message d'erreur s'affiche : Veuillez saisir toutes les
tif :
données.
Le scénario nominal reprend au point 4.

21
Description du cas d'utilisation « Supprimer un journal »

Tab. 2.9: Description du cas d'utilisation « Supprimer un journal»

Titre : Supprimer un journal

Sommaire Acteur : Comptable
d'identification Résumé : Le comptable va supprimer un joural.
Préconditions : L'administrateur est authentifié.
Description des
Postconditions : L'Journal considéré est supprimé.
scénarios
1. Le système affiche la liste des journaux.
2. Le comptable choisit un journal à supprimer
parmi la liste des journaux et clique sur le bouton
supprimer.
Scénario
3. Le système affiche un message pour valider la
nominal
suppression.
4. Le comptable valide la suppression.
5. Le système affiche un message de validation de suppression.
1. Si l’authentification est invalide, l’utilisateur est redirigé
vers la page de login
Scénario alterna-
2.Si le journal a supprimé est vide un message d’erreur est
tif :
apparue et l’enchainement démarre au point 2.

22
2.4.2.3 Cas d’utilisation «Gérer les plans comptables»
De même dans ce cas d’utilisation on va ajouter, modifier, supprimer ou bien
consulter les plans.
Le tableau suivant va détailler le cas de «consultation des plans».
Description du cas d'utilisation « consulter les plans »

Tab. 2.11: Description du cas d’utilisation « Consultation des

plans »

Titre : consulter les plans

Sommaire Acteur : Comptable
d'identification Résumé : Le comptable pourra consulter tous les plans.
Préconditions : L'utilisateur est authentifié.
Description des
Postconditions : 'Plans consultés.
scénarios
1. Le système montre une interface qui contient un tableau
Scénario nomi- des plans.
nal 2. Le client consulte ses plans avec ses informations.
Scénario alterna- Si l’authentification est invalide alors la page de login est affichée.
tif :

23
Description du cas d'utilisation « Ajouter un plan »

Tab. 2.13: Description du cas d'utilisation « Ajouter un plan »

Titre : Ajouter un plan

Acteur : Comptable
Sommaire
Résumé : Le comptable va ajouter un nouveau
d'identification
plan avec ses champs nécessaires.
Préconditions : L'administrateur est authentifié.
Description des
Postconditions : Nouveau plan ajouté
scénarios
Ce C.U débute quand le comptable demande de créer
un plan.
1. Le système affiche l'interface de l'ajout d'un plan.
2. Le comptable remplit ces champs et clique sur le
Scénario bouton ajouter.
nominal 3. Le système vérifie les champs.
4. Le système sauvegarde les informations dans la base
de données.
5. le système affiche un message de confirmation.
1) Données manquantes.
L'enchaînement « 1 » démarre au point « 3 » du scénario
nominal.
Scénario alterna-
1. Un message d'erreur s'affiche : Veuillez saisir toutes les
tif :
données.
le scénario nominal reprend au point 2.

24
Description du cas d'utilisation « Modifier un plan »

Tab. 2.15: Description du cas d'utilisation « Modifier un plan »

Titre : Modifier un plan

Acteur : Comptable
Sommaire
Résumé : Le comptable va modifier un plan
d'identification
selon le nécessaire.
Préconditions : Plan non modifié
Description des
Postconditions : Plan modifié .
scénarios
1. Le système affiche la liste des
plans.
2. Le comptable choisit un plan à modifier parmi
la liste.
3. Une fois le plan est sélectionné, le comptable
clique sur le bouton modifier.
Scénario
4. Toutes les données du journal s'affichent sur une
nominal
autre interface.
5. Le comptable modifie le plan et valide.
6. Le système vérifie la validité des champs.
7. L'opération est considérée terminée lorsque le système
affiche un message de succès.
1) Données manquantes.
L'enchaînement « 2 » démarre au point « 6 » du scénario
nominal.
Scénario alterna-
1. Un message d'erreur s'affiche : Veuillez saisir toutes les
tif :
données.
Le scénario nominal reprend au point 4.

25
Description du cas d'utilisation « Supprimer un plan »

Tab. 2.17: Description du cas d'utilisation « Supprimer un plan»

Titre : Supprimer un plan

Sommaire Acteur : Comptable
d'identification Résumé : Le comptable veut supprimer un plan.
Pré-conditions : Le plan existe.
Description des
Post-conditions : Plan supprimé
scénarios
1. Le système affiche la liste des plans.
2. Le comptable choisit un plan a supprimer
parmi la liste et clique sur le bouton
supprimer.
Scénario
3. Le système affiche un message pour valider la
nominal
suppression.
4. Le comptable valide la suppression.
5. Le système affiche un message de validation de suppression.
1. Si l’authentification est invalide, l’utilisateur est redirigé
vers la page de login
Scénario alterna-
2.Si le plan a supprimé est vide un message d’erreur est
tif :
apparue et l’enchainement démarre au point 2.

2.5 Conclusion
Dans ce chapitre, nous avons présenté les besoins fonctionnels et non fonctionnels
de notre système, les acteurs ainsi que le C.U global et la description de quelques
cas d’utilisation. Alors que dans le chapitre suivant nous passerons à la conception
pour élaborer le diagramme de classe et les diagrammes des séquences.

26
Conception 3
3.1 Introduction
Après avoir détaillé l’analyse et la spécification des besoins de notre application,
dans ce chapitre nous avons amené à la partie conception du projet. Pour cela, nous
allons présenter dans un premier lieu l’architecture de notre application. Par la suite,
nous détaillerons la conception de notre projet en spécifiant le diagramme de classe
et les diagrammes de séquences.

3.2 Architecture logicielle de l’application

La définition de l’architecture de l’application consiste une étape importante dans le
processus de conception. La figure suivante illustre l’architecture logicielle de notre
projet. L’architecture est composée de deux système :
à Système Backend : constitué d’une application basée sur la framework Laravel
liée à une base de données SQL server.
à Système Frontend : constitué d’une application basée sur la Framework
AngularJS.
Les deux systèmes sont liés entre eux à partir des services web Rest.

Fig. 3.1: Architecture logicielle de notre application web

27
3.3 Diagramme de classes
Nous avons présenté dans le chapitre précédent l’interaction entre l’utilisateur et le
système à travers le diagramme de cas d’utilisation, nous présenterons dans ce qui
suit la structure de l’application à travers le diagramme de classe. Ce dernier est une
collection d’élément de modélisation statique(classes) qui montre la structure d’un
modèle. Un diagramme de classe est le point central dans un développement orienté
objet.

28
Fig. 3.2: Diagramme de classe

29
3.4 Diagrammes de séquence
Le diagramme de séquence décrit l’aspect dynamique du système. Il modélise les
interactions entre les objets ou entre l’utilisateur et l’objet, en mettant l’accent sur la
chronologie des messages échangés. Dans ce qui suit, nous allons dresser quelques
diagrammes des séquences.

3.4.1 Diagramme de séquence«S’authentifier»

C’est le premier scénario qui se déroule lors du déclenchement de l’application. Selon
la figure ci-dessous, l’utilisateur est invité à saisir ses paramètres de connexion. Le
système vérifie la disponibilité du login et du mot de passe pour donner ensuite
accès aux fonctionnalités de l’application.

Fig. 3.3: Diagramme de séquence «S’authentifier»

30
3.4.2 Diagramme de séquence «Gérer les journaux»
Le cas d’utilisation gérer les journaux se décompose en quatre cas d’utilisation
’ajouter’, ’afficher’, ’supprimer’ et ’modifier’. Nous présentons toutes les étapes et les
séquences nécessaires pour ces cas d’utilisation.
3.4.2.1 Diagramme de séquence«Ajouter journal»

Fig. 3.4: Diagramme de séquence «Ajouter un journal»

31
3.4.2.2 Diagramme de séquence«Modifier journal»

Fig. 3.5: Diagramme de séquence «Modifier un journal»

32
3.4.2.3 Diagramme de séquence«Supprimer journal»

Fig. 3.6: Diagramme de séquence «Suppression de journal»

33
3.4.2.4 Diagramme de séquence«Afficher journal»

Fig. 3.7: Diagramme de séquence «Lister les journaux»

3.5 Conclusion
Dans ce chapitre nous avons détaillé les différentes vues conceptuelles de notre
application à réaliser à travers les modèles UML nécessaires. Cette conception est
essentielle pour la phase de réalisation qui constitue l’objet du chapitre suivant.

34
Réalisation 4
4.1 Introduction
Dans ce chapitre, nous allons présenter l’environnement de travail (logiciel et maté-
riel), les technologies utilisées et quelques interfaces de notre application.

4.2 Environnement de travail

4.2.1 Environnement matériel
Afin de réaliser notre travail dans le bon conditionnement, nous avons choisis un
environnement compatible à cette mission. Dans ce qui suit un tableau qui présente
les caractéristiques de notre machine.

Tab. 4.1: Environnement matériel

Marque HP
Processeur Intel core™i7-2620M CPU @2.70GHZ
Mémoire vive 8 GO
Système d’exploitation Windows 10 x64
Disque Dur 500 Go

4.2.2 Environnement logiciel

4.2.2.1 Visual Paradigm for UML
C’est un outil de modélisation UML. Il permet de dessiner tous les types de dia-
grammes UML. Aussi il offre des fonctionnalités de génération des rapports, y
compris la génération de code. Visual Paradigum peut inverser l’ingénierie des
schémas à partir du code et fournir une ingénierie aller-retour pour des différents
langages de programmation [11].

Fig. 4.1: Logo Visual Paradigm For UML [11]

35
4.2.2.2 Visual Studio Code
Visual Studio Code est un éditeur de code source léger mais puissant qui s’exécute
sur bureau et qui est disponible pour Windows, macOS et Linux. Il comprend un
support intégré pour :
ä JavaScript
ä TypeScript
ä Node.js
Il possède un riche écosystème d’extensions pour d’autres langages tels que C++,
Java, Python et des environnements d’exécution tels que .NET et Unity [12].

Fig. 4.2: Logo Visual Studio Code [12]

4.2.2.3 Postman
Une application moderne est construite sur des APIs. C’est sur cette phrase d’accroche
que nous découvrons le site de Postman, un outil qui permet de construire et de
tester rapidement des requêtes HTTP. Deux versions sont actuellement disponibles,
la première se présente sous forme d’application pour le navigateur google Chrome
et l’autre, en version Beta est disponible pour Mac [13].

Fig. 4.3: Logo Postman [13]

36
4.3 Technologies et Framework utilisés
4.3.1 Angular
Lors de notre recherche nous trouvons qu’il y a plusieurs Framework similaires à
Angular, pour cela nous allons faire une comparaison avec une permis eux pour
savoir et illustrer notre choix de Framework Angular.
Le tableau 4.2 montre une comparaison entre React et Angular comme suit :

Tab. 4.2: Comparaison entre Angular et React

Angular React
3 Fourni par Google. 3 Fourni par Facebook .
3 C’est une Framework JavaScript. 3 C’est une open source libraire JS.
3 Utilise un DOM habitué. 3 Travaille avec un DOM virtuel.
3 Une liaison des données bi-directionnelle. 3Une liaison des données uni-
3 Utilise l’architecture MVC. directionnelle.
3 Utilise seulement le Controller View.

Après savoir cette comparaison, nous trouvons que Angular est le bon choix pour
notre application à cause de ces raisons :
^Une configuration de build et d’optimisation complète.
^Module d’animations
^Module de routing
^Module de formulaire
^Permet de mieux séparer les responsabilités avec une approche MVC et l’injection
de dépendances.
Nous avons utilisé Angular comme un Framework front-end. Il est basé sur le langage
TypeScript et repose sur la décomposition de l’application. Nous utilisons le Frame-
work Angular avec un serveur Node permettant de traduire TypeScript en JavaScript
compréhensible par un navigateur, et Angular CLI, un outil en ligne de commande
qui permet de générer la structure du projet, générer des composants Angular, etc et
d’autres utilitaires facilitant le développement des applications Angular [14].

37
 Fig. 4.4: Logo Angular7 [15]

Dans ce qui suit, nous allons montrer une étude sur les faiblesses et les bienfaits de
framework Angular.

Tab. 4.3: Les points forts et faibles d’Angular

Points forts Points faibles

Ú L’intégrité : Angular s’intègre facilement dans Ø La documentation d’AngularJS n’est pas
n’importe quel projet développé en PHP, Sym- forcement terrible : Il n’est pas évident
fony, Java ou d’autres technologies il suffit d’in- de trouver des exemples complets et perti-
clure un script pour commencer à faire de l’An- nents.
gular. Ø La communauté Angular grandit vite
Ú Facilité d’apprendre :Il existe des nombreux mais reste plus restreinte que d’autres Fra-
tutoriels sur google qui permette l’apprentissage mework JS. L’internationalisation n’est pas
en quelques jours. non plus super.
Ú La stabilité : Nous n’avons jamais été bloqués
par une fonctionnalité absente ou un gros bug
parce que chaque fois cet framework s’est bien
comporté et a apporté des solutions à nos diffé-
rents problèmes.
Ú La performance :En effet, même sur des
écrans complexes, à savoir des formulaires très
dynamiques avec de nombreux rechargements
de listes de valeurs, la vitesse est stupéfiante.
Ú L’extensibilité : Nous pouvons facilement
créer des extensions comme des directives. Et
après une seule semaine sur AngularJS, tout un
chacun peut étendre le Framework.

38
4.3.2 TypeScript
TypeScript est un langage de programmation libre développé par Microsoft pour
JavaScript à l’échelle de l’application. TypeScript ajoute des types facultatifs à
JavaScript qui prend en charge les outils pour les applications JavaScript à grande
échelle pour tous les navigateurs, tous les hôtes et tous les systèmes d’exploitation.
TypeScript compile en JavaScript lisible et basé sur des normes [16].
Nous avons choisi TypeScript parce que :
^Il a un typage fort.
^Il crée des classes, des interfaces et import des modules.
^Il fournit une solide option pour le typage du JavaScript.

Fig. 4.5: Logo TypeScript [17]

4.3.3 Laravel
Nous menons dans un premier lieu à comparer le framework Laravel à celle de
CodeIgniter pour savoir le bon choix de notre travail.

39
 Tab. 4.4: Comparaison entre Laravel et CodeIgniter

Laravel CodeIgniter
3 Les contrôleurs RESTful peuvent don- 3 CodeIgniter ne facilite pas le développement
ner aux développeurs les moyens de créer rationalisé des API REST.
un assortiment d’API REST sans perdre de 3Support des SGBD tel que MySQL, MongoDB,
temps. PostgreSQL.
3 Support des SGBD comme ORACLE, 3 CodeIgniter n’a aucune fonctionnalité d’au-
PostgreSQL, Microsoft SQL Server et thentification intégrée. Les développeurs doivent
MYSQL. autoriser et authentifier les utilisateurs avec les
3 Laravel possède une fonctionnalité de extensions personnalisées CodeIgniter.
classe d’authentification qui facilite la mise
en œuvre de règles d’authentification et
d’autorisation.
3 Il a une grande fonctionnalité de docu-
mentation

D’après cette comparaison, nous trouvons que la framework Laravel est le bon
choix pour notre travail. Nous permettons aussi illustrant notre choix par la figure
suivante qui présente l’intérêt des développeurs sur cette framework.

Fig. 4.6: Evolution de l’intérêt entre Laravel et

Codeigniter [18]

Laravel est un framework PHP open source, robuste et facile à comprendre. Elle
réutilise les composants existants de différents cadres, ce qui aide à créer une
application Web. Dans cet framework nous allons trouver les caractéristiques

40
suivantes :
ã un système de routage perfectionné (RESTFul et ressources).
ã un créateur de requêtes SQL et un ORM performants.
ã un moteur de template efficace.
ã un système d’authentification pour les connexions.
ã un système de validation.
ã un système de pagination.
ã un système de migration pour les bases de données.

Fig. 4.7: Logo Laravel [19]

4.3.4 PHP
Hypertext Préprocessor est un langage de programmation libre utilisé pour produire
des pages web dynamiques via un serveur HTTP. Il est considéré comme une des
bases de la création des sites dites dynamiques mais également des applications web.
Notre choix de ce langage est basé sur beaucoup des raisons tel que :
^Il est un langage facile à apprendre.
^Il est gratuit.
^Il est intégré dans de nombreux serveurs web (Apache, Rest).
^Il se combine très bien avec les différentes bases de données.
^Les scripts PHP sont très simples à comprendre.

Fig. 4.8: Logo PHP [20]

41
4.4 Serveur et base de données
4.4.1 Le serveur Rest
Un service web est un mécanisme qui tend à donner plus d’interactions pour
permettre à deux entités hétérogènes de dialoguer à travers du réseau internet. Il
existe beaucoup de styles d’architecture sur lesquels sont basés les services web tel
que REST et SOAP.

Tab. 4.5: Comparaison entre REST et SOAP

REST SOAP
Type 3 C’est un style d’architecture. 3 C’est un protocole.
Cache 3 Les appels d’API peuvent être mis 3 Les appels d’API ne peuvent pas
en cache. être mis en cache.
Sécurité 3 Prend en charge HTTPS et SSL. 3 WS-Security avec support SSL.
Performance 3 Nécessite moins de ressources. 3 Nécessite plus de bande passante
et de puissance de calcul.
Avantages 3 Évolutivité, meilleures perfor- 3 standardisé, extensibilité.
mances, convivialité du navigateur,
flexibilité.

Alors, pour notre système nous avons choisi le service REST qui est un style d’ar-
chitecture qui repose sur le protocole HTTP. Ce protocole fournit les opérations
nécessaires à la manipulation des données suivants :
4 GET : accéder à une ressource existante.
4 POST : ajouter une nouvelle ressource.
4 DELETE : supprimer une ressource.
4 PUT : affecte une ressource (existante ou non).

42
 Fig. 4.9: Architecture de web service Restful [21]

4.4.2 Base de données :SQLServer

Microsoft SQL Server est un système de gestion de base de données en langage
SQL incorporant entre autres un SGBDR développé et commercialisé par la société
Microsoft.
Le choix de cette base est illustré par les raisons suivantes :
^ Gestion avancée de la sécurité en offrant deux modes d’authentification une de
Windows et l’autre Sql Server.
^ Programmabilité.
^ Coût relativement moins cher par rapport aux autres SGBD du marché.
^ Il est utilisé pour la mise en place d’application de gestion.

Fig. 4.10: Logo de Microsoft SQL Server [22]

4.5 Les interfaces de l’application

4.5.1 Authentification
Le figure 4.11 décrit l’interface graphique de la page d’authentification de notre
application. Cette page qui assure l’authentification est commune pour tous les
utilisateurs. Un contrôle de saisie est effectué à ce niveau : si le mot de passe ou login

43
est erroné, un message d’erreur sera affiché. Une fois authentifié, selon la catégorie
de l’utilisateur, la page d’accueil appropriée s’affiche.

Fig. 4.11: Interface d’authentification

Le figure 4.12, nous montre un contrôle de saisie sur les champs d’authentification.
Il nous indique un message d’erreur parce que les champs sont vides.

Fig. 4.12: Contrôle de saisie

4.5.2 Gérer les journaux

L’administrateur a le droit de gérer les journaux comme l’indique les interfaces
suivantes.

44
4.5.2.1 Ajout journal
En appuyant sur le bouton d’ajout nous serons dirigés vers l’interface d’ajout, l’admi-
nistrateur peut ajouter un nouveau journal en saisissant les données nécessaires de
ce journal.

Fig. 4.13: Interface d’ajout journal

45
4.5.2.2 Lister les journaux
L’interface suivante nous montre une liste des journaux qui sont enregistrés dans la
base de données avec une description comme indiqué ci-dessous.

46
Fig. 4.14: Interface des journaux

47
4.5.2.3 Suppression journal
Afin de supprimer un journal, l’administrateur choisit le journal à supprimer puis
clique sur le bouton «supprimer», une boite de dialogue s’affiche pour confirmer la
suppression.

Fig. 4.15: Suppression d’un journal

48
4.5.2.4 Modification journal
L’administrateur peut modifier un journal existant en saisissant les nouvelles coor-
données comme le montre l’interface suivante.

Fig. 4.16: Confirmation de modification de journal

49
4.5.3 Gérer les écritures
4.5.3.1 Ajout d’écriture
La figure 4.17 montre l’interface pour ajouter une écriture, l’administrateur choisit
les coordonnées convenables puis il clique sur le bouton «enregistrer».

Fig. 4.17: Interface d’ajout écriture

50
4.5.3.2 Afficher les écritures
La figure 4.18 montre une liste d’écritures avec leur description.

Fig. 4.18: Interface des écritures

4.5.3.3 Modification d’écriture

Après changement des attributs désirés, une boite de dialogue s’affiche pour confir-
mer la modification comme indique la figure ci-dessous :

51
 Fig. 4.19: Interface de modification écriture

4.5.3.4 Suppression d’écriture

En appuyant sur le bouton «supprimer» une boite de dialogue s’affiche pour confirmer
la suppression ou l’annulation de cette écriture. La figure 4.20 nous montre celui
ci.

52
 Fig. 4.20: Interface de suppression d’écriture

4.6 Conclusion
Dans ce chapitre, nous avons décrit en premier lieu l’environnement du travail et
les technologies utilisées dans notre application. La deuxième partie a été dédiée à
la présentation de notre travail grâce à des captures d’écran et une description des
fonctionnalités offertes par les différentes interfaces de l’application développée.

53
Conclusion générale
Dans ce projet, nous avons réalisé une étude à la fois théorique et pratique dans le
cadre de développement d’une application de gestion de comptabilité.
Cette application web permet de gérer les tâches convenables d’un comptable pour
le faciliter tout accès, ajout, suppression ou bien modification des données stockés
dans la base de données SQLServer. Cette application est présentée au sein de la
société ASM. Elle est la solution qui intervient dans le cadre d’améliorer la solution
existante pour assurer une performance élevée. Notre application web reprend aux
besoins fonctionnels et non fonctionnels du notre client qui sont modélisés par des
diagrammes UML spécifiques.
Ce projet nous a permis de maîtriser le langage UML, évaluer nos capacités et nos
aptitudes à gérer un projet. Aussi elle nous a offert l’opportunité de développer nos
sens de collaboration, nos relations, notre autonomie et notre prise de décision.
D’un point de vue académique, cette expérience nous a permis de mettre en évidence
nos connaissances dans la conception et le développement en tant que nous arrivons
à réaliser les besoins nécessaires de notre client dans cette application et surtout
d’approcher une technologie qui ne cesse d’évoluer et d’innover et qui domine de
plus en plus le marché des technologies de l’information.
L’expérience au sein d’un cadre professionnel, nous a été bénéfique. Ce stage nous a
permis de nous familiariser à la vie professionnelle, d’exploiter des notions fonda-
mentales et d’approfondir nos connaissances théoriques acquises à l’école nationale
d’ingénieurs de Sfax. Nous souhaitons que la société adopte réellement notre appli-
cation et essayera de la commercialiser.
Comme perspective à notre travail, nous pourrons ajouter une version mobile pour
rendre l’application accessible même en dehors du travail via des tablettes, ce qui
est utile lorsqu’il y a un plan ou une écriture ou un journal comptable doit être livré
et qu’il nécessite une confirmation.

54
Netographie

[1] ASM - Posts. URL : https://www.facebook.com/pg/allsoftmultimedia/posts/

(visité le 15 mai 2019) (cf. p. 3).

[2] Qu’est ce qu’un ERP ? - Définition d’un logiciel ERP (ou PGI). URL : https://www.
choisirmonerp.com/erp/definition-d-un-erp (visité le 15 mai 2019) (cf. p. 4).

[3] Logiciel de gestion comptable, comptabilité, factures, projets, devis. URL : https://www.
kiwili.com/ (visité le 11 mai 2019) (cf. p. 5).

[4] Blogue | Momenteo. URL : https://fr.momenteo.com/blogue/ (visité le 11 mai

2019) (cf. p. 6).

[5] Fichier :Logo-Clementine.svg — Wikipédia. URL : https://fr.wikipedia.org/wiki/

Fichier:Logo-Clementine.svg (visité le 11 mai 2019) (cf. p. 6).

[6] Introduction aux méthodes agiles et Scrum. L’Agiliste. 3 juin 2013. URL : https :
//agiliste.fr/introduction-methodes-agiles/ (visité le 21 fév. 2019) (cf. p. 8,
9).

[7] André De S OUSA. Scrum : le process en 5 minutes ! URL : http : / / www . coffee -
meeting.com/scrum-process-en-5-minutes (visité le 19 fév. 2019) (cf. p. 10).

[8] 2017-Scrum-Guide-US.pdf. URL : https : / / www . scrumguides . org / docs /

scrumguide/v2017/2017-Scrum-Guide-US.pdf (visité le 21 fév. 2019) (cf. p. 10).

[9] UML (informatique). In : Wikipédia. Page Version ID : 163617736. 17 avr. 2019

(cf. p. 12).

[10] Diagramme de GANTT, suivez le guide de la planification projet ! URL : http://www.

diagramme-de-gantt.fr/ (visité le 6 mar. 2019) (cf. p. 12).

[11] Visual Paradigm. In : Wikipedia. Page Version ID : 896993014. 14 juin 2019 (cf. p. 35).

[12] Documentation for Visual Studio Code. URL : https://code.visualstudio.com/docs

(visité le 24 juin 2019) (cf. p. 36).

[13] Postman, un outil pour tester les API RESTful. URL : http://www.alain-dessi.com/
blog/post/postman-un-outil-pour-tester-les-api-restful (visité le 22 juin
2019) (cf. p. 36).

[14] Angular. URL : https://angular.io/ (visité le 26 juin 2019) (cf. p. 37).

[15] Actualités Nouveautés Angular 7 | INOW. URL : https://www.inow.fr/actualite/

developpement-web/nouveautes-angular-7/13 (visité le 15 nov. 2019) (cf. p. 38).

[16] TypeScript is a superset of JavaScript that compiles to clean JavaScript output. : micro-
soft/TypeScript. original-date : 2014-06-17T15 :28 :39Z. 26 juin 2019 (cf. p. 39).

55
[17] Learn TypeScript (Ditch JavaScript). Udemy. URL : https://www.udemy.com/course/
understanding-typescript/ (visité le 15 nov. 2019) (cf. p. 39).

[18] CodeIgniter vs Laravel 2019 | Which is Best ? Technostacks Infotech Pvt. Ltd. 8 mai
2019. URL : https://technostacks.com/blog/codeigniter-vs-laravel/ (visité
le 15 nov. 2019) (cf. p. 40).

[19] Laravel. In : Wikipédia. Page Version ID : 163203140. 3 oct. 2019 (cf. p. 41).

[20] PHP. In : Wikipédia. Page Version ID : 163587609. 16 oct. 2019 (cf. p. 41).

[21] Ahmet ÖZLÜ. Mastering REST Architecture — REST Architecture Details. Medium.
13 jan. 2019. URL : https : / / medium . com / @ahmetozlu93 / mastering - rest -
architecture - rest - architecture - details - e47ec659f6bc (visité le 15 nov.
2019) (cf. p. 43).

[22] Microsoft SQL Server - Plateforme de Business Intelligence. COSMO CONSULT. URL :
https://fr.cosmoconsult.com/produits/business-intelligence/microsoft-
sql-server/ (visité le 15 nov. 2019) (cf. p. 43).

56
 Application de gestion de comptabilité pour un ERP

Moufida Salah

‫ إىل تصميم‬All Soft Multimedia ‫بشكة‬ ‫المشوع لختم الدراسات الذي تم ر‬

‫ يهدف هذا ر‬:‫ملخص‬
ً ‫ يتيح هذا التطبيق للمستخدم إدارة المهام المطلوبة للمحاسب‬.‫وتطوير تطبيق واب إلدارة المحاسبة‬
‫بناء‬
‫وبالتاىل الحصول عىل رضا ووالء العمالءـ‬
‫ي‬ ‫معايي األداء لضمان الحصول عىل منتج ذي نوعية جيدة‬
‫ر‬ ‫عىل‬

Résumé : Ce projet de fin d’études élaboré au sein de la société All Soft MultiMedia
vise à concevoir et à développer une application web de gestion de comptabilité.
Cette application permet à l’utilisateur de gérer les tâches nécessaires pour un
comptable en se basant sur des critères de performance afin d’assurer un produit
de bonne qualité et donc gagner la satisfaction et la fidélisation des clients.

Abstract: This graduation project developed within the company All Soft
Multimedia aims at designing and developing a web application for accounting
management. This application allows the user to manage the tasks required for an
accountant based on performance criteria to ensure a good quality product and
thus to gain the satisfaction and the customer loyalty.

‫ اسكيل ر‬،‫ انـڤـيالر‬،‫ الرافل‬،‫ تخطيط موارد المؤسسات‬،‫ المحاسبة‬:‫المفاتيح‬

.‫ واب‬،‫سيفر‬

Mots clés : comptabilité, ERP, Angular, Laravel, SQL Server, Web.

Keywords: accounting, ERP, Angular, Laravel , SQL Server, Web.

58