PROJET DE FIN D’ANNEE

4éme Année en Ingénierie Informatique et Réseaux

Réalisé par :
Prénom & Nom

Tuteur (s) :

Encadrant Professionnel : Prénom NOM

Encadrant Pédagogique : Prénom NOM.

Au sein de (Organisme d’accueil) :

 Année universitaire : 20xx/20xx

Dédicaces
Les dédicaces du rapport sont généralement destinées à toutes sources de soutien
moral (généralement sont des membres de votre famille, …).
La mise en forme de cette page est personnelle à l’étudiant.

Remerciements

Les remerciements du rapport sont généralement destinés à l’encadreur de

projet et à toutes personnes ayant joué un rôle important pendant la période de
réalisation de votre projet. Citez le nom, le poste de chaque personne et la
justification de votre remerciement.
Attention : Les remerciements ne sont pas adressés aux membres du jury.

Ces remerciements sont exprimés en une dizaine de lignes au maximum, de la

façon la plus simple possible, sans platitude ni exagération.
La mise en forme de cette page est au gré de l’étudiant.

Table des matières

La table des matières (sommaire) permet, grâce à la pagination, de retrouver
l’endroit où se trouve un élément recherché par le lecteur. La table des
matières doit être générée d’une façon automatique. Elle ne doit pas présenter
plus que trois niveaux de sous-titres.
Pour générer la table des matières, veuillez suivre la procédure suivante :
• Ouvrir le menu "Références" ensuite "Table des matières"
• Choisir un modèle et le niveau désiré.
Attention : Pour pouvoir utiliser la table automatique, il faut utiliser les styles
prédéfinis pour les titres et sous-titres.
La table des matières doit être claire, pas besoin de plus de 1 ou 3 niveaux de
sous-titres (la table des matières ne doit pas dépasser 1 à 3 pages sinon le
lecteur ne voit pas la progression des parties).
 On donne ici la table des matières de ce guide :

Liste des figures

Insérer ici la liste des figures qui existent dans le rapport en fixant le nom de
chaque figure avec le numéro de sa page.

Attention : La liste des figures doit être générée automatiquement.

NB : le titre de la figure doit être placé en

dessous de la figure. Exemple de la liste des
figures de ce guide :
Figure 1 : Différents messages dans un diagramme de séquences...........................................................9
Figure 2 : Diagramme de séquences "Authentification"........................................................................10

Liste des tableaux

Insérer ici la liste des tableaux qui existent dans le rapport en fixant le nom du
tableau avec le numéro de sa page.

Attention : La liste des tableaux doit être gênée de manière automatique.

NB : Le titre du tableau doit être placé au-

dessus du tableau. Exemple de liste des
tableaux :
Tableau 1 : Planning prévisionnel.............................................................................................................4
Tableau 2 : Description du cas d’utilisation « xxx » pour l’acteur x.......................................................7
Tableau 3 : Dictionnaire de données......................................................................................................11

Introduction générale

Introduction générale

[Tous le long de ce rapport, l’étudiant

doit utiliser le pronom « nous »
à la place de « je »]
L’introduction générale comporte, généralement, deux parties.

Dans la première partie, l’étudiant présentera son sujet à travers des

informations précises et posera par la suite la problématique à résoudre avec
clarté et sans évocation de résultats.
[Il ne faut pas parachuter des introductions « passe partout »]

Dans la deuxième partie, l’étudiant présentera le plan de son rapport en

évoquant, brièvement, le contenu de chaque chapitre.

L’étudiant doit impérativement suivre ce guide et doit aussi respecter la

mise en forme recommandée dans l’ANNEXE B.

[Un étudiant du département Technologies de l’informatique doit développer

dans son stage une application pas nécessairement avec un langage de
programmation vu dans son parcours]
Attention : La numérotation du rapport commence par l’introduction, c’est la page numéro 1.

Guide de rédaction du rapport de PFA 1

 C
Présentation
du projet
cadre de

hapitre

1
Objectifs du chapitre
L’étudiant évoquera implicitement les différents objectifs de ce chapitre.

Ce chapitre comprend, généralement, trois parties ; la présentation de la

société où s’est déroulé le stage, une étude de l’existant sur les
modalités de travail actuelles, la critique de l’existant et les solutions
envisagées par l’étudiant.

Chapitre 1 : Présentation du cadre de projet

• Introduction

Ce projet vise à concevoir et à réaliser un site web permettant aux clients de

trouver facilement des services automobiles de qualité. L'objectif est de
fournir une expérience utilisateur optimale et de faciliter la gestion des
activités pour l'entreprise.
 • Etude de l’existant
• Critique de l’existant
La solution actuelle présente une interface utilisateur démodée et peu intuitive,
un manque de personnalisation des recommandations, des fonctionnalités de
recherche et de filtrage inefficaces, l'absence de gestion des avis et
commentaires des clients, ainsi que des outils de gestion d'entreprise limités.
Ces insuffisances réduisent la satisfaction des utilisateurs, la crédibilité du
site, et l'efficacité opérationnelle de l'entreprise.
• Solution proposée
Pour améliorer l'expérience utilisateur et la gestion des activités de
l'entreprise, nous proposons de développer une plateforme en ligne responsive
et intuitive. Cette plateforme intégrera un système de réservation de rendez-
vous en ligne et de suivi des commandes, facilitant ainsi la navigation et la
prise de rendez-vous pour les clients. En outre, nous créerons du contenu
pertinent et engageant pour établir une relation de confiance avec les clients et
personnaliser leur expérience. Cette solution vise à moderniser le site web
actuel et à optimiser les processus internes, offrant ainsi une expérience
utilisateur optimale et une gestion plus efficace des services.
• Choix de modèle de développement

Pour développer cette application, nous avons choisi le modèle Agile en raison de sa flexibilité et
de sa capacité à s'adapter aux changements. Ce modèle permet des livraisons incrémentales et
fréquentes, assurant une amélioration continue basée sur les retours des utilisateurs. La
collaboration étroite avec les parties prenantes et les réunions quotidiennes permettent de suivre
l'avancement et de résoudre rapidement les obstacles. En adoptant des sprints courts, nous
pouvons tester et valider chaque fonctionnalité régulièrement, garantissant ainsi un produit final
de haute qualité. Le modèle Agile assure une réponse efficace aux besoins évolutifs de
l'entreprise et de ses clients.
Planning prévisionnel

Ici l’étudiant doit mettre le plan de son travail pendant la

période de son stage. Planning prévisionnel devra être
représenté comme suit :

Chapitre 1 : Présentation du cadre de projet

Tableau 1 : Planning prévisionnel

Semaine Février Mars Avril Mai

Etape 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
Etude préalable * * * *
Conception * * * *
Réalisation * * * *
Test et Validation * * * *
Explication du Planning
Etude préalable (Février) : Les premières semaines sont consacrées à l'analyse des
besoins, la recherche et la définition des exigences du projet.

Conception (Mars) : La phase de conception commence en mars, avec la création

des maquettes, la définition de l'architecture du système, et la planification
détaillée des fonctionnalités.

Réalisation (Avril) : Le mois d’avril est dédié au développement et à la mise en

œuvre des fonctionnalités définies lors de la phase de conception. Le
développement se poursuit en mai pour finaliser toutes les fonctionnalités et
effectuer les ajustements nécessaires.

Test et Validation (Mai) : Les dernières semaines sont consacrées aux tests et à la
validation de l'application, y compris les tests fonctionnels, d’intégration, et de
validation finale avant le déploiement.

• Conclusion

Ce chapitre a présenté le cadre de notre projet en détaillant les étapes clés et le planning
prévisionnel pour le développement de l'application. Nous avons d'abord abordé l'étude
préalable, qui est essentielle pour comprendre les besoins et les exigences du projet.
Ensuite, nous avons planifié la phase de conception, où nous définirons l'architecture du
système et créerons des maquettes pour guider le développement. La phase de
réalisation, programmée pour le mois d'avril, se concentrera sur le développement
effectif des fonctionnalités de l'application, tandis que la phase de test et validation,
prévue pour mai, garantira que l'application répond aux exigences de qualité et de
performance. Ce planning permet une gestion efficace du projet et assure que chaque
étape est exécutée de manière ordonnée pour atteindre les objectifs fixés.
 C
Spécification
des besoins

hapitre

2
Objectifs du chapitre
Ce chapitre comprend, généralement, deux parties : les besoins
fonctionnels et les besoins non fonctionnels.

Chapitre 2 : Spécification des besoins

 • Introduction
Ce chapitre détaillera les différents services automobiles proposés par l'application. Nous
inclurons un système de prise de rendez-vous, permettant aux clients de réserver des services
facilement. Le suivi des commandes offrira la possibilité de vérifier l'état des commandes, avec
des options pour accepter ou rejeter. Le système intégrera également un paiement à la livraison
en espèces (Cash on Delivery), assurant une flexibilité pour le règlement. Ces besoins
fonctionnels répondent aux exigences essentielles pour offrir une expérience utilisateur complète
et efficace. Les besoins non-fonctionnels, tels que la performance, la sécurité et l'interopérabilité,
seront définis en parallèle pour garantir la qualité globale du système.
Spécification des besoins fonctionnels
• Besoin fonctionnel 1 : Prise de rendez-vous
• 1.1. Réservation de service
• Les clients doivent pouvoir réserver un service automobile via un
système en ligne. La réservation doit inclure la sélection du service,
la date et l'heure souhaitées.
•
• 1.2. Gestion des disponibilités
• Le système doit afficher les créneaux horaires disponibles en temps
réel pour chaque service, permettant aux clients de choisir un
créneau libre.
•
• 1.3. Confirmation de rendez-vous
• Une fois la réservation effectuée, le système doit envoyer une
confirmation de rendez-vous par email ou SMS au client, incluant
les détails de la réservation.
•
• Besoin fonctionnel 2 : Suivi des commandes
• 2.1. Consultation de l'état des commandes
• Les clients doivent pouvoir consulter l'état de leur commande en
ligne, avec des mises à jour sur l'avancement du service (en cours,
terminé, etc.).
•
• 2.2. Options de gestion
• Le système doit permettre aux clients d'accepter ou de rejeter l'état
de la commande, en offrant une interface simple pour ces actions.
•
• Besoin fonctionnel 3 : Paiement
• 3.1. Mode de paiement
• Le système doit intégrer une option de paiement à la livraison en
espèces (Cash on Delivery), permettant aux clients de payer en
liquide lors de la réception du service.
 •
• 3.2. Confirmation de paiement
• Après le paiement, le système doit générer une confirmation de
paiement pour le client et enregistrer la transaction dans le système.
Spécification des besoins non fonctionnels

Convivialité et Ergonomie
L'interface utilisateur doit être intuitive et facile à naviguer pour assurer une
expérience utilisateur fluide. Les éléments de l'interface doivent être
clairement définis et accessibles.

Performance
Le système doit offrir un temps de réponse rapide pour les actions des
utilisateurs, telles que la réservation de services et le suivi des commandes.
Les temps de chargement des pages ne doivent pas dépasser 2 secondes.

Sécurité
Les données des utilisateurs doivent être protégées par des mesures de sécurité
appropriées, telles que le cryptage des informations personnelles et des
transactions financières.

Accessibilité
L'application doit être accessible sur différents dispositifs (ordinateurs,
smartphones, tablettes) et compatible avec les principaux navigateurs web.
Une version mobile optimisée est requise.

Scalabilité
L'architecture de l'application doit permettre une montée en charge facile pour
gérer un nombre croissant d'utilisateurs et de transactions sans impact
significatif sur les performances.

Maintenance
Le code et les fonctionnalités de l'application doivent être conçus pour faciliter
les mises à jour et la maintenance régulière. Une documentation claire et
 complète est nécessaire pour les futurs développeurs et administrateurs.

• Présentation des cas d’utilisation

• Présentation des acteurs
Dans l'application de gestion de site e-commerce pour le secteur automobile, les principaux
acteurs sont :

Visiteur
Le visiteur est un utilisateur non authentifié qui peut naviguer sur le site, consulter les produits et
services proposés, et obtenir des informations générales. Les visiteurs peuvent également
s'inscrire ou se connecter pour accéder à des fonctionnalités supplémentaires.

Acteur
L'acteur est un utilisateur authentifié qui peut être un concessionnaire, un vendeur de pièces, ou
un garagiste. Il a accès à des fonctionnalités spécifiques pour gérer les produits, les commandes,
et les services. Les acteurs peuvent ajouter ou modifier des articles, suivre les commandes, et
gérer les rendez-vous ou les services.

Admin
L'administrateur est le superviseur global de l'application. Il dispose de toutes les autorisations
nécessaires pour gérer les utilisateurs, les paramètres du système, et les opérations de
l'application. L'administrateur peut également consulter des rapports détaillés, configurer les
rôles et les permissions, et superviser l'ensemble des activités de la plateforme.

Ces acteurs interagissent avec l'application selon leurs rôles et responsabilités, garantissant ainsi
une gestion efficace des opérations et une expérience utilisateur fluide.
Chapitre 2 : Spécification des besoins

• Diagramme des cas d’utilisation global

 C
Conception
du système

hapitre

3
Objectifs du chapitre
Ce chapitre a pour objectif de présenter la solution conceptuelle proposée
par l’étudiant. En d’autres termes, ce chapitre devrait répondre à la question
COMMENT FAIRE.

Chapitre 3 : Conception du système

• Introduction

Dans ce chapitre, l’étudiant doit modéliser son application d’un point de vue
statique et dynamique. Pour la modélisation dynamique, les digrammes de
séquences, les digrammes de collaboration et les diagrammes d’états doivent
être figurés. Pour modéliser l’aspect statique le diagramme de classes et le
diagramme de déploiement doivent être présenté à la fin de ce chapitre.
 • Modélisation dynamique
• Diagrammes de séquences

Diagrammes de Séquences des utlisateurs

Visiteur

Recherche de Produits/Services :
Le visiteur accède à la page d'accueil.
Il utilise la barre de recherche pour trouver des véhicules, des pièces ou des services d'entretien.
Le système affiche les résultats de la recherche.
Inscription/Connexion :
Le visiteur choisit de s'inscrire ou de se connecter.
Le système affiche le formulaire d'inscription ou de connexion.
Le visiteur remplit et soumet le formulaire.
Le système vérifie les informations et crée un compte ou permet l'accès.

Diagrammes de Séquences des Administrateurs

Gestion des Utilisateurs :

L'admin se connecte à son compte.
Il accède à la section de gestion des utilisateurs.
Il peut ajouter, modifier ou supprimer des comptes d'utilisateurs (acteurs et
visiteurs).
Le système met à jour la base de données des utilisateurs.
Supervision des Activités :
L'admin consulte les rapports d'activité.
Il analyse les statistiques de vente, les niveaux de stock, et les performances du
site.
Le système génère des rapports et des tableaux de bord interactifs.
Configuration du Système :
L'admin accède aux paramètres du système.
Il configure les rôles, les permissions, et les paramètres globaux de l'application.
Le système enregistre les configurations et applique les modifications.

Chapitre 3 : Conception du système

Chapitre 3 : Conception du système

 • Modélisation statique
• Diagramme de classes

Diagrammes Relationnel

• Architecture de l’application
• Architecture logiciel

• Architecture matériel

• Conclusion
Ce chapitre a présenté l'architecture de l'application développée avec Laravel, en détaillant à la
fois l'architecture logiciel et matériel.

L'architecture logiciel est structurée autour de composants clés tels que le serveur web
(Apache/Nginx), le framework Laravel, la base de données, le serveur de cache, le serveur de
files d'attente et les API externes. Chaque composant joue un rôle essentiel dans la gestion des
requêtes, le traitement des données, et l'amélioration des performances et de la scalabilité de
l'application.

L'architecture matériel est composée de nœuds distincts pour chaque fonction critique, y compris
les serveurs web, de base de données, de cache, et de files d'attente. Cette répartition permet une
gestion efficace des ressources et assure un fonctionnement fluide de l'application dans un
environnement de production.

En résumé, l'architecture mise en place permet d'assurer une performance optimale, une
scalabilité adaptée aux besoins croissants, et une gestion efficace des différentes couches de
l'application.
 C
Réalisation
du système

hapitre

4
Objectifs du chapitre
Ce chapitre a pour objectif de présenter la solution logicielle et
l’environnement de développent qui sont utilisés afin d’aboutir à
développer l’application.

Chapitre 4 : Réalisation du système

• Introduction

Dans ce chapitre, nous détaillons l’environnement matériel et logiciel utilisé

pour le développement de l’application ainsi que les principales interfaces
graphiques. La première partie du chapitre est consacrée à l’environnement de
développement, tandis que la seconde partie présente la mise en œuvre de la
solution proposée.
• Environnement de développement
• Environnement matériel
L’environnement matériel sous lequel l’application a été développée
comprend les caractéristiques suivantes :

Processeur : Intel i5 8e génération

Mémoire RAM : 8 Go
Stockage : 500 Go HDD
Autres : Équipements de réseau comme routeurs et hubs pour le
développement et les tests.
• Environnement logiciel
Système d’exploitation : Windows 10, 11,7
Framework : Laravel (version 10)
Base de données : MySQL (version 8)
Serveur Web : Apache/Nginx
Éditeur de code : VSCode, PHPStorm
Outils de modélisation : StarUml
 Principales interfaces
graphiques(NIZAR 3AMER HNA
•

TSAWER ANA WERITK FIN )

• Interface de Connexion : Permet aux utilisateurs de se connecter à l'application avec leurs
identifiants. Elle comprend des champs pour l'email et le mot de passe, ainsi qu'un bouton
pour soumettre les informations.

(LOGIN REGISTRE)
• Tableau de Bord de l'Administrateur : Offre une vue d'ensemble des statistiques clés de
l'application, telles que les utilisateurs inscrits, les ventes récentes, et les activités de
l'application.
(ADMIN PANNEL)

• Page de Gestion des Produits : Permet à l'administrateur de gérer les produits, avec des
options pour ajouter, modifier ou supprimer des produits. Elle affiche également une liste
de tous les produits existants avec des options de filtrage.
(Admin Pannel)

• Interface de Commande : Affiche les détails de la commande, y compris les produits

achetés, les informations de livraison et le statut de la commande. Les utilisateurs
peuvent suivre l'état de leurs commandes depuis cette [Link]

(USER PANNEL)
Ce chapitre a exposé l’environnement matériel et logiciel utilisé pour développer
l’application, ainsi que les principales interfaces graphiques développées.
L’environnement matériel assure une base solide pour le développement, tandis que les
outils logiciels facilitent la création et la gestion des différentes fonctionnalités de
l’application. Les interfaces graphiques présentées offrent une vue détaillée des
principales fonctionnalités et assurent une expérience utilisateur fluide et intuitive. Ce
travail constitue une base essentielle pour la mise en œuvre et le déploiement de
l’application.

Conclusion générale

Conclusion générale
La conclusion du rapport doit comprendre, impérativement, un rappel de
l’objectif du stage de perfectionnement et une récapitulation du travail fait en
présentant les résultats (en d’autres termes, les réponses aux problèmes posés
au début).
Il est, également, recommandé de porter un œil critique sur le travail fait en
soulevant certaines insuffisances ou améliorations possibles.
Remarque : La conclusion devrait être rédigée en une page sous forme d’un
paragraphe et non pas de tirets.

Bibliographie et Nétographie

Bibliographie et Nétographie
 Cette partie comprend les différents livres, articles, revues et sites internet qui ont
servi à la documentation.
Bibliographie [Obligatoire]

L’ordre de ces références peut se faire soit par ordre alphabétique du nom de
l’auteur soit par ordre d’apparition dans le rapport.
• NOM_AUTEUR, Prénom. « Titre de l’ouvrage », lieu de publication,
nom de l’éditeur, année de publication, nombre de tomes, nombre de pages.
S’il s’agit d’un rapport de PFE, par exemple, on peut ajouter le numéro
d’ordre (référence) associé. (i= 1, 2, …,n).
Exemple :
• REEVES, Hubert. « Bases de données relationnelles », Paris, Editions du seuil,
1988, p88.
Nétographie

Sites Web visités lors de l’élaboration du projet, avec une brève description du
thème consulté (une ou deux lignes au maximum).
Exemple :
• [Link] HYPERLINK "[Link]
%20%22[Link] HYPERLINK
"[Link]
HYPERLINK
"[Link]
HYPERLINK "[Link] HYPERLINK
"[Link]
HYPERLINK
"[Link]
HYPERLINK
"[Link] :
Fondements du langage [Link].
A ne pas mentionner :
• Les moteurs de recherche tels que [Link] HYPERLINK
"[Link] HYPERLINK "[Link] HYPERLINK
"[Link] HYPERLINK "[Link] HYPERLINK
"[Link] HYPERLINK "[Link] HYPERLINK
"[Link] ou [Link]
• Les cours étudiés au niveau de l’ISET ; ils sont considérés comme
faisant partie des connaissances acquises et assimilées par les étudiants.
Remarque : Il est impératif de référencer la bibliographie et nétographie au niveau du
rapport.

On donne ici la Bibliographie et la Nétographie de ce guide :

 Bibliographie

[2] Pascal Roques, UML 2 par la pratique Etudes de cas et exercices

corrigés, 5ème Edition, 2006, p54.
Nétographie
[1] [Link]
• [Link]
• [Link]
transitions
• [Link]

ANNEXES

ANNEXE A : Que placer en annexes ? ANNEXE

B : Proposition de mise en forme ANNEXE C :
Diverses recommandations
[Les annexes sont facultatives et ne suivent pas de règles particulières]

ANNEXE A

ANNEXE A : Que placer en annexes ?

L’annexe présente un complément de documents qui ne sont pas

indispensables à la compréhension du projet, mais qui présentent un certain
intérêt. Ces documents peuvent être :
• Des explications plus détaillées liées au thème du projet, à
l’environnement de développement,…,
• Des documents qui ont servi de base pour le développement de
l’application comme des fiches et formulaires remis par la société
d’accueil,
• Des interfaces de l’application qui ne figurent pas au niveau de la réalisation,
• Des diagrammes non présentés précédemment,
• Des bouts de code illustrant soit la difficulté de l’implémentation soit
l’originalité liée au codage ou au langage de développement,
 …

ANNEXE B

ANNEXE B : Proposition de mise en forme

Cette annexe présente différentes recommandations relatives à la mise en forme du
rapport.

• Titres et sous-titres

• Il est recommandé de précéder le titre du chapitre par son numéro (Chapitre 1 :

…),
• Les titres et sous-titres doivent être sur le même niveau vertical,
• On peut distinguer les niveaux de titres et sous-titres par la taille de police,
• A ne pas utiliser « : » à la fin d’un titre ou d’un sous-titre,
• Les titres et sous titres ne sont ni soulignés ni écrits en italique,
• Un titre ou sous-titre ne doit jamais figurer en fin de page.

Remarque : Le titre d’un chapitre peut être placé sur une page indépendante ;
dans ce cas, la page en question devrait être comptabilisée mais non
numérotée et ne devrait comporter ni entête ni pied de page. La page d’après
(contenant le corps du chapitre) ne doit porter aucun titre. En d’autres termes,
le titre d’un chapitre doit être mentionné une seule fois.
• Corps du texte
• Justifié,
• 1er ligne : 0.8 cm,
• Interligne : 1.5 ligne,
• Espacement avant et après : 6pts,
• Police : Times New Roman, 12 pts.
• Puces

• Il faut adopter le même type de puces pour tout le rapport et conserver le même
retrait,
• Chaque puce finit par une virgule« , » à l’exception de la dernière qui finit par un
point
« . ».
• Entête et pied de page

• L’entête peut contenir :

• Le titre du chapitre courant
• Une ligne le séparant du texte de la page
• Le pied de page peut contenir :
• Le numéro de page
• Le titre du projet de fin d’études
 • Une ligne le séparant du texte de la page

Remarque : Il n’est pas apprécié de mentionner le nom de l’étudiant ou de la

société en entête ou pied de page dans la mesure où elle ne présente aucune
plus-value.
• Marges
2.5 cm (haut, bas, droite, gauche)

• Couleurs
A éviter sauf en cas de besoin (Interfaces de l’application, …)

• Numérotation des pages

• La pagination débute au niveau de l’introduction.
• Les annexes peuvent avoir une numérotation différente du reste du rapport.

ANNEXE C

ANNEXE C : Diverses recommandations

• Les annexes sont facultatives ; elles pourraient, éventuellement,
comprendre un complément d’interfaces graphiques qui n’ont pas été
mentionnées au niveau du rapport.
Si une partie de la programmation est jugée intéressante ou innovante, il est
possible de placer le code source en annexes. De même, certaines notions
théoriques pourraient être détaillées au niveau des annexes.
• Le nombre de pages d’un rapport de PFE (de l’introduction à la conclusion)
ne devrait pas excéder 60 pages (entre 50 et 60 pages généralement).