Charte de projet

Application Web de Gestion des Événements

Oussema Abdaoui
Ranim Abker
Nour Zrida
Ines Bouderbela
Mohamed Houcine El Gatri

Année Universitaire 2024 - 2025

Table des matières

Introduction générale 1

1 Contexte général 2
1.1 Conception et Infrastructures : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 Conception : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2 Infrastructures : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Devloppement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Introduction : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2 Le Code en tant que Fondation du DevOps : . . . . . . . . . . . . . . . . . . . 5
1.2.3 Les Bonnes Pratiques pour l’Élaboration de Code en DevOps : . . . . . . . . . 5
1.2.4 La Sécurité du Code en DevOps : . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.5 Les Outils pour l’Élaboration de Code en DevOps : . . . . . . . . . . . . . . . 6
1.2.6 Présentation générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 L’intégration continue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1 Les avantages de CI : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.2 Les pipeline de CI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.3 Les outils de CI : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.4 L’importance de test automatisé en CI : . . . . . . . . . . . . . . . . . . . . . . 7
1.3.5 Types de Tests Automatisés : . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 CD/ Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4.1 Déploiement Continu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4.2 Déploiement sans Interruption : . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5 Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6 Etude de cas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6.1 Avant l’adoption de DevOps : . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6.2 Après l’adoption de DevOps : . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.6.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 Analyse et spécification des besoins 11

2.1 Identification des acteurs du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Identification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

ii
 2.2.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Diagramme des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 Sprint 0 :Planification du projet 15

3.1 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3.1 Langage de programmation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3.2 Logiciels et outils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3.3 Frameworks et bibliothèques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.5 Planification des Sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.6 Diagramme de GANTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

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

Conclusion générale 27

Annexes 28
Annexe 1. Exemple d’annexe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Annexe 2. Entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

iii
Table des figures

3.1 Logo Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2 Logo Java Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3 Logo de Visual Studio Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4 Logo de power BI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.5 Logo de Draw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.6 Logo de MobaXtrem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.7 Logo de Overleaf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.8 Logo de Overleaf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Annexe 2.1 Logo d’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

iv
Liste des tableaux

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

3.2 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3 Planifications des Sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

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

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 Conception et Infrastructures : . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Devloppement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 L’intégration continue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

4 CD/ Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

5 Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

6 Etude de cas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Chapitre 1. Contexte général

Introduction

DevOps est une méthodologie de développement logiciel qui a émergé pour répondre aux défis de
l’industrie informatique en intégrant le développement logiciel (Dev) avec les opérations informatiques
(Ops). Cette approche vise à améliorer la collaboration, l’efficacité et la productivité des équipes de
développement en encourageant une culture de travail plus intégrée et en favorisant l’automatisation
des processus.
Le concept de DevOps est apparu pour la première fois autour des années 2007-2008. Il a été
popularisé par des praticiens et des leaders de l’industrie comme Patrick Debois et Andrew Clay Shafer,
qui ont organisé des conférences et des discussions autour de la convergence du développement logiciel
et des opérations informatiques.
DevOps repose sur des principes fondamentaux tels que l’automatisation des processus, la
collaboration étroite entre les équipes de développement et d’opérations, l’utilisation d’outils et de
pratiques pour accélérer la livraison des logiciels, la mise en place de l’intégration continue et du
déploiement continu, et une approche axée sur l’amélioration continue (Kaizen). Il vise à réduire les
silos organisationnels, à optimiser les processus, et à favoriser une livraison logicielle plus rapide, plus
stable et de meilleure qualité.
Le terme "DevOps" lui-même est un néologisme issu de la fusion de "Development" et "Operations",
soulignant ainsi la collaboration étroite entre les équipes de développement et d’opérations pour créer
un écosystème logiciel plus efficace et agile.

1.1 Conception et Infrastructures :

1.1.1 Conception :

La phase de conception est l’une des étapes fondamentales du cycle de développement de

logiciels, et c’est là que tout commence. Dans le cadre de DevOps, cette phase est cruciale car elle
établit les bases de tout le processus de développement, de déploiement et de gestion de l’infrastructure.

• Définition des Besoins du Logiciel : Tout commence par comprendre les besoins du logiciel.
Cela implique d’identifier les fonctionnalités requises, les performances attendues, les contraintes
budgétaires, les délais de livraison, et d’autres exigences spécifiques. Ces besoins serviront de
guide tout au long du projet.

• Conception du Logiciel : Une fois les besoins clarifiés, on passe à la phase de conception
proprement dite. Ici, les développeurs, les architectes et d’autres parties prenantes travaillent
ensemble pour élaborer la structure globale du logiciel. Cela inclut la conception des composants,

3
Chapitre 1. Contexte général

des modules, de l’architecture globale, et parfois des schémas de base de données.

• Collaboration Développeurs-Opérationnels : La particularité de DevOps réside dans la

collaboration précoce entre les développeurs et les opérationnels. Les équipes de développement
et d’opérations travaillent de concert pour s’assurer que la conception du logiciel tient compte des
besoins opérationnels. Cela signifie prendre en compte des considérations telles que la scalabilité,
la disponibilité, la sécurité, la performance, et la gestion de l’infrastructure dès la phase de
conception.

• Conception en tant que Code (IaC) : Dans le contexte de DevOps, l’approche "Conception
en tant que Code" (IaC) est particulièrement importante pour l’infrastructure. Plutôt que de
concevoir manuellement des serveurs et des ressources, IaC consiste à définir l’infrastructure
nécessaire sous forme de code informatique. Cette approche permet une gestion automatisée,
reproductible et évolutive de l’infrastructure. Les outils IaC tels que Terraform et Ansible sont
utilisés pour décrire l’infrastructure comme du code, facilitant ainsi son déploiement, sa maintenance
et son évolution. En résumé, la phase de conception dans le contexte de DevOps consiste à
planifier le logiciel, à collaborer dès le début entre les développeurs et les opérationnels, et à
adopter l’approche IaC pour garantir que les besoins opérationnels sont pris en compte et que
l’infrastructure est gérée de manière automatisée et reproductible. Cette approche contribue à
éviter des problèmes potentiels plus tard dans le cycle de développement.

1.1.2 Infrastructures :

• Gestion des Infrastructures : Cloud, Virtualisation et Sécurité Provisionnement

sur Demande Dans l’environnement informatique actuel, le provisionnement sur demande
est essentiel. Il permet de mettre en place des ressources informatiques, telles que des
serveurs, des bases de données et des réseaux, en fonction des besoins de manière instantanée.
- Les services basés sur le cloud, tels que AWS, Azure et Google Cloud, offrent des capacités
de provisionnement sur demande, permettant aux organisations de réduire les coûts et de
s’adapter rapidement aux changements.

• Gestion des Services : La gestion des services est la clé pour garantir que les ressources
informatiques sont utilisées de manière efficace. Les équipes informatiques doivent gérer
l’allocation des ressources, le suivi des performances, et la résolution des problèmes. Les
outils de gestion des services, tels que ITIL (Information Technology Infrastructure Library),
aident à organiser et à améliorer la prestation des services informatiques.

• Virtualisation : La virtualisation permet de créer des environnements informatiques

4
Chapitre 1. Contexte général

virtuels, ce qui optimise l’utilisation des ressources matérielles. Cela permet d’exécuter
plusieurs systèmes d’exploitation sur un seul serveur physique. - Des technologies telles
que les hyperviseurs et les conteneurs (comme Docker) sont couramment utilisées pour la
virtualisation.

• Sécurité Matérielle et de l’Information : La sécurité est un aspect critique de la gestion

des infrastructures. Elle englobe la protection des données, la surveillance des menaces
et la gestion des accès. - Les mesures de sécurité matérielles, telles que les pare-feu, les
contrôles d’accès physique, et la sécurité des serveurs, sont complémentaires à la sécurité de
l’information, qui protège les données sensibles et les communications.

• Outils "As Code" : - Les outils "as code" sont essentiels pour automatiser la gestion de
l’infrastructure. Ils permettent de décrire et de gérer l’infrastructure sous forme de code
informatique. - Des outils populaires comme Terraform et Ansible sont utilisés pour

1.2 Devloppement logiciel

1.2.1 Introduction :

La phase de développement dans DevOps est l’étape où les développeurs travaillent sur la création
de nouvelles fonctionnalités ou la modification de celles existantes dans le logiciel

1.2.2 Le Code en tant que Fondation du DevOps :

Le code source correspond au texte d’écriture du logiciel dans un langage compréhensible par
l’homme, c’est-à-dire dans l’un des nombreux langages informatiques aujourd’hui utilisés par les
développeurs (ex : Java, C++, Python, PHP. . .).

1.2.3 Les Bonnes Pratiques pour l’Élaboration de Code en DevOps :

L’automatisation informatique consiste à utiliser des logiciels pour créer des instructions et des
processus reproductibles dans le but de réduire les interventions humaines ou de les remplacer
par des systèmes informatiques

1.2.4 La Sécurité du Code en DevOps :

Les processus DevOps requièrent des identifiants dit ‘à privilèges’, accès spéciaux très puissants,
censés être sécurisés qui sont la cible des cyberattaques. La gestion de ces accès est un enjeu, que
ce soit : Les accès humains dans les environnements de développement et de production et Les

5
Chapitre 1. Contexte général

accès machine pour accéder aux ressources sans intervention humaine.

1.2.5 Les Outils pour l’Élaboration de Code en DevOps :

La première étape d’une collaboration Devops est d’aligner les équipes de développement et les ops
sur un même outil de gestion de code source. Cela permet de connaître les différentes modifications
du code et les auteurs de celles-ci. Il s’agit d’un outil de versionning : toute modification de code
entraîne la création d’une nouvelle version. Il y a deux types de gestions de code : Les outils
comme Git et Subversion, qui servent à créer un historique en temps réel de ses fichiers et Les
outils comme Github , Gitlab et Bitbucket qui servent à partager son code, et donc l’historique
qui va avec. Ils sont basés sur Git et il est possible d’avoir l’historique du code et de travailler à
plusieurs dessus.

1.2.6 Présentation générale

1.3 L’intégration continue

L’intégration continue (CI) en DevOps, c’est l’automatisation de l’intégration fréquente des

changements de code avec des tests automatiques pour assurer une meilleure qualité du logiciel.

1.3.1 Les avantages de CI :

L’intégration continue offre plusieurs avantages, notamment :

• Détection précoce des erreurs : Elle permet de repérer rapidement les problèmes de
code, ce qui facilite leur résolution et réduit les coûts de correction.

• Amélioration de la qualité du logiciel : En exécutant des tests automatisés à chaque

intégration, l’IC garantit que le logiciel fonctionne correctement, évitant ainsi les régressions.

• Collaboration efficace : Les développeurs peuvent travailler de manière plus coordonnée,

en partageant régulièrement leurs modifications de code, ce qui favorise une meilleure
communication et une collaboration plus étroite.

• Feedback immédiat : Les développeurs reçoivent rapidement des commentaires sur leur
code, ce qui les aide à s’améliorer et à éliminer les erreurs plus tôt dans le processus.

1.3.2 Les pipeline de CI

Il s’agit d’une série d’étapes et de tâches automatisées qui sont exécutées chaque fois qu’un
développeur effectue une modification de code.

6
Chapitre 1. Contexte général

• Compilation (Build) : Cette étape compile le code source pour créer l’application ou le
logiciel. Cela inclut généralement la compilation du code source, la génération de fichiers
exécutables ou d’artefacts, et d’autres tâches nécessaires.

• Tests unitaires : Des tests automatisés sont exécutés pour vérifier la fonctionnalité des
unités de code individuelles, telles que les fonctions ou les classes.

• Analyse statique du code Des outils d’analyse statique du code sont utilisés pour
identifier des problèmes potentiels de qualité du code, tels que des violations de style, des
erreurs de programmation courantes, ou des vulnérabilités.

• Tests d’intégration : Des tests sont effectués pour s’assurer que les différentes parties de
l’application fonctionnent correctement ensemble.

Remarque : On peut dire que la CI ne se limite pas à un seul pipeline, mais peut plutôt inclure
plusieurs pipelines, chacun dédié à un aspect spécifique du développement logiciel, tels que le
développement, les tests, la sécurité etc.

1.3.3 Les outils de CI :

Certains des outils de CI populaires incluent Jenkins, Travis CI, CircleCI, GitLab CI/CD, et
TeamCity , parmi d’autres. Ces outils permettent aux équipes de développement de travailler de
manière collaborative, de tester automatiquement leur code et de le déployer plus efficacement.

1.3.4 L’importance de test automatisé en CI :

les tests automatisés en CI sont un pilier du processus de développement DevOps, contribuant

à la qualité du code, à l’efficacité, à la confiance dans les mises à jour, à la collaboration et à la
réduction des risques, ce qui permet d’offrir des logiciels de meilleure qualité plus rapidement.

1.3.5 Types de Tests Automatisés :

• Tests unitaires : on teste chaque morceau de code de manière isolée pour vérifier qu’il
produit les résultats attendus.

• Tests d’intégration : Les tests d’intégration visent à évaluer la manière dont différentes
unités ou composants d’un système interagissent ensemble pour garantir son bon fonctionnement
dans son ensemble.

• Tests de système : Les tests de système consistent à évaluer l’ensemble d’un système ou
d’une application dans son environnement réel pour s’assurer qu’il répond aux exigences et
fonctionne correctement avant sa mise en production.

7
Chapitre 1. Contexte général

• Tests de régression : Les tests de régression sont utilisés pour vérifier qu’une modification
récente du code n’a pas introduit de nouveaux bugs ou affecté négativement des fonctionnalités
existantes dans un logiciel en revenant sur des tests préexistants.

Outils de Tests Automatisés : Selenium, JUnit, TestNG, Robot Framework, etc.

1.4 CD/ Deployment

1.4.1 Déploiement Continu

1.4.1.1 Définition de Déploiement Continu

Le Déploiement Continu (CD) est une pratique essentielle de DevOps qui consiste à automatiser
le déploiement de chaque modification de code validée dans un environnement de production.

1.4.1.2 Objectif du CD :

L’objectif principal du CD est d’assurer que les modifications de code passent rapidement et en
toute sécurité de l’environnement de développement à la production, sans intervention manuelle.

1.4.1.3 les étapes du CD :

Déploiement automatique : déployée l’application dans l’environnement de production, y

compris la création de nouvelles instances d’application et la bascule du trafic vers la nouvelle
version. Tests de validation en production : Des tests de validation en production sont
exécutés pour s’assurer que l’application fonctionne correctement dans l’environnement de production.
Cela peut inclure des tests de charge, des tests de sécurité et d’autres tests pertinents.

1.4.1.4 Avantages du CD :

• Rapidité : Le CD permet de réduire considérablement les délais entre le développement et

la mise en production

• Fiabilité : L’automatisation du déploiement réduit les erreurs humaines, ce qui améliore la

fiabilité et la stabilité du logiciel en production.

• Réduction des risques : Le CD facilite le rollback automatique en cas de problème,

minimisant ainsi les risques associés aux déploiements.

• Rétroaction rapide : En cas de problème, les équipes obtiennent rapidement des retours
d’information, ce qui permet des corrections rapides.

8
Chapitre 1. Contexte général

1.4.1.5 Exemples d’outils de CD :

- Il existe de nombreux outils de déploiement continu disponibles, notamment Jenkins, CircleCI,

GitLab CI/CD, et bien d’autres. Ces outils permettent d’automatiser le processus de déploiement.

1.4.2 Déploiement sans Interruption :

1.4.2.1 Definition :

C’est une pratique de deploiement qui permet de maintenir la disponibilité du service pendant
les mises à jour, ce qui est essentiel pour les applications nécessitant une disponibilité continue.

1.4.2.2 Difference entre Déploiement sans Interruption et CD :

Le CD vise à déployer rapidement chaque modification, ce qui peut entraîner des interruptions
temporaires, et le Déploiement sans Interruption garantissant une disponibilité continue du
service lors des mises à jour. Le choix entre ces deux approches dépend des besoins spécifiques
de l’application et des préoccupations en matière de disponibilité.

1.5 Maintenance

1.6 Etude de cas

À un moment donné de son histoire, Amazon était déjà un géant du commerce en ligne, mais
l’entreprise était confrontée à certains défis dans le domaine du développement logiciel. Voici
comment les choses se passaient avant l’adoption de DevOps :

1.6.1 Avant l’adoption de DevOps :

• Livraisons peu fréquentes : Amazon avait du mal à livrer rapidement de nouvelles

fonctionnalités et des correctifs logiciels en raison de processus manuels, de tests longs et de
déploiements coûteux. jour.

• Complexité opérationnelle : Avec une infrastructure de grande envergure, la gestion des

opérations informatiques était devenue complexe et sujette à des erreurs humaines.

• Incapacité à gérer la montée en charge : Les périodes de trafic intense, telles que le
Black Friday, posaient des problèmes d’évolutivité et de disponibilité du site.

9
Chapitre 1. Contexte général

1.6.2 Après l’adoption de DevOps :

Amazon a entrepris une transformation en adoptant DevOps, et les résultats ont été remarquables :

• Livraisons continues : Amazon a mis en place un pipeline de livraison continue (CI/CD)

qui lui permet de déployer de nouvelles fonctionnalités en production de manière continue.
Cela a renforcé la réactivité aux besoins des clients.

• Automatisation à grande échelle : Amazon a automatisé massivement ses processus

de déploiement, de gestion des infrastructures et de surveillance. Cela a considérablement
réduit les erreurs humaines et accéléré le déploiement de logiciels.

• Évolutivité améliorée : En utilisant des services de cloud computing, tels qu’Amazon

Web Services (AWS), Amazon peut s’adapter rapidement aux variations de trafic. Cela leur
a permis de gérer les pics de trafic pendant les événements de vente sans interruption de
service.

• Collaboration étroite : Amazon a encouragé la collaboration entre les équipes de développement,

d’exploitation et de sécurité. Les équipes partagent la responsabilité de l’ensemble du cycle
de vie des applications.

• Retour sur investissement élevé : La mise en œuvre de DevOps a permis à Amazon de

réduire les coûts d’exploitation tout en augmentant la qualité des services proposés. Cela a
contribué de manière significative à la rentabilité de l’entreprise.

1.6.3 Conclusion

L’adoption de DevOps a joué un rôle clé dans la croissance et le succès continu d’Amazon en
tant qu’une des plus grandes entreprises technologiques au monde. Grâce à DevOps, Amazon a
réussi à améliorer la rapidité, la qualité et la fiabilité de ses services tout en réduisant les coûts
opérationnels, ce qui constitue un exemple convaincant de l’impact de DevOps dans le monde
des affaires.

Conclusion

Ce premier chapitre a été consacré à la présentation de l’organisme d’acceuil et la mise du projet

dans son cadre général, en introduisant les problèmes à résoudre et les objectifs du projet. Nous
avons aussi annoncé la démarche qui va être suivie tout au long de ce projet. Nous passons par
la suite à étudier et à analyser les spécifications des besoins.

10
 Chapitre 2

Analyse et spécification des besoins

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

2 Identification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . 12

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

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

12
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.

13
Chapitre 2. Analyse et spécification des besoins

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 : ************

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.

14
 Chapitre 3

Sprint 0 :Planification du projet

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

2 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5 Planification des Sprints . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6 Diagramme de GANTT . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
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

16
Chapitre 3. Sprint 0 :Planification du projet

notre environnement matériel est constitué par un ordinateur portable ayant les caractéristiques
présentées 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 interactives.Il 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,
Vue.js, Node.js, etc., qui peuvent être utilisés pour simplifier et accélérer le processus de
développement.

17
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

• Draw.io

18
Chapitre 3. Sprint 0 :Planification du projet

raw.io est une application gratuite en ligne qui permet de dessiner des diagrammes ou des
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

19
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éaliser.Il 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 projet.est 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

20
Chapitre 3. Sprint 0 :Planification du projet

ID Thème ID User stories Priorité Estimation

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.

21
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 ,
a jour classes ,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
des ressources il faut pour mettre à jour les données.
durant la
migration

22
Chapitre 3. Sprint 0 :Planification du projet

7.2 En tant qu’utilisateur, je veux être 1 -

en mesure de connaître la quantité de
RAM utilisée pendant la mise à jour de
Datahub.
7.3 En tant qu’utilisateur, je veux connaître 1 -
la 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.

23
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.

24
 Chapitre 4

Réalisation

Plan
1 Choix techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2 Travail réalisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

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

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.

26
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é.

27
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

28
Annexes

Annexe 2. Entreprise

La figure annexe 2.1 présente le logo entreprise.

Figure annexe 2.1 : Logo d’entreprise

29
 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@company.com : ¨ž¤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@company.com
isi@isim.rnu.tn : ¨ž¤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@isim.rnu.tn