Rsum

Dans le cadre de ce projet on souhaite concevoir et dvelopper une plateforme e-commerce

dans le domaine dautomobile
Nous souhaitons dvelopper un site web qui constitue un service en ligne et gratuit, permettant
aux visiteurs (socits, agences ou particulier) de rechercher et/ou publier une annonce de
voiture vendre
Ce rapport dtaillera le droulement de projet de fin dtude, ainsi que la manire dont nous
dveloppons notre application web

Introduction gnral

Lvolution du secteur informatique durant les dernires annes a favoris lapparition des
nouvelles technologies web qui apportent une certaine facilit dans ladministration et la
gestion de contenu dun site web.
Cette volution prend part dans divers secteurs et impose son existence vu la simplicit des
applications facilitant la communication entre les gens et les socits surtout que la publication
et la disponibilit des informations joue un rle trs important dans lvolution de la qualit des
services.
Dans lesprit de ce qui prcde, notre projet sinscrit dans le cadre de dveloppement dune
application web tirant profit des nouvelles fonctionnalits et avantages quoffrent les
technologies web.
Dans le prsent rapport, organis en cinq chapitres, on commencera par introduire le contexte
gnral du projet, savoir l'organisme d'accueil ainsi que le contexte du projet.
Ensuite, on exposera l'tude pralable mene durant ce stage. Puis on enchanera par la
spcification des besoins de lapplication.
Au quatrime chapitre, on dtaillera l'tape de conception. Et pour terminer on dcrira les
tapes de ralisation, les outils utiliss ainsi que les rsultats obtenus travers quelques
interfaces de l'application.

Chapitre 1

Prsentation gnral

Dans le prsent chapitre, nous prsentons le cadre gnral du projet et la socit accueillante.

1.1 Cadre du projet :

Ce projet rentre dans le cadre de projet de fin dtudes lcole national
dingnieur Tunis (ENIT), en vue de lobtention du diplme dingnieur en
informatique. Le projet consiste concevoir et dvelopper une plateforme de e-commerce
dans le secteur de lautomobile.
Le projet sest droul au sein de la socit APP4MOB, durant la priode du
15 fvrier 2012 au 30 Mai 2012.

1.2 Prsentation de lorganisme daccueil :

1.2.1

Prsentation gnrale :

APP4MOB est une socit spcialise dans le dveloppement et le test

dapplications mobiles.
Elle a t fonde en 2010 par une quipe de professionnels expriments
dans la technologie mobile, et est actuellement installe dans la ppinire
du parc technologique des communications de la cit EL Ghazela. Cette
entreprise dveloppe les applications mobiles pour accrotre la productivit
afin de permettre ses clients daccder aux services essentiels, mme
sils sont loin de leurs ordinateurs. Les dveloppeurs des applications
mobiles rencontrent chaque jour une multitude de dfis en raison de la
diversit des plateformes mobiles.

1.2.2

Domaine dactivit principale : Applications mobiles

Le march mobile a connu une croissance explosive au cours des dernires

annes. Par consquent, il a contribu au dveloppement de lindustrie des
applications mobiles. APP4MOB est une SSI spcialise principalement dans
le dveloppement des applications mobiles. Elle fournit la pointe de ce
paysage hautement concurrentiel des applications mobiles intressantes,
touchant diffrents domaines et services. Cette entreprise aide ses clients
atteindre

en

un

minimum

de

temps

linformation

recherche

en

dveloppant des logiciels qui offrent beaucoup davantages des cots

raisonnables. APP4MOB dveloppe des solutions dapplications mobiles
pour les plateformes suivantes:
Androde
iPhone
BlackBerry
Windows Mobile

1.2.3

Application web : Nouveau domaine dactivit

Aujourdhui lInternet est plus que jamais prsent dans lactivit des
entreprises. Pour enrichir son march, APP4MOB a dcid dajouter ce
domaine bnfique et bien riche ses activits

1.3 Prsentation du projet :

1.3.1

Contexte du projet :

Le e-commerce est tout autour de nous, il l'est depuis des annes, mme
bien avant Internet. Dans les annes 60, les entreprises ont commenc
partager

des

fichiers

et

des

informations

entre

elles

de

manire

lectronique, cest la toute premire forme de e-commerce. Avec Internet,

les gens ont obtenu la possibilit d'acheter des biens et des services des
entreprises et entre eux, lectroniquement. Tout cela constitue le visage du
e-commerce aujourd'hui.
Le e-commerce d'entreprise entreprise est l'change et le transfert de
fichiers et d'argent entre les entreprises, et comme nous l'avons indiqu,
cela a commenc dans les annes 60. Cela a pris dans les annes 80,
cependant, quand un standard a t tabli pour les

transactions

lectroniques qui ont permis toutes les entreprises de se connecter de

cette manire.
Le e-commerce entre consommateurs est quand une personne va en ligne
et change des biens et des services avec une autre personne. eBay, par
exemple, est le site de consommateur consommateur original, avec ses
enchres dans lesquelles n'importe qui peut mettre des biens en vente pour
les visiteurs du site.
Le e-commerce Peer-to-Peer a dmarr avec Napster qui offrait des
tlchargements gratuits de musique via un systme de partage de
fichiers. Maintenant il y a beaucoup plus de sites et de programmes
informatiques qui oprent selon ce modle, o les utilisateurs partagent des
fichiers avec les autres.
Et bien entendu, le e-commerce d'entreprise consommateur est
simplement quand un consommateur achte des biens ou des services
une entreprise en ligne. Avec l'explosion de la popularit d'Internet ces

dernires annes, ce type de e-commerce est devenu une industrie qui

pse des milliards d'euros et qui va ne faire que grossir.
Le plus de le-commerce :
pour les clients :
Le e-commerce est un extraordinaire outil de pr-slection. En effet, les
clients peuvent voir des centaines d'articles en quelques "clics" et choisir
les meilleurs produits. Les produits peuvent tre compars plus
facilement, sans avoir se dplacer. Certains produits peuvent tre
achets uniquement sur internet. De plus, la pression soumise pas les
vendeurs aux clients a disparu et les informations ou caractristiques
sont expliques trs clairement.
L'un des gros avantages du e-commerce : l'offre est actualise trs
souvent. C'est--dire que les nouveaux produits, pas encore sortis en
magasin, sont disponibles l'achat sur quelques sites internet. Sur
certains sites (ebay.fr ; onatoo.com), la possibilit de enchrir certains
produits peut diminuer considrablement leur prix initiaux. En plus de
cela, les cots de transports (ou frais de port) sont souvent gratuits ou
trs faible prix.
Il y a aussi la recherche du meilleur prix grce la concurrence entre les Ecommerants. En effet, avec une concurrence de plus en plus importante
loffre augmentera ce qui contribuera une baisse des prix.
Et pour finir avec les avantages, grce internet, vous pouvez avoir des
caractristiques prcisent des produits ainsi que de nombreux avis
dinternautes qui ont dj achets ce produit
pour les entreprises
Le principal avantage du e-commerce pour les entreprises, c'est
l'augmentation de leur visibilit internationale. Cest--dire que les
entreprises verront leurs clientles s'tendre plusieurs pays. Ainsi, le e-

commerce agrandi le "portefeuille de clients" des entreprises. Et

contrairement aux enseignes physiques, les sites internet sont ouverts
24/24 et 7/7 et ils sont mme ouverts le dimanche.
Grce la facilit de navigation dans les sites, le panier moyen des
cyberacheteurs suprieur celui d'un simple acheteur.
Les entreprises peuvent mettre des catalogues jour tous les jours en
renouvelant la page daccueil, ce qui donnera aux clients une envie de
revenir. Le client peut aussi suivre en direct o en est sa commande, sa
livraison. De plus, avec le grand dveloppement d'internet, le e-commerce
augmente, donc les bnfices des entreprises augmentent aussi.

Objectifs du projet :
Le site Web VOITURES.TN constitue le lieu privilgi du commerce sur
Internet pour dvelopper le potentiel commercial des automobiles en ligne.
Prsenter un support nos clients plus pratique, plus ergonomique, plus
esthtique et plus fonctionnel.
La plateforme devra permettre :
Une recherche rapide des annonces (recherche par titre)
Une recherche avance des annonces (recherche par marque, modle, annes
dimmatriculation, kilomtrage, carburant, option)
Un affinement des recherches par tri (tri par date de dpt des annonces, tri par prix, tri
par distance).
Linscription, lauthentification, et la gestion du compte dun utilisateur.
Le dpt dune annonce (que lutilisateur ait un compte ou pas)
Les utilisateurs ayant un compte peuvent :
o grer leurs favoris,
o ajouter des annonces leurs favoris,
o grer leurs annonces publies,
o grer leurs profils,
o sabonner des alertes e-mails
de contacter le vendeur du vhicule dune annonce par e-mail,
de golocaliser le vhicule dune annonce par Google Maps,
partager une annonce sur les rseaux sociaux tels que Facebook, Twitter

1.3.2

Choix mthodologique :

Lors du dveloppement dun projet il est imprativement conseill de suivre

un processus et une mthode de conception afin daugmenter la
productivit, destimer le temps de dveloppement et de crer des
applications consistantes.
1.3.2.1

Les mthodes agiles

Une mthode agile est une approche itrative et incrmentale, qui est
mene dans un esprit collaboratif avec juste ce quil faut de formalisme.
Elle gnre un produit de haute qualit tout en prenant en compte
lvolution des besoins des clients.
Les mthodes agiles se caractrisent par :
Priorit des personnes et des interactions sur les procdures et les
outils
Priorit dapplications oprationnelles sur une documentation
exhaustive
Priorit de la collaboration avec le client sur la ngociation de contrat
Priorit de lacceptation du changement sur la planification
Les principes des mthodes agiles sont :
Dlivrer rapidement et trs frquemment des versions

oprationnelles, pour favoriser un feed-back client permanent.

Accueillir favorablement le changement
Assurer une coopration forte entre client et dveloppeurs
Garder un haut niveau de motivation
Le fonctionnement de lapplication est le premier indicateur du projet
Garder un rythme soutenable
Viser lexcellence technique et la simplicit
Se remettre en cause rgulirement.

1.3.2.2

Un comparatif des mthodes agiles

Au cours de ce paragraphe nous allons essayer de dgager les diffrences

entre quelques-unes des mthodes de dveloppement agiles les plus
connues, et ceci en fournissant un tableau comparatif de ces dernires. Le
tableau suivant, Tableau 1.1, compare sommairement les mthodes
courantes suivantes:
Extreme Programming (XP)
Rational Unified Process (RUP)
Feature Driven Development (FDD)
Scrum
Mthode

Points cls
Dveloppement guid
par
les besoins du client.
Equipes rduites,
entres
sur les dveloppeurs
par binmes.
Builds journaliers,
amlioration constante,
adaptabilit aux
modifications

Inconvnients
Focalisation sur laspect
individuel
du dveloppement, au
dtriment dune vue globale et
des pratiques de management
ou de formalisation.
Risque de manquer de contrle
et de structuration en laissant
les dveloppeurs trop libres de
driver par
rapport aux fonctions de
lapplication

RUP

Processus complet
assist par des outils
Rles bien dfinis.

Scrum

Petites quipes,
itrations de 30 jours,
runions journalires

FDD

Procd bien dfini et

Lourd, largement tendu, il

peut tre difficile mettre en
uvre de faon spcifique.
Convient pour les gros projets
qui gnrent beaucoup de
documentation
La mise en uvre du
dveloppement nest pas
prcise, seule compte la
gestion des ressources
humaines.
Centr uniquement sur le

XP

simple, orient objet et

bas sur le
dveloppement.
Itrations trs courtes.

1.3.2.3

dveloppement.

La mthodologie Scrum

Introduction la mthodologie Scrum

Scrum repose sur une thorie moderne du contrle des processus et permet
dlaborer de faon systmatique les meilleurs logiciels possibles partir
des ressources disponibles, un niveau de qualit acceptable et dans le
respect des dlais de livraison.
Le choix de la mthodologie Scrum
Notre choix de la mthodologie Scrum sest bas sur la faon avec laquelle
nous dveloppons un produit, en effet, une quipe Scrum dveloppe un
produit de la manire suivante:
Les fonctionnalits souhaites sont collectes dans le backlog de produit
et classes par priorit, linitiative du Product Owner (propritaire du
produit), le reprsentant des clients et utilisateurs dans lquipe.
Le dveloppement du produit est rythm par une srie ditrations, dun
mois ou moins, qui sont appeles des sprints. Le contenu dun sprint est
dfini par lquipe, en tenant compte des priorits et de sa capacit. A
partir de ce contenu, lquipe identifie les tches ncessaires et sengage
pour raliser les fonctionnalits slectionnes pour le sprint.

 Pendant un sprint, des points de contrle sur le droulement des tches

sont effectus quotidiennement. Cela permet didentifier les obstacles qui
ralentissent lquipe que le ScrumMaster, animateur de lquipe et garant
du suivi de Scrum, a pour responsabilit dliminer.
Cette inspection quotidienne permet de dterminer lavancement par
rapport aux engagements et dappliquer, en quipe, des ajustements pour
assurer le succs du sprint.
A la fin de chaque sprint, lquipe prsente ce quelle a ajout au produit
pendant le sprint. Cet incrment du produit est potentiellement livrable ;
son valuation permet dajuster le backlog pour le sprint suivant.
La figure 1 dcrit davantage le droulement de la production dun produit
avec la mthodologie Scrum.

Figure 1.1 - Description de Scrum

tant donn que notre application peut avoir des nouveaux besoins et des
fonctionnalits imprvues chaque moment du dveloppement, nous
allons adopter la mthode Scrum comme mthodologie de conception.
Concernant le formalisme adopter, nous avons choisi le standard
industriel de modlisation objet UML (Unified Modeling Language).

Conclusion

Ce chapitre constitue une partie introductive dans laquelle une prsentation

des grandes lignes du sujet a t tablie. Nous avons prsent le cadre
gnral du travail, lorganisme daccueil, le contexte, la problmatique
voque et lobjectif qui consiste concevoir et dvelopper une plateforme
de commerce lectronique (e-commerce) dans le secteur automobile en
Tunisie. Compte tenu de cela, une spcification des besoins fonctionnels et
non fonctionnels ainsi que les solutions existantes sont ncessaire pour la
comprhension du sujet, et feront lobjet du chapitre suivant.

Chapitre 2

Analyse

Introduction

Avant dentamer le dveloppement de notre projet, il est ncessaire de bien

tudier les besoins remplir par lapplication. Dans ce chapitre, nous
exposons une tude de lexistant, ensuite nous abordons la spcification
des besoins fonctionnels et non fonctionnels afin de dgager le diagramme
de cas dutilisation gnral.

2.1 Etude de lexistant

Une tude approfondie des plateformes existantes permet de dgager les
dtails du sujet et danalyser les besoins et les spcifications ncessaires. A
lattention de cette partie, nous effectuons une description et une analyse
de quelques plateformes de vente et achat en Tunisie et dans dautres
pays.

2.1.1

Le commerce lectronique en Tunisie (secteur voiture)

Depuis certaines annes, plusieurs sites web ont t dvelopps pour la

recherche et la vente de divers produits via internet. Les sites les plus
visits et les plus connus en Tunisie, faisant le service pour les voitures sont
:
Http : //www.tunisie-annonce.com : Ce site permet de publier, chercher
divers produits, y inclut le secteur auto/moto. Les critres de choix pour les
voitures sont : pays, gouvernorat, dlgation, localit, rubrique, marque,
modle, code annonce, prix, ge du vhicule et lnergie comme il est
illustr par la figure 2.1.

Figure 2.2 - La recherche de vhicules via le site Annonce Tunisie

La publication dannonce ne se fait que si lutilisateur possde un compte

comme le montre la figure 2.2.

Figure 2.3 - Publication dannonce pour le site Annonce Tunisie

http://www.tunisie-autos.com : Pour ce site les seuls critres de recherche

sont la marque et le modle. Comme il est dmontr par la figure 2.3, le
site www.tunisie-autos.com est membre du rseau www.tunisieannonce.com, prcdemment cit. La publication dannonce ne se fait
quaprs une inscription auprs de ce dernier.

Figure 2.4 - Publication dannonce pour le site Tunisie Auto

Le contenu site est essentiellement ax sur la prsentation des annonces
voitures postules par les utilisateurs inscrit au www.tunisie-annonce.com .
Au niveau dIHM en remarque que les couleurs choisies rendent le site
moins attractif.

Figure 2.5 - dtail dannonce dans le site Tunisie Auto

Le tableau suivant dgage les points forts et les points faibles des sites
tunisiens existant de point du vue technique et design
Aspect technique
Points forts

Aspect design
Prsentation simple

Points

Absence de module de recherche

Utilisation de police lisible

Les pages ne sont pas misent

faibles

dtaill.

en valeur (trs petit)

Absence despace pour les clients.

La page daccueil est presque

Pas de possibilit de postuler une

vide

annonce sans avoir faire une

Non cohrent entre les

inscription

couleurs des pages.

pauvre de point de vue

informations sur lannonce.

http://www.automobile.fr est le site spcialis dans les annonces auto/moto.

Il sappuie sur les annonces que lon peut trouver sur eBay. Cest quasiment
le meilleur site des annonces automobiles, il se base sur une recherche
multi critres, comme le montre la figure 2.5, la recherche peut seffectuer
selon des critres gnraux comme la marque, la catgorie, la boite

vitesse... et dtaills comme le couleur de l'intrieur, la climatisation, le

nombre de places, comme le montre la figure 2.6

Figure 2.6 - recherche dannonce dans le site Automobile.fr

Figure 2.7 - plus de critre de recherche dannonce dans le site Automobile.fr

2.2 Critique de lexistant

Depuis ltude qualitative des sites tunisiens, prsentes par les diffrentes
figures au-dessus, ces sites permettent la chercher des vhicules via un
formulaire trs rduit, et aucune deux ne permet la recherche avec des
critres bien prcises. En effet, ces sites ne permettent que la recherche
travers quelques critres de voiture (marque, modle, couleur, carburant).
Elles ne permettent pas deffectuer une recherche selon votre emplacement
ou de faire une recherche en prcisant dautres critres qui sont, un degr
variable, influant sur le choix du client. De plus lajout dune nouvelle
annonce exige la cration dun compte.
Ces fonctionnalits ne sont pas suffisantes pour les exigences des
internautes maintenant, il savre plus intressant davoir la possibilit de
publier une annonce sans avoir besoin de sinscrire ou de sengager, il est
encore plus intressant dajouter plus de critres de recherche de la
voiture.

2.3 Solution envisage

Dans le but de rpondre aux besoins mentionns prcdemment, nous

proposons travers ce projet une solution web destine la fois ceux qui
veulent acheter une voiture, aux propritaires des voitures vendre et aux
professionnels dans le commerce des automobiles.
Ce site web doit fournir plusieurs services (publication des annonces,
gestion des annonces favorites, systme d'alerte par email, gestion des
recherches...).
L'inscription sur le portail est simple, il suffit de remplir un formulaire dans
lequel on met les diffrentes coordonnes de l'utilisateur et les informations
ncessaires l'authentification. L'utilisateur doit avoir un abonnement sur le
site pour jouir des services d'un gestionnaire. Aprs l'activation de son
compte, le client se trouve en face aux services que propose notre solution.
Il peut publier ainsi son annonce et effectuer des recherches simples ou
avances pour trouver les offres idales pour lui.
On dcrira dans les paragraphes qui suivront deux interfaces ; on
commencera par l'interface de l'espace client et laccueil ensuite on
enchanera par celle du l'administrateur.
Dans le cas dclient, il a la possibilit de publier des annonces pour vendre
sa voiture et de faire la gestion de ses annonces (modification,
suppression).
Le portail offre aussi pour le client la possibilit de faire des recherches des
annonces. Cette recherche est multicritre (type de vhicule, rgion,
marque, options...). Dans le cas o il trouve une offre publie par une
entreprise ou une autre personne qui correspond ses besoins, il envoie
une rponse sur cette annonce en indiquant comment on peut le contacte
sil nest pas dj connect.

Le propritaire de lannonce peut aussi recevoir des rponses sur ses

annonces publies dans le portail. Il consulte ces rponses, et confirme si
l'offre lui plat et ignore des autres. S'il est engag avec un quelqu'un, il
peut contacter ce dernier partir des emails.

Conclusion
Cette partie a permis de prciser le cadre dans lequel se situe ce projet,
ainsi que de prsenter ses objectifs viss. En plus, nous avons eu l'occasion
d'tudier des concepts qui seront utiliss dans le cadre du projet. Enfin,
nous avons prsent une tude de l'existant pour pouvoir cibler les points
importants de l'application. Dans ce que suive, nous allons spcifier les
besoins fonctionnels et non fonctionnels de notre application. Nous
dtaillerons ensuite quelques cas d'utilisation que nous avons pu dgager.

2.4 Analyse et spcifications des besoins

Dans tout systme, les fonctionnalits doivent tre mises en relation avec
un ensemble de besoins utilisateurs. Ces besoins dfinissent les fonctions
que les utilisateurs s'attendent voir par le systme. La spcification des
besoins forme les fondations sur lesquelles l'architecture du systme est
construite.
Aprs ltude de lexistant et lidentification de la solution adopter et la
technologie adquate pour laborer notre site internet de vente et achat de
voiture, nous allons mettre en vidence les diffrents acteurs qui sont en
interaction avec cette plateforme, ainsi que la spcification besoins fin de
dgager, le diagramme gnral de cas dutilisation de notre plateforme.
Lanalyse de ce sujet nous a permis didentifier les divers besoins auxquels
doit rpondre notre application. Ces besoins dgags sont classs en deux
catgories savoir les besoins fonctionnels et les besoins non fonctionnels.

2.4.1

Besoins fonctionnels :

B1 Publier une annonce gratuitement : Le systme doit permettre un

utilisateur non inscrit de publier une annonce gratuite, il est amen
remplir les informations de la voiture, et ses informations personnelles pour
pouvoir le contacter.
B2 Publier une annonce : Le systme doit permettre un utilisateur
connect de publier une annonce, il est ramen remplir les informations
de la voiture, sans avoir besoins ici de saisir ses informations personnelles
car il est dj inscrit.
B3 Rechercher des annonces :
- Le systme doit permettre lutilisateur deffectuer une recherche selon
les critres dune voiture.
- Le systme doit offrir un affinement des recherches par tri (tri par date de
dpt des annonces, tri par prix, tri par distance).
- Le systme doit permettre lutilisateur de consulter une annonce
trouve, de go localiser le vhicule dune annonce par Google Maps, et de
contacter son annonceur.
B4 Partager une annonce : Le systme doit permettre un utilisateur de
partager une annonce sur un rseau social.
B5 Grer ses annonces : Le systme doit permettre un utilisateur
inscrit de grer ses annonces dj publies. Il peut modifier une annonce, la
supprimer, ou la prolonger.
B6 Grer ses favoris : Le systme doit permettre un utilisateur inscrit
de grer ses favoris. Il peut soit ajouter une annonce ses favoris soit la
supprime.
B7 Grer ses alertes e- mail : Le systme doit permettre la possibilit de
sabonner des alertes e-mails. Il peut les modifier ou les supprimer.

2.4.2

Besoins non fonctionnels :

Une fois les besoins fonctionnels sont bien dfinis, les besoins non
fonctionnels doivent tre pris en compte tout au long du processus de
dveloppement de la plateforme savoir :
Ergonomie et convivialit : la plateforme doit fournir aux diffrents
utilisateurs une interface conviviale.
Interaction avec les utilisateurs : linteraction avec lutilisateur est
fortement recommande afin de fournir ce dernier la bonne information
au meilleur instant.
Champs obligatoires : Si le champ est obligatoire, il faut qu'il soit prcd
d'un flag au niveau du label du champ, ex : *.Si un champ obligatoire n'est
pas renseign, il faut prvenir l'utilisateur et positionner un indicateur sur le
ou les champs qu'il doit absolument remplir ou changer.
Maintenabilit et volutivit : le code de la plateforme doit tre lisible et
comprhensible pour pouvoir le maintenir facilement et rapidement. En
outre, le systme doit tre volutif afin de rpondre aux changements des
besoins du march.

2.5 Modlisation des besoins :

La modlisation au niveau de ltape de spcification est base sur les
diagrammes de cas dutilisation. Ces diagrammes permettent de structurer
les besoins des utilisateurs et les objectifs du systme tout en identifiant
ses utilisateurs et leurs interactions.

2.5.1

Les acteurs du systme :

Lacteur principal qui interagit avec notre plateforme est linternaute. Un

tunisien, ayant un accs Internet, peut accder au site web automobile.tn
pour bnficier des fonctionnalits offertes mme sans avoir un compte. Un
utilisateur connect, a en plus des privilges qui lui permettent

dajouter/supprimer des annonces ses favoris les comparer, de consulter

ses annonces dj publies, les modifier, et les supprimer. Il peut
galement modifier son profil. Do nous dgageons deux acteurs
principaux, dont le second hrite des fonctionnalits du premier. Ces deux
acteurs sont :

Utilisateur non inscrit : Cet utilisateur peut publier une annonce gratuite,
sans avoir besoin de crer un compte. En outre, aprs avoir saisir les
diffrents critres de choix, il peut effectuer une recherche. Une fois quil
trouve une annonce, il peut la partager il peut contacter son vendeur et le
golocaliser. En plus, cet utilisateur peut bnficier de plus de
fonctionnalits en sinscrivant.

Utilisateur inscrit : une fois inscrit et connect, un utilisateur peut publier

des annonces et les grer, il peut aussi grer ses favoris, et diter son
profil. Comme il a la possibilit de crer une alerte sur une recherche pour
que le systme lui envoie les annonces convenables aux critres exigs.
De plus, il peut grer les rponses et les messages envoys par les autres
utilisateurs. On a deux types dabonnements un particulier et lautre
professionnel. Un professionnel a laccs plus doption dans la publication
dune annonce et les informations personnelles.
En plus de ces deux acteurs principaux notre systme possde un acteur
secondaire cet acteur est l'administrateur du site :

Ladministrateur peut vrifier les informations de lannonce et du compte

soumises par lutilisateur, activer les annonces et les comptes, met jour
les annonces et le site y compris les rebiques, les fonctionnalits, supprimer
les annonces indsirable

2.5.2

Description de cas dutilisation gnral:

Dans le diagramme du cas dutilisation gnral nous regroupons tous les

cas dutilisation de base afin davoir une vue globale du fonctionnement de

notre systme et afin de mettre en vidence les ventuels relations qui

peuvent les relier.
La figure 2.13 illustre le cas dutilisation gnral de lapplication. Ce
diagramme dcrit les grandes fonctionnalits de systme de point de vue
des acteurs, mais nexpose pas de faon dtaille le dialogue entre les
acteurs et les cas dutilisation. Dans le chapitre suivant nous dtaillerons
quelques cas dutilisations.

Figure 2.8 - Diagramme de cas dutilisation gnral

Conclusion :
Lanalyse et lnumration des besoins fonctionnels et non fonctionnels ont
t un moyen pour mieux assimiler les diffrentes difficults rsoudre
travers lapplication. Nous pouvons maintenant passer la deuxime tape
du processus de dveloppement qui est la conception qui fera lobjet du
prochain chapitre.

Chapitre 3

Conception

Introduction
Le prsent chapitre sera consacr la prsentation de l'tape de
conception de notre systme. La conception est un processus cratif qui
permet de dcrire la manire non ambigu du fonctionnement dsir du
systme afin d'en faciliter la ralisation et la maintenance. Pour ce faire,
nous prsentons dans une premire partie une conception gnrale de
notre application ensuite dans la deuxime partie nous dtaillons la
conception de l'application et de la base de donnes utilise.

3.1 Conception gnrale

Notre projet se base essentiellement sur deux grandes parties. La premire
partie touche au systme interne de l'application qui comprend la
construction du schma de la base de donnes gnrique. La deuxime
dcrit l'interface interactive de l'application qui permet l'utilisateur de
spcifier ses donnes et valider ses choix. Nous justifions, dans le
paragraphe suivant, le choix de l'architecture du systme.

3.1.1

Conception architecturale

L'architecture de l'application est une architecture trois-tiers base sur le modle MVC.

3.1.1.1

Larchitecture trois-tiers

L'architecture trois-tiers est un modle logique d'architecture applicative

qui vise sparer trs nettement trois couches logicielles au sein d'une
mme application ou systme, modliser et prsenter cette application
comme un empilement de trois couches, tages, niveaux ou strates dont le
rle est clairement dfini [N5] :
- la prsentation des donnes : Elle correspond la partie de l'application
visible et interactive avec les utilisateurs. On parle d'Interface Homme
Machine. En informatique, elle peut tre ralise par une application graphique ou
textuelle. Elle peut aussi tre reprsente en HTML pour tre exploite par un navigateur web
ou en WML pour tre utilise par un tlphone portable.
- le traitement mtier des donnes : Elle correspond la partie fonctionnelle
de l'application, celle qui implmente la logique , et qui dcrit les
oprations que l'application opre sur les donnes en fonction des requtes
des utilisateurs, effectues au travers de la couche prsentation. Les
diffrentes rgles de gestion et de contrle du systme sont mises en
uvre dans cette couche.
- laccs aux donnes persistantes : Elle consiste en la partie grant l'accs
aux gisements de donnes du systme. Ces donnes peuvent tre propres
au systme, ou gres par un autre systme. La couche mtier n'a pas
s'adapter ces deux cas, ils sont transparents pour elle, et elle accde aux
donnes de manire uniforme (couplage faible).
Dans cette approche, les couches communiquent entre elles au travers d'un
modle d'change , et chacune d'entre elles propose un ensemble de
services rendus. Les services d'une couche sont mis disposition de la
couche suprieure. On s'interdit par consquent qu'une couche invoque les
services d'une couche plus basse que la couche immdiatement infrieure
ou plus haute que la couche immdiatement suprieure (chaque niveau ne
communique qu'avec ses voisins immdiats).

Le rle de chacune des couches et leur interface de communication tant

bien dfinis, les fonctionnalits de chacune d'entre elles peuvent voluer
sans induire de changement dans les autres couches. Cependant, une
nouvelle fonctionnalit de l'application peut avoir des rpercussions dans
plusieurs d'entre elles. Il est donc essentiel de dfinir un modle d'change
assez souple, pour permettre une maintenance aise de l'application.
La figure suivante illustre les trois niveaux de l'architecture.

Figure 3.9 - Architecture trois-tiers

Le modle MVC
Un Modele-Vue-Contrleur (MVC) est une architecture qui organise
l'interface Homme-Machine, les traitements et les donnes d'une
application logicielle. [N6]
- La vue correspond l'interface avec laquelle l'utilisateur interagit. Sa
premire tche est de prsenter les rsultats renvoys par le modle. Sa
seconde tche est de recevoir toutes les actions de l'utilisateur (clic de
souris, slection d'une entre, boutons, etc.). Ces diffrents vnements
sont envoys au contrleur. La vue n'effectue aucun traitement, elle se
contente d'afficher les rsultats des traitements effectus par le modle et
d'interagir avec l'utilisateur.

- Le Modle reprsente le comportement de l'application : traitements des

donnes, interactions avec la base de donnes, etc. Il dcrit ou contient les
donnes manipules par l'application. Il assure la gestion de ces donnes et
garantit leur intgrit. Dans le cas typique d'une base de donnes, c'est le
modle qui la contient. Le modle offre des mthodes pour mettre jour
ces donnes (insertion, suppression, changement de valeur). Il offre aussi
des mthodes pour rcuprer ces donnes. Les rsultats renvoys par le
modle sont dnus de toute prsentation.
- Le contrleur Le contrleur prend en charge la gestion des vnements de
synchronisation pour mettre jour la vue ou le modle et les synchroniser.
Il reoit tous les vnements de l'utilisateur et enclenche les actions
effectuer. Si une action ncessite un changement des donnes, le
contrleur demande la modification des donnes au modle, ce dernier
avertit la vue que les donnes ont t chang pour qu'elle se mette jour.
Certains vnements de l'utilisateur ne concernent pas les donnes mais la
vue. Dans ce cas, le contrleur demande la vue de se modifier.
Le contrleur n'effectue aucun traitement, ne modifie aucune donne. Il
analyse la requte du client et se contente d'appeler le modle adquat et
de renvoyer la vue correspondant la demande.

Figure 3.10 - L'interaction entre le modle, la vue et le contrleur

Comme l'indique la figure ci-dessus, le contrleur d'aprs les vnements
reus par l'utilisateur (touches appuyes...) d'envoyer la vue
correspondante (a). Il effectue la synchronisation entre le modle et la vue.
Il contrle la modification des donnes du modle (b).

1.2. Architecture retenue

Notre systme offre une interface interactive l'utilisateur lui permettant
de spcifier ses paramtres appropris la base de donnes de la bourse.
Notre application est gnrique et doit satisfaire aux diffrents schmas des
bases relationnelles utilises pour dcrire chaque annonce. Afin de faciliter
cet aspect gnrique, nous appliquons l'architecture MVC.
Elle sert bien organiser le systme en permettant :
- Une sparation des interfaces, des contrles des vnements de
l'utilisateur et des traitements de donnes.
- Une synchronisation des diffrentes vues (interfaces) possibles de
l'application.

- Une interprtation plus claire des entres.

- Une isolation des donnes (BD, fichiers).

3.2 Conception dtaille

Dans cette partie, nous prsentons la conception dtaille de la plateforme.
Nous allons commencer par quelques diagrammes de cas dutilisation et de
squence qu'on on a jug ncessaires qui nous sont utiles pour dtailler nos
dcisions conceptuelles pour le diagramme de classes.

3.2.1

Etude dtaille des cas dutilisation

Pour permettre une bonne comprhension des cas dutilisation, nous allons
illustrer les divers scnarios mettant en jeu lchange des messages entre
les diffrentes classes du systme par des diagrammes de squence qui
dcrivent ces interactions.
3.2.1.1

Authentification

La figure 3.3 situe ci-dessous illustre le cas dune authentification par un

utilisateur. Lchec dauthentification peut avoir lieu dans trois cas savoir :
ladresse e-mail est non valide, cest -dire ne respecte pas lexpression
rgulire dune adresse e-mail, ou un chec de connexion parviendra au
moment dauthentification ou bien aprs vrification avec la base de
donnes il se trouve que ladresse e-mail et/ou le mot de passe soient
errons.

Figure 3.11 - Diagramme de squence dauthentification

L'oprateur "Alt" dsigne un choix, une alternative. Il reprsente deux

comportements possibles : c'est en quelque sorte l'quivalent du
SI...ALORS...SINON : donc, une seule des deux branches sera ralise dans
un scnario donn. La condition d'excution d'une des deux branches
(l'quivalent du SI) peut tre explicite ou implicite. L'utilisation de
l'oprateur else permet d'indiquer que la branche est excute si la
condition du Alt est fausse. [N4]
L'exemple ci-dessus montre un oprateur "Alt" :
soit il y a un chec d'identification

 soit il y a un chec d'identification puis il passe la procdure de

rcupration de mot de passe,
soit l'identification russit et l'utilisateur est redirig vers son profil.
L'oprateur "rf" rfrence un autre diagramme de squence (c'est un
appel de fonction). Nous dtaillons par la suite le scnario de rcupration
du mot de passe oubli . Dans ce cas, l'utilisateur est appel saisir son
mail, aprs vrification que cet email existe dans la base, les paramtres
nom d'utilisateur et mot de passe seront renvoys directement depuis le
serveur vers sa voite email.

Figure 3.12 - Diagramme de squence pour le scnario rcupration mot de passe

3.2.1.2

Inscription

Afin de respecter le design pattern MVC, un contrleur de systme se

charge de valider les informations

saisies par lutilisateur, En effet, si

l'internaute soumettait une adresse email invalide ou si le mot de passe

tait vide ? Dans ce cas, nous afficherons des messages d'erreurs l'invitant
corriger sa saisie. Si les le formulaire est valide le contrleur interroge la
base de pour vrifier lexistence de cet email et enfin il affiche le rsultat
sur la page.

Figure 3.13 - Diagramme de squence dinscription

3.2.1.3

Gestion du profil :

Un utilisateur, aprs avoir authentifi, a la possibilit de changer ses

informations personnelles, telles que sa localit et son numro de
tlphone... Laffichage de profile pour un professionnel est plus riche que
pour un utilisateur particulier.

Figure 3.14 - Diagramme de cas dutilisation de gestion du profil

3.2.1.4

Publication dune annonce :

La publication dune annonce comme il est indiqu dans le diagramme cidessus

se

fait

de

deux

manires

soit

gratuitement

soit

aprs

authentification. Dans le cas o elle est gratuite, lutilisateur devra saisir

quelques champs de plus tels que son numro de tlphone, son adresse email et ventuellement son adresse. Le scnario dune publication gratuite
ou non est dcrit par la figure suivante.

3.2.1.5

Recherche dannonces :

La recherche dannonce peut seffectuer selon plusieurs critres de choix et

par diffrents moyens de visualisation. En effet, lutilisateur trouve, sur la
page daccueil, les 10 dernires annonces affiches alatoirement.
De plus la recherche peut seffectuer par mot cl, cest--dire la plateforme
serait mene par un simple moteur de recherche qui va offrir la possibilit
de chercher les annonces qui contiennent le mot saisie par lutilisateur.
La recherche peut seffectuer aussi par choix de critres du vhicule dsir,
cest--dire la marque le modle le prix ...etc. Dans le cas o lutilisateur a

trouv les annonces qui correspondent sa recherche, il peut les trier soit
par prix soit par kilomtrage soit par date dimmatriculation. galement
linternaute peut affiner sa recherche grce au formulaire se trouvant
gauche.

En choisissant une annonce, il aura aussi la possibilit de

contacter le vendeur, de le go-localiser, connaitre le raison social si celui-ci

est un professionnel, partager lannonce sur Facebook et Twitter et lajouter
ces favoris sil est inscrit.
La recherche peut se faire aussi selon plusieurs critres tels que la marque,
le modle, le kilomtrage, la rgion ou des critres de performance ainsi
que les quipements de confort. La figure 3.7 illustre ce scnario.

Figure 3.15 - Diagramme de squence de recherche dannonces selon les critres

3.2.1.6

Gestion dannonces

Aprs lauthentification, un utilisateur peut consulter ses annonces sur une

liste, il aura la possibilit de les trier par prix, par date ou par kilomtrage. Il
peut aussi modifier ou supprimer une annonce. Lorsquil accde une
annonce, il peut partager son annonce sur Facebook et sil est un
professionnel, il peut voir le nombre de visiteurs qui ont visualis son

annonce, activer laffichage de son logo et/ou le fond de couleur lors de la

publication des annonces.

Figure 3.16 - Diagramme de cas dutilisation de gestion dannonces

3.2.1.7

Ajout d'une alerte

Le client, aprs avoir s'authentifi et valid son compte, peut lancer de

nouvelles alerte dans la plateforme. En effet il choisit quelles sont les
critres dsir (marque, modle, les options) grce un formulaire
dtaill et l'enregistre. Cette alerte sera excute chaque jour, si on trouve
une(s) annonce(s) un email sera envoy automatiquement.

Figure 3.17 - Diagramme de squence dajout dune alerte

3.2.2

Diagrammes de navigation

Dans ce qui suit nous allons rsumer les diffrentes fonctionnalits offertes
par

notre

plateforme

avec

des

schmas

de

navigations.

Comme

lapplication donne des services pour deux acteurs diffrents (utilisateur

ayant un compte et utilisateur sans compte) deux schmas de navigation
peuvent tre dgags.

3.2.2.1

Schma de navigation pour un simple visiteur

Le diagramme ci-dessous illustre la navigation dans lapplication ds son

dmarrage pour un utilisateur non authentifi.

Figure 3.18 - Diagramme de navigation pour un utilisateur non inscrit

3.2.2.2

Schma de navigation pour un utilisateur inscrit

Lutilisateur inscrit bnfice de toutes les fonctionnalits offertes pour un

utilisateur non inscrit.

Figure 3.19 - Diagramme de navigation pour un utilisateur inscrit

3.2.3

Diagramme de classes

La modlisation statique permet didentifier, daffiner et de complter les

diffrentes classes relatives notre application. Elle consiste rechercher
les relations entre les classes et les complter par leurs attributs
spcifiques. Le diagramme de classes est le point central dans un
dveloppement orient objet

Figure 3.20 - Digramme de classes

On expliquera encore plus quelques classes et leurs rles ainsi que leurs
associations les uns avec autres.
annonce_voiture : cest la classe principale pour notre application,
elle contient toutes les informations concernant le vhicule vendre.
marque : cette classe contient toutes les marques des vhicules
existantes et elle est associe par agrgation la classe Model
puisque chaque marque contient un certain nombre de modles.
Notons ici que ces deux classes sont gres par ladministrateur, cest
pourquoi ces deux entits sont mise de hors la classe principale
annonce_voiture.

 model : correspond aux diffrents modles. Chaque modle est

associ une marque.
catgorie : correspond aux diffrents types des voitures.
photos : cette classe sert stocker les URLs des photos dune
annonce.
User : cest la classe qui contient toutes les informations dun
annonceur aprs inscription. Parmi les attributs les plus importants de
cette classe la longitude et la latitude de lutilisateur, qui vont nous
servir par la suite pour connatre la position exacte du vendeur dont
le cas o lon veut golocaliser lannonce.
alerte : elle permet denregistrer les alertes faite par user. Cette
classe est rserve aux clients inscrits.
user_professionnel : elle hrite de la classe user et elle contienne
en plus des informations de contact, le logo du vendeur et les
prfrences daffichage de la publication.
rgion : cette classe sert prciser la localisation de lannonce, elle
est utile pour la recherche dannonces par rgion.
annonce_favorite : cest une classe dassociation, elle correspond
aux annonces voitures que prfre lutilisateur.
En se rfrant aux associations publier et prfr nous pouvons
dgager les assertions suivantes :
Un utilisateur inscrit peut ajouter des annonces ses favoris dans le
but de comparer celles-ci ou pour les voir ultrieurement, do
lapparition dune nouvelle classe intitule annonce_favorit qui stocke
les annonces prfres par un utilisateur. Par ailleurs si une annonce
a t supprime elle ne sera plus accessible dans les favoris des
utilisateurs, donc il faut faire une suppression en cascade.
Un utilisateur inscrit peut grer ses annonces (suppression et
modification).

Conclusion

Tout au long de ce chapitre, nous avons dtaill la conception de notre

application travers les diffrents diagrammes de classes, de cas
dutilisation et de squences ainsi que les schmas de navigation afin que
a soit le plus souple et le plus ais pour ltape suivante ; la ralisation et
la mise en place de lapplication. Le chapitre suivant mettra en vidence, le
fruit de ce passage et les diffrents rsultats du dveloppement de
lapplication demande.

Chapitre 4

Ralisation

Ce chapitre a pour objectif d'achever le travail, c'est la dernire tape du

processus de dveloppement. Cette tape concerne les technologies
choisies pour mener terme ce projet. Nous commenons, tout d'abord, par
prsenter l'environnement matriel et logiciel ainsi que le choix de
technologies. Ensuite, nous prsentons le travail accompli tout au long de la
priode du stage. Enfin, nous illustrons le chronogramme de la ralisation
de ce projet.