CHAPITRE 1 : CONTEXTE GÉNÉRAL DU PROJET
1.1 INTRODUCTION :
Pour définir le contexte de notre projet, nous introduisons
l’environnement, lieu où se déroulera notre stage, le cadre général et
les méthodologies à suivre pour réaliser ce travail. D’abord, nous
présentons l’objectif et le cadre général du projet. Ensuite, on
s’intéresse à une étape fondamentale :
La spécification des besoins fonctionnels et non fonctionnels
puisqu’elle représente l’origine de toute activité de développement.
Pour garantir la réussite de cette étape ; on doit :
* Nous réalisons une étude comparative de l’existant.
*Nous modélisons les principales fonctionnalités de notre
application.
*Nous définissons les besoins et les rôles.
1.2 Présentation de l’organisme d’accueil :
À ce stade, nous présentons l’organisme d’accueil et on se focalise
sur les différents domaines d’activité de la société et de partenaires.
1|Page
1.2.1 Présentation générale :
IoTech-Tunisie est une société de services en ingénierie informatique (SSII)
fondée en juillet 2018. L’entreprise a réussi à se positionner progressivement
dans le monde IT grâce à son ingénierie logicielle et développement web...
Aujourd’hui, IoTech déploie et développe des projets et des services en Tunisie
et en France à forte valeur ajoutée, conformes aux standards de 18 qualités et
aux exigences du marché international. Pour ses activités à l’international,
IoTech offre ses services en mode offshore pour le compte de ses clients et
partenaires.
Logo IoTech_Tunisie.
1.2.2 Technologies maîtrisées :
IoTech-Tunisie maitrise les meilleures technologies pour faire
décoller des applications professionnelles. IoTech-Tunisie utilise les
dernières tendances en matière de développement logiciel pour
garantir des services à la hauteur.
* Développement PostgresSQL.
2|Page
* Développement ANGULAR 11.
*Développement Nest js.
* Développement Nginx.
* Développement Docker.
1.3 Présentation du projet :
Notre mission dans ce stage est de développer une application d’une
solution d’administration de gestion des véhicules, stock,
financements, ventes, CRM, partenaire, statistiques et utilisateurs
pour un site e-commerce d’un mandataire automobile. Nous
proposons alors comme projet de fin des études, le développement
des deux modules très importants et dépendant l’un de l’autre: le
module de gestion des clients, et le module de gestion des avis.
1.4 Étude de l’existant :
L’étude de l’existant a pour objectif d’analyser et de préciser les
critiques des solutions existantes, et aussi présente une phase
essentielle permettant d’avoir une idée sur ses différentes solutions.
1.4.1 Description de l’existant :
Sur l'e-commerce français, l'automobile reste sous-représentée dans l'e-
commerce. Néanmoins, on ne peut plus nier le rôle prépondérant du
Web dans l'achat d'un nouveau véhicule. L'enquête Cars Online 2010 de
CAP Gemini Consulting révèle en effet que 47 % des Français utilisent
Internet pour trouver des informations sur le prix ou le concessionnaire à
choisir, 32 % pour accéder à une gamme complète d'informations sur les
produits, 21 % pour comparer des voitures, 17 % pour trouver des
conseils, ou encore 14 % pour configurer ou visualiser le véhicule choisi
en 3D.
3|Page
On peut citer comme exemples : Auto-ies, Auto123, Auto
Montpellier, CitroenStore et Rachat Cash.
1.4.2 Critique de l’existant :
L’étude de l’existant nous a permis de déceler les points suivants :
*Analyse de la solution Auto_ies :
Figure de auto-ies
Avantage(s) :
+Les titres et les informations sur les véhicules sont clairs et
biens détaillés.
+Il met en considération la satisfaction de leur client.
+vous pouvez créer votre propre compte.
Inconvénient(s) :
-ce site contient un faible nombre de marque (16 marques).
*Analyse de la solution Auto123 :
4|Page
Figure d’auto123
Avantage(s) :
+ Ce site contient un nombre acceptable de marque (plus que
80 marques) => le client à des choix.
+Il met en considération la satisfaction de leur client.
Inconvénient(s) :
-Une charge d’écriture et des images, design non organisé.
*Analyse de la solution Auto Montpellier :
Figure d’Am
Inconvénient(s) :
5|Page
-Vous ne pouvez pas créer votre propre compte d’où vous ne
pouvez pas Bénéficiez d'offres personnalisées.
- L'organisation de l'interface est non amiable lors d’un
déménagement d’un titre à un autre.
*Analyse de la solution Citroën Store :
Figure de Citroën
Avantage(s) :
+Ils se sont concentre sur une seul marque alors là il présente
leur véhicule en détail par des descriptions biens rédigés et
des images claire.
Inconvénient(s) :
-Il ne contient pas une zone pour qu’un client partage leur
avis.
*Analyse de la solution Rachat Cash:
6|Page
Figure de rachat cash
Avantage(s) :
+pas d’arnaques.
+Planification des rendez-vous avec des spécialistes pour
expertisera votre véhicule.
Inconvénient(s) :
- Il ne contient pas une zone pour qu’un client partage leur
avis.
-il y’a pas des images descriptive de chaque marque.
1.4.3 Solution adoptée :
En tenant compte des critiques déjà citées en se basant sur les
contraintes de nos clients, la solution est de concevoir et développer
une nouvelle application permettant de satisfaire au maximum les
besoins des utilisateurs. Nous proposons ainsi une plateforme de
gestion de client, et d’avis qui s’articule sur les points suivants pour
surmonter les défaillances existantes :
* Retrouvez tous vos devis et estimations de reprise en un seul endroit
7|Page
* Bénéficiez d'offres personnalisées
* Profitez des nouveautés en avant-première.
* Suivez vos commandes et gagnez du temps
1.5 Analyse des besoins :
Dans cette section on a identifié l’ensemble des besoins fonctionnels
et non fonctionnels nécessaires à la mise en place de cette application :
1.5.1 Besoins fonctionnels :
Le besoin le plus important de ce projet est de développer deux
modules intéressants appartenant l’un de l’autre :
* GESTION DE CLIENT (crud d’un client) :
Ajout d’un client :
Un formulaire permet d’ajouter un client à la base des données.
Filtre d’un client :
Ce cas ‘’Filtrer’’ facilite l’opération de recherche d’un client
spécifique.
Mise à jour d’un client :
Mise à jour des donnes d’un client.
8|Page
Suppressions d’un client :
Appliquer la suppression d’un client.
Affichage d’un client :
Un formulaire permet d’afficher un client à la base des données.
* GESTION DES AVIS (rédiger un avis selon chaque
commande passée, crud d’un avis) :
Ajout d’un avis:
Chaque client peut donner un avis sur une commande.
Recherche d’un avis :
Un filtre de recherche selon les critères souhaités par
l’administrateur.
Mise à jour d’un avis :
Liste des avis des clients, avec les actions de suppression et
modification.
Suppressions d’un avis :
Appliquer la suppression d’un avis.
Statistique des avis :
Les avis seront ensuite interprétés pour faire des statistiques.
9|Page
1.5.2 Besoins non fonctionnels :
Les spécifications non fonctionnelles décrivent les contraintes
auxquelles est soumis le système pour sa réalisation et son bon
fonctionnement :
Performance : L’application doit faire face à un très grand nombre
de requêtes et doit également avoir un temps de réponse rapide.
Fiabilité : L’application doit assurer l’échange des données et n’en
perdre aucun détail.
Configuration : La configuration du logiciel ne doit présenter
aucune difficulté pour un simple utilisateur non expert.
Sécurité : L’application devra assurer la sécurité des utilisateurs.
D’où la nécessité de procéder à l’authentification d’administrateur,
de comptable et des agents de facturation tout en assurant la
confidentialité de leurs données.
Extensibilité : C’est-à-dire qu’il doit y avoir une possibilité d’ajouter
de nouvelles fonctionnalités ou de modifier celles existantes.
Les erreurs : l’application doit les signaler par des messages clairs
et compréhensibles.
Disponibilité : Le système doit toujours être opérationnel.
1.6 Diagramme de cas d’utilisation globale :
10 | P a g e
1.6.1 Cas d’utilisation globale :
Le diagramme de cas d’utilisation représente les actions réalisées par
le système, pour avoir un résultat qui répond au besoin d’un acteur
particulier. Je vais présenter ici les diagrammes de cas d’utilisation de
chaque partie.
Diagramme de cas d’utilisation ‘«Authentification et gestion des clients’
11 | P a g e
1.6.2 Description textuelle :
Pour mieux comprendre le diagramme des cas d’utilisation, les
concepteurs d’UML proposent une technique qui sert à décrire le
comportement du système informatique appelé « la description
textuelle ». De ce fait, nous allons présenter les descriptions
textuelles du cas d’utilisation "S’authentifier" via le tableau ci-
dessous :
Cas d’utilisation S’authentifier
Acteurs Administrateur
Pré conditions L’administrateur doit être inscrit
1. L’administrateur demande la page
d’authentification.
2. Le système affiche le formulaire
d’authentification.
Scénario nominal 3. L’administrateur saisit ses identifiants puis
valides.
4. Le système vérifie les données saisies et affiche
l’interface réservée à l’administrateur.
Scénario alternatif Si le nom d’administrateur et/ou le mot de passe ne
sont pas correctes, l’enchaînement reprend à l’étape
3.
Post conditions Administrateur authentifié
Description textuelle : «S’authentifier»
12 | P a g e
Cas d’utilisation Ajouter client
Acteurs Administrateur
Pré conditions L’administrateur doit être authentifié.
1. Le système affiche une interface pour l’ajout d’un
client.
2. L’administrateur clique sur le bouton ‘Ajouter
client’ et remplir le formulaire "Client" puis le valide.
Scénario nominal 3. Le système affiche alors un message de validation
et la nouvelle liste des clients.
Scénario alternatif Si les champs obligatoires sont vides, une alerte
d’erreur s’affiche au-dessous.
Post conditions Client ajouté avec succès.
Description textuelle : «Ajouter client»
Cas d’utilisation Modifier client
Acteurs Administrateur
Pré conditions L’administrateur doit être authentifié.
1. Le système affiche la table des clients enregistrés.
2. L’administrateur sélectionne le client à modifier.
3. L’administrateur clique sur l’icône de modification
4. Le système affiche un formulaire pour la
Scénario nominal modification d’un client, l’administrateur le remplir
puis le valide.
5. Le système avertit l’administrateur par un
message de confirmation.
6. Si l’administrateur valide la mise à jour, les
données du client seront modifiées de la liste des
clients.
Scénario alternatif Si les champs obligatoires sont vides, une alerte
d’erreur s’affiche au-dessous.
Post conditions Client modifié avec succès.
Description textuelle : «Modifier client» 13 | P a g e
Cas d’utilisation Supprimer client
Acteurs Administrateur
Pré conditions L’administrateur doit être authentifié.
1. Le système affiche la table des clients enregistrés.
2. L’administrateur sélectionne un client à
supprimer.
3. L’administrateur clique sur l’icône de
Scénario nominal suppression.
4. Le système avertit l’administrateur par un
message de confirmation.
5. Si l’administrateur valide la suppression, le client
sera effacé de la liste des clients, sinon la
suppression sera annulée
Post conditions Client supprimé avec succès.
Description textuelle : «Supprimer client»
Cas d’utilisation Consulter client
Acteurs Administrateur
Pré conditions L’administrateur doit être authentifié.
1. Le système affiche au-dessus de l’interface de
client une zone de ‘filtre’
2. L’administrateur clique sur le bouton ‘Filtrer’ puis
il remplir les champs nécessaires pour faire une
Scénario nominal recherche rapide d’un client spécifique
4. Le système affiche les résultats
automatiquement dans le tableau de client s’il
existe.
Post conditions Une recherche rapide d’un client
Description textuelle : «Consulter client»
14 | P a g e
Conclusion :
Dans ce chapitre, nous avons présenté notre entreprise d'accueil,
dans la partie qui suit nous allons étudier et analyser nos besoins, en
spécifiant l’étude et la critique de l’existant, présentant notre projet
et distinguant nos besoins fonctionnels et non fonctionnels qui ont
permis de mieux expliciter le système à réaliser.
Dans le chapitre suivant, nous entameront l’étude conceptuelle.
15 | P a g e