Rapport

Application Mobile de Gestion des Spectacles

Ines Bouderbela

Année Universitaire 2024 - 2025

Table des matières

Introduction générale 1

1 Contexte général 2
1.1 Étude du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2 Description du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.3 Fonctionnalités principales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Analyse et spécification des besoins 6

2.1 Identification des acteurs du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Identification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Diagramme des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Sprint 0 :Planification du projet 10

3.1 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.1 Langage de programmation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.2 Logiciels et outils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.3 Frameworks et bibliothèques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5 Planification des Sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.6 Diagramme de GANTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4 Réalisation 20
4.1 Choix techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2 Travail réalisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3 Planning réel du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

ii
Conclusion générale 22

Annexes 23
Annexe 1. Exemple d’annexe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Annexe 2. Entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

iii
Table des figures

3.1 Logo Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 Logo Java Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Logo de Visual Studio Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4 Logo de power BI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5 Logo de Draw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.6 Logo de MobaXtrem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.7 Logo de Overleaf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.8 Logo de Overleaf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Annexe 2.1 Logo d’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

iv
Liste des tableaux

3.1 Description de la machine de développement . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3 Planifications des Sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Annexe 1.1 Exemple tableau dans l’annexe . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

v
Liste des abréviations

— GISI = Génie Informatique des Systèmes Industriels

— GLSI = Génie Logiciel et Systèmes d’Information

— GTR = Génie des Télécommunications et Réseaux

vi
Introduction générale

Le monde du développement logiciel est en constante évolution, s’adaptant aux exigences

croissantes en matière de déploiement rapide, de qualité et de fiabilité des logiciels. Dans ce contexte,
les pratiques DevOps ont émergé comme un paradigme essentiel pour répondre à ces impératifs.
Ce rapport vise à explorer l’application des principes DevOps dans le cycle de développement
logiciel, en abordant plusieurs aspects clés. Dans la section sur la Conception et le Développement
Logiciel, nous analyserons la façon dont les pratiques DevOps ont été intégrées dès la phase de
conception pour optimiser les processus de développement. Ensuite, la partie dédiée aux Tests Automatisés
et à l’Intégration Continue (CI) mettra en lumière l’automatisation des tests et son intégration continue
pour garantir la qualité du code et réduire les erreurs potentielles. Nous aborderons également la
pratique du Déploiement Continu, soulignant comment les déploiements automatisés ont permis des
livraisons plus rapides et plus fiables. Enfin, une Étude de Cas spécifique illustrera concrètement
l’impact de DevOps. Nous détaillerons un projet spécifique, ses défis initiaux, les solutions apportées
par l’adoption de DevOps, et les résultats concrets obtenus, comme des déploiements plus fréquents,
une réduction des temps d’arrêt, et une amélioration notable de la collaboration et des performances
globales.

1
 Chapitre 1

Contexte général

Plan
1 Étude du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Chapitre 1. Contexte général

Introduction

Ce rapport présente ReserviSpectacle, une application Android de réservation de billets pour

spectacles culturels, développée dans le cadre du module Développement Mobile à l’École Nationale
d’Ingénieurs de Carthage. Notre solution centralise l’offre culturelle locale tout en offrant une expérience
utilisateur innovante, avec sélection visuelle des sièges, paiement sécurisé et géolocalisation des salles. Ce
document détaille notre démarche technique, depuis l’analyse des besoins jusqu’aux défis de développement,
en mettant l’accent sur l’architecture modulaire et les optimisations d’interface qui garantissent fluidité
et accessibilité. Par son approche intégrée, SpectaReserve répond aux attentes des utilisateurs tout en
servant de cadre pédagogique pour l’application des bonnes pratiques Android.
"

1.1 Étude du projet

1.1.1 Introduction

Dans un contexte marqué par la digitalisation accélérée des services culturels, le projet Ce
rapport présente ReserviSpectacle, une application Android de réservation de billets pour
spectacles culturels, développée dans le cadre du module Développement Mobile à l’École
Nationale d’Ingénieurs de Carthage. Notre solution centralise l’offre culturelle locale
tout en offrant une expérience utilisateur innovante, avec sélection visuelle des sièges,
paiement sécurisé et géolocalisation des salles. Ce document détaille notre démarche
technique, depuis l’analyse des besoins jusqu’aux défis de développement, en mettant
l’accent sur l’architecture modulaire et les optimisations d’interface qui garantissent
fluidité et accessibilité. Par son approche intégrée, SpectaReserve répond aux attentes des
utilisateurs tout en servant de cadre pédagogique pour l’application des bonnes pratiques
Android. propose une modernisation de l’accès aux événements artistiques tunisiens. Cette application
mobile Android offre une plateforme intégrée permettant aux utilisateurs de découvrir, explorer et
réserver des billets pour des spectacles diversifiés (théâtre, musique, danse) à travers le pays.

1.1.2 Description du projet

SpectaReserve est une application développée en Kotlin suivant l’architecture MVVM, connectée
à un backend Spring Boot via une API REST. Son écosystème technique comprend :

— Frontend Android :

— Interface responsive avec Jetpack Compose

3
Chapitre 1. Contexte général

— Géolocalisation via Google Maps SDK

— Paiement sécurisé avec Stripe Integration

— Backend :

— Spring Boot (Java 17)

— Base de données PostgreSQL

— Système de caching avec Redis

1.1.3 Fonctionnalités principales

[Link]

sectionFonctionnalités utilisateur

• Recherche avancée avec filtres :

— Par catégorie (théâtre, concert...)

— Par date et localisation

— Par prix et notation

• Réservation interactive :

— Sélection visuelle des sièges sur plan 3D

— Calcul dynamique des tarifs

— Timer de réservation (15 min)

• Gestion personnalisée :

— Profil utilisateur avec historique

— Système de favoris et alertes

— E-tickets QR code

[Link] Fonctionnalités techniques

• Synchronisation temps réel des disponibilités

• API REST documentée avec Swagger

• Tests unitaires (JUnit 5) et UI (Espresso)

1.1.4 Conclusion

SpectaReserve représente une avancée significative dans l’accès numérique à la culture en

Tunisie. Par son architecture modulaire et ses fonctionnalités centrées utilisateur, le projet démontre
comment les technologies mobiles peuvent :

4
Chapitre 1. Contexte général

— Faciliter l’accès à l’offre culturelle

— Optimiser la gestion des réservations

— Valoriser le patrimoine artistique national

5
 Chapitre 2

Analyse et spécification des besoins

Plan
1 Identification des acteurs du système . . . . . . . . . . . . . . . . . . . . . . 7

2 Identification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Diagramme des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Chapitre 2. Analyse et spécification des besoins

Introduction

Dans ce chapitre, nous abordons une étape indispensable qui est la spécification des besoins afin
de déterminer les fonctionnalités et la conception nécessaires pour réaliser notre application. Dans cette
phase, nous précisons les acteurs de l’application, ainsi que les besoins fonctionnels et non fonctionnels.
Pour ce faire, nous avons choisi le langage UML, un langage de modélisation orienté objet formel et
normalisé.

2.1 Identification des acteurs du système

Un acteur est une personne ou un système extérieur qui interagit avec le système à développer
afin de réaliser une valeur ajoutée

• utilisateur final : peut être soit un consultant soit un client . Il a accès à plusieurs fonctionnalités
de l’application, telles que l’initiation de la mise à jour de Data Hub, la reprise de la mise à
jour si nécessaire, la surveillance en temps réel de l’avancement des étapes de la migration, la
consultation des données mises à jour et la vérification des ressources utilisées lors de la mise à
jour.

• data hub : C’est un acteur secondaire et un élément clé de l’application. C’est un logiciel qui
est mis à jour par une notre application qui fournit les fonctionnalités de base nécessaires à
l’application .en effet, DataHub contient les fichiers journaux et les fichiers shell nécessaires aux
mises à jour.L’application interagit avec le DataHub pour appliquer la mise à jour et effectue des
contrôles sur l’état de la mise à jour.
Pour mieux comprendre le fonctionnement du DataHub, la Figure ??représente l’architecture de
ses composants.

2.2 Identification des besoins

L’identification des besoins est une étape cruciale dans le développement du projet puisque ça
aide à exprimer les buts de l’application et à planifier la réalisation avec une vision plus claire

2.2.1 Besoins fonctionnels

Il s’agit des fonctionnalités du système. Ce sont les besoins spécifiant un comportement d’entrée
/ sortie du système. Les besoins fonctionnels auxquels notre application doit répondre se résument dans
les points suivants :

• L’authentification : L’application doit comporter un mécanisme d’authentification permettant

7
Chapitre 2. Analyse et spécification des besoins

aux utilisateurs de se connecter en à l’environnement DH, où la mise à jour sera effectuée.

• Mise à jour de la datahub : L’application doit automatiquement lancer la mise à jour dès
que l’utilisateur se connecte.

• Gestion des erreurs de mise à jour : L’application doit être en mesure de détecter les erreurs
survenues lors de la mise à jour et d’arrêter le processus si nécessaire.

• Reprise de la mise à jour :Le client a la possibilité de reprendre la mise à jour de la datahub
après avoir effectué les modifications nécessaires dans les paramètres en cas d’erreurs détectées.

• suivi de la migration : L’application offre une interface de visualisation permettant au client

de suivre en temps réel les différentes étapes de la migration et de visualiser leur statut.

• Gestion des données mises à jour

— Extraction des données

— Traitement et filtrage des données

— Afficher les données mises à jour dans un tableau de bord convivial pour les utilisateurs

• Affichage des indicateurs de consommation de ressources : L’application doit calculer

et afficher les indicateurs de consommation des ressources utilisées lors de la mise à jour de la
datahub, tels que la RAM et les données de base.

2.2.2 Besoins non fonctionnels

Ce sont des besoins qui ne concernent pas spécifiquement le comportement du système mais
plutôt identifient des contraintes internes et externes du système. Notre solution doit prendre en compte
les critères suivants :

• Interfaces utilisateur simples et intuitives : l’application a pour but de simplifier la mise

a jour de DH pour les consultants de NeoXam. Les interfaces doivent, donc,être bien organisée,
être simples, conviviales et claires.r

• Maintenabilité et mise à jour : Le code source doit être lisible et compréhensible et l’application
doit être facilement extensible et permet d’intégrer facilement d’autres fonctionnalités.

2.3 Diagramme des cas d’utilisation

Le diagramme de cas d’utilisation principal permet de décrire la manière dont les acteurs
voudraient interagir avec le système. C’est un moyen qui permet de recueillir les besoins des utilisateurs
du système et de les représenter sous forme de fonctionnalités : ************

8
Chapitre 2. Analyse et spécification des besoins

Conclusion

Dans ce chapitre, nous avons décrit les besoins fonctionnels et les besoins non fonctionnels
permettant d’assurer une bonne performance de l’application et d’atteindre l’objectif de chaque besoin
fonctionnel. Nous avons par la suite exposé le diagramme de cas d’utilisation général . Dans le chapitre
suivant, nous commençons par le Sprint 0 qui présente notre environnement de travail et où on va
définir le Backlog Produit pour en déduire la planification des sprints de notre application.

9
 Chapitre 3

Sprint 0 :Planification du projet

Plan
1 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5 Planification des Sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

6 Diagramme de GANTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Chapitre 3. Sprint 0 :Planification du projet

Introduction

Ce chapitre décrit l’architecture physique et logicielle de notre application,les différents outils

qui constituent l’environnement de travail, les différentes technologies que nous avons utilisées tout au
long du projet, ainsi que le Backlog produit et la planification des Sprints.

3.1 Architecture de l’application

L’architecture à trois niveaux, aussi connue sous le nom d’architecture trois tiers ou à trois
couches, est une architecture de type client-serveur qui comprend des modules indépendants pour gérer
respectivement l’interface utilisateur, les processus logiques, fonctionnels et métiers, ainsi que l’accès
aux données. Cette architecture repose sur une infrastructure physique qui soutient une infrastructure
logicielle. Toute application peut être divisée en trois parties : une partie qui gère l’interface graphique,
une partie qui gère les fonctions métiers et logiques, et une partie qui gère le stockage de données.

— Couche de présentation : Cette couche est la première couche de l’architecture trois-tiers et

contient l’interface utilisateur et permet l’interaction entre l’utilisateur et l’application.

— Couche de traitement : Cette couche est la deuxième couche de l’architecture trois-tiers et

correspond à un ensemble de composants métiers qui permettent de traiter les actions sur le
serveur Flask ,il est composée de deux parties :

• Serveur : le serveur Flask est responsable de recevoir les informations de l’interface utilisateur,
de déclencher un script Python pour exécuter la migration sur le serveur DataHub, et
d’envoyer les résultats à l’interface utilisateur.

• Script migration : Le script de migration est responsable de la mise à jour du data hub
,il se connecte au data hub et tout au long de ce processus, il envoie des requêtes au serveur
Flask pour suivre l’avancement de la mise à jour.

— Couche d’accès aux données : Cette couche est la troisième couche de l’architecture trois-tiers
et correspond au serveur de données. le serveur DataHub est le serveur de données qui contient
les commandes nécessaires pour effectuer les étapes de la mise à jour et stocker les journaux
(logs) pour le suivi de la mise à jour et gestion d’erreur.

3.2 Environnement matériel

Concernant la partie matérielle, il faut utiliser un matériel performant au niveau processeur

et mémoire pour gagner au niveau du temps de réponse de l’exécution de l’application. Ainsi notre
environnement matériel est constitué par un ordinateur portable ayant les caractéristiques présentées

11
Chapitre 3. Sprint 0 :Planification du projet

par le tableau 3.1

Tableau 3.1 : Description de la machine de développement

Ordinatuer portable HP

Processeur 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz

2.42 GHz

Mémoire RAM 8 Go

Disque dur 256 Go

Système d’exploitation Windows 10 Professionnel 64 bit

3.3 Environnement logiciel

3.3.1 Langage de programmation

• Python
Python est un langage de programmation interprété, multiplateforme et orienté objet. Créé par
Guido van Rossum en 1991, il est devenu rapidement très populaire grâce à sa simplicité, sa
lisibilité et sa polyvalence. Python est très utilisé dans différents domaines, grâce à la disponibilité
de nombreuses bibliothèques et outils dédiés qui nous aident à développer mon application.
Python est également utilisé pour la création d’applications web, de scripts système, et bien plus
encore.

Figure 3.1 : Logo Python

• Java script
JavaScript est un langage de programmation de haut niveau et orienté objet, principalement
utilisé pour créer des pages web [Link] est pris en charge par tous les navigateurs web
modernes et est largement utilisé dans le développement web. Il existe également de nombreuses
bibliothèques et frameworks JavaScript populaires tels que React, Angular, [Link], [Link], etc.,
qui peuvent être utilisés pour simplifier et accélérer le processus de développement.

12
Chapitre 3. Sprint 0 :Planification du projet

Figure 3.2 : Logo Java Script

3.3.2 Logiciels et outils

• Visual studio code

Visual Studio Code est un éditeur de code source gratuit, multiplateforme et open-source,
développé par Microsoft prenant en charge les opérations de développement telles que le débogage,
l’exécution des tâches et le contrôle de version. Il vise à fournir uniquement les outils dont un
développeur a besoin pour un cycle rapide de construction de code-débogage et laisse des flux de
travail plus complexes aux IDE plus complets, tels que Visual Studio IDE. VS Code .

Figure 3.3 : Logo de Visual Studio Code

• PowerBI
Power BI est un outil de Business Intelligence (BI) développé par Microsoft. Il permet aux
utilisateurs de collecter, d’analyser et de visualiser des données de manière efficace et intuitive.
Power BI est conçu pour aider les entreprises à prendre des décisions éclairées en utilisant des
données en temps réel, des tableaux de bord interactifs, des rapports personnalisables et des
fonctionnalités d’analyse avancées.

Figure 3.4 : Logo de power BI

• [Link]
[Link] est une application gratuite en ligne qui permet de dessiner des diagrammes ou des

13
Chapitre 3. Sprint 0 :Planification du projet

organigrammes. Cet outil vous propose de concevoir toutes sortes de diagrammes, de dessins
vectoriels, de les enregistrer au format XML puis de les exporter.

Figure 3.5 : Logo de Draw

• MobaXterm
MobaXterm est un logiciel de terminal amélioré pour Windows qui offre une solution complète
pour les administrateurs système, les développeurs et les utilisateurs avancés. Il est basé sur
un environnement Unix-like avec des fonctionnalités telles que la prise en charge de multiples
sessions, la gestion des fichiers, le transfert de fichiers sécurisé (FTP, SFTP, SSH, etc.), l’accès à
distance, le partage de sessions, la gestion des tunnels, etc.

Figure 3.6 : Logo de MobaXtrem

• Overleaf
Overleaf est une plateforme en ligne gratuite permettant d’éditer du texte en LaTeX sans
aucun téléchargement d’application. Elle offre la possibilité de rédiger des documents de manière
collaborative et de les compiler en PDF

Figure 3.7 : Logo de Overleaf

14
Chapitre 3. Sprint 0 :Planification du projet

3.3.3 Frameworks et bibliothèques

• Flask
Flask est un framework web léger, flexible et puissant pour Python. Il est conçu pour être facile
à apprendre et à utiliser, tout en offrant une grande extensibilité pour les développeurs avancés.
Flask permet de construire rapidement des applications web de petite à grande échelle, avec
une structure modulaire et une grande variété d’extensions tierces disponibles pour ajouter des
fonctionnalités supplémentaires.

Figure 3.8 : Logo de Overleaf

3.4 Backlog du produit

Le backlog du produit est l’artefact le plus important de Scrum .Il est destiné à recueillir tous
les besoins du client que l’équipe projet doit ré[Link] contient donc la liste des fonctionnalités ou
encore les « User Stories » intervenant dans la constitution d’un produit, ainsi que tous les éléments
nécessitant l’intervention de l’équipe [Link] généralement présenté sous forme de user stories qui
sont priorisées selon l’importance de la fonctionnalité.

— ID :Caractérise la user story par un identifiant unique.

— User-Story :Caractérise la fonctionnalité souhaitée par l’utilisateur.

— Priorité : Caractérise l’importance de la fonctionnalité.

Le tableau 3.2 présent ci-dessous comporte le backlog du produit de notre application. Pour commencer
la réalisation de nos histoires utilisateur, nous avons choisi les cas d’utilisation les plus prioritaires.
Ici nous avons opté pour une échelle de 0 à 2, 0 ayant la priorité la plus élévée

Tableau 3.2 : Backlog produit

ID Thème ID User stories Priorité Estimation

15
Chapitre 3. Sprint 0 :Planification du projet

1 S’authentifier 1.1 En tant qu’utilisateur, je voudrais pouvoir 2 -

me connecter à l’applicarion DH.

2 configuration 2.1 En tant qu’utilisateur, je veux pouvoir 0 -

modifier les informations de la fichier de
configuration sans avoir à quitter l’interface
de l’application, afin de gagner du temps et
de faciliter le processus de modification.

executer la 3.1 En tant qu’utilisateur, je souhaite que 2 -

3
procedure de le système vérifie automatiquement les
l’automatisation paramètres contenus dans le fichier de
de la mise a configuration de l’application
jour DH
3.2 En tant qu’utilisateur, je souhaite que 2 -
le système démarre automatiquement le
serveur et le scheduler.
3.3 En tant qu’utilisateur, je souhaite que le 2 -
système mette en place automatiquement le
package des prérequis à la migration.
3.4 En tant qu’utilisateur, je souhaite que 2 -
le système exécute automatiquement des
tâches pour l’installation des packages de la
migration.

gestion des 4.1 En tant qu’utilisateur, je souhaite que le 2 -

4
erreurs système affiche clairement les erreurs et
les exceptions détectées, afin que je puisse
comprendre rapidement ce qui s’est mal
passé
4.2 En tant qu’utilisateur, je veux que la mise à 2 -
jour soit interrompue automatiquement en
cas d’erreur critique.

16
Chapitre 3. Sprint 0 :Planification du projet

Suivi de la 5.1 En tant qu’utilisateur, je veux pouvoir 2 -

5
mise à jour de visualiser la mise à jour de Datahub étape
Datahub par étape pour suivre le déroulement du
processus de mise à jour.
5.2 En tant qu’utilisateur, je souhaite pouvoir 2 -
accéder facilement aux fichiers journaux de
la mise à jour, afin de pouvoir contrôler plus
précisément le déroulement de la mise à jour.

Reprise mise 6.1 En tant qu’utilisateur, je veux pouvoir 1 -

6
a jour en cas reprendre la mise à jour de Datahub à
erreur partir du point d’arrêt en cas d’erreur pour
garantir la réussite de la mise à jour
6.2 En tant qu’utilisateur, je veux être 0 -
en mesure de corriger le fichier de
configuration de Datahub directement
depuis l’application, sans avoir à quitter
l’interface de l’application pour gagner
du temps et simplifier le processus de
correction.

6 affichage des 6.1 En tant qu’utilisateur, je veux être en 2 -

objets DH mis mesure de visualiser les objets(listes , classes
a jour ,rules) mis à jour dans Datahub pour voir les
éléments qui ont été modifiés.

affichage des 7.1 En tant qu’utilisateur, je veux être en 1 -

indicateur de mesure de voir la durée de la mise à jour
7
consommation de Datahub pour savoir combien de temps il
des ressources faut pour mettre à jour les données.
durant la
migration
7.2 En tant qu’utilisateur, je veux être en 1 -
mesure de connaître la quantité de RAM
utilisée pendant la mise à jour de Datahub.

17
Chapitre 3. Sprint 0 :Planification du projet

7.3 En tant qu’utilisateur, je veux connaître la 1 -

quantité de base de données utilisée pour la
mise à jour de Datahub.
7.4 En tant qu’utilisateur, je veux être en 1 -
mesure de connaître la quantité d’espace
disque utilisée pour la mise à jour de
Datahub.

3.5 Planification des Sprints

L’étape de planification des sprints, est l’une des étapes les plus importants dans la méthodologie
de travail Scrum. Dans le Tableau 3.3 nous allons diviser le projet en Sprints, en spécifiant les cas
d’utilisation correspondant.

18
Chapitre 3. Sprint 0 :Planification du projet

Tableau 3.3 : Planifications des Sprints

Nom du Sprint Cas d’utilisation correspondant

Sprint 1 lancer de la procédure de la migration DH

gestin des erreurs

authentification
Sprint 2
configuration
reprise mis a jour en cas erreur

suivi de la mise a jour de datahub

affichage des objets DH mis a jour
Sprint 3
affichage des indicateur de consommation des
ressources durant la migration

3.6 Diagramme de GANTT

Un diagramme de Gantt est un outil de planification qui permet de suivre l’avancement du

projet en visualisant la durée des différentes tâches. L’importance de ce schéma se résume à ce qu’il
fait, la planification, qui est une étape très importante avant de réaliser un projet. La Figure présente
le diagramme de GANTT de notre projet durant la période du stage

Conclusion

Dans ce chapitre nous avons présenté l’environnement matériel et logiciel que nous préparons
pour la mise en place de notre système, l’architecture physique ainsi que le Backlog produit et la
planification des Sprints, que nous allons entamer dans le chapitre suivant.

19
 Chapitre 4

Réalisation

Plan
1 Choix techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2 Travail réalisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3 Planning réel du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Chapitre 4. Réalisation

Introduction

Introduction partielle, qui annonce le contenu.

4.1 Choix techniques

4.2 Travail réalisé

4.3 Planning réel du projet

Conclusion

Conclusion partielle ayant pour objectif de synthétiser le chapitre et d’annoncer le chapitre

suivant.

21
Conclusion générale

Rappel du contexte et de la problématique.

Brève récapitulation du travail réalisé et de la soultion proposée.

La taille de la conclusion doit être réduite, une page de texte tout au plus. Il est important de
souligner que la conclusion ne comporte pas de nouveaux résultats ni de nouvelles interprétations.

Le plus souvent, la conclusion comporte :

• un résumé très rapide du corps du texte ;

• un rappel des objectifs du projet ;

• un bilan professionnel qui indique clairement les objectifs annoncés dans l’introduction et en
particulier ceux qui n’ont pu être atteints. Il présente et synthétise les conclusions partielles ;

• un bilan personnel qui décrit les principales leçons que vous tirez de cette expérience sur le plan
humain ;

• les limites et les perspectives du travail effectué.

22
Annexes

Annexe 1. Exemple d’annexe

Les chapitres doivent présenter l’essentiel du travail. Certaines informations-trop détaillées ou

constituant un complément d’information pour toute personne qui désire mieux comprendre ou refaire
une expérience décrite dans le document- peuvent être mises au niveau des annexes. Les annexes,
placées après la bibliographie, doivent donc être numérotées avec des titres (Annexe1, Annexe2,
etc.).
Le tableau annexe 1.1 présente un exemple d’un tableau dans l’annexe.
Tableau annexe 1.1 : Exemple tableau dans l’annexe

0 0

1 1

2 2

3 3

4 4

23
Annexes

Annexe 2. Entreprise

La figure annexe 2.1 présente le logo entreprise.

Figure annexe 2.1 : Logo d’entreprise

24
 PÌl›
Lepneumatique T•rJ ¨ Ty›®ˆ³ œ\ž TFdn¡ ¨ ­EA³ Ylˆ rt˜ Š¤rK› ™mˆ r§rqt˜ @¡ Pl§
­C ³ Aylmˆ dyw ¤ œy\n Y˜ , d§d˜ AsF¥m˜ C w› XyW A\ž ºAKž Y˜ ™m`˜ @¡ ‘dh§ . CAV²˜
Ÿ›¤ ºAW± ¨ œkt˜ ¤ ‰§rs˜ šw}w˜A Ÿy›dtsm˜ d§¤z , “ybWt˜ @¡ Ÿ› |rŒ˜ w.T•rK˜ C w› ‰ym˜
Odoo ‰’w› ‰› T•rK˜A T}A˜ §w˜ TkbJ Xr Anm’ , –˜Ð Y˜ TAR³A .Ty›wy˜ Ahm˜ ™ylq , «r
TyAž
.‰’wm˜ ¤ ERP Ÿy XyFw• Middleware A\ž  dtF ºAn

ERP, Odoo, Symfony, Angular, e-commerce, web application. : y Af› Aml•

Résumé
Ce rapport résume le travail effectué dans le cadre du projet de fin d’études pour l’ob- tention du
diplôme Licence en Ingénierie des systèmes informatiques au sein de l’entreprise Lepneumatique.
Ce travail vise à mettre en place un nouveau ERP, afin d’organiser et d’unifier les processus de
gestion de toutes les ressources de l’entreprise. Cette application a pour but, d’une part, d’offrir
aux utilisateurs un accès rapide et un contrôle des erreurs et, d’autre part, de réduire les tâches
quotidiennes. En outre, nous avons lié le site Web de l’entreprise avec Odoo tout en utilisant un
système Middleware en tant qu’intermédiaire entre l’ERP et le site Web.

Mots clés : ERP, Odoo, Symfony, Angular, e-commerce, web application.

Abstract
This report summarizes the work of the graduation project Bachelor’s degree in Com- puter
Systems Engineering at Lepneumatique. This work aims to set up a new ERP, to organize and
unify the management processes of all the company’s resources. The purpose of this application
is, on the one hand, to provide users with quick access and error control and, on the other hand,
to reduce daily tasks. In addition, we linked the company’s web- site with Odoo while using a
Middleware system as an intermediary between the ERP and the website.

Keywords : ERP, Odoo, Symfony, Angular, e-commerce, Application web.

contact@[Link] : ¨ž¤rtk˜¯ d§rb˜ 71 222 222 : H•Af˜ 71 111 111 :  Ah˜ Hžw - ­ryb˜ ‘AfR - C®› ­ry hž
Rue du Lac Malaren, Les Berges du Lac 1053 Tunis Tél : 71 111 111 Fax : 71 222 222 Email : contact@[Link]
isi@[Link] : ¨ž¤rtk˜¯ d§rb˜ 71 706 698 : H•Af˜ 71 706 164 :  Ah˜ TžA§C
2080 ¨ž¤CAb˜ A§r˜ w
hž 2
2, Abou Raihane Bayrouni 2080 l’Ariana Tél : 71 706 164 Fax : 71 706 698 Email : isi@[Link]