Université de Sfax

***
Institut supérieur d’informatique
et du multimédia de Sfax

Rapport du Stage d’Eté

Présenté à

L’Institut supérieur d’informatique et de multimédia de

Sfax

Effectué à

Arab Soft
Par

Khammassi Nourhene
Programme : Cycle d’ingénierie
Spécialisation : Génie logiciel
Année universitaire : 2023/2024

2
 Remerciements

On remercie Dieu le tout puissant de m’avoir donné la santé et la volonté

d’entamer et de terminer ce projet de fin d’année.

Mes remerciements s’adressent également à tous les membres de l’ISIMS

Tout d’abord, Veuillez bien recevoir mes remerciements pour le grand honneur que
vous m’avez fait d'accepter de m’encadrer. Ce travail ne serait pas aussi riche et
n’aurait pas pu avoir le jour sans l’aide et l’encadrement de
M. Balti Aymen
Vous avez bien voulu me guider à chaque étape de ce travail riche d’intérêt durant
toute sa réalisation. Vous m’avez toujours réservé le meilleur accueil, malgré vos
obligations professionnelles. Je saisis cette occasion pour vous exprimer ma
profonde gratitude tout en vous témoignant mon respect.
M. Ktata Mounir
Votre compétence, votre encadrement ont toujours suscité mon profond respect. Je
vous remercie pour votre accueil et vos conseils, malgré vos obligations
professionnelles. Veuillez trouver ici, l’expression de mes gratitudes et de ma
grande estime.
Aux membres du jury
Messieurs les jurys, vous me faites un grand honneur en acceptant de juger ce
travail.

Je tiens à remercier chaleureusement, tous mes proches et tous ceux

qui, de près ou de loin, m’ont apporté leurs sollicitudes pour
accomplir ce Projet.
 Table des matières

Chapitre 1 : Cadre Générale du projet.................................................................................................

I. Introduction.............................................................................................................................
II. Présentation de l’organisme d’accueil...............................................................................
1. Historique :...............................................................................................................................
3. Savoir-faire :....................................................................................................................................
4. Parc informatique ...........................................................................................................................
III. Étude de l’existant.................................................................................................................
IV. Critiques de l’existant...........................................................................................................
V. Solution proposée..................................................................................................................
VI. Choix méthodologique.........................................................................................................
1. Principe de la méthodologie agile Scrum..............................................................................................
2. Justification de choix.............................................................................................................................
VII. Conclusion..............................................................................................................................
Chapitre 2 : Planification et spécification des besoins.......................................................................
I. Introduction.............................................................................................................................
II. Identification des acteurs.......................................................................................................
III. Besoins fonctionnels...............................................................................................................
IV. Besoins non fonctionnels.......................................................................................................
V. Diagramme de cas d’utilisation général...........................................................................
VI. Pilotage du projet avec Scrum...........................................................................................
1. Présentation de la méthode Scrum.......................................................................................................
1. Équipe de travail..................................................................................................................................
1. Backlog du produit..............................................................................................................................
1. Planification des sprints.......................................................................................................................
VII. Conclusion............................................................................................................................
Chapitre 3 : Lancement du projet et Environnement du travail........................................................
I. Introduction...........................................................................................................................
II. Architecture logicielle........................................................................................................
 1 Choix de l’architecture « MVC »........................................................................................................
III. Choix technologique...........................................................................................................
1 . Côté client..........................................................................................................................................
IV. Environnement de travail....................................................................................................
1. Environnement logiciel........................................................................................................................
2. Environnement matériel.......................................................................................................................
V. Diagramme de déploiement...............................................................................................
VI. Conclusion............................................................................................................................
Chapitre 4 : Sprint 1..........................................................................................................................
I. Introduction...........................................................................................................................
II. Backlog sprint 1...................................................................................................................
III. Diagramme de cas d’utilisation.........................................................................................
IV. Diagrammes de séquence...................................................................................................
V. Diagramme de classe..........................................................................................................
1. Les règles de gestion............................................................................................................................
2. Dictionnaire de données......................................................................................................................
3. Le modèle............................................................................................................................................
VI. Réalisation.............................................................................................................................
VII. Tests.......................................................................................................................................
VIII. Conclusion.......................................................................................................................
Chapitre 5 : Sprint 2.........................................................................................................................
I. Introduction...........................................................................................................................
II. Backlog sprint 2...................................................................................................................
III. Diagramme de cas d’utilisation.........................................................................................
IV. Diagrammes de séquence...................................................................................................
V. Diagramme de classe..........................................................................................................
1. Les règles de gestion............................................................................................................................
2. Dictionnaire de données......................................................................................................................
3. Le modèle............................................................................................................................................
VI. Réalisation.............................................................................................................................
VII. Tests.......................................................................................................................................
VIII. Conclusion.......................................................................................................................
Chapitre 6 : Sprint 3..........................................................................................................................
I. Introduction...........................................................................................................................
II. Backlog sprint 3...................................................................................................................
III. Diagramme de cas d’utilisation.........................................................................................
IV. Diagrammes de séquence...................................................................................................
V. Diagramme de classe..........................................................................................................
1. Les règles de gestion............................................................................................................................
2. Dictionnaire de données......................................................................................................................
3. Le modèle............................................................................................................................................
VI. Réalisation.............................................................................................................................
VII. Tests.......................................................................................................................................
VIII. Conclusion.......................................................................................................................
 Liste des figures

Figure 1: logo arab soft..............................................................................................................................12

Figure 2: la méthodologie agile Scrum......................................................................................................15
Figure 3: DIAGRAMME DE CAS D'UTILISATION GÉNÉRAL...........................................................20
Figure 4: méthodologie Scrum...................................................................................................................22
Figure 5:PLANIFICATION DES SPRINT...............................................................................................24
Figure 6: STRUCTURE DE L'ARCHITECTURE MVC..........................................................................27
Figure 7: DIAGRAMME DE DÉPLOIEMENT........................................................................................30
Figure 8: DIAGRAMME DE CAS D'UTILISATION DU SPRINT 1......................................................33
Figure 9:DIAGRAMME DE SÉQUENCE DE CAS D’UTILISATION « AUTHENTIFICATION ».....35
Figure 10: DIAGRAMME DE CLASSES DE SPRINT 1........................................................................37
Figure 11: INTERFACE DE REGISTRE..................................................................................................38
Figure 12: INTERFACE D’AUTHENTIFICATION................................................................................38
Figure 13: TEST DE L'API DE REGISTER.............................................................................................39
Figure 14: TEST DE L'API D'AUTHENTIFICATION............................................................................39
Figure 15: DIAGRAMME DE CAS D'UTILISATION DU SPRINT 2....................................................43
Figure 16: DIAGRAMME DE SÉQUENCE DE CAS D’UTILISATION « AJOUTER FILM »............44
Figure 17: DIAGRAMME DE CLASSES DE SPRINT 2........................................................................46
Figure 18: INTERFACES DE GESTION DES FILMS............................................................................48
Figure 19: INTERFACES DE GESTION DES SALLES.........................................................................50
Figure 20: TEST DE L’API D'AJOUT DE FILM.....................................................................................50
Figure 21: TEST DE L’API D'AJOUT DE SALLE..................................................................................51
Figure 22: DIAGRAMME DE CAS D'UTILISATION DU SPRINT 3....................................................54
Figure 23: DIAGRAMME DE SÉQUENCE DE CAS D’UTILISATION « AJOUTER PROJECTION »
....................................................................................................................................................................55
Figure 24: INTERFACES DE GESTION DES PROJECTIONS..............................................................59
Figure 25: INTERFACES DE RESERVATION.......................................................................................59
Figure 26: TEST DE L'API DE PROJECTION........................................................................................60
Figure 27: TEST DE L'API DE RESERVATION.....................................................................................61
 Liste des tableaux

Tableau 1: MEMBRES DE L'ÉQUIPE SCRUM......................................................................................23

Tableau 2: BACKLOG DU PRODUIT.....................................................................................................23
Tableau 3: ENVIRONNEMENT MATÉRIEL.........................................................................................29
Tableau 4:BACKLOG DU SPRINT 1.......................................................................................................32
Tableau 5:DESCRIPTION TEXTUELLE DU CAS D’UTILISATION « AUTHENTIFICATION ».....34
Tableau 6:DESCRIPTION TEXTUELLE DU CAS D’UTILISATION « AUTHENTIFICATION ».....34
Tableau 7: Dictionnaire de données...........................................................................................................36
Tableau 8: BACKLOG DU SPRINT 2......................................................................................................42
Tableau 9: DESCRIPTION TEXTUELLE DU CAS D’UTILISATION « Gestion Films »....................43
Tableau 10: DICTIONNAIRE DE DONNÉES DE SPRINT 2.................................................................45
Tableau 11: BACKLOG DU SPRINT 3....................................................................................................53
Tableau 12: DESCRIPTION TEXTUELLE DU CAS D’UTILISATION « GESTION DES
PROJECTION ».........................................................................................................................................54
Tableau 13: DICTIONNAIRE DE DONNÉES DE SPRINT 3.................................................................56
Tableau 14: DIAGRAMME DE CLASSES DE SPRINT.........................................................................56
Introduction Générale

10
 Introduction Générale

Avec les progrès technologiques, l'informatique a révolutionné la gestion de

l'information. Avant, tout était manuel, entraînant des retards et des erreurs.
Aujourd'hui, dans le domaine de la consultation et réservation des films en ligne,
l'automatisation devient essentielle. Cela garantit une gestion plus rapide et efficace,
répondant aux besoins modernes. En abandonnant les méthodes manuelles, on
améliore l'efficacité et l'expérience utilisateur. L'automatisation devient ainsi une
nécessité pour rester compétitif et offrir un service de qualité.

C’est dans ce cadre que s’inscrit notre projet de fin d’année qui consiste en la
conception et l’implémentation d’une application web capable de consulter et de
réserver des films en ligne.

Par le biais de ce rapport, nous allons détailler les différentes étapes par lesquelles
nous avons passées pour réaliser ce projet. Le présent rapport s’articule autour de
quatre parties :

 La première partie présente le cadre général du projet, à savoir l’organisme

d’accueil, l’étude de l’existant, notre solution proposée et la méthodologie de
réalisation suivie.
 La deuxième partie est consacrée pour les spécifications générales, la
modélisation des besoins et la présentation de la méthodologie de pilotage de
notre projet.
 La troisième partie présente l’architecture de l’application ainsi que les
différentes technologies et outils utilisés pour le développement du projet

 La dernière partie détaille les phases séquentielles de développement de

notre projet, présentées sous forme de Sprint.

Nous clôturons ce rapport par une conclusion qui établit le bilan du travail et
nous donnons quelques perspectives envisageables au présent projet.

11
 Chapitre 1 : Cadre Générale du projet

Chapitre 1 :
Cadre Générale du
projet

12
 Chapitre 1 : Cadre Générale du projet

Chapitre 1 : Cadre générale du

projet

I. Introduction

Ce chapitre introductif sera réservé pour présenter le contexte général de notre projet.
Il comporte en premier lieu une étude de l’existant afin d’identifier les lacunes de la
procédure actuelle. Nous proposons par la suite une solution tout en présentant la
méthodologie de travail adoptée lors de la réalisation du projet tout en argumentant
notre choix.

II. Présentation de l’organisme d’accueil

ARAB SOFT, peut se targuer d’être le leader dans le domaine du

service d’ingénierie informatique. Elle est leader en Tunisie mais aussi à
l’échelle international où ses compétences sont très prisées.

1. Historique :
Figure 1: logo arab soft
Créée en 1985 avec un effectif de 8 employés et disposant
actuellement d'une équipe dépassant les 100 employés la société a connu dès sa première année

d'existence une croissance rapide qui L’a propulsé au rang de leader national en ingénierie de

software anticipant ainsi l'évolution inévitable de l'ensemble du marché.

2. Mission :
ARAB SOFT développe plusieurs logiciels, notamment dans la gestion des RH,
Comptabilité financière, gestion hôtelière, gestion de maintenance assistée par
ordinateur, gestion commerciale, gestion des services administratifs, les contentieux
pour toutes les activités…et elle a comme principales Missions :
 L'édition des logiciels
 La vente ERP (Administration publique et privé, sociétés, groupe sociétés, firmes,
hôtellerie.)

13
 Chapitre 1 : Cadre Générale du projet

 La conception et développement de systèmes spécifiques.

 Le conseil. La formation et l’assistance.

3. Savoir-faire :
 Etude, conception, développement de logiciels sectoriels spécifiques,
développement des logiciels standards, développement des sites Web dynamiques,
formation sur les logiciels conçus et distribués, déploiements de solutions en
architectures clients/serveurs et n-tiers.

4. Parc informatique :

Cette partie décrit les composants du parc informatique d’ARABSOFT en citant

l’ensemble des outils informatiques par catégorie comme suit :

 Les méthodologies de conception : MERISE, UML.

 Les outils de conception : DESIGNER 2000, AMC DESIGNER, RATIONAL

ROSE.

 Les systèmes d'exploitation maîtrisés et utilisés : UNIX, SOLARIS, LINUX,

WINDOWS NT, WINDOWS 2000, WINDOWS XP.

 Les systèmes de gestion de base de données maîtrisés et exploités : ORACLE,

MySQL.

III. Étude de l’existant

• Actuellement, dans la consultation et la réservation des films en ligne, les processus

restent largement manuels avec des interfaces parfois peu intuitives, entraînant des
frustrations.
• Les systèmes actuels présentent des lacunes en termes de rapidité et d'efficacité,
avec des retards dus aux opérations manuelles et des erreurs humaines impactant
l'expérience utilisateur.
• Du cô té des gestionnaires, la collecte et la mise à jour des informations ainsi que la
gestion des transactions sont chronophages et sujettes à des erreurs.
• L'étude de l'existant révèle un potentiel inexploité pour optimiser ces processus

14
 Chapitre 1 : Cadre Générale du projet

grâ ce à l'automatisation, améliorant la fluidité des opérations et offrant une meilleure

expérience utilisateur.

IV. Critiques de l’existant

Après l’étude des différentes étapes de réservation et consultation des films en

ligne , nous avons pu dégager les défaillances suivantes :

• Difficulté de Gestion de l'Organisation des Données : La gestion manuelle des

données relatives aux films, horaires et réservations présente des difficultés, pouvant
entraîner des erreurs et des incohérences.

• Perte de Temps Importante avec Microsoft Office Excel : L'utilisation exclusive

de Microsoft Office Excel pour la réalisation de chaque processus génère une perte de
temps significative, limitant l'efficacité opérationnelle.

• Risque d'Incohérence des Données : Les redondances de saisie manuelle

accroissent le risque d'incohérences dans les données, surtout en présence de fautes de
frappe, compromettant la fiabilité des informations.

• Risque d'Erreurs lors de la Saisie des Données : La saisie manuelle des

informations dans chaque étape du processus augmente le risque d'erreurs humaines,
potentiellement impactant la précision des réservations et des données associées.

• Risque de Perte des Données : La gestion manuelle expose le système au risque de

perte de données, qu'il s'agisse de réservations, de détails sur les films ou
d'informations liées aux utilisateurs.

V. Solution proposée

Afin de remédier aux problèmes déjà mentionnés, nous avons opté pour la conception
et le développement d’une application web qui sera accessible depuis n’importe quel
navigateur sur ordinateur ou smartphone.
Cette application vise à simplifier et automatiser le processus de réservation et de
consultation des films en ligne, allégeant ainsi la préparation et la planification. L'objectif
principal est d'éliminer les erreurs potentielles et de garantir la sécurité des données en les

15
 Chapitre 1 : Cadre Générale du projet

centralisant dans une base de données sécurisée. Par ailleurs, la plateforme sera conçue pour
être intuitive et facile à utiliser, offrant ainsi une expérience optimale aux utilisateurs.

VI. Choix méthodologique

Une méthodologie est un système de pratiques, de techniques, de procédures et de

règles utilisées dans une discipline afin de contrôler et planifier un projet visant à
avoir un produit final d’une bonne qualité et dans un délai de livraison satisfaisant.
Choisir une méthodologie parmi plusieurs qui convient le mieux à notre projet est
important parce qu’elle détermine notre façon de travailler et elle nous fournit les
structures qui peuvent nous guider vers la réussite ou l’échec de notre projet, ce qui
nous mène au méthode de développement agile qui est orientée projet informatique
dont ses ressources sont régulièrement actualisées et plus précisément la méthode
Scrum qui vise à satisfaire au mieux les besoins du client en raison de sa flexibilité
apparente qui permet de faire pivoter le projet, ce qui leur donne plus d’occasions de
changer d’avis continuellement.

1. Principe de la méthodologie agile Scrum

Figure 2: la méthodologie agile Scrum

La méthode agile est une méthodologie de gestion de projet qui repose sur un cycle
de développement itératif, incrémental et adaptif qui a pour but d’améliorer le process
et de réduire le taux d’échec en mettant en place le client au cœur du projet. Étant
donné que la méthode Scrum est considérée comme méthode agile, elle suppose donc
que le développement d’un logiciel n'est pas prévisible et ne peut donc pas suivre le
processus défini traditionnelle, afin d’améliorer la productivité des équipes tout en

16
 Chapitre 1 : Cadre Générale du projet

permettant une optimisation du projet grâce à des feedbacks réguliers avec le client
ou les utilisateurs finaux.

2. Justification de choix
Notre choix de Scrum comme méthodologie de pilotage et de gestion de notre projet
se base sur les avantages et les atouts de ce dernier qui se résument comme suit :

 La capacité de contrôle qu’offre le Scrum sur le produit final grâce à la

manière incrémentale et itératif rapide du travail ce qui permet au produit
d’être modifié et pivoté selon le besoin du client.
 La compréhension des tâches à accomplir en subdivisant le projet en plusieurs
parties réalisable ce qui facilite l’optimisation en continu des étapes et des
tâches qui nous mènent à notre objectif final.
 La rapidité de développement et d’avancement du projet qui est due aux
échéances intégrées chaque jour pour évaluer l’avancement ce qui implique
que tout le monde assume leurs responsabilités.

VII. Conclusion

Dans ce premier chapitre, nous avons présenté le cadre général du projet à savoir
l’organisme d’accueil ARABSOFT au sein duquel nous avons passé notre stage.
Nous avons aussi étudié l’existant afin de relever ses défaillances et proposer des
solutions d’optimisation. Finalement nous avons dévoilé la méthodologie de travail
utilisée durant notre travail.

Dans le chapitre qui suit nous avons mis l’accent sur la phase de planification et de
spécification des besoins.

17
 Chapitre 3 : Lancement du projet et Environnement du travail

Chapitre 2 :
Planification et spécification
des besoins

18
 Chapitre 3 : Lancement du projet et Environnement du travail

Chapitre 2 : Planification et
spécification des besoins

I. Introduction

Avant de développer notre application, nous proposons de commencer par la phase de

spécification pour bien organiser et clarifier les tâches de notre projet. Ce chapitre
consiste donc à identifier les acteurs de notre système ainsi que les besoins
fonctionnels et non fonctionnels. Nous avons détaillé notre travail avec la
méthodologie choisie dans le chapitre précédent. Enfin, nous produisons le backlog
initial ainsi qu’une première planification des sprints.

II. Identification des acteurs

Pour préparer les besoins fonctionnels et non fonctionnels de notre application, nous
procédons ici à l’identification des acteurs de notre système tout en détaillant le
rôle de chacun. Un acteur est une entité externe au système, il présente une personne
ou un autre système informatique qui attend un ou plusieurs services offerts par une
interface d’accès qui interagit avec le système par envoi ou par réception des
messages. En se basant sur cette définition, nous avons dégagé la liste des acteurs de
notre système présentée ci-dessous :

 Administrateur : C’est l’acteur principal qui gère la majorité du processus

de planification des films se résumant en :
o Gestion des Films
o Gestion des salles
o Gestion des projections

 Client : Il est responsable de :

o Faire un registre, s’authentifier.
o Consulter les films affichés dans la page d’accueil.
o Voir les projections disponibles de chaque film.

19
 Chapitre 3 : Lancement du projet et Environnement du travail

o Réserver un film.
o Finir par faire le payement (s’il est intéressé).

 Visiteur :
o Consulter les films qui sont affichés dans la page d’accueil.

III. Besoins fonctionnels

Les besoins fonctionnels doivent répondre aux exigences du système en termes de

fonctionnalités. Ils constituent une sorte de contrat par rapport au comportement du
système. Application doit donc permettre de :

o Gestion d’authentification (session, principal, Token).

o Gestion autorisation (Rôle).
o Gestion des Films (Ajout, modification et suppression des films)
o Gestion des projections (Ajout, modification et suppression des projections)
o Gestion des salles et Réservations (Ajout, modification et suppression des salles)

IV. Besoins non fonctionnels

Afin d’être conforme aux normes et aux standards des outils informatiques,
l’application doit vérifier quelques propriétés et doit tenir compte de certaines contraintes et
exigences suivantes :

• Ergonomie et convivialité : il faut assurer la clarté du contenu de toutes les

interfaces développées qui devront offrir une convivialité et une ergonomie
permettant des présentations claires pour une navigation aisée.

• Modularité : la solution doit être modulaire et bien structurée pour garantir sa

souplesse et son évolutivité.

• La sécurité : la sécurité permet de définir les niveaux d’accès possibles. Un

utilisateur non authentifié il est aussi partiellement autorisé à accéder à l’application.

• Réutilisabilité : possibilité de réutiliser des composants du projet en les intégrant

dans d’autres logiciels à développer. On pourra réutiliser la conception et
l’architecture adoptée.

20
 Chapitre 3 : Lancement du projet et Environnement du travail

V. Diagramme de cas d’utilisation général

Le diagramme de cas d’utilisation est un moyen de communiquer avec les utilisateurs

et d’autres parties prenantes ce que le système est destiné à faire. Il montre
l’interaction entre le système et les entités externes au système. Il est représenté par
une ellipse contenant le nom du cas d’utilisation et optionnellement un stéréotype au-
dessus du nom.

Figure 3: DIAGRAMME DE CAS D'UTILISATION GÉNÉRAL

21
 Chapitre 3 : Lancement du projet et Environnement du travail

VI. Pilotage du projet avec Scrum

1. Présentation de la méthode Scrum
Le Scrum est considéré comme un cadre ou « Framework » de gestion de projet
Agile, il décrit un ensemble de réunions, d’outils et de rôles qui interagissent de
concert pour aider les équipes à structurer leur travail et à le gérer.

Il existe des événements Scrum qui sont décrits comme des boîtes de temps
(timeboxes). Ils servent à organiser le travail de l’équipe et cadrer le temps
passé en réunion :

 Planification de sprint (Sprint planning) : La durée maximale de cette

réunion est de 8 heures pour des sprints de 4 semaines. Au cours de laquelle
tout l’équipe du Scrum à savoir le Product Owner, l’équipe de développement
et le Scrum master si nécessaire, pour répondre à trois principales questions
qui consistent d’identifier l’objectif spécifique du sprint, les éléments
prioritaires du Product Backlog qui peuvent être convertis en un incrément
potentiellement livrable au cours du sprint et la façon de convertir ces
éléments sélectionnés en un incrément potentiellement utilisable à la fin du
sprint.
 Mêlée quotidienne (Daily Scrum) : Comme son nom l’indique, elle a lieu
tous les jours. Cette réunion a une durée maximale de 15 minutes. Elle permet
à l’équipe de développement de se synchroniser, de mesurer son avancement
au quotidien et d’ajuster son plan d’action en conséquence.
 Revue de sprint (Sprint Review) : Elle se déroule à la fin du sprint, elle
consiste à inspecter l’incrément et adapter le Product Backlog si nécessaire. Sa
durée maximale est de 4 heures pour un sprint de 4 semaines. Le Product
Owner y invite les parties prenantes clefs. L’intention est de recueillir auprès
d’eux des feedbacks et renforcer la collaboration.
 Rétrospective de sprint (Sprint Retrospective) : Lors de cette réunion qui a
lieu entre la revue de sprint et la planification du suivant, l’équipe Scrum
s’inspecte elle-même afin de tirer les leçons de l’expérience acquise sur le
sprint écoulé pour les mettre au profit du sprint suivant, à travers l’élaboration
22
 Chapitre 3 : Lancement du projet et Environnement du travail

d’un plan d’actions d’amélioration.

Figure 4: méthodologie Scrum

1. Équipe de travail
Les équipes Scrum sont autoorganisées et pluridisciplinaires. Elles choisissent la
meilleure façon d’accomplir leur travail, au lieu d’être dirigées par des personnes
externes à l’équipe, ce qui favorise la flexibilité, la créativité et la productivité. Ces
derniers sont principalement composés de :

 Product Owner : C’est généralement un expert du domaine métier. Il porte la

vision du produit à réaliser et travaille en interaction avec l’équipe de
développement pour assurer la bonne exécution du projet. Il est ainsi en
étroite relation avec l’équipe de marketing et les clients pour assurer que le
développement du produit est en harmonie avec l’utilisateur et ses besoins.
 Scrum master : C’est le chef de projet. Il s’assure que le principe Scrum se
déroule comme il se doit, il fixe les rôles, les timings et les objectifs. Il a donc
un rôle de coach à la fois auprès du Product Owner et auprès de l’équipe de
développement. Il doit donc faire preuve de pédagogie.
 L’équipe de développement : Elle est pluridisciplinaire qui est chargée de
transformer les besoins exprimés par le Product Owner en fonctionnalités
utilisables. Cela inclut la planification, conception, développement (codage),
tests et les paramétrages.

23
 Chapitre 3 : Lancement du projet et Environnement du travail

Rôl Membr
e e
Product Owner Mr. Aymen Balti

Scrum Master Mr. Ktata Mounir

L’équipe de Khammassi
développement Nourhene
Tableau 1: MEMBRES DE L'ÉQUIPE SCRUM

1. Backlog du produit
Le Backlog de produit est la liste des fonctionnalités attendues d’un produit. Plus
exactement, au- delà de cet aspect fonctionnel, il contient tous les éléments qui vont
nécessiter du travail pour l’équipe. Les éléments y sont classés par priorité ce qui
permet de définir l’ordre de réalisation.

En se basant sur cette définition, nous allons présenter le Backlog du produit

relatif à notre application :

8 : Deux semaines 6 : une semaine

User story Story Priority

point
Gestion authentification et 8 1
autorisation

Gestion des films 6 2

Gestion Salles 6 2
Gestion des projections 6 3
Gestion des réservations 6 4
Tableau 2: BACKLOG DU PRODUIT

1. Planification des sprints

Afin de préparer le planning de travail et d’identifier les sprints, nous devons faire
recours à la vélocité qui est un indicateur qui a pour début de nous aider à évaluer la
24
 Chapitre 3 : Lancement du projet et Environnement du travail

quantité de travail qu’on peut sélectionner pour chaque sprint. Elle est exprimée en
nombre de points et elle est égale à la somme des complexités des user stories ÷
le nombre de sprint.

Dans notre cas, la vélocité est égale à 36 ÷ 3 = 12 points.

La figure ci-dessus présente la planification des sprints de notre projet :

Figure 5:PLANIFICATION DES SPRINT

VII. Conclusion

Durant ce chapitre, nous avons spécifié en premier lieu les besoins fonctionnels et
non fonctionnels et présenté le diagramme de cas d’utilisations générale du projet.
Ensuite, nous avons détaillé la première étape de la méthodologie adoptée à savoir le
pilotage du projet avec Scrum tout en élaborant le backlog du produit ainsi que la
planification des sprints.

Dans le chapitre suivant, nous allons mettre en évidence l’environnement et l’architecture

25
 Chapitre 3 : Lancement du projet et Environnement du travail

du projet.

26
 Chapitre 3 : Lancement du projet et Environnement du travail

Chapitre 3 :
Lancement du projet et
Environnement du
travail

27
 Chapitre 3 : Lancement du projet et Environnement du travail

Chapitre 3 : Lancement du projet et

Environnement du travail

I. Introduction

Après avoir spécifié les besoin fonctionnels et non fonctionnels ainsi que la
méthodologie de pilotage choisie pour la réalisation du projet. Il nous reste que
d’entamer ce chapitre afin de décrire l’architecture de l’application, le choix des
technologies, l’environnement de travail et les outils utilisés qui nous mèneront vers
une application complète qui satisfait les besoins de l’utilisateur.

II. Architecture logicielle

La conception de l’architecture est une phase particulièrement importante du

développement d’un logiciel. Elle conditionne sa stabilité, son efficacité et sa
pérennité. Au contraire, certaines applications peuvent connaitre des faiblesses dues à
une architecture mal pensée, pas ou plus adaptée au contexte, pour cela nous avons
pris en considération plusieurs critère pour choisir l’architecture adéquate pour notre
application qui se résument en l’évolutivité de l’application et sa simplicité.

1 Choix de l’architecture « MVC »

L’architecture MVC (modèle-vue-contrôleur) est un patron utilisé pour le
développement d’applications web. Elle permet de concevoir des applications web de
manière claire et efficace grâce à la séparation des intentions ce qui rend les
opérations de maintenance et de mise à jour fortement simplifiées. Elle se compose de
trois modules :

 Modèle : c’est le noyau de l’application qui gère les données, permet de

récupérer les informations dans la base de données, de les organiser pour
qu’elles puissent ensuite être traitées par le contrôleur.
 Vue : c’est un composant graphique de l’interface qui permet de présenter les
données du modèle à l’utilisateur.

28
 Chapitre 3 : Lancement du projet et Environnement du travail

 Contrôleur : c’est le composant responsable des prises de décision. Il gère la

logique du code e t qui prend des décisions. Il est
l’intermédiaire entre le modèle et la vue.

Figure 6: STRUCTURE DE L'ARCHITECTURE MVC

III. Choix technologique

Le choix des technologies est l’une des étapes les plus importantes du développement
d’un produit réussi. La création d’un produit ne se limite pas à la conception d’une
interface utilisateur agréable et d’une interface utilisateur pratique, il s’agit également
de concevoir un produit stable, sécurisé et facile à entretenir.

1 . Côté client
 Angular 13

Angular est un Framework populaire de création d’application web

Client d’une seule page appelé SPA (Single Page Application) à

l’aide du HTML et du TypeScript.
Notre choix de ce Framework s’est basé sur son implémentation

simple de l’architecture MVC. Il gère nos composants et

agit également comme le pipeline qui les relie.

 Bootstrap
29
 Chapitre 3 : Lancement du projet et Environnement du travail

Bootstrap est un Framework proposé en open source.

Il fournit aux développeurs des outils pour créer des
applications web avec un design responsive, qui
s’adapte à tout type d’écran, et en priorité pour les
smartphones ainsi que des outils avec des styles déjà
en place pour des typographies, des boutons, des
interfaces de navigation et bien d’autre encore. Son
infrastructure repose sur HTML, CSS et JavaScript.

2. Coté serveur :

 Spring Boot :
Spring Boot est un Framework open-source basé sur Java qui propose un ensemble
de composants de haute qualité, conçu pour s'assembler harmonieusement en vue créer un cadre solide
de développement web. Il se distingue par sa grande souplesse, son extensibilité et sa simplicité
d'utilisation, tout en offrant des performances optimales. Spring Boot repose sur le modèle architectural
MVC (Modèle-Vue-Contrôleur), ce qui simplifie grandement le processus de développement et de
maintenance des applications.

IV. Environnement de travail

Avoir un environnement de travail efficace nous permettra d’optimiser notre

productivité et nos performances afin d’atteindre notre objectif d’apporter une
application conviviale qui répond aux besoins du client. Dans cette partie nous
présentons les environnements logiciels ainsi que matériels employés.

1. Environnement logiciel
L’environnement logiciel employé pour la réalisation de notre projet sont les suivants :

 Visual Studio Code : est un éditeur de code redéfini et optimisé pour la

création et le débogage d’applications web et cloud modernes. Il peut être
utilisé avec une
variété de langages de programmation, notamment PHP, Java, JavaScript, etc.

 Angular CLI : est un outil permettant de créer, générer, tester et maintenir

nos applications et librairies Angular directement depuis une commande
shell.

30
 Chapitre 3 : Lancement du projet et Environnement du travail

 Microsoft Visio : est un logiciel de création de diagrammes

personnalisée, complexes et surtout adaptés à nos besoins.

 Xampp : est une suite facilitant l’installation d’un serveur Web Apache.
Cette « distribution » se chargera donc d’installer l’ensemble des outils dont
nous avons besoin lors de la créer de notre application web.

 Node.js : est un environnement d’exécution qui permet d’exécuter du

code JavaScript à l’intérieur du navigateur, directement sans le serveur.

 PhpMyAdmin : est un outil qui permet de visualiser rapidement l’état de

notre base de données et de la modifier, sans avoir à écrire de requête SQL.

 Postman : est un logiciel qui se focalise sur les tests des API. Il sert à
exécuter des appels http directement depuis une interface graphique.

 Swagger : est un ensemble open source de règles, de spécifications et

d'outils permettant de développer et de décrire des API RESTful.

2. Environnement matériel
Notre projet a été réalisé sur un ordinateur portable dont la configuration est la suivante :

Ordinateur Portable MSI GF63 Thin 11SC

Système Windows 10 (64 bits)

d’exploitation
Processeur Intel® Core™ i7-11800H CPU@ 2.30
GHz
Mémoire vive 24 Go

Disque dur 512 Go

Tableau 3: ENVIRONNEMENT MATÉRIEL

31
 Chapitre 3 : Lancement du projet et Environnement du travail

V. Diagramme de déploiement

Le diagramme de déploiement modélise l’architecture physique du système. Il affiche

les relations entre les composants logiciels et matériels du système, d’une part, et la
distribution physique du traitement, d’autre part.

Figure 7: DIAGRAMME DE DÉPLOIEMENT

VI. Conclusion
Dans ce chapitre nous avons énoncé en premier lieu, l’architecture de notre projet ainsi que les
technologies choisies. Ensuite, nous avons présenté l’environnement de travail à savoir les
environnements matériels et logiciels. Dans le chapitre qui suit, nous traiterons le premier sprint.

32
 Chapitre 4 : Sprint 1

Chapitre 4 : Sprint 1

33
 Chapitre 4 : Sprint 1

Chapitre 4 : Sprint 1

I. Introduction

Après avoir spécifié l’environnement logiciel et matériel dans le chapitre précédent,

il nous reste que d’entamer ce chapitre afin de décrire les différentes fonctionnalités
et les principaux objectifs de notre futur système.

Ce chapitre contiendra la première partie mentionnée dans le backlog du sprint.

Nous ne passons par une partie d’analyse, une phase de conception et une phase de
réalisations où nous présentons quelques interfaces réalisées au cours de chaque
User Story.

II. Backlog sprint 1

Dans la méthodologie Scrum, tous les sprints ont une durée constante et ne se
chevauchent jamais, c’est-à-dire qu’un sprint ne peut pas démarrer tant que le
précédent n’est pas encore terminé.
Avant de se lancer dans un sprint, l’équipe Scrum doit obligatoirement définir le but
de ce dernier. Ce but doit être défini en termes métiers et non pas en termes
techniques pour qu’il soit compréhensible par les membres en dehors de l’équipe. Il
s’agit de répondre à une question fondamentale « pourquoi faisons-nous ce sprint ? ».
Une fois que le but de notre sprint soit défini, on choisit les histoires qui seront
incluses dans le backlog du sprint.

User story Stor P

y r
point i
o
r
i
t
34
 Chapitre 4 : Sprint 1

y
Un utilisateur peut s'inscrire 6 1
dans le système

Un utilisateur peut 6 2
s'authentifier pour accéder au
système

III. Diagramme de cas d’utilisation

Dans cette section, nous allons présenter le cas d’utilisation du premier sprint et
les diagrammes de séquence système de cas d’utilisation à traiter.

Tableau 4:BACKLOG DU SPRINT 1

Figure 8: DIAGRAMME DE CAS D'UTILISATION DU SPRINT 1

Cas Authentifier
d’utilis
ation
Acteur Client ou Administrateur
35
 Chapitre 4 : Sprint 1

Pré Utilisateurs inscrits (Client)

conditions
Post Utilisateur connecté
conditions
Scénario Client :
de base 1) La page d’accueil s’affiche

2) Client peut faire une authentification

3) Client saisit son email et son mot de passe
4) Le client peut Consulter toutes les projections
possibles et peut faire une réservation.

Administrateur :
1) L’administrateur faire une authentification
2) L’administrateur saisit son email et son mot de passe
3) L’administrateur est redirigé vers le Dashboard

E.1) Données saisies sont incorrectes : le système

Scénario
alternatif affiche un message d’erreur
L’utilisateur s’inscrire (Visiteur)
Tableau 5:DESCRIPTION TEXTUELLE DU CAS D’UTILISATION « AUTHENTIFICATION »

Cas S’inscrire
d’utilis
ation
Acteur Visiteur

Pré -
conditions
Post Compte crée
conditions
Scénario 1) Le visiteur faire le saisie de ces informations d’identification
de base (email, password)

36
 Chapitre 4 : Sprint 1

Tableau 6:DESCRIPTION TEXTUELLE DU CAS D’UTILISATION « AUTHENTIFICATION »

IV. Diagrammes de séquence

Pour donner suite à la description textuelle précédente nous allons modéliser la

dynamique globale du système et l’interaction entre le système et l’acteur en fessant
appel à un ensemble de diagrammes de séquences qui chacun correspondant à une
sous fonction du système illustré par les diagrammes de cas d’utilisations
précédentes.

Pour que l’utilisateur accède à la page d’accueil, il doit passer par l’interface
d’authentification. Cette authentification est basée sur la vérification des
données saisies par l’utilisateur qui donnera suite à un échange d’un token qui
contient les informations nécessaires pour identifier l’utilisateur entre le client et le
serveur.

La figure ci-dessous présente le diagramme de séquence du cas d’utilisation «

Authentification » :

Page JWT auth Entity

Utilisateur
authentification service

Saisir les information

d’authentification(email,mdp)

Cliquer sur btn submit

Authentification(token)

Vérifier les
information

alt

Informations valide
récupérer_user(email,mdp)

User_informations

Authentification_response Créer_Token
(token)

37
Rediriger vers page
d’authentification

Informations invalide
Authentification_response
 Chapitre 4 : Sprint 1

Figure 9:DIAGRAMME DE SÉQUENCE DE CAS D’UTILISATION « AUTHENTIFICATION »

V. Diagramme de classe

Le diagramme de classes est fondamental pour le processus de modélisation des

objets et modélise la structure statique du système. Il présente les classes et les
interfaces du système ainsi que les différentes relations entre celles-ci.
1. Les règles de gestion
L’analyse sémantique des données du dictionnaire permet de les regrouper dans des
entités à part. Les liens qui les relient compte des règles de gestion qui sont fondées
sur les exigences du monde réel.

Le diagramme de classe qu’on va construire sera basé sur les règles de gestion que
nous allons les préciser dans cette partie :

 Un utilisateur à un ou plusieurs rôles (CLIENT, ADMINISTRATEUR).

2. Dictionnaire de données
Le dictionnaire de données est un document qui regroupe toutes les données que nous
allons conserver dans notre base de données. Il indique le code mnémonique, la
désignation, le type de donnée et sa taille.

Code Désignation Type

mnémonique
idUser L’abréviation du nom de département int

firstName Nom de l’utilisateur String

email L’email de l’utilisateur String

password Mot de passe de l’utilisateur String

idRole Identifiant de l’utilisateur String

38
 Chapitre 4 : Sprint 1

nameRole Rôle de l’utilisateur int

Tableau 7: Dictionnaire de données

3. Le modèle

Figure 10: DIAGRAMME DE CLASSES DE SPRINT 1

VI. Réalisation

Après avoir achevé l’étape de la conception, en tenant compte des besoins fixés et
des choix conceptuels effectués précédemment, nous allons présenter quelques
interfaces réalisées durant ce sprint.

La figure ci-dessous présente l’interface de registre qui est l’interface affichée lorsque
un visiteur peut faire une réservation après l’ouverture de la page d’accueil :

39
 Chapitre 4 : Sprint 1

Figure 11: INTERFACE DE REGISTRE

Figure 12: INTERFACE D’AUTHENTIFICATION

40
 Chapitre 4 : Sprint 1

VII. Tests

La phase de tests est essentielle qui permet de s’assurer a priori que le produit
fonctionnera correctement. Elle évalue le système ou le composant afin de déterminer
si les conditions imposées au début de la phase de développement sont satisfaites.

Afin de nous assurer que le système fonctionne correctement on a utilisé le logiciel

swagger comme outil de test unitaire. Les figures ci-dessous montrent la réussite de
quelques tests et l’atteinte de l’objectif attendu :

Figure 13: TEST DE L'API DE REGISTER

Figure 14: TEST DE L'API D'AUTHENTIFICATION

41
 Chapitre 4 : Sprint 1

VIII. Conclusion

Dans ce chapitre, nous avons présenté tout le cycle de développement du premier

sprint à savoir sa conception et certaines interfaces de l’application pour ce sprint.
Dans le chapitre suivant, nous allons présenter le deuxième sprint qui présentera la
partie du projet consacrée pour la modification des répartitions de séances et matières
ainsi que la réalisation de la répartition des groupes.

42
 Chapitre 5 : Sprint 2

Chapitre 5 : Sprint 2

43
 Chapitre 5 : Sprint 2

Chapitre 5 : Sprint 2

I. Introduction

Après avoir terminé et présenté le premier sprint de notre application, nous allons
nous intéresser dans ce chapitre à la réalisation du deuxième sprint qui se
décompose de :

 Gestion des films.

 Répartition des salles.

II. Backlog sprint 2

User story Story point Priority

Un administrateur peut gérer les films. 6 3
Un client peut consulter les derniers films 3 4
à projeter dans la page d'accueil.

Un administrateur peut gérer les salles. 3 4

Tableau 8: BACKLOG DU SPRINT 2

III. Diagramme de cas d’utilisation

Dans cette section, nous allons présenter le cas d’utilisation du deuxième sprint et les
diagrammes de séquence système de cas d’utilisation à traiter.

44
 Chapitre 5 : Sprint 2

Figure 15: DIAGRAMME DE CAS D'UTILISATION DU SPRINT 2

Cas d’utilisation Gestion films

Acteur Administrateur

 Administrateur authentifié
Pré conditions

Post conditions  Administrateur connecté

1) La page d’accueil s’affiche.

2) L’administrateur faire une authentification.
Scénario de base 3) L’administrateur saisit son email et son mot de passe.
4) L’administrateur peut ajouter, supprimer et modifier des films.
5) L’administrateur peut ajouter, supprimer et modifier des salles.

E.2) Données saisies sont incorrectes : le système affiche un

Scénario alternatif message d’erreur

Tableau 9: DESCRIPTION TEXTUELLE DU CAS D’UTILISATION « Gestion Films »

45
 Chapitre 5 : Sprint 2

IV. Diagrammes de séquence

Le directeur des études peut répartir les groupes sur les salles. La figure ci-
dessous illustre le diagramme de séquence du cas d’utilisation « Ajouter film »

Figure 16: DIAGRAMME DE SÉQUENCE DE CAS D’UTILISATION « AJOUTER FILM »

V. Diagramme de classe

1. Les règles de gestion

Le diagramme de classe qu’on va construire sera basé sur les règles de gestion que
nous allons les préciser dans cette partie :

 Une salle contient un de plusieurs places

2. Dictionnaire de données
Le tableau ci-dessous représente le dictionnaire de données de ce sprint :

46
 Chapitre 5 : Sprint 2

Code Désignation Type

mnémonique
idFilm Identifiant d’un film Numérique

nomFilm Nom du film Alphabétiq

ue
dureeFilm Durée du film DateTime

createur Créateur du film Alphabétiq

ue
description Description sur le film Alphabétiq
ue
isactif Film actif ou non Boolean

Category Catégorie du film Alphabétiq

ue
image Image du film Alphabétiq
ue
dateFilm Date du film DATE

idSalle Identifiant de salle Numérique

nomSalle Nom de salle Alphabétiq

ue
nbrPlacesOccupee Nombre des Places Occupée dans la Numérique
salle
nbrPlacesDisponible Nombre des Places disponible dans la Numérique
s salle

Tableau 10: DICTIONNAIRE DE DONNÉES DE SPRINT 2

47
 Chapitre 5 : Sprint 2

3. Le modèle

Figure 17: DIAGRAMME DE CLASSES DE SPRINT 2

VI. Réalisation

Les figures ci-dessous montrent les interfaces où l’administrateur peut gérer les
films et les salles :

48
Chapitre 5 : Sprint 2

49
 Chapitre 5 : Sprint 2

Figure 18: INTERFACES DE GESTION DES FILMS

50
Chapitre 5 : Sprint 2

51
 Chapitre 5 : Sprint 2

Figure 19: INTERFACES DE GESTION DES SALLES

VII. Tests

52
 Chapitre 5 : Sprint 2

Figure 20: TEST DE L’API D'AJOUT DE FILM

Figure 21: TEST DE L’API D'AJOUT DE SALLE

VIII. Conclusion

Tout au long de ce chapitre, nous avons entamé et achevé le deuxième sprint qui
s’intéresse généralement à la réalisation de la deuxième partie de la gestion des
53
 Chapitre 5 : Sprint 2

films et des salles . Nous allons présenter dans le chapitre qui suit le dernier
sprint qui à savoir la phase finale de réservation des films ainsi que les
fonctionnalités nécessaires dans le projet (projection et réservation des films).

54
 Chapitre 6 : Sprint 3

Chapitre 6 : Sprint 3

55
 Chapitre 6 : Sprint 3

Chapitre 6 : Sprint 3

I. Introduction

Après avoir présenté le deuxième sprint de notre application, nous allons entamer le
troisième sprint qui se focalise sur la dernière partie de la planification des examens
et qui est composé de:

 Gestion des projections

 Gestion des réservations

II. Backlog sprint 3

User story Story Priority

point
Un administrateur peut organiser des projections 3 5
des films dans les salles disponibles.

Un client peut consulter la liste des projections 3 6

disponible de chaque film.

Un client peut consulter les films ordonnés par 3 7

ordre de précédences dans la page d'accueil

Un client peut réserver un ticket d’une 3 8

projection d'un film

Tableau 11: BACKLOG DU SPRINT 3

III. Diagramme de cas d’utilisation

Dans cette section, nous allons présenter le cas d’utilisation du deuxième sprint et les
diagrammes de séquence système de cas d’utilisation à traiter.

56
 Chapitre 6 : Sprint 3

Figure 22: DIAGRAMME DE CAS D'UTILISATION DU SPRINT 3

Cas d’utilisation Gestion Projections

Acteur Administrateur ou client

Pré conditions Administrateur authentifié

1) L’administrateur faire une authentification.

2) L’administrateur accède à l’interface de gestion des

Scénario de base projections
3) L’administrateur peut ajouter, modifier, supprimer une
projection.

E.4 ) Manque d’information : le système affiche un message

Scénario alternatif
d’erreur

Tableau 12: DESCRIPTION TEXTUELLE DU CAS D’UTILISATION « GESTION DES PROJECTION »

57
 Chapitre 6 : Sprint 3

IV. Diagrammes de séquence

La figure ci-dessous présente le diagramme de séquence du cas d’utilisation « Ajouter

projection » :

Figure 23: DIAGRAMME DE SÉQUENCE DE CAS D’UTILISATION « AJOUTER PROJECTION »

V. Diagramme de classe

1. Les règles de gestion

Le diagramme de classe qu’on va construire sera basé sur les règles de gestion que nous
allons les préciser dans cette partie :
 Une réservation réservée à une seule projection.
 Réservation d’une ou plusieurs places.

2. Dictionnaire de données
Le tableau ci-dessous représente le dictionnaire de données de ce sprint :

58
 Chapitre 6 : Sprint 3

Code Désignation Type

mnémonique
idProjection Identifiant de projection Numérique

dateProjection Date de projection Date

tarifProjection Tarif de projection Alphabétiq

ue
timeProjection Temp de projection Date

idReservation Identifiant de réservation Numérique

dateReservation Date de réservation Alphabétiq

ue
nbrPlaces Nombre de places réservé Numérique

Tableau 13: DICTIONNAIRE DE DONNÉES DE SPRINT 3

3. Le modèle

Tableau 14: DIAGRAMME DE CLASSES DE SPRINT

59
 Chapitre 6 : Sprint 3

VI. Réalisation

60
Chapitre 6 : Sprint 3

61
 Chapitre 6 : Sprint 3

Figure 24: INTERFACES DE GESTION DES PROJECTIONS

Figure 25: INTERFACES DE RESERVATION

VII. Tests

62
 Chapitre 6 : Sprint 3

Figure 26: TEST DE L'API DE PROJECTION

63
 Chapitre 6 : Sprint 3

Figure 27: TEST DE L'API DE RESERVATION

64
 Chapitre 6 : Sprint 3

VIII. Conclusion
A ce stade, nous avons clôturé notre travail. Tout au long de ce chapitre, nous
avons présenté le troisième et dernier sprint relatif à la réalisation de la dernière
partie de la projection et réservation des films.

65
Conclusion et
perspective

66
 Conclusion et perspective

Face aux défis complexes de la réservation et de la consultation des films en ligne, nous
avons conçu une application web visant à simplifier et autonomiser l'ensemble du processus.
Cette initiative vise à faciliter le flux d'informations, de tâches et de documents entre les
différentes activités de manière indépendante, conformément à des règles de gestion
préalablement définies. En adoptant une approche agile, inspirée de la méthodologie Scrum,
nous avons analysé et traduit les exigences du produit en scénarios applicables, exploitant les
technologies du développement web pour améliorer la capacité et la qualité d'exécution selon
les besoins des utilisateurs.
Ce projet s'inscrit dans le cadre du projet de fin d'année, représentant une expérience
enrichissante où nous avons pu mettre en pratique nos compétences techniques et théoriques
acquises au cours de notre parcours universitaire.
Cependant, notre engagement ne s'arrête pas là, car la perfection est un horizon toujours
à atteindre. Des améliorations futures sont envisagées, notamment l'intégration d'un module de
gestion des projections des films même que la phase de réservation des films.

67
 Netographie

 https://angular.io/docs
 https://udemy.com
 https://www.angularjswiki.com/fr/angular/angular-material-icons-list-mat-icon-list/
 https://fr.wikipedia.org/
 https://www.piloter.org/projet/methode/scrum.htm
 https://getbootstrap.com/

68