Modèle de rapport PFE

1. Chapitre I : Cadre Général du
Projet
A cours de ce chapitre, nous allons étudier le cadre générale du projet. Cette
étude comprend la présentation de l’entreprise dans laquelle s’est déroulé le
stage ainsi qu’une petite présentation du projet.

2. Chapitre I : Cadre Général du Projet
Titre projet Page 2
Introduction
Au cours de ce premier chapitre, nous allons étudier le cadre générale du projet.
Dans un premier temps, une brève présentation de l’organisme d’accueil sera effectuée. Et
dans un second temps, nous décrivons le contexte du projet proposé ainsi que la
problématique et le travail demandé.
I- Présentation de l’organisme d’accueil
Media Plus imagine et construit
des sites web fonctionnels et attractifs
aux dernières technologies tels que le
responsive. Avec un effectif formé d’un
groupe solide et dynamique de
professionnel de l’infographie, du web
design et du développement web, l’agence Media Plus vous propose des services variés tel
que :
 WEB DESIGN :
- La création d’un graphisme en adéquation avec votre identité visuelle actuelle
- Flash, Photoshop, Illustrator
 INTEGRARTION WEB :
- La programmation de votre site avec HTML5, CSS3, JavaScript, jQuery
- L’hébergement de votre site en toute sécurité
 COMMUNICATION PAPIER :
- Catalogue produits, magazine, Menu de restaurant ou de café, Couverture de livre
- Dépliant publicitaire, Flyers, affiches publicitaires
- Brochure publicitaire, carte de visite, papier à entête, Modèle de facture...
 IDENTITE VISUELLE – CHARTE GRAPHIQUE :
- Création de logo, conception habillage, Enseigne
- Plaquette, Porte Document, Enveloppe
- Création ou refonte d’identité visuelle.
 WEB MOBILE :
- Android, IPhone OS, Windows mobile
 NOUVELLE ACTIVITE :
- Impression Numérique laser

3. Chapitre I : Cadre Général du Projet
Titre projet Page 3
Nous avons fait le compromis de vous satisfaire et de créer l’image la plus excitante
et attrayante de votre entreprise et de vous fournir les solutions informatiques les plus
adaptées à vos besoins pour vous aider à atteindre vos objectifs.
Que vous soyez un particulier ou une petite ou grande entreprise, nous vous invitons
à entendre notre manière de penser, nous proposons nos produits et solutions, collaborons
avec vous pour mener à bien vos projets.
Nous demeurons à votre entière disposition pour toute précision.
Dans l’attente de vous lire, nous vous prions d’agréer, chers partenaires, nos
salutations les plus sincères.
II- Présentation du projet
Présenter votre projet en quelques lignes.
Exemple :
L’évolution de la technologie de l’information et de la communication a contribué au
développement des systèmes d’information et de gestion au sein des entreprises. En effet
l’intégration de l’outil informatique dans le domaine de l’entreprise est devenue une
nécessité dont l’enjeu est déterminant face au processus d’amélioration des qualités de
service et des conditions de travail.
Le sujet de notre projet de fin d’études consiste à développer …
L'objectif de ce stage est de concevoir et développer …
III- Travail demandé
Présenter le travail demandé (les principales fonctionnalités à implémenter dans votre
application)
Conclusion
C’est ainsi que nous sommes parvenus à définir le cadre général de ce stage et le
contexte large du projet à réaliser. Le prochain chapitre aura pour objectif la présentation
des solutions existantes, les insuffisances qu’elles apportent ainsi que la solution future.

4. Chapitre II : Etude de
l’existant
Ce chapitre représente une étude bien déterminée de l’existant, ses critiques
et ses orientations futures favorables.

5. Chapitre II : Etude de l’existant
Titre projet Page 2
Introduction
L’étape de l’étude de l’existant est une étape primordiale dans la réalisation de tout
projet informatique. Cette étape préalable fera l’objet de ce chapitre et permettra de décrire
le système existant, de dégager les insuffisances de l’état actuel et de proposer les
orientations de la solution future. Il est indispensable si c’est possible avant de se lancer
dans la réalisation de tout projet, de bien étudier et analyser des projets similaires s’il existe
pour profiter des avantages et éviter les malveillances dans le présent projet.
I- Description de l’existant
Si l’application à développer est pour un système non informatisé qui n’existe pas
déjà donc à décrire les fonctionnalités qui existe manuellement, ou à travers des
manipulations des fichiers Excel ou autres…
Si le système possède déjà une application mais qui contient des trous et des
insuffisances alors décrire ce qui existe en mettant en relief les points positifs et en citant
aussi les points négatives pour y remédier.
S’il existe des applications pareilles dans le même domaine alors décrivez les
applications existantes, leurs fonctionnalités, les avantages pour pouvoir les critiquer par la
suite. Vous pouvez mettre des imprimes écrans des applications qui existent et les décrire
selon leur contenus.
II- Critique de l’existant
III- Orientation de la solution future
Conclusion
En se basant sur la critique de l’existant, nous allons déterminer les différentes
améliorations qui permettent de garantir le bon fonctionnement et la bonne gestion de
notre application. Après avoir mis le sujet dans son cadre théorique, il est temps d’identifier
les différents besoins afin de recenser la liste des fonctionnalités qui doivent être présentes

6. Chapitre III : Analyse &
spécification des besoins
Ce chapitre représente une vision approximative de la finalité du projet qui
consiste à comprendre le contexte du système à réaliser en recensant à la fois
les besoins fonctionnels et les besoins non fonctionnels. Et nous présentons la
conception de notre projet avec les diagrammes de cas d’utilisations.

7. Chapitre III : Analyse & spécification des besoins
Titre projet Page 2
Introduction
L’analyse, étant considérée comme une première ébauche du modèle de conception,
joue un rôle capital pour la démarche ergonomique. Cette analyse s’intéresse aux besoins et
aux attentes des utilisateurs en général. Il s’agit de modéliser les éléments et les
mécanismes principaux du nouveau système, ainsi que de livrer des spécifications pour
permettre de choisir la conception de la solution.
Une méthode d'analyse et de conception a pour objectif de permettre de formaliser
les étapes préliminaires du développement d'un système afin de rendre ce développement
plus fidèle aux besoins du client.
Ce modèle d’analyse permet d’avoir une spécification complète des besoins issus des
cas d’utilisation et les structures sous une forme (diagrammes d’activités, séquences, états
transitions, …etc.) qui facilite la compréhension, la préparation (définition de l’architecture),
la modification et la maintenance du système.
I- Langage et méthodologie utilisés
Modéliser un système avant sa réalisation permet de mieux comprendre le
fonctionnement du système. C’est également un bon moyen de maitriser sa complexité et
d’assurer sa cohérence. Un modèle est en effet un langage commun, précis, qui est connu
par tous les membres d’une équipe et il est donc un vecteur privilégié pour communiquer.
Dans le domaine de l’ingénierie du logiciel, ce modèle permet de mieux répartir les
tâches et d’automatiser certaines d’entre elles. C’est également un facteur de réduction des
coûts et des délais. Ce modèle est enfin indispensable pour assurer un bon niveau de qualité
et une maintenance efficace car, une fois mise en production, l’application va devoir être
maintenue, probablement par une autre équipe et pas nécessairement la même ayant créée
l’application.
Un processus de développement définit une séquence d’étapes, en partie ordonnée,
qui concoure à l’obtention d’un système logiciel ou à l’évolution d’un système existant pour
produire des logiciels de qualité, qui répondent aux besoins des utilisateurs dans des temps
et des coûts prévisibles.
1) Méthodologie de conception
Plusieurs méthodologie de conception et à vous de chercher quelle méthodologie adoptée.
Exemple de choix de méthodologie de conception : Processus Unifié (UP)
Les méthodes de développement dites « méthodes agiles » visent à réduire le cycle
de vie du logiciel (donc accélérer son développement) en développant une version minimale,
puis en intégrant les fonctionnalités par un processus itératif basé sur une écoute client et
des tests tout au long du cycle de développement. On peut citer parmi les méthodes agiles

8. Chapitre III : Analyse & spécification des besoins
Titre projet Page 3
l’UP (Unified Process) qui est en mesure de répondre directement ou indirectement à
diverse problématiques notamment financières ou temporelles.
Le processus unifié (UP) est un processus de développement logiciel « itératif et
incrémental, centré sur l’architecture, conduit par les cas d’utilisation et piloté par les
risques » :
 Itératif et incrémental : Le projet est découpé en itérations de courte durée (environ
un mois et demi) qui aident à mieux suivre l’avancement global. À la fin de chaque
itération, une partie exécutable du système final est produite de façon incrémentale.
 Centré sur l’architecture : Tout système complexe doit être décomposé en parties
modulaires afin de garantir une maintenance et une évolution facile. Cette
architecture (fonctionnelle, logique, matérielle, … etc.) doit être modélisée en UML et
pas seulement documentée en texte.
 Conduit par les cas d’utilisation : Le projet est mené en tenant compte des besoins et
des exigences des utilisateurs. Les cas d’utilisation du futur système sont identifiés,
décrits avec précision et priorisés.
 Piloté par les risques : Les risques majeurs du projet doivent être identifiés au plus
tôt, mais surtout levés le plus rapidement possible. Les mesures à prendre dans ce
cadre déterminent l’ordre des itérations.
Le processus que nous avons utilisé pour le développement de notre système,
comme c’est présenté dans la
figure ci-contre, est:
 Itératif et conduit par les
cas d’utilisation, comme
UP mais beaucoup plus
simple ;
 Relativement léger et
restreint, comme les
méthodes agiles, mais sans
négliger les activités de
modélisation en analyse et
conception ;
 Fondé sur l’utilisation des
diagrammes du langage
UML 2.0 (Unified Modeling
Language), conformément
à la modélisation agile
(Agile Modeling).

9. Chapitre III : Analyse & spécification des besoins
Titre projet Page 4
2) Langage de conception
UML (Unified Modeling Language) est un langage de modélisation graphique apparu
dans le monde du génie logiciel dans le cadre de la conception orientée objet. C’est
l’accomplissement de la fusion de précédents langages de modélisation objet : Booch, OMT,
OOSE. UML est à présent un standard défini par l’OMG (Object Management Group). La
dernière version diffusée par l’OMG est la 2.4.1 depuis août 2011 *4+.
UML est utilisé pour spécifier, visualiser, modifier et construire les documents
nécessaires au bon développement d'un logiciel orienté objet. UML offre un standard de
modélisation, pour représenter l'architecture logicielle. Les différents éléments
représentables sont :
 Activité d'un objet/logiciel,
 Acteurs,
 Processus,
 Schéma de base de données,
 Composants logiciels,
 Réutilisation de composants.
Grâce aux outils de modélisation UML, il est également possible de générer
automatiquement une partie de code, par exemple Java, à partir des divers documents
réalisés.
UML 2.0 propose 14 types de diagrammes et comme n’étant pas une méthode, leur
utilisation est laissée à l’appréciation de chacun et la nature du projet. Par exemple, les
diagrammes utilisés pour un projet d’application mobile diffèrent de ceux utilisés pour un
site web.

10. Chapitre III : Analyse & spécification des besoins
Titre projet Page 5
II- Spécification des besoins
1) Les besoins fonctionnels
Dans cette section du chapitre, nous nous intéressons aux besoins des utilisateurs
traités dans notre projet c’est à dire l’inscription du client, le choix des produits, le
lancement des commandes enfin la confirmation et donc le payement en ligne à travers les
spécifications fonctionnelles et non fonctionnelles pour aboutir à un site de qualité qui
répond aux besoins des clients.
Selon le cahier de charge, les besoins changent d’un projet à un autre. Vous allez citer
dans cette partie les besoins fonctionnels de votre application.
Exemple :
Les besoins fonctionnels se présentent en huit grandes parties :
 Exposition des produits ainsi que leurs prix et caractéristiques.
 Inscription des clients.
 Ajout des produits choisis au panier.
 Choix du mode de livraison.
 Choix de la boutique de livraison.
 Confirmation de la commande.
 Le payement en ligne.
 Confirmation de l’opération d’achat et la réception de la facture.
a) L’EXPOSITION DES PRODUITS:
Notre site doit disposer d’une vitrine virtuelle à travers laquelle le client peut
consulter une grande variété des produits, il sera donc indispensable d’y présenter les prix et
les caractéristiques techniques de chaque produit pour faciliter la sélection du produit à
acheter.
b) L’INSCRIPTION DU CLIENT :
Jusqu’à ce stade, le client est toujours anonyme mais pour pouvoir passer à un stade
plus rigoureux, il faut qu’il s’inscrive, ce la se fait uniquement pour la première commande
mais après, notre client peut s’authentifier avec son E-mail et son mot de passe pour passer
d’autres commandes.
c) AJOUT DES PRODUITS AU PANIER :
Après le choix d’un produit le client doit mentionner la quantité qui s’ajoute
automatiquement à son panier avec le prix unitaire et le prix total.

11. Chapitre III : Analyse & spécification des besoins
Titre projet Page 6
d) MODE DE LIVRAISON :
Un client qui a déjà confirmé sa commande il est libre de choisir le mode de livraison
de sa marchandise soit à domicile ou chez une boutique selon une liste de chois mentionnée
sur notre site web.
e) BOUTIQUE DE LIVRAISON:
Si le mode de livraison choisi est la boutique il faut que le client indique cette
boutique avec une précision qui permet aux livreurs d’être sûrs que la marchandise sera
dans le bon lieu et dans les rendez-vous, ayant une panoplie de boutiques réelles, le client
pourra choisir la plus proche.
f) LA LIVRAISON A DOMICILE :
En choisissant cette option comme mode de livraison, le client devrait remplir
soigneusement un formulaire contenant les informations nécessaires telles que :
 Le nom du destinataire qui peut être le client même ou une autre personne.
 L’adresse précise de livraison.
 Le numéro de la pièce d’identité du destinataire.
 Le jour et l’heure de la livraison estimés.
g) LA CONFIRMATION DE LA COMMANDE :
Jusqu’à cette phase on a un client, une commande et une adresse de livraison le
chemin maintenant est plus clair, la commande ne passera qu’après la validation de toutes
les informations qui sont affichées dans une seule interface avant de passer à la phase de
payement.
h) LE PAYEMENT :
C’est une phase très sensible, pour cela il faut qu’elle soit très sécurisée, pour
terminer la procédure de payement avec succès le client doit choisir un mode de paiement
proposées sur notre site web (paiement par cheque, paiement contre remboursement,
paiement espèce, paiement chez la boutique…).
i) LA FIN DE L’OPERATION D’ACHAT:
La page finale représente un petit message de remerciement à nos clients avec une
idée sur l’adresse, la date, le temps de la livraison en question et bien sur la possibilité
d’imprimer la facture du client.

12. Chapitre III : Analyse & spécification des besoins
Titre projet Page 7
Il faut détailler les autres fonctionnalités, ce n’est qu’un exemple pour vous faire
comprendre quoi mettre.
2) Les besoins non fonctionnels
Les besoins non fonctionnels sont importants car ils agissent de façon indirecte sur le
résultat et sur le rendement de l’utilisateur, ce qui fait qu’ils ne doivent pas être négligés,
pour cela il faut répondre aux exigences suivantes :
 Fiabilité: L’application doit fonctionner de façon cohérente sans erreurs et doit être
satisfaisante.
 Les erreurs : Les ambigüités doivent être signalées par des messages d’erreurs bien
organisés pour bien guider l’utilisateur et le familiariser avec notre application.
 Ergonomie et bonne Interface : L’application doit être adaptée à l’utilisateur sans
qu’il ne fournisse aucun effort (utilisation claire et facile) de point de vue navigation
entre les différents modules, couleurs et mise en textes utilisés.
 Sécurité : Notre solution doit respecter surtout la confidentialité des données
personnelles des clients qui reste l’une des contraintes les plus importantes dans les
sites web.
 Aptitude à la maintenance et la réutilisation : Le système doit être conforme à une
architecture standard et claire permettant sa maintenance et sa réutilisation.
 Compatibilité et portabilité : Un site web quel que soit son domaine, son éditeur et
son langage de programmation ne peut être fiable qu’avec une compatibilité avec
tout les navigateurs web et tous les moyens que ce soit PC, IPAD ou Mobiles.
III- Identifications des acteurs
Définir les acteurs selon votre projet. Décrire chaque acteur à part et citer les
fonctionnalités de chacun si vous voulez dans un tableau.
Exemple :
Le visiteur : c’est un individu qui est entrain de fouiller sur le net, cherchant un
produit pour l’acheter ou pour avoir une idée sur les modèles et les prix. Jusqu’au ce stade
c’est un utilisateur inconnu donc il n’est pas encore un client.
Le Client : cette acteur est un visiteur ayant déjà créer un compte sur notre site, il
peut donc suivre le processus d’achat des produits en toute sécurité sachant que notre
système doit être l’unique responsable de la confidentialité des données personnelles de ses
clients.

13. Chapitre III : Analyse & spécification des besoins
Titre projet Page 8
L’administrateur : pour les sites web on l’appelle généralement « le webmaster ».
C’est celui qui assure le dynamisme du site et veille sur les mises à jour des produits, de leurs
prix, de leurs disponibilités, de la gestion des payements et la gestion des livraisons.
IV-Diagrammes de cas d’utilisation
Les cas d’utilisation sont très utiles en phase de recherche de besoin. L’approche
consiste à regarder le système à construire de l’extérieure, du point de vue de l’utilisateur et
des fonctionnalités afin de déterminer ses besoins fonctionnels c'est-à-dire ce qu’il attend du
système.
1) Diagramme de cas d’utilisation global
Mettre le diagramme de cas d’utilisation global de votre système.
Figure : Diagramme cas d’utilisation global
2) Diagramme de cas d’utilisation Détaillé
Vous aller détailler les différents cas d’utilisation de votre système à mettre en
œuvre.

14. Chapitre III : Analyse & spécification des besoins
Titre projet Page 9
Mettre en relief surtout les fonctionnalités primordiales (Mettre le diagramme de cas
d’utilisation, écrire un petit paragraphe descriptif et mettre un tableau détaillant les
scénarios.)
a) Description scénario cas d’utilisation « Authentification »
Pour que l’utilisateur puisse bénéficier de n’importe quel service de l’application, il
doit avant tout s’authentifier avec son login et son mot de passe.
Figure : Diagramme de cas d’utilisation « Authentification »
Patron textuel du cas d’utilisation « Authentification»
Sommaire d’authentification
Nom : S’authentifier
Résumé :
Le système vérifie l’identité de l’utilisateur en utilisant son
pseudo et son mot de passe.
Acteur : Citer les acteurs …
Pré-condition L’utilisateur doit être inscrit : possède un compte.
Description du scénario : 1) L’utilisateur introduit son login et son mot de passe.
2) L’utilisateur confirme son identification
3) Le système vérifie les informations fournit par
l’utilisateur
4) Le système autorise ou refuse l’accès à l’application
Exception : Affichage d’un message d’erreur dans le cas ou le mot de

15. Chapitre III : Analyse & spécification des besoins
Titre projet Page 10
passe ou le pseudo est incorrect ou invalide
Post-condition : Utilisateur authentifié
b) Description scénario cas d’utilisation « Gestion Discipline »
Exemple de cas d’utilisation détaillé de la gestion des disciplines.
Figure : Diagramme de cas d’utilisation « Gestion Discipline »
c) Description scénario cas d’utilisation « Gestion Compte »
L’administrateur est le responsable de la gestion des comptes, il peut :
 Créer un nouveau compte : la création se fait après avoir fournir les données
nécessaires (nom, prénom, tél, email, adresse, login et mot de passe…)
 Consulter un compte : la consultation se fait à travers certains critères spécifiques
pour chaque compte. L’utilisateur peut déjà consulter les paramètres de son compte.
 Supprimer un compte : après la consultation des données relatives à un compte,
l’administrateur peut les supprimer.
 Modifier les paramètres d’un compte : cette fonctionnalité consiste à modifier les
données du paramètres compte et les remplacer par des nouvelles données.
Exemple de cas d’utilisation détaillé de la gestion des disciplines.

16. Chapitre III : Analyse & spécification des besoins
Titre projet Page 11
Figure : Diagramme de cas d’utilisation « Gestion Compte »
Patron textuel du cas d’utilisation « Créer Compte »
Sommaire créer compte
Nom : Créer compte
Résumé : Création d’un nouveau compte
Acteur : Administrateur
Pré-condition Utilisateur authentifié
Description du scénario : 1. L’utilisateur choisit l’option « Créer compte »
2. L’utilisateur fournit les informations nécessaires du
compte approprié
3. L’utilisateur valide l’ajout
4. Le système vérifie les informations
5. Le système enregistre les informations fournies par
l’administrateur
6. Le système renvoie un message d’ajout effectué.
Exception : Si le compte (apprenant, tuteur) existe déjà, donc le système
affiche un message d’utilisateur existant.
Post-condition : Compte créé

17. Chapitre III : Analyse & spécification des besoins
Titre projet Page 12
Patron textuel du cas d’utilisation « Modifier Compte »
Sommaire Modifier Compte
Nom : Modifier compte
Résumé : Modifier les paramètres du compte
Acteur : Acteur : Administrateur, Etudiant
Pré-condition Utilisateur authentifié
Description du scénario :
1. L’utilisateur sélectionne le paramètre de « Modification
paramètres »
2. L’utilisateur fournit les nouvelles données (Email, Tel,
Adresse, mot de passe…)
3. Le système vérifie les données
4. Le système enregistre les modifications
5. Le système renvoie un message pour informer
l’administrateur que la modification est effectuée avec
succès.
Exception : Si les nouvelles données sont erronées donc le système
affiche un message de saisie erronée.
Post-condition : Paramètres compte mis à jour
Patron textuel du cas d’utilisation « supprimer Compte »
Sommaire Supprimer Compte
Nom : supprimer compte
Résumer : Supprimer compte
Acteur : Acteur : Administrateur.
Pré-condition Utilisateur authentifié et compte existant
Description du scénario : 1. L’utilisateur sélectionne le compte à supprimer
2. L’utilisateur confirme la suppression
3. Le système supprime le compte en question.
4. Le système renvoie un message pour informer
l’administrateur que la suppression est effectuée avec
succès

18. Chapitre III : Analyse & spécification des besoins
Titre projet Page 13
Exception : Pas d’exception
Post-condition : Compte supprimé
Patron textuel du cas d’utilisation « Consulter Compte »
Sommaire Consulter Compte
Nom : Consulter compte
Résumer :
L’utilisateur peut consulter les paramètres du son compte.
Acteur : Administrateur, Etudiant
Pré-condition Utilisateur authentifié et compte existant
Description du scénario : 1. L’utilisateur accède à son espace de paramètre compte
2. Le système recherche les données du compte approprié
3. Le système affiche les informations du paramètre du
compte concerné.
Exception : Pas d’exception
Post-condition : Compte consulté
A compléter tout les diagrammes de cas d’utilisation primordial dans votre application.
Conclusion
En se basant sur la critique de l’existant, nous allons déterminer les différentes
améliorations qui permettent de garantir le bon fonctionnement et la bonne gestion de
notre application. Après avoir mis le sujet dans son cadre théorique, il est temps d’identifier
les différents besoins afin de recenser la liste des fonctionnalités qui doivent être présentes