Rapport du Projet de Fin d'année Génie informatique

Projet de Fin d’Année 1 2019 - 2020
ENSA4/G.INFO/2019-2020
Rapport du Projet de Fin d’Année
Présenté par
Bourass Karim
Jirou Mouhsin
Daoudi Ayoub
Spécialité : Génie Informatique
Thème :
Conception et développement d’une
plateforme de gestion commerciale
Encadré par : Entreprise : Grafimage
M. Abdenbi Abenaou, Encadrant à l’ENSA
M. Abdelkarim Msaad, Encadrant à l’Entreprise
Soutenu le : 14/07/2020, devant la commission du jury : M. Abdenbi Abenaou,
M. Toumanari ahmed,
M. Bnouhachem Abddelah

Remerciements
Avant tout développement de cette expérience professionnelle, il parait
important de commencer ce rapport de Stage de Fin d’Année par des remerciements
à ceux et à celles qui nous ont beaucoup apprises, nous ont assistées et
accompagnées tout au long de ce stage et à ceux qui ont eu la gentillesse de faire
de ce Stage un moment très profitable.
Nous tenons en particulier à remercier notre encadrant, M. Abdenbi
Abenaou, pour son assistance et son accompagnement durant et après la période
du stage, ainsi que pour les différentes connaissances qu’il nous a transmises.
Nous tenons aussi à remercier M. Mohamed Elyaakoubi et M. CHAOUKI
Brahim El Khalil pour leurs directives précieuses et leurs conseils pertinents qui
nous ont été d’un appui considérable dans notre démarche.
Nous tenons aussi à remercier tous les membres du jury qui nous ont fait
l’honneur d’accepter de juger notre travail. Enfin, nous présentons nos sincères
remerciements à M Abdelkarim MSAAD notre encadrant, pour nous avoir fournies
toutes les informations et données nécessaires pour la réalisation de notre travail
ainsi que pour son accompagnement et supervision permanents. Nos remerciements
s’adressent de même à tout le personnel de la société Grafimage, qui n’a épargné
aucun effort pour nous assister au cours de notre Stage.

Résumé
L’objectif de notre projet de fin d’année au sein de l’entreprise Grafimage est
de concevoir une plateforme de gestion commerciale, dont le but est la gestion d’un
grossiste, qui permettrait à ce dernier de gérer son stock entrant et sortant à travers
des interfaces ergonomiques facile à utiliser tout en gardant l'esprit que l'accès
devrait être sécurisé par un système d'authentification.
Afin de parvenir à notre but nous avons opté pour Spring / Angular comme
Framework de développement de l’application web, Java pour la partie backend, Css
Html Bootstrap pour la partie frontend, et UML pour la conception.
Abstract
The objective of our end-of-year project within the Grafimage company is to
design a commercial management platform, the aim of which is the management of a
wholesaler, which would allow the latter to manage its incoming and outgoing stock
through ergonomic interfaces easy to use while keeping in mind that access should
be secured by an authentication system.
In order to achieve our goal, we opted for Spring / Angular as a framework for
developing the web application, Java for the backend part, CSS Html Bootstrap for
the frontend and UML for the design.

Table des figures :
Figure 1 : Adresse de Grafimage.............................................................................. 12
Figure 2 : Principe de la méthodologie de développement 2TUP............................. 20
Figure 3 : Diagramme de Gantt prévisionnel ............................................................ 22
Figure 4 : Diagramme de Gantt réel ......................................................................... 23
Figure 5 : L'architecture J2EE................................................................................... 25
Figure 6 : interface de gestion des taches................................................................ 31
Figure 7 : diagramme de cas d’utilisation d’un utilisateurs........................................ 33
Figure 8 : diagramme de cas d’utilisation d’achat..................................................... 34
Figure 9 : diagramme de cas d’utilisation des avoirs client....................................... 34
Figure 10 : diagramme de cas d’utilisation des avoirs fournisseur .......................... 35
Figure 11 : diagramme de cas d’utilisation des clients ............................................. 36
Figure 12 : diagramme de cas d’utilisation des dépôts............................................. 37
Figure 13 : diagramme de cas d’utilisation des devis ............................................... 37
Figure 14 : diagramme de cas d’utilisation des factures........................................... 38
Figure 15 : diagramme de cas d’utilisation des fournisseurs .................................... 38
Figure 16 : diagramme de cas d’utilisation des paiement client................................ 39
Figure 17 : diagramme de cas d’utilisation des paiement fournisseur ...................... 39
Figure 18 : diagramme de cas d’utilisation des produits........................................... 40
Figure 19 : diagramme de classe ............................................................................. 41
Figure 20 : Architecture back-end............................................................................. 43
Figure 21 : La couche beans .................................................................................... 44
Figure 22 : La couche sécurité ................................................................................. 44
Figure 23 : La couche service................................................................................... 45
Figure 24 : La couche dao........................................................................................ 45
Figure 25 : La couche controller ............................................................................... 46
Figure 26 : Architecture du front-end........................................................................ 47
Figure 27 : Architecture du projet ............................................................................. 47
Figure 28 : Modèles des composants....................................................................... 48
Figure 29 : Services des composants....................................................................... 48
Figure 30 : Le Plan de site........................................................................................ 49
Figure 31 : Interface d'authentification...................................................................... 49
Figure 32 : Interface d'authentification...................................................................... 50

Figure 33 : interface Dashboard ............................................................................... 51
Figure 34 : suite interface dashboard ....................................................................... 51
Figure 35 : interface Rapport.................................................................................... 52
Figure 36 : interface achat du mois .......................................................................... 52
Figure 37 : interface vente du jour ............................................................................ 53
Figure 38 : Interface produits.................................................................................... 53
Figure 39 : Interface Modifier un produit................................................................... 54
Figure 40 : Interface Supprimer un produit ............................................................... 54
Figure 41 : Interface alert stock ................................................................................ 55
Figure 42 : Interface dépôt........................................................................................ 55
Figure 43 : Interface pour consulter les produits d’un dépôt..................................... 56
Figure 44 : Interface charges.................................................................................... 56
Figure 45 : Interface Ajouter facture ........................................................................ 57
Figure 46 : Interface client ........................................................................................ 57
Figure 47 : interface factures d'un client................................................................... 58
Figure 48 : Interface detail facture client................................................................... 58
Figure 49 : Interface paiement client ........................................................................ 59
Figure 50 : Interface verser client ............................................................................. 59
Figure 51 : Interface historique avoir client............................................................... 60
Figure 52 : Interface nouveau avoir client................................................................. 60
Figure 53 : Interface Utilisateurs............................................................................... 61
Figure 54: Interface pour modifier en mot de passe ................................................. 61
Figure 55 : Interface des charges ............................................................................. 62
Figure 56 : Interface pour ajouter un utilisateur ........................................................ 62
Figure 57 : Authentication Spring Security avec JWT............................................... 63
Figure 58 : Capture de la table User de la base de donnée ..................................... 64
Figure 59 : Diagramme de la demande d'une ressource qui nécessite
l'authentification........................................................................................................ 64
Figure 60 : Emplacement du jwt dans le stockage local ........................................... 65
Figure 61 : interface intercepteur HTTP.................................................................... 66
Figure 62 : Interface pour la déconnexion ................................................................ 67
Figure 63 : Interface de stockage local d’un utilisateur déconnecter ........................ 68

Liste des abréviations
Abréviation Signification
API Application Programming Interface
HTTP HyperText Transfer Protocol
IOC Inversion of Control
JEE Java Entreprise Edition
JPA Java Persistance API
MVC Modèle Vue Contrôleur
CSRF Cross-Site Request Forgery
SHA Secure Hash Algorithm
MYSQL My Structured Query Language
UML Unified Modeling Language
POJO Plain Old Java Object
URL Uniform Resource Locator

Sommaire
Table des figures :...................................................................................................... 4
Liste des abréviations................................................................................................. 6
Introduction Générale : ............................................................................................... 9
Chapitre 1 : Présentation de l’organisme d’accueil................................................... 11
1.1 Introduction ..................................................................................................... 11
1.2 Fiche de l'entreprise :...................................................................................... 11
1.3 Domaines d'expertise :.................................................................................... 11
1.3.1 Développement ........................................................................................ 11
1.3.2 Design et Ergonomie ............................................................................ 12
1.3.3 Marketing Digital ................................................................................... 12
1.3.4 Photographie & Vidéos ......................................................................... 12
1.4 Situation géographique : ................................................................................. 12
Chapitre 2 : Cahier des Charges .............................................................................. 14
2.1 Spécification et analyse des besoins : ............................................................ 14
2.2 Cycle de vie du projet...................................................................................... 19
2.3 Diagramme de Gantt....................................................................................... 22
2.3.1 Gantt prévisionnel..................................................................................... 22
2.3.2 Gantt réel.................................................................................................. 23
Chapitre 3 : Etude Technique................................................................................... 25
3.1 Outils et Technologies de Développement...................................................... 25
3.1.1 JAVA 2 ENTERPRISE EDITION (JAVA 2EE) .......................................... 25
3.1.2 LANGAGE JAVA ...................................................................................... 25
3.1.3 HTML........................................................................................................ 26
3.1.4 CSS.......................................................................................................... 26
3.2 Environnements de Développement ............................................................... 26

3.2.1 ECLIPSE (IDE)............................................................................................. 26
3.2.2 WebStorm ................................................................................................ 27
3.2.3 Postman : ................................................................................................. 27
3.3 Outils et Technologies de Base de données................................................... 27
3.3.1 ATELIER POWERAMC ............................................................................ 27
3.3.2 phpMyAdmin............................................................................................. 28
3.4 Framework ...................................................................................................... 28
3.4.1 SPRING.................................................................................................... 28
3.4.2 Angular..................................................................................................... 29
3.4.3 BOOTSTRAP ........................................................................................... 30
3.4.3 Chart.Js.................................................................................................... 30
3.5 Autre outils...................................................................................................... 31
3.5.1 Trello ........................................................................................................ 31
3.5.2 JSON WEB TOKEN ................................................................................. 31
Chapitre 4 : Analyse et Conception .......................................................................... 33
4.1 Diagrammes des cas d’utilisation.................................................................... 33
4.1.1 DIFFERENTS CAS D’UTILISATION ........................................................ 33
4.2 Diagrammes de classes.................................................................................. 40
Chapitre 5 : Réalisation ............................................................................................ 43
5.1 Architecture général de l’application ............................................................... 43
5.1.1 Architecture du back-end :........................................................................ 43
5.1.2 Architecture du front-end :........................................................................ 46
5.1.3 Plan de site :............................................................................................. 49
5.2 Les interfaces de l’application ......................................................................... 49
5.3 La sécurité : .................................................................................................... 63
5.3.1 La Sécurité côté back-end........................................................................ 63
5.3.1 La Sécurité côté front-end ........................................................................ 65

Introduction Générale :
Étant étudiants en deuxième année du cycle ingénieur en génie informatique,
Nous étions tenus d'effectuer, le long du second semestre de cette année, un stage
de PFA en entreprise. Le but de ce stage est d'enrichir notre formation académique
d'une expérience professionnelle aujourd'hui devenue nécessaire pour une bonne
intégration de l'élève ingénieur dans le marché du travail à l'obtention de son
diplôme. D'autre part, ce stage fut l'occasion pour nous de nous familiariser avec le
travail en entreprise et d'appliquer nos connaissances théoriques pour résoudre une
problématique réelle.
Notre but était de créer une application web qui facilite la tâche aux
commerçants d'une part d’obtenir, consulter, et renouveler leur stock vis-à-vis leur
client ou fournisseur, d'autre part gérer la traçabilité en détail des produits dès leur
achat jusqu'à leur vente.
Ce présent rapport est composé de cinq chapitres :
 Premier chapitre : Il présente l’organisme d’accueil, et son domaine de
fonctionnement.
 Deuxième chapitre : Il est consacré à une étude d’analyse et de la
spécification des besoins.
 Troisième chapitre : Il est dédié aux outils et aux technologies utilisés lors du
développement de cette application.
 Quatrième chapitre : Il présente une analyse des besoins que nous avons
cités dans la partie précédente, et les modéliser par la suite.
 Cinquième chapitre : Il est consacré à la description de la phase de mise en
œuvre de l’application. Nous y décrivons l’architecture de notre application et
nous illustrons certaines fonctionnalités assurées à travers les interfaces.
 On finit ce rapport par une conclusion, montrant la valeur ajoutée de notre
application, et les perspectives que nous avons envisagées pour l’évoluer.

Chapitre I
Présentation de l'entreprise
Dans ce premier chapitre nous présentons l’organisme d’accueil, et
son domaine de fonctionnement.

Chapitre 1 : Présentation de l’organisme
d’accueil
1.1 Introduction
GRAFIMAGE, la société au sein de laquelle nous avons effectué notre stage, est
une entreprise de services et d’ingénierie informatique, qui opère principalement
dans le domaine du web et audiovisuel, GRAFIMAGE apporte des solutions
informatiques performantes et innovatrices basées sur les nouvelles technologies
adaptées aux besoins IT de ses clients.
1.2 Fiche de l'entreprise :
Nom GRAFIMAGE
Secteur d'activité Web et audiovisuel
Adresse Bureau NВ° 6 2ème étage, Imm Amal Anzi Av
Hassan 1er, Hay Almassira 80000 Agadir - Maroc
Site web www.grafimage.com/
Création 2015
Téléphone +212 (5) 28 21 41 51
1.3 Domaines d'expertise :
1.3.1 Développement
Dans l’approche de GRAFIMAGE, la technologie est au service du marketing et de la
satisfaction des utilisateurs, avec l’utilisation des solutions Open Source éprouvées
et un choix plus adapté aux projets.

1.3.2 Design et Ergonomie
GRAFIMAGE permet de concevoir une identité visuelle originale en fonction
du métier et de la cible des clients. Elle accorde autant d'importance aux aspects
esthétiques et ergonomiques pour réussir un business.
1.3.3 Marketing Digital
GRAFIMAGE aide à définir la stratégie digitale, au déploiement et au pilotage.
Elle aime mesurer, analyser pour faire évoluer et maximiser les enjeux business.
1.3.4 Photographie & Vidéos
GRAFIMAGE propose une gamme variée de solutions en lien avec une
stratégie marketing (photographie, films institutionnels, animations), l’équipe répond
aux besoins de communication interne et externe.
1.4 Situation géographique :
La société « Grafimage» se situe l’avenue Hassan 1er, Hay Almassira 80000 Agadir
- Maroc Le plan de situation de Grafimage est donné dans la figure suivante :
Figure 1 : Adresse de Grafimage

Chapitre II
Cahier des charges
Dans ce deuxième chapitre nous passerons à une étude
d’analyse et de spécification des besoins.

Chapitre 2 : Cahier des Charges
2.1 Spécification et analyse des besoins :
Après avoir définir le cadre général de notre projet, nous passerons à une
étude d’analyse et de spécification des besoins.
L’analyse et la spécification des besoins représentent la première étape du
cycle de vie d’un logiciel informatique. Elle sert à identifier les acteurs réactifs du
système ainsi que la source des données relatif à l’application, et ceci pour donner
un résultat optimal et satisfaisant.
Ainsi, dans cette section, nous commençons par une spécification des besoins
auxquels doit répondre l’application, passant ensuite à l’analyse de ces besoins à
travers l’introduction des acteurs du système et la source des données.
Les besoins fonctionnels
Les services proposés par notre application web se résument en deux acteurs
majeurs :
• Elle permet à l’utilisateur de :

S’authentifier :
♦ À travers un nom d’utilisateur et un mot de passe.
Gérer les factures :
♦ Ajouter des factures.
♦ Une recherche des factures selon l’Id et le nom du client.
♦ Afficher le détail d'une facture.
♦ Consulter les factures à travers leur statut (payées/non payées)

♦ Afficher l'historique des paiements pour chaque facture et calculer le crédit
restant.
♦ Verser un montant pour une facture qui a un statut *non payée*.
♦ Décrémenter le stock après chaque facture.
Gérer les produits :
♦ Afficher, Ajouter, Modifier et supprimer des produits.
♦ Afficher les produits qui sont en rupture de stock.
♦ Notifier lorsqu’un produit est hors stock.
♦ Calculer automatiquement le prix d'achat moyen d'un produit.
Gérer les bons d’achat :
♦ Ajouter des bons d’achat.
♦ Une recherche des bons d’achat selon l’Id et le fournisseur.
♦ Afficher le détail d’un bon d’achat.
♦ Consulter les bons d’achat à travers leur statut (payé/non payé)
♦ Afficher l'historique des paiements pour chaque bon d’achat et calculer le
crédit restant.
♦ Verser un montant pour un bon d’achat qui a un statut *non payé*.
♦ Incrémenter le stock après chaque achat.
Gérer les avoirs d’un client :
♦ Ajouter un avoir, le supprimer, consulter les produits rendus.
♦ Une recherche des avoirs client selon la date.
♦ Incrémenter le stock après chaque avoir.

Gérer les avoirs d’un fournisseur :
♦ Ajouter un avoir, le supprimer, consulter les produits rendus.
♦ Une recherche des avoirs fournisseur selon la date.
♦ Décrémenter le stock après chaque avoir.
Gérer les devis :
♦ Ajouter, supprimer, chercher un devis.
♦ Afficher le détail d'un devis (ses produits)
Gérer les charges :
♦ Ajouter, modifier supprimer et chercher une charge.
Gérer les paiements d’un client :
♦ Afficher tous les paiements des clients
♦ Chercher un paiement selon le nom du client
♦ Supprimer un paiement.
Gérer les paiements d’un fournisseur :
♦ Afficher tous les paiements des fournisseurs
♦ Chercher un payement selon le nom d’un fournisseur.
♦ Supprimer un paiement
Gérer les clients :
♦ Ajouter, modifier, supprimer un client
♦ Chercher un client selon son nom
♦ Afficher l'historique des factures pour chaque client.

♦ Chercher une facture selon une date pour un client
♦ Afficher les factures d’un client selon leur statut.
♦ Régler les factures non payées.
♦ Calculer le montant total des factures pour chaque client, le total des
paiements, et le crédit restant pour toutes ces factures.
♦ Afficher les avoirs d’un client.
Gérer les fournisseurs :
♦ Ajouter, modifier, supprimer un fournisseur.
♦ Chercher un fournisseur selon son nom.
♦ Afficher l'historique des bons d’achat pour chaque fournisseur.
♦ Chercher un bon d’achat selon une date pour un client
♦ Afficher les bons d’achat d’un fournisseur selon leur statut.
♦ Régler les bons d’achat non payées.
♦ Calculer le montant total des bons d’achat pour chaque fournisseur, le total
des paiements, et le crédit restant pour toutes ces achats.
♦ Afficher les avoirs d’un fournisseur.
Gérer les dépôts :
♦ Ajouter, modifier, supprimer, chercher selon l’emplacement.
♦ Afficher les produits de chaque dépôt.
Accès aux statistiques :
♦ Afficher les produits les plus vendus entre deux dates avec la quantité
vendue.
♦ Afficher les charges les plus élevées entre deux dates.

♦ Afficher le chiffre d'affaire effectué selon une date (total des ventes), total
des charges, total des achats, total des avoirs clients et fournisseurs
♦ calculer la caisse du jour, ou selon une date
♦ Donner le rapport journalier des ventes, achats, charges
♦ Donner le rapport mensuel des ventes, achats et charges
♦ Classer les clients selon les ventes.
• Elle permet à l’administrateur de :
L’administrateur peut accéder aux mêmes fonctionnalités que celle d’un utilisateur.
De plus :
S’authentifier :
♦ À travers un login et un mot de passe.
Gérer les utilisateurs :
♦ Afficher la liste des utilisateurs.
♦ Modifier les informations d’un utilisateur ainsi que son mot de passe.
♦ Supprimer un utilisateur.
♦ Consulter l’utilisateur responsable d’une opération (Charge, Facture, Bon
d’Achat).
Les besoins non fonctionnels
Les besoins non fonctionnels sont des exigences qui ne concernent pas
spécifiquement le comportement du système mais plutôt identifient des contraintes
internes et externes du système.
♦Les principaux besoins non fonctionnels de notre application se résume dans
les points suivants :

 Ergonomie :
♦ L’application doit avoir une interface conviviale, souple et ergonomique
exploitable par l’utilisateur.
 Rapidité :
♦ L’application doit optimiser les traitements pour avoir un temps de réponse
raisonnable.
 Sécurité :
♦ L'application doit respecter la confidentialité des données.
 Maintenabilité :
♦ Le code de l’application doit être compréhensible et lisible pour minimiser
l’effort d’évolution du système et pour localiser et corriger les erreurs facilement.
2.2 Cycle de vie du projet
Pour tout projet informatique, il est primordial de spécifier un cycle de vie de
projet informatique qui régira toute la période du projet. Étant donné les spécificités
de notre projet, notamment l'aspect éducatif et académique de ce projet, ce qui nous
contraignait à apprendre beaucoup, parfois par l'erreur, tout au long du projet, nous
avons opté pour un cycle de vie en Y.

Figure 2 : Principe de la méthodologie de développement 2TUP
Branche fonctionnelle
Les principales étapes de la branche fonctionnelle se présentent comme suit :
L’étape capture des besoins fonctionnels a pour objectif de définir :
♦ La frontière fonctionnelle entre le système et son environnement.

♦ Les activités attendues des différents utilisateurs par rapport au système.
♦ L’étape d’analyse : consiste à étudier précisément les spécifications
fonctionnelles de manière à obtenir une idée de ce que va réaliser le système en
termes de métier.
Branche technique
Les principales étapes de la branche technique se présentent comme suit :
♦ L’étape capture des besoins techniques : Cette étape recense toutes les
contraintes sur les choix de technologies pour la conception du système. Les outils et
le matériel sélectionnés ainsi que la prise en compte des contraintes d’intégration
avec l’existant (pré requis d’architecture technique).
♦ L’étape architecture matérielle et logiciel: Définit les composants
nécessaires à la construction de l’architecture technique. Cette conception est
complètement indépendante des aspects fonctionnels. Elle permet de générer le
modèle de conception technique qui définit les Frameworks.
Branche de conception et développement logiciel
Les principales étapes de cette branche se présentent comme suit :
♦ L’étape conception préliminaire : Cette étape permet de produire le
modèle de conception système. Ce dernier organise le système en composants,
délivrant les services techniques et fonctionnels, Ce qui induit le regroupement des
informations des branches technique et fonctionnelle.
♦ L’étape conception détaillée : permet d’étudier comment réaliser chaque
composant. Le résultat fournit l’image prête fabriquée du système complet.
♦ L’étape de codage : permet d’effectuer la production des composants et les
tests des unités de code au fur et à mesure de leur réalisation.

♦ L’étape de recette : consiste à valider les fonctionnalités du système
développé.
2.3 Diagramme de Gantt
Les diagrammes de Gantt prévisionnel et réel suivant comparent la
planification prévisionnelle et le déroulement réel de notre projet, mettant ainsi en
évidence les différents écarts, problèmes et autres imprévus auxquels nous nous
sommes confrontés.
2.3.1 Gantt prévisionnel
Après avoir élaboré le cahier des charges et avant de commencer une étude
technique, il est primordial de poser un planning afin d’organiser le travail et préciser
les dates de début et de fin de chaque tâche. Nous avons divisé l’application en
plusieurs modules qui dépendent un peu les uns des autres afin de faciliter la
planification et la réalisation. Pour chaque module, il est nécessaire de le concevoir
avant de procéder à sa réalisation.
Figure 3 : Diagramme de Gantt prévisionnel

2.3.2 Gantt réel
Il est aussi nécessaire d’élaborer le diagramme de Gantt [8] réel afin de
comparer entre les deux et de voir si effectivement le diagramme prévisionnel a été
respecté ou pas. Nous avons dû modifier les modules à réaliser vu que nous avons
remarqué que certains modules sont plus prioritaires que d’autres.
On a aussi rencontré des problèmes au niveau du développement de la partie
front-end, vu que la technologie utilisée (Angular) nous l’avons appris en
autoformation, ce qui a influencé sur la durée prolongée dans le diagramme de Gantt
réel.
Figure 4 : Diagramme de Gantt réel

Chapitre I I I
Etude Technique
Dans ce troisième chapitre nous présentons, en premier
lieu, l’environnement de travail et nous justifions les choix du
langage de programmation et la technologie de développement
appliqué.

Chapitre 3 : Etude Technique
3.1 Outils et Technologies de Développement
3.1.1 JAVA 2 ENTERPRISE EDITION (JAVA 2EE)
L'architecture J2EE[9] permet de séparer la couche présentation,
correspondant à l'interface homme-machine (IHM), la couche métier contenant
l'essentiel des traitements de données en se basant dans la mesure du possible sur
des API existantes, et enfin la couche de données correspondant aux informations
de l'entreprise stockées dans des fichiers, dans des bases de données relationnelles
ou XML, dans des annuaires d'entreprise ou encore dans des systèmes d'information
complexes.
Figure 5 : L'architecture J2EE
3.1.2 LANGAGE JAVA
Java[11] est un langage de programmation orienté
objet créé par James Gosling et Patrick Naughton,
employés de Sun Microsystems, avec le soutien de Bill
Joy (cofondateur de Sun Microsystems en 1982), présenté officiellement le 23 mai
1995 au SunWorld..

Java est un langage de programmation orienté objet utilisable sur divers systèmes
d’exploitation. Il est assez robuste, rapide, et fiable. Une particularité de Java est que
les logiciels écrits dans ce langage sont compilés vers une représentation binaire
intermédiaire qui peut être exécutée dans une machine virtuelle Java (JVM) en
faisant abstraction du système d'exploitation.
3.1.3 HTML
HTML5 (HyperText Mark up Langage 5) est la nouvelle révision
majeure d’HTML, format de données conçu pour représenter les
pages web Cette version est devenue stable depuis 2012. Le
langage comprend une couche application avec de nombreuses
API.
3.1.4 CSS
CSS est l'acronyme anglais de Cascading Style Sheets qui peut se
traduire par "feuilles de style en cascade". Le CSS est un langage
informatique utilisé sur l'internet pour mettre en forme les fichiers
HTML ou XML. Ainsi, les feuilles de style, aussi appelé les fichiers
CSS
3.2 Environnements de Développement
3.2.1 ECLIPSE (IDE)
Eclipse est un projet, décliné et organisé en un ensemble de sous-projets de
développements logiciels. Son objectif est de produire et fournir des outils pour la
réalisation de logiciels, englobant les activités de programmation
(notamment environnement de développement intégré et
frameworks) mais aussi d'AGL recouvrant modélisation,
conception, test, gestion de configuration, reporting… Son EDI,

partie intégrante du projet, vise notamment à supporter tout langage de
programmation à l'instar de Microsoft Visual Studio.
3.2.2 WebStorm
WebStorm propose une assistance au codage intelligente pour
les langages JavaScript et compilés vers JavaScript, HTML et
CSS. Profitez de la saisie automatique du code, de puissantes
fonctionnalités de navigation, de la détection d'erreurs à la
volée, et des refactorisations pour tous ces langages.
3.2.3 Postman :
Postman est une extension de Google Chrome qui est un navigateur
propriétaire fonctionnant sous Windows, Mac, Linux, Android et
IOS. Il est conçu pour tester les web services, est gratuit, facile
et rapide à manipuler.Il possède également une ergonomie
simple et conviviale.
3.3 Outils et Technologies de Base de données
3.3.1 ATELIER POWERAMC
PowerAMC (PowerDesigner aux USA) est un outil de
modélisation collaboratif d’entreprise de Sybase.Pour la
conception UML de notre projet nous avons opté pour le
logiciel PowerAMC vu sa simplicité d’utilisation et vu que c’est le logiciel que nous
avons l’habitude d’utiliser le long de notre formation.

3.3.2 phpMyAdmin
phpMyAdmin (PMA) est une application
Web de gestion pour les systèmes de gestion de
base de données MySQL distribuée sous licence
GNU GPL.Il s'agit de l'une des plus célèbres
interfaces pour gérer une base de données MySQL. De nombreux hébergeurs,
gratuits comme payants, le proposent ce qui évite à l'utilisateur d'avoir à l'installer.
3.4 Framework
3.4.1 SPRING
Spring est un Framework open source pour construire et définir l'infrastructure
d'une application Java [11], dont il facilite le développement et les tests. En 2004,
Rod Johnson a écrit le livre Expert One-on-One J2EE Design and Développent qui
explique les raisons de la création de Spring
a. Spring IoC :
Spring Ioc étant un Framework très complet et complexe, il ne sera décrit en détail
qu'une des multiples manières de faire de l'injection de dépendance avec Spring.
Le fonctionnement de Spring Ioc repose sur 3 éléments clés :
 La configuration XML pour lier les implémentations à leurs interfaces
 Les classes sont des beans et possèdent donc des getters et setters pour les
champs à injecter
 L'injection en même est effectuée par un conteneur de Spring

b. Spring Boot
Spring [1,2,4,7]. Boot est un framework qui facilite le
développement d'applications fondées sur Spring en
offrant des outils permettant d'obtenir une application
packagée en jar , totalement autonome. Ce qui nous intéresse particulièrement,
puisque nous essayons de développer des Micro services !
c. Spring Security
Spring Security est un framework Java / Java EE qui
fournit l'authentification, l'autorisation et d'autres
fonctionnalités de sécurité pour les applications
d'entreprise. Le projet a été lancé fin 2003 sous le nom de «Acegi Security» par Ben
Alex, et il a été rendu public sous la licence Apache en mars 2004 [3].
Spring Security utilise un algorithme de type bcrypt, Bcrypt est un algorithme de
hachage qui est évolutif en fonction du serveur qui le lance. Sa lenteur et sa robustesse
garantit qu'un hacker voulant décoder un mot de passe doit investir dans un matériel
couteux et très puissant pour décoder un mot de passe. Ajouter à cela que l'algorithme
utilise toujours des grains de sels, et vous pouvez être certain qu’une attaque est
aujourd'hui presque impossible. Il s'agit aujourd'hui de la méthode de hashage la plus
sûr !
3.4.2 Angular
Angular (communément appelé "Angular 2+" ou
"Angular v2 et plus")est un cadriciel (Framework) côté
client, open source, basé sur TypeScript, et co-dirigé par
l'équipe du projet « Angular » à Google et par une
communauté de particuliers et de sociétés. Angular est
une réécriture complète de AngularJS, cadriciel construit
par la même équipe [5,6].

3.4.3 BOOTSTRAP
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. C'est
un ensemble qui contient des codes HTML et CSS, des
formulaires, boutons, outils de navigation et autres éléments
interactifs, ainsi que des extensions JavaScript en option.
C'est l'un des projets les plus populaires sur la plate-forme de gestion de
développement GitHub.
3.4.3 Chart.Js
Chart.js, la bibliothèque JavaScript de
représentation des données sous forme de
graphes statistiques vient d’être publiée sur le
site officiel de son créateur Nick Downie.
D’une utilisation très simple avec plusieurs
options de personnalisation, l’outil offre une
prise en charge du HTML5 et ne nécessite pas de dépendance tierce.
Six représentations graphiques sont offertes par la bibliothèque, notamment les
courbes, les camemberts, les diagrammes en bâtons, les diagrammes en étoiles, les
graphiques en anneau et les donuts.
3.4.4 Hibernate
Hibernate[9] est un framework de mapping Objet/Relationnel
pour applications JAVA (et .NET avec Nhibernate). Supporter
par Jboss/RedHat Hibernate, permet de créer une couche
d’accès aux données (DAO) plus modulaire, plus maintenable,
plus performante qu’une couche d’accès aux données
“classique” reposant sur l’API JDBC.

3.5 Autre outils
3.5.1 Trello
Figure 6 : interface de gestion des taches
Trello est un outil de gestion de projet en ligne, lancé en septembre 2011 et
inspiré par la méthode Kanban de Toyota. Il repose sur une organisation des projets
en planches listant des cartes, chacune représentant des tâches. Les cartes sont
assignables à des utilisateurs et sont mobiles d'une planche à l'autre, traduisant leur
avancement
3.5.2 JSON WEB TOKEN
JSON Web Token (JWT) est un standard ouvert défini dans la RFC 75191. Il permet
l'échange sécurisé de jetons (tokens) entre plusieurs parties. Cette sécurité de
l’échange se traduit par la vérification de l’intégrité des données à l’aide d’une
signature numérique. Elle s’effectue par l'algorithme HMAC ou RSA

Chapitre IV
Analyse et Conception
Dans ce quatrième chapitre nous allons analyser les besoins que
nous avons cités dans la partie précédente, et les modéliser par la
suite.

Chapitre 4 : Analyse et Conception
4.1 Diagrammes des cas d’utilisation
Dans cette partie nous avons utilisé le langage de modélisation UML [10] pour
analyser les besoins que nous avons cité dans la partie précédente, et les modéliser
par la suite. La modélisation d’un système nous permet de mieux le comprendre, du
coup maitriser sa complexité pour assurer sa cohérence.
4.1.1 DIFFERENTS CAS D’UTILISATION
a. Cas d’utilisation « Gestion_ Utilisateurs » :
La figure 7 présente le diagramme des cas d’utilisation de la gestion des utilisateurs
Figure 7 : diagramme de cas d’utilisation d’un utilisateurs

b. Cas d’utilisation « Gestion_ Achat » :
La figure 8 présente le diagramme des cas d’utilisation de la gestion des achats
Figure 8 : diagramme de cas d’utilisation d’achat
c. Cas d’utilisation « Gestion_ Avoir_Client » :
La figure 9 présente le diagramme cas d’utilisation de la gestion des avoirs client
Figure 9 : diagramme de cas d’utilisation des avoirs client

d. Cas d’utilisation « Gestion_ Avoir_ Fournisseur » :
La figure 10 présente le diagramme des cas d’utilisation de la gestion des avoirs
fournisseur
Figure 10 : diagramme de cas d’utilisation des avoirs fournisseur
e. Cas d’utilisation « Gestion_ Des_ Charge » :
La figure 11 présente le diagramme des cas d’utilisation de la gestion des charges
Figure 10 : diagramme de cas d’utilisation des charges

f. Cas d’utilisation « Gestion_ Des_ Clients » :
La figure 11 présente le diagramme des cas d’utilisation de la gestion des clients
Figure 11 : diagramme de cas d’utilisation des clients

g. Cas d’utilisation « Gestion_ Des_ Dépôts » :
La figure 12 présente le diagramme des cas d’utilisation de la gestion des dépôts
Figure 12 : diagramme de cas d’utilisation des dépôts
h. Cas d’utilisation « Gestion_ Des_ Devis » :
La figure 13 présente le diagramme des cas d’utilisation de la gestion des devis
Figure 13 : diagramme de cas d’utilisation des devis

i. Cas d’utilisation « Gestion_ Des_ Factures » :
La figure 14 présente le diagramme des cas d’utilisation de la gestion des
factures
Figure 14 : diagramme de cas d’utilisation des factures
j. Cas d’utilisation « Gestion_ Des_ Fournisseurs » :
fournisseurs
Figure 15 : diagramme de cas d’utilisation des fournisseurs

k. Cas d’utilisation « Gestion_ Paiement_ Client » :
paiements client
Figure 16 : diagramme de cas d’utilisation des paiement client
l. Cas d’utilisation « Gestion_ Paiement_ Fournisseurs » :
paiements fournisseurs
Figure 17 : diagramme de cas d’utilisation des paiement fournisseur

m. Cas d’utilisation « Gestion_ Des_ Produits » :
produits
Figure 18 : diagramme de cas d’utilisation des produits
4.2 Diagrammes de classes
Le diagramme de classes (figure 19) montre la structure interne du
système. Il permet de fournir une présentation abstraite des objets du système, qui
vont interagir ensemble pour réaliser les cas d’utilisation. La figure 19 représente le
diagramme de classes que nous avons élaboré après une étude détaillée des
fonctionnalités du système.[10]

Figure 19 : diagramme de classe

Chapitre V
Réalisation
Ce chapitre est consacré à la description de la phase de mise en
œuvre de l’application. Nous y décrivons l’architecture de notre
application et nous illustrons certaines fonctionnalités assurées à
travers les interfaces.

Chapitre 5 : Réalisation
5.1 Architecture général de l’application
5.1.1 Architecture du back-end :
L’application est décomposée en couches applicatives, chaque couche a un
rôle prédéfini dans l’architecture globale.
Figure 20 : Architecture back-end
a. La couche beans (model)
Cette couche (figure 21) contient les entités, donc c'est une représentation des
informations liées spécifiquement au domaine de l'application. La partie Modèle
encapsule les données de l’application ; ces données sont en général définies et
traitées par des simples POJO (simple classe java).

Figure 21 : La couche beans
b. La couche Sécurité
Figure 22 : La couche sécurité
Cette couche (figure 22) a le rôle de gérer la sécurité cotée back end donc
générer et vérifier les Json Web Token. Elle possède donc deux filtres, le premier
s'exécute lors d’une authentification, donc il génère un JWT qui sera stocké dans le
navigateur, et le deuxième c'est un filtre d'autorisation qui s'exécute lors de la
demande d'une ressource, donc il valide la JWT qui se situe dans l'entête HTTP.
c. La couche Services
La couche service (figure 23) est une abstraction sur la logique de
l'application. En règle générale, les applications nécessitent plusieurs types
d'interfaces pour les données qu'elles stockent et la logique qu'elles implémentent :
interfaces utilisateur, passerelles d'intégration et autres. Malgré leurs objectifs

différents, ces interfaces ont souvent besoin d'interactions communes avec
l'application pour accéder et manipuler ses données et invoquer son logique métier.
La couche service remplit ce rôle.
Figure 23 : La couche service
d. La couche Dao
La couche DAO (figure 24) ou bien Data Access Object est un modèle
structurel qui nous permet d'isoler la couche métier de la couche de persistance
(généralement une base de données relationnelle, mais il pourrait s'agir de tout autre
mécanisme de persistance) à l'aide d'une API abstraite.
Figure 24 : La couche dao

e. La couche Controller
C’est la couche (figure 25) supérieure d'une application Web. Il est
responsable du traitement des entrées de l'utilisateur et du retour de la réponse
correcte à l'utilisateur. La couche Controller doit également gérer les exceptions
levées par les autres couches. La couche Controller étant le point d'entrée de notre
application, elle doit prendre en charge l'authentification et agir comme première
ligne de défense contre les utilisateurs non autorisés.
Figure 25 : La couche controller
5.1.2 Architecture du front-end [6]:
La figure 26 montre le traitement des requêtes qui passe par les séquences
suivantes :
• L’utilisateur commence par une action, elle se peut qu’il soit un affichage ou
un ajout des enregistrements à travers une vue Html.
• La vue appelle la fonction correspondante depuis la classe typescript.
• Dans le cas d’un ajout d’un enregistrement, la fonction échange les données
avec le modèle, afin de l’envoyer dans une requête au niveau du service, ce
dernier envoie une requête http au contrôleur du serveur.
• Dans le cas d’un affichage, la fonction envoie directement la requête au
service.

Figure 26 : Architecture du front-end
Le projet Angular contient des composants (figure 27), chacun a une vue
Component.html et une classe Component.ts.
Figure 27 : Architecture du projet

Chaque composant (figure 28) a son modèle correspondant qui fait échanger les
données avec le service
Figure 28 : Modèles des composants
Chaque service (figure 29) envoie des requêtes http vers le contrôleur du serveur via
l’API REST.
Figure 29 : Services des composants

5.1.3 Plan de site :
La Plan de site de notre application web finale côté client est la suivante :
5.2 Les interfaces de l’application
Pour accéder à la page d’accueil de l’application, l’utilisateur doit saisir son nom et
son mot de passe via l’interface d’authentification (fig.31). Il existe deux types
d’utilisateurs : Utilisateur et Administrateur.
Figure 31 : Interface d'authentification
Figure 30 : Le Plan de site

La figure ci-dessous montre un message d’erreur après avoir saisi un identifiant ou
un mot de passe incorrect.
Figure 32 : Interface d'authentification
1- Pour le cas de : Utilisateur
Après avoir être authentifié, la première interface qui s’affiche au début concerne la
page d’accueil qui représente des statistiques de l’ensemble des activités du
grosserie, plus précisément : le rapport des ventes, achats et des charges, le nombre
total des produits, les produits en rupture de stock, les clients de mois, deux
graphes : le premier représente les statistiques des 3 derniers mois, le deuxième est
un graphe en courbe représentant le profit dans les 6 derniers mois.

Figure 33 : interface Dashboard
♦Suite de la page d’accueil :
Figure 34 : suite interface dashboard

♦Rapport :
L’utilisateur peut consulter le rapport des ventes, des achats et des charges entre
deux dates qu’il va choisir. Le rapport des ventes contient le classement des produits
les plus vendus avec leurs montants totaux.
Figure 35 : interface Rapport
♦Achat du mois :
L’utilisateur peut consulter les statistiques des achats pour chaque mois pendant une
année. Il peut aussi choisir les mois à afficher.
Figure 36 : interface achat du mois

♦Vente du jour :
L’utilisateur peut consulter les statistiques des ventes pour chaque jour.
Figure 37 : interface vente du jour
♦Produits :
Consulter les produits qui sont dans le stock, avec la possibilité de chercher selon la
désignation du produit, ajouter un produit, le modifier ou aussi le supprimer.
Le prix d’achat moyen est calculé automatiquement et synchronisé selon la variation
du prix d’achat.
Figure 38 : Interface produits

♦Modifier un produit :
L’utilisateur peut modifier les informations d’un produit.
Figure 39 : Interface Modifier un produit
♦Supprimer un produit :
L’utilisateur peut supprimer un produit
Figure 40 : Interface Supprimer un produit

♦Alerte du stock :
Consulter les produits qui sont en rupture du stock (seuil < quantité) avec la
possibilité de chercher un produit selon sa désignation.
Figure 41 : Interface alert stock
♦Dépôt :
Consulter la liste des dépôts avec la possibilité de chercher un dépôt selon
son emplacement, ajouter un nouveau dépôt, modifier ses informations, le supprimer.
Figure 42 : Interface dépôt

♦Détails dépôt :
Consulter les produits d’un dépôt
Figure 43 : Interface pour consulter les produits d’un dépôt
♦Charges :
Consulter toutes les charges, chercher selon le libellé, ajouter une nouvelle
charge, la modifier et la supprimer
Figure 44 : Interface charges

♦Ajouter une facture :
Cette interface permet de saisir une facture. La saisie ne serait pas valide tant
que la quantité saisie pour un produit est supérieure à son niveau de stock.
Figure 45 : Interface Ajouter facture
♦Clients :
Consulter tous les clients, chercher un client selon son nom ou son prénom.
L’utilisateur peut ajouter un nouveau client, modifier ses informations, le supprimer,
consulter toutes ses factures et ses avoirs.
Figure 46 : Interface client

♦Factures d’un client :
Consulter l’historique des factures d’un client avec la possibilité de filtrer la
recherche des factures selon une date. L’utilisateur peut voir le crédit restant pour ce
client, consulter les factures non payées et faire un paiement.
Figure 47 : interface factures d'un client
♦Détail facture client :
Consulter les produits d’une facture, leurs prix, leurs quantités et le montant total.
Figure 48 : Interface detail facture client

♦Paiement facture client :
Consulter l’historique des paiements d’une facture qui a été payé en crédit.
L’utilisateur peut faire un paiement pour cette facture afin de payer le crédit restant.
Figure 49 : Interface paiement client
♦Paiement client
L’utilisateur peut payer la totalité du crédit restant pour une facture, ou juste
une partie du crédit.
Figure 50 : Interface verser client

♦Avoir client :
Consulter l’historique des avoirs d’un client. L’utilisateur peur chercher un
avoir selon un date, il peut aussi consulter les produits rendus.
Figure 51 : Interface historique avoir client
♦Nouveau avoir client
Cette interface permet de faire rendre un ou plusieurs produits qui sont déjà
présentés sur une facture.
Figure 52 : Interface nouveau avoir client

2- Pour le cas de : Administrateur
L’administrateur peut utiliser cette application de la même manière déjà citée pour
l’utilisateur et profiter de toutes les fonctionnalités. De plus, l’administrateur peut
gérer les rôles des utilisateurs et leurs activités.
Ces deux interfaces permettent à l’administrateur de consulter la liste des
utilisateurs et modifier leurs informations.
Figure 53 : Interface Utilisateurs
Figure 54: Interface pour modifier en mot de passe

L’administrateur peut gérer la traçabilité des factures, bons d’achat ainsi que les
charges en saisissant leurs numéros comme montre la figure 55 :
Figure 55 : Interface des charges
L’administrateur peut aussi ajouter de nouveaux utilisateurs. En remplissant le
formulaire suivant :
Figure 56 : Interface pour ajouter un utilisateur

5.3 La sécurité :
5.3.1 La Sécurité côté back-end
Le but c'est de rendre l'accès à l'API REST sécurisé d’une manière apatride, par
Spring security en utilisant Json Web Token.
Figure 57 : Authentication Spring Security avec JWT
Spring Security nous permet d'intégrer la notion de sécurité à notre
application, car l’accès à l’API REST est maintenant sécurisé d’une manière apatride
(stateless) par Spring Security en utilisant Json Web Token, donc après une
première authentification validée par le serveur, un jeton contenant un JWT
est envoyé est stocké dans le navigateur.
Les mots de passe sont encodés à travers la méthode encode de la classe
bCryptPasswordEncoder, il s’agit d’une fonction de hachage reposant sur
l’algorithme blowfish.
Basiquement, l'algorithme fonctionne ainsi : il génère un grain de sel aléatoire.
Un facteur coût a été préconfiguré. Générer le hash.
Le hash est la concaténation du cout, du grain de sel et du mot de passe
"encodé". Quand quelqu'un essaye de se connecter, on récupère son mot de passe

hashé pour savoir le grain de sel et le cout utilisé, et on génère un hash de la même
manière. Si le hash est identique, le mot de passe est bon, donc seul l’utilisateur peut
connaitre son mot de passe.
Figure 58 : Capture de la table User de la base de donnée
Chaque utilisateur de l'application a un rôle des deux, soit un utilisateur ou un
administrateur. Et avec ce rôle le serveur permet d’accepter ou bien interdire l’accès
à une page.
Figure 59 : Diagramme de la demande d'une ressource qui nécessite l'authentification
Lors d'une prochaine connexion, le client n'a pas besoin de ressaisir à
nouveau son nom d'utilisateur et mot de passe, le serveur juste valide la JWT dans le
header à travers un filtre qui décode la JWT et récupère ses informations, et si elle
est valable, les requêtes sont acceptées.

5.3.1 La Sécurité côté front-end
1- L’authentification :
L’utilisateur ou l’administrateur est demandé à s’authentifier, pour cela il faut saisir
le login et le mot de passe. Le serveur renvoie un jeton JWT après une
authentification réussite (JSON WEB TOKEN), ce jeton définit un mécanisme
compact et autonome pour la transmission de données entre les parties de manière
vérifiable et fiable.
Ce JWT contient des informations sur l’utilisateur authentifié, ses rôles ainsi que
sa durée d’expiration, qui constitue alors un bon choix pour la mise en œuvre de
mécanismes d’authentification sans état.
La figure ci-dessous représente le stockage local du navigateur d’un utilisateur
authentifié :
Figure 60 : Emplacement du jwt dans le stockage local
2- L’intercepteur HTTP :
Une fois le jeton JWT est obtenu, on peut faire appel à nos URL sécurisée en
envoyant le jeton avec notre requête.
Un intercepteur http vous permet d’intercepter les demandes sortantes HTTP afin
de pouvoir les modifier en ajoutant des en-têtes supplémentaires à toutes les
demandes sortantes.

Vous pouvez ajouter manuellement le jeton d’autorisation à toutes les requêtes,
mais cela demande beaucoup de travail, ou vous pouvez automatiquement
intercepter et ajouter l’en-tête avant d’envoyer la requête au serveur.
Figure 61 : interface intercepteur HTTP
3- Route Guards
Les « Guards » permettent de contrôler l’accès à une route, elles servent à
améliorer l’expérience utilisateur en évitant par exemple l’accès à des routes qui ne
fonctionnent pas car l’accès aux données serait rejeté par l’API.
On a configuré dans notre projet trois types de guard :
 Auth-Guard : Permets qu’aux utilisateurs authentifiés à accéder aux
ressources de l’application. Si un utilisateur non authentifié tente d’accéder à
une route, il sera redirigé vers l’interface d’authentification.
 Role-Guard : Permets aux administrateurs d’accéder et de gérer les
utilisateurs. Si un utilisateur authentifié tente d’accéder à ces ressources, il
sera redirigé vers l’interface d’accueil. Si un utilisateur non authentifié essaye
d’y accéder, il sera redirigé vers l’interface de login.
 Login-Guard : Son rôle est de contrôler l’accès à la page d’authentification. Si
un utilisateur est authentifié, il n’a pas le droit d’accéder à la page
d’authentification. S’il tente il sera redirigé vers la page d’accueil. Alors afin
qu’un utilisateur puisse accéder à la cette interface, il doit tout d’abord se
déconnecter.

4- La déconnection automatique :
Le jeton JWT est composé de plusieurs claims réservés, l’un de ses claims s’agit
de la date d’expiration du jeton. C’est grâce à cette date qu’on a pu implémenter la
déconnection automatique des utilisateurs lorsque le jeton expire, et alors rediriger
l’utilisateur vers l’interface d’authentification en lui redemandant ses identifiants.
5- La déconnection :
Si un utilisateur souhaite se déconnecter, il doit tout simplement cliquer sur le
bouton se déconnecter comme montre la figure ci-dessous :
Figure 62 : Interface pour la déconnexion
Si l’utilisateur se déconnecte, il sera redirigé à nouveau vers l’interface
d’authentification, et le stockage local du navigateur sera vide.

Figure 63 : Interface de stockage local d’un utilisateur déconnecter

Conclusion Générale
Le projet de fin d’année est une occasion et une vraie opportunité pour mettre
en pratique les connaissances théoriques et techniques acquises durant notre
formation à l’école, et c’est aussi une occasion pour pratiquer de nouvelles
technologies non vues lors de la formation.
Durant notre stage, nous avions comme mission mettre en place une solution
informatique pour la gestion du stock, des achats, des ventes, et des avoirs afin
d’optimiser et faciliter l’activité commerciale de l’entreprise.
Afin de réaliser le projet, nous avons commencé par spécifier les besoins
fonctionnels auprès du client, ensuite nous avons réalisé une conception pour
l’application en présentant les différents diagrammes UML. Enfin, nous avons mis en
place l’application demandée.
Ce projet de fin d’année, nous a permis de vivre une expérience
professionnelle très enrichissante en termes d’autonomie, et des connaissances
techniques. En effet, nous avons réussi à maîtriser une nouvelle technologie Angular
9, que nous n’avions pas eu l’occasion de l’apprendre à l’école. Ceci nous a permis
d’augmenter notre capacité d’auto-apprentissage. Le travail en équipe nous a permis
de surmonter quelques obstacles dus au problème du confinement que nous avons
vu pendant la réalisation du projet.
En perspective d’avenir, plusieurs réflexions ont été mené afin d’améliorer le
système, notamment : réaliser un système d’impression des factures et des bilans
financières, ajouter un lecteur de code-barres, et rajouter d’autres moyens de
paiements comme carte bancaire, chèque et Paypal.

Webographie et Bibliographie
♦ [1] Medium : consulté le 27 avril 2020
https://cutt.ly/kuGDyPs
♦ [2] Hellokoding : consulté le 05 mai 2020
https://cutt.ly/DuGSMzg
♦ [3] YouTube : consulté le 07 juin 2020
https://youtu.be/1BlJeu-Q4dk
♦ [4] Medium : consulté le 10 juin 2020
https://cutt.ly/nuGFdq9
♦ [5] Angular 9 : consulté le 31 mars 2020
https://cutt.ly/ZiqwuLD
♦ [6] Angular + API REST : consulté le 20 mai 2020
https://youtu.be/KJEJejxcnEQ
♦ [7] Elyaakoubi Mohamed, cours « Génie Logiciel », Ensa d’Agadir, 2020.
♦ [8] KAHAJI Abdelilah, cours « Gestion de projet », Ensa d’Agadir, 2020.
♦ [9] Youness Boukouchi, cours « J2e », Ensa d’Agadir, 2020.
♦ [10] CHAOUKI Brahim El Khalil et Brahim Erraha, cours « UML », Ensa
d’Agadir,2020.
♦ [11] Abdellaziz Walid , cours « JAVA », Ensa d’Agadir,2020.

Rapport du Projet de Fin d'année Génie informatique

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Rapport du Projet de Fin d'année Génie informatique

Similaire à Rapport du Projet de Fin d'année Génie informatique (20)

Rapport du Projet de Fin d'année Génie informatique