‫ﺍلجمهوﺭ ية ﺍلشعبية ﺍلديمقرﺍطية ﺍلجزﺍئر ية‬

République Algérienne Démocratique et Populaire

‫وﺯﺍﺭﺓ ﺍلتعليم ﺍلعالي و ﺍلبحث ﺍلعلمي‬
Ministère de l’Enseignement Supérieur et de la Recherche Scientifique
‫ بسيدي بلعباﺱ‬.5491 ‫ ماي‬٠80 ‫ﺍلمدﺭسة ﺍلعليا للإعلام ﺍلآلي‬
École Supérieure en Informatique
-08 Mai 1945- Sidi Bel Abbès

MEMOIRE
En vue de l’obtention du diplôme d’ingénieur d’état
Filière: Informatique
Spécialité: Système D’information et Web (SIW)

Thème

Migration d’une application monolithique vers une

architecture microservices : Étude de cas et
implémentation pour une plateforme éducative web

Présenté par:
AOUADJ Moncef

Date de soumission: Sept, 2023

Devant le jury composé de:

Mr. Someone President

Ms. Someone Co-Supervisor
Ms. someone Supervisor
Mr. Someone Examiner

Année Universitaire : 2023/2024

 Remerciements

Je tiens tout d’abord à exprimer ma profonde gratitude à ALLAH le Tout-Puissant, qui

m’a accordé la volonté, la patience, et la lumière nécessaires pour mener à bien ce travail de
mémoire.
Je souhaite également remercier chaleureusement mes encadrants de mémoire, M. Chouki
Tibermacine, M. Vincent Berry du LIRMM et M. Malki Abdelhamid de l’ESI-SBA.
Leur guidance précieuse, leurs encouragements constants, et leurs conseils avisés ont été in-
dispensables à l’aboutissement de ce projet. Je les remercie sincèrement pour le temps et
l’attention qu’ils m’ont consacrés.
Mes remerciements vont également à toute l’équipe du département d’informatique de
l’ESI-SBA, ainsi qu’à l’équipe du LIRMM. Leur soutien pédagogique et leur disponibilité
ont grandement facilité mon parcours.
Je tiens à exprimer ma reconnaissance aux membres du jury pour l’honneur qu’ils m’ont
fait en acceptant de juger et d’évaluer mon travail. Leurs retours seront pour moi une source
précieuse d’amélioration.
Je n’oublie pas de remercier tous ceux qui m’ont aidé, de près ou de loin, dans la réalisation
de ce mémoire. Leur aide a été précieuse et je leur en suis profondément reconnaissant.
Enfin, j’adresse mes remerciements les plus sincères à ma famille et à mes amis, qui m’ont
accompagné, soutenu et encouragé tout au long de cette aventure académique. Leur présence
à mes côtés a été une source inestimable de force et de motivation.

1
 Resumé

Face à la complexité croissante des applications logicielles modernes, les défis liés à leur
développement, déploiement et maintenance sont devenus plus pressants. L’architecture mi-
croservices, en décomposant les applications en services indépendants, se présente comme une
solution efficace pour améliorer la flexibilité, l’évolutivité et la maintenabilité des systèmes.

Ce mémoire traite de la migration de l’application éducative ”ShellOnYou” d’une archi-

tecture monolithique vers une architecture microservices. Le processus de migration a permis
de redéfinir l’application en plusieurs services autonomes, chacun responsable d’une partie
spécifique des fonctionnalités globales. Cette restructuration a non seulement facilité la ges-
tion et le déploiement de l’application, mais a également amélioré sa capacité à évoluer avec
les besoins futurs.

En conclusion, la transition vers une architecture microservices a renforcé la performance

globale et la maintenabilité de l’application ”ShellOnYou”, tout en posant les bases pour des
évolutions futures. Les perspectives d’amélioration comprennent l’exploration de nouvelles
technologies et l’optimisation continue des services.

2
 Abstract

In the face of the growing complexity of modern software applications, the challenges related
to their development, deployment, and maintenance have become increasingly pressing. The
microservices architecture, which breaks down applications into independent services, offers
an effective solution to enhance the flexibility, scalability, and maintainability of systems.

This thesis addresses the migration of the educational application ”ShellOnYou” from
a monolithic architecture to a microservices architecture. The migration process involved
redefining the application into several autonomous services, each responsible for a specific
part of the overall functionality. This restructuring not only facilitated the management and
deployment of the application but also improved its ability to evolve with future needs.

In conclusion, the transition to a microservices architecture strengthened the overall per-

formance and maintainability of the ”ShellOnYou” application, while laying the foundation
for future developments. The improvement prospects include exploring new technologies and
the continuous optimization of services.

3
 CONTENTS

I Introduction 11

1 Introduction 12
1.1 Contexte et Présentation Générale . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2 Motivation et Énoncé du Problème . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3 Objectifs du Mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4 Plan de la Thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

II Background 14

2 Architecture Monolithique 15
2.1 Introduction à l’Architecture Monolithique . . . . . . . . . . . . . . . . . . . . 15
2.2 Structure et Composants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Avantages et Utilisation Initiale . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Défis et Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.1 Pile Technologique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.2 Scalabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.3 Gestion des Changements et Maintenance . . . . . . . . . . . . . . . 18
2.4.4 Déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.5 Dette Architecturale et Silos de Données . . . . . . . . . . . . . . . . 18

3 Architecture SOA 19
3.1 Principes et Pratiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.1 Caractéristiques de SOA . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.2 Pratiques Courantes . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 Catégories de Services en SOA . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4
4 Architecture Microservices 21
4.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2 Les Caractéristiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3 Avantages et Inconvénients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5 Comparaison Entre Monolithique, SOA et Microservices 24

6 Les Patterns des Microservices 27

6.1 Les Patterns de Décomposition . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.1.1 Pattern de Décomposition par Capacité Commerciale . . . . . . . . . 27
6.1.2 Pattern de Décomposition par Sous-Domaine . . . . . . . . . . . . . 27
6.1.3 Nouveaux Patterns de Décomposition . . . . . . . . . . . . . . . . . . 28
6.2 Les Patterns De Messagerie Transactionnelle . . . . . . . . . . . . . . . . . . . 28
6.2.1 Pattern Boîte D’envoi Transactionnelle . . . . . . . . . . . . . . . . . 28
6.2.2 Pattern Journal Des Transactions . . . . . . . . . . . . . . . . . . . . 28
6.2.3 Pattern Éditeur De Sondage . . . . . . . . . . . . . . . . . . . . . . . 29
6.3 Les Patterns de Gestion de Données . . . . . . . . . . . . . . . . . . . . . . . 29
6.3.1 Pattern de Base de Données pour Chaque Service . . . . . . . . . . . 29
6.3.2 Pattern de Base de Données Partagée . . . . . . . . . . . . . . . . . . 29
6.3.3 Pattern SAGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.4 Les Patterns de Déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.4.1 Pattern Multi-Service par Hôte . . . . . . . . . . . . . . . . . . . . . 30
6.4.2 Pattern Un Seul Service par Hôte . . . . . . . . . . . . . . . . . . . . 31
6.5 Les Patterns d’API Externes . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.5.1 API-Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.5.2 API-Gateway / Backends Pour Frontends (BFF) . . . . . . . . . . . 32
6.6 Les Patterns de Découverte de Service . . . . . . . . . . . . . . . . . . . . . . 33
6.6.1 Pattern de Découverte Côté Client . . . . . . . . . . . . . . . . . . . 33
6.6.2 Pattern de Découverte Côté Serveur . . . . . . . . . . . . . . . . . . 33
6.6.3 Pattern Registre de Services . . . . . . . . . . . . . . . . . . . . . . . 34
6.7 Les Patterns de Sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.7.1 Pattern d’Authentification par Jeton . . . . . . . . . . . . . . . . . . 34
6.7.2 Pattern de Porte de Sécurité (Security Gateway) . . . . . . . . . . . 35
6.7.3 Pattern de Chiffrement des Données . . . . . . . . . . . . . . . . . . 35
6.7.4 Pattern d’Audit et de Suivi . . . . . . . . . . . . . . . . . . . . . . . 36

5
III Contribution 37

7 Introduction 38

8 Présentation du Système 39
8.1 Introduction à ShellOnYou . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.2 Fonctionnement général . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
8.2.1 Architecture Monolithique de l’Application ShellOnYou (SOY) . . . . 40
8.2.1.1 SOY Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 40
8.2.1.2 SOY Controller . . . . . . . . . . . . . . . . . . . . . . . . . 40
8.2.1.3 SOY Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.2.1.4 SOY Database . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.2.2 Intégration et interactions . . . . . . . . . . . . . . . . . . . . . . . . 42
8.2.3 Problèmes de performance . . . . . . . . . . . . . . . . . . . . . . . . 42
8.2.4 Conséquences et anticipation . . . . . . . . . . . . . . . . . . . . . . 43
8.3 Évolution et Améliorations des Versions Précédentes . . . . . . . . . . . . . . 43
8.3.1 Ajout de Fonctionnalités: . . . . . . . . . . . . . . . . . . . . . . . . 43
8.3.2 Mise à jour de l’Interface Utilisateur: . . . . . . . . . . . . . . . . . . 43
8.3.3 Stabilité du Stack Technologique: . . . . . . . . . . . . . . . . . . . . 44
8.3.4 Incrémentation Basée sur les Retours: . . . . . . . . . . . . . . . . . 44
8.3.5 Visualisation des Données: . . . . . . . . . . . . . . . . . . . . . . . . 44
8.4 De Monolithique (v6) à Microservices (v7) . . . . . . . . . . . . . . . . . . . . 44
8.4.1 Analyse Initiale et Décision de Migration . . . . . . . . . . . . . . . . 44
8.4.2 Domain-Driven Design (DDD) . . . . . . . . . . . . . . . . . . . . . . 46
8.4.2.1 Application du Domain-Driven Design (DDD) dans notre
Projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
8.4.2.2 Identification des Domaines Contextuels . . . . . . . . . . . 47
8.4.2.2.1 1. Contexte des Utilisateurs . . . . . . . . . . . . . 47
8.4.2.2.2 2. Contexte des Compétences . . . . . . . . . . . . 47
8.4.2.2.3 3. Contexte des Étudiants et de leurs Productions . 47
8.4.2.2.4 4. Contexte des Enseignants et des Exercices (ms-
exercise-teacher) . . . . . . . . . . . . . . . . . . . 48
8.4.2.3 Bénéfices du DDD dans la Migration vers les Microservices . 48
8.4.3 Analyse Statique du Code . . . . . . . . . . . . . . . . . . . . . . . . 49
8.4.4 Tableau de Transaction . . . . . . . . . . . . . . . . . . . . . . . . . 49
8.4.4.1 Ms-exercise-4-teacher . . . . . . . . . . . . . . . . . . . . . . 49
8.4.4.2 Ms-exercise-4-student . . . . . . . . . . . . . . . . . . . . . . 54
8.4.4.3 Ms-user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6
 8.4.4.4 Ms-skill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
8.4.5 Définition des Microservices . . . . . . . . . . . . . . . . . . . . . . . 66
8.4.6 Visualisation de l’Architecture . . . . . . . . . . . . . . . . . . . . . . 67

9 Refonte Technique 70
9.1 Migration de JavaScript à TypeScript . . . . . . . . . . . . . . . . . . . . . . 70
9.1.1 Contexte JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
9.1.2 Introduction à TypeScript . . . . . . . . . . . . . . . . . . . . . . . . 70
9.1.3 Avantages de TypeScript . . . . . . . . . . . . . . . . . . . . . . . . . 71
9.1.4 Défis de la Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
9.2 Introduction de la Couche Service . . . . . . . . . . . . . . . . . . . . . . . . . 71
9.2.1 Structure de Microservice . . . . . . . . . . . . . . . . . . . . . . . . 71
9.3 Impact de la Refonte sur la Performance et la Maintenabilité . . . . . . . . . . 72

10 Analyse du Résultat 73
10.1 Analyse du Résultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
10.2 SonarQube: Un Outil d’Analyse de Code . . . . . . . . . . . . . . . . . . . . . 73
10.3 Résultats de l’Analyse SonarQube . . . . . . . . . . . . . . . . . . . . . . . . . 73
10.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

11 Déploiement des Microservices avec Kubernetes 75

11.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
11.2 Développement des Microservices . . . . . . . . . . . . . . . . . . . . . . . . . 75
11.3 Création des Images Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
11.4 Gestion des Services Kubernetes . . . . . . . . . . . . . . . . . . . . . . . . . 76
11.5 Gestion des Variables d’Environnement . . . . . . . . . . . . . . . . . . . . . . 76
11.6 Reconstruction et Redéploiement des Microservices . . . . . . . . . . . . . . . 76
11.7 Tests et Vérifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

12 Création des Guides d’Installation (V6 et V7) 78

12.1 Guide d’Installation V6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
12.2 Guide d’Installation V7 (Post-Migration) . . . . . . . . . . . . . . . . . . . . . 79

13 Gestion de Projet 80
13.1 Organisation des Tâches avec Trello et GitLab Issues . . . . . . . . . . . . . . 80
13.1.1 Trello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
13.1.2 GitLab Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
13.2 Communication et Collaboration avec Mattermost . . . . . . . . . . . . . . . . 81
13.3 Réunions Virtuelles avec Zoom . . . . . . . . . . . . . . . . . . . . . . . . . . 82

7
 13.4 Bilan de la Gestion de Projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

14 Environnement et Outils de Développement 83

14.1 Environnement Matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
14.2 Environnement logiciel (Langages, Bibliothèques et Frameworks) . . . . . . . . 83
14.2.1 Node.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
14.2.2 React . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
14.2.3 PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
14.2.4 Visual Studio Code (VSCode) . . . . . . . . . . . . . . . . . . . . . . 84
14.2.5 Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
14.2.6 GitLab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

IV Conclusion et perspectives 86

15 Conclusion et perspectives 87
15.1 Récapitulatif des Principales Réalisations . . . . . . . . . . . . . . . . . . . . . 87
15.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Bibliography 90

8
 LIST OF FIGURES

2.1 Modèle générique d’architecture monolithique . . . . . . . . . . . . . . . . . 16

2.2 Scalabilité horizontale d’un monolithe . . . . . . . . . . . . . . . . . . . . . . 17

3.1 Architecture SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1 Exemple d’une architecture Microservices . . . . . . . . . . . . . . . . . . . . 21

6.1 Resumer de tous les patterns de microservices . . . . . . . . . . . . . . . . . 36

8.1 Schéma général de l’architecture monolithique de l’application ShellOnYou . 41

8.2 schéma de la base de données de la v6 . . . . . . . . . . . . . . . . . . . . . 45
8.3 schéma simplifié DB v6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
8.4 Segmentation de l’Application Monolithique en Microservices avec Domain-
Driven Design (DDD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
8.5 Vue simplifiée de la décomposition en microservices de l’application ShellOnYou 68
8.6 Vue détaillée de la décomposition en microservices de l’application ShellOnYou,
montrant les interactions détaillées entre les entités . . . . . . . . . . . . . . 69

9.1 Structure du microservice Ms-skill illustrant l’organisation des composants

internes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

10.1 Résultats SonarQube : Front, Gateway, Student . . . . . . . . . . . . . . . . 74

10.2 Analyse SonarQube : ms-skill . . . . . . . . . . . . . . . . . . . . . . . . . . 74
10.3 SonarQube : Student et Teacher . . . . . . . . . . . . . . . . . . . . . . . . . 74
10.4 SonarQube : Skill, User, Aggregate . . . . . . . . . . . . . . . . . . . . . . . 74

11.1 Exemple de fichier deployment.yaml (ms-user-deployment.yaml) . . . . . . . 77

13.1 Vue de l’espace de travail Trello . . . . . . . . . . . . . . . . . . . . . . . . . 81

13.2 Aperçu de la gestion des tâches dans GitLab . . . . . . . . . . . . . . . . . . 81

9
 LIST OF TABLES

5.1 Comparaison des architectures Monolithique, SOA et Microservices . . . . . 26

8.1 Transactions du microservice ms-exercise-4-teacher . . . . . . . . . . . . . . 54

8.2 Transactions du microservice ms-exercise-4-student . . . . . . . . . . . . . . 57
8.3 Transactions du microservice ms-user . . . . . . . . . . . . . . . . . . . . . . 62
8.4 Transactions du microservice ms-skill . . . . . . . . . . . . . . . . . . . . . . 66

10
 Part I

Introduction

11
Section 1

Introduction

1.1 Contexte et Présentation Générale

L’évolution rapide des technologies web a constamment poussé les développeurs et archi-
tectes logiciels à rechercher des solutions plus efficaces pour la gestion et la maintenance des
applications complexes. Dans ce contexte, l’application ShellOnYou, dédiée à l’apprentissage
du Shell Unix, a été développée initialement avec une architecture monolithique, en utilisant
des technologies telles que NodeJS, Python, et des vues EJS. Cependant, avec l’accroisse-
ment du nombre d’utilisateurs et des exigences en termes de performance, cette architecture a
montré ses limites, notamment lors des sessions intenses d’utilisation simultanée par plusieurs
dizaines d’étudiants.

12
1.2 Motivation et Énoncé du Problème
Les architectures monolithiques, bien qu’efficaces pour les petites applications ou les pro-
totypes, présentent des défis significatifs en termes de scalabilité et de maintenance, par-
ticulièrement sous des charges élevées. Pour ShellOnYou, les problèmes de performance
étaient principalement dus aux appels système bloquants effectués par des scripts Python
pour évaluer les réponses des étudiants. Ce ”goulot d’étranglement” a rendu impératif une
réévaluation de l’architecture sous-jacente. La motivation derrière cette migration était donc
double : améliorer la performance et la scalabilité de l’application tout en facilitant son
déploiement et sa maintenance.

1.3 Objectifs du Mémoire

Ce mémoire vise à documenter le processus de transition de ShellOnYou vers une architec-
ture microservices, en mettant l’accent sur la méthodologie de migration, les défis rencontrés,
et les solutions apportées. Les objectifs spécifiques incluent :

• Implémentation du pattern ”Database-per-service” pour améliorer l’encapsulation et la

gestion des données.

• Adoption de l’architecture microservices pour faciliter le déploiement indépendant des

services et améliorer la résilience de l’application.

• Évaluation des performances avant et après la migration pour quantifier les améliora-
tions apportées.

1.4 Plan de la Thèse

Le mémoire est structuré comme suit pour guider le lecteur à travers les différentes phases
du projet :

• Théorie Pertinente et Contexte : Présentation des fondements théoriques des

architectures monolithiques et microservices, et leur comparaison.

• Notre Contribution : Détail de la planification, la conception, et l’implémentation

de la migration, y compris les technologies utilisées et les défis techniques surmontés.

• Conclusion et Perspectives : Synthèse des travaux réalisés, évaluation des objectifs

atteints, et discussion des améliorations futures possibles.

13
 Part II

Background

14
Section 2

Architecture Monolithique

2.1 Introduction à l’Architecture Monolithique

L’architecture monolithique, ou ”monolithe”, décrit un style architectural où la modular-
ité n’est pas considérée comme un principe de conception fondamental. Initialement, ce terme
a été utilisé pour désigner des applications lourdes sur mainframe, autonomes et devenant
de plus en plus complexes à maintenir à mesure que le nombre de fonctionnalités augmente
avec les mises à jour des versions [1].

2.2 Structure et Composants

Une architecture monolithique se base généralement sur un modèle en couches, où chaque
couche est fortement couplée et centralisée. Elle comprend typiquement une couche d’inter-
face utilisateur, une couche de logique métier et une couche d’accès aux données [2]. Toutes
les fonctionnalités de l’application sont regroupées dans un seul bloc de code, ce qui simplifie
initialement le développement, le déploiement et la mise à l’échelle tant que la taille du code
reste gérable [3].
La figure ci-dessous (figure 2.1) montre un modèle générique d’architecture monolithique,
incluant ses composants clés pour la logique, l’interface utilisateur et la communication avec
une base de données.

2.3 Avantages et Utilisation Initiale

Malgré ses limitations, l’architecture monolithique reste populaire, notamment pour les
petits projets et les preuves de concept, grâce à sa simplicité initiale et à la rapidité de mise
sur le marché qu’elle offre [4]. Elle permet de centraliser les composants et de bénéficier
d’une vitesse de développement initiale avant que la complexité et les défis de maintenance
ne deviennent apparents [1].

15
 Figure 2.1: Modèle générique d’architecture monolithique

2.4 Défis et Limitations

2.4.1 Pile Technologique

Un des principaux inconvénients des applications monolithiques est leur dépendance à
une seule pile technologique. Par exemple, une application écrite en Java devra continuer à
utiliser Java pour toute extension future, ce qui limite l’utilisation de nouveaux frameworks
ou langages adaptés au déploiement dans le cloud.

2.4.2 Scalabilité
La scalabilité d’une architecture monolithique est limitée. Toutes les fonctionnalités
partagent les ressources (CPU et mémoire) d’un même système hôte, ce qui peut conduire à
une saturation des ressources en cas de forte demande pour une fonctionnalité particulière.

16
La mise à l’échelle verticale, en augmentant la mémoire, est souvent insuffisante, et la mise
à l’échelle horizontale, en ajoutant des serveurs redondants, est coûteuse et complexe à gérer
[1, 5].
Par conséquent, la mise à l’échelle horizontale, illustrée à la figure 2.2, est la seule solution
réaliste pour augmenter la capacité des monolithes. Cela implique d’ajouter plus d’instances
de l’application entière sur de nouveaux serveurs redondants jusqu’à ce que la capacité soit
suffisante pour traiter les demandes provenant de l’interface utilisateur graphique. Il est
également nécessaire d’utiliser un équilibreur de charge pour distribuer les requêtes entrantes
entre les serveurs. La réplication des sessions est nécessaire pour distribuer les sessions entre
les serveurs afin qu’une session utilisateur puisse être traitée sur plusieurs serveurs. Comme
l’illustre la figure 3, il n’y a pas de base de données partagée entre les instances fonctionnant
sur des serveurs distincts. Il est donc nécessaire de répliquer la base de données pour garantir
des instances actuelles et redondantes de la base de données. Cette technique de mise à
l’échelle est coûteuse et ajoute de la complexité au système exécutant les instances, et n’est
pas bien adaptée au déploiement dans le cloud [1].

Figure 2.2: Scalabilité horizontale d’un monolithe

17
2.4.3 Gestion des Changements et Maintenance
Avec l’augmentation du nombre de fonctionnalités, un monolithe devient de plus en plus
complexe à maintenir. Les fonctionnalités sont fortement couplées et interdépendantes, ren-
dant chaque changement potentiellement risqué pour l’ensemble du système. Tester une
fonctionnalité modifiée nécessite souvent de re-tester l’application entière, augmentant le
temps et les coûts de maintenance [5, 6].

2.4.4 Déploiement
Le déploiement d’une application monolithique est un autre défi majeur. Il n’est pas
possible de déployer des fonctionnalités individuelles de manière indépendante ; c’est toujours
l’application entière qui doit être déployée. Cela implique souvent des temps d’arrêt pendant
le redémarrage de l’application, à moins d’utiliser des configurations de haute disponibilité
qui peuvent être coûteuses [5, 7].

2.4.5 Dette Architecturale et Silos de Données

Les systèmes monolithiques souffrent souvent de ”dette architecturale” due à la complex-
ité croissante et aux solutions sous-optimales adoptées au fil du temps. Les architectures
basées sur des silos de données créent des couplages serrés et des dépendances, rendant les
changements difficiles et risqués. Cette complexité accrue peut freiner l’innovation et le
développement commercial [8, 9].

18
Section 3

Architecture SOA

3.1 Principes et Pratiques

L’Architecture Orientée Services, ou SOA, est un modèle architectural qui a gagné en
popularité au début des années 2000 [10]. Cette architecture répond à un besoin croissant
d’agilité dans les entreprises, permettant une réponse rapide et flexible aux exigences com-
merciales changeantes. Dans SOA, les applications sont décomposées en petits composants
fonctionnels, appelés services, qui peuvent être assemblés et réassemblés pour former des
applications complètes [11]. Ces services sont indépendants mais peuvent interagir via des
protocoles de communication bien définis, souvent implémentés sur des réseaux.

Figure 3.1: Architecture SOA

3.1.1 Caractéristiques de SOA

SOA est basée sur quelques principes clés qui visent à améliorer la flexibilité et la réutil-
isabilité des ressources informatiques [12]:

19
 • Réutilisation des services: Les services dans une architecture SOA sont conçus pour
être réutilisés dans différents contextes et applications. Cela permet de réduire les coûts
et le temps de développement en réutilisant des fonctionnalités existantes plutôt que
de les reconstruire à chaque fois.

• Modularité: Chaque service est un module indépendant qui peut être développé,
déployé, maintenu et mis à jour indépendamment des autres services.

• Abstraction: Les détails de l’implémentation des services sont cachés derrière des
interfaces bien définies. Cela permet aux utilisateurs des services de se concentrer sur
l’utilisation de leurs fonctionnalités sans se préoccuper de leur fonctionnement interne.

3.1.2 Pratiques Courantes

L’un des composants les plus courants dans les architectures SOA est le Bus de Services
d’Entreprise (ESB). L’ESB facilite la communication entre les services en agissant comme
un intermédiaire, gérant la transformation et le routage des messages entre les services [13].
Cela simplifie l’intégration et assure une communication fluide malgré les différences dans les
technologies ou les protocoles utilisés par les services individuels.

3.2 Catégories de Services en SOA

SOA classifie les services en plusieurs catégories, chacune répondant à des besoins spéci-
fiques:

• Services d’entreprise: Ce sont des services de haut niveau qui sont souvent réutil-
isables à travers plusieurs applications et processus métier. Ils sont alignés avec les
modèles d’information de l’entreprise et fournissent des fonctionnalités essentielles.

• Services internes: Ces services sont généralement conçus pour des besoins spécifiques
à une unité d’affaires et ne sont pas destinés à la réutilisation à l’échelle de l’entreprise.

• Services de produits: Fournis par des fournisseurs externes ou par des produits spéci-
fiques, ces services sont intégrés dans les solutions SOA pour fournir des fonctionnalités
spécialisées.

L’architecture SOA offre une grande flexibilité et peut contribuer à une plus grande
agilité dans les entreprises, mais elle peut aussi introduire des complexités, notamment dans
la gestion et l’orchestration des services. Son succès dépend de la capacité à bien concevoir
et implémenter ses composants, ainsi que de l’adoption de bonnes pratiques en matière de
gouvernance et de gestion des services.

20
Section 4

Architecture Microservices

4.1 Définition
L’architecture des microservices est une approche de conception d’applications comme un
ensemble de services petits, autonomes, et déployables indépendamment. Chaque microser-
vice exécute un processus d’affaires spécifique et communique via des interfaces légères, typ-
iquement des API HTTP. Cette architecture se distingue des architectures monolithiques et
SOA par sa capacité à fonctionner indépendamment en choisissant ses propres technologies
et plateformes, ce qui permet une évolutivité et une maintenance améliorées. Selon Newman
(2015), les microservices peuvent être envisagés comme des applications indépendantes qui
coopèrent pour former une application globale plus grande [14].

Figure 4.1: Exemple d’une architecture Microservices

21
4.2 Les Caractéristiques
Les caractéristiques principales des microservices comprennent:

• Autonomie : Chaque service fonctionne indépendamment des autres, ce qui facilite le

développement, les tests, le déploiement et la mise à l’échelle. Cette autonomie permet
également à des équipes distinctes de travailler sur différents services simultanément
sans interférence.

• Décentralisation : Les microservices favorisent la décentralisation de la gestion des

données. Chaque service gère sa propre base de données, ce qui élimine la dépendance
à une base de données monolithique centrale et améliore les performances et la sécurité
[15].

• Tolérance aux pannes : Ils sont conçus pour être résilients ; l’échec d’un microservice
n’impacte pas directement les autres. Des stratégies comme les circuits breakers sont
souvent utilisées pour gérer les échecs et maintenir la disponibilité du système [16].

4.3 Avantages et Inconvénients

Avantages :

• Agilité et flexibilité : Les microservices permettent des itérations rapides et des

mises à jour fréquentes, soutenant l’agilité des entreprises dans des environnements
compétitifs.

• Scalabilité : Ils peuvent être scalés indépendamment, ce qui est particulièrement

bénéfique dans des environnements cloud où les ressources peuvent être ajustées dy-
namiquement pour répondre à la demande [17].

• Diversité technologique : Chaque microservice peut être développé en utilisant la

technologie la mieux adaptée à ses besoins, favorisant l’innovation et l’efficacité.

Inconvénients :

• Complexité de gestion : La gestion de multiples services autonomes nécessite des

outils sophistiqués pour la surveillance, le déploiement et l’orchestration, augmentant
la complexité opérationnelle.

• Défis de monitoring : La surveillance de nombreux services distribués nécessite des

solutions avancées pour assurer une visibilité et un contrôle efficaces.

22
• Consistance des données : Assurer la consistance des données à travers des ser-
vices distribués pose des défis particuliers, souvent gérés par des techniques comme les
transactions compensatoires ou les événements asynchrones [18].

23
Section 5

Comparaison Entre Monolithique, SOA

et Microservices

Les architectures logicielles jouent un rôle crucial dans la manière dont les applications
sont conçues, développées et maintenues. Les modèles monolithiques, SOA (Service-Oriented
Architecture) et microservices offrent des approches distinctes avec des avantages et des
inconvénients spécifiques. Cette section fournit une analyse critique de ces architectures, en
se concentrant sur plusieurs aspects clés qui influencent leur adoption et leur efficacité dans
différents environnements de développement. Les facteurs utilisés pour cette comparaison
comprennent :

• Conception: Évalue comment chaque architecture organise et structure ses com-

posants et services. Cela inclut la manière dont les fonctionnalités sont encapsulées
et interagissent au sein de l’application.

• Scalabilité: Examine la capacité de chaque architecture à s’adapter à des charges de

travail croissantes, soit par l’ajout de ressources au même système (scalabilité verticale),
soit par l’ajout de plus de systèmes (scalabilité horizontale).

• Maintenance: Considère la facilité avec laquelle chaque architecture peut être mise à
jour et maintenue, en tenant compte de la complexité des mises à jour et de l’impact
potentiel des changements sur l’ensemble du système.

• Déploiement: Aborde la facilité de déploiement des modifications, la fréquence des

mises à jour et la manière dont les architectures supportent le déploiement continu et
indépendant.

• Gestion des données: Discute de la manière dont chaque architecture gère les don-
nées, notamment en termes de centralisation versus décentralisation et de gestion de la
cohérence des données.

24
 • Sécurité: Analyse les défis et les approches de la sécurité dans chaque architecture,
y compris la gestion des risques de sécurité liés à la distribution et à l’intégration des
services.

• Intégration technologique: Évalue la capacité de chaque architecture à intégrer de

nouvelles technologies et à supporter des environnements hétérogènes.

Ces critères sont essentiels pour comprendre les implications pratiques de choisir une ar-
chitecture sur une autre en fonction des besoins spécifiques d’un projet ou d’une organisation.
Le tableau suivant résume et compare ces architectures selon ces dimensions clés.

25
Critère Monolithique SOA Microservices
Conception Unité indivisible Ensemble de Collection de ser-
avec toutes les services inter- vices indépendants
fonctionnalités dépendants et autonomes
intégrées
Scalabilité Scalabilité verticale Scalabilité horizon- Excellente scala-
principalement, né- tale possible mais bilité horizontale,
cessite la duplica- gestion complexe chaque service est
tion complète de due aux dépen- indépendant
l’application dances
Maintenance Peut être com- Amélioration grâce Plus facile et
plexe, car une à la modularité des rapide, chaque ser-
modification né- services mais coor- vice est mis à jour
cessite souvent le dination nécessaire indépendamment
redéploiement de
tout le système
Déploiement Risqué et poten- Moins risqué que le Simplifié et con-
tiellement instable, monolithique, peut tinu, avec des
affecte toute l’ap- nécessiter une ges- déploiements
plication tion complexe des indépendants min-
versions imisant les risques
d’interruption
Gestion des données Centralisée, ce Peut être décentral- Complètement dé-
qui peut créer des isée mais souvent centralisée, chaque
goulots d’étrangle- synchronisée via service gère ses pro-
ment des services d’en- pres données, ce qui
treprise améliore la perfor-
mance
Sécurité Un seul point de Nécessite une sécu- Défis en termes de
sécurité, plus facile rité coordonnée à sécurité distribuée,
à gérer mais risque travers les services, chaque service doit
plus élevé en cas de complexe à gérer implémenter ses
compromission propres mesures
Intégration technologique Limitée à une stack Permet une cer- Très flexible, per-
technologique, dif- taine hétérogénéité met l’utilisation
ficile d’intégrer de mais peut être de différentes tech-
nouvelles technolo- limitée par des nologies et stacks
gies sans une re- contraintes d’in- pour chaque service
fonte complète teropérabilité

Table 5.1: Comparaison des architectures Monolithique, SOA et Microservices

26
Section 6

Les Patterns des Microservices

L’architecture des microservices n’est pas simplement un style architectural, mais une
suite de patterns stratégiques et opérationnels qui aident à décomposer une application en
services plus petits et gérables. Ces patterns ont pour double objectif de déterminer la per-
tinence des microservices pour une application spécifique et de faciliter une implémentation
efficace de cette architecture, comme le soutiennent [19, 20].

6.1 Les Patterns de Décomposition

Les patterns de décomposition dans l’architecture des microservices sont cruciaux pour
structurer les applications en services plus petits et gérables qui correspondent directement
aux besoins commerciaux de l’entreprise. Ces patterns facilitent la gestion, la maintenance, et
l’évolution des systèmes en alignant étroitement les services avec les fonctions commerciales.

6.1.1 Pattern de Décomposition par Capacité Commerciale

Ce pattern organise les microservices selon les capacités fonctionnelles de l’entreprise,
souvent en reflétant une structure organisationnelle hiérarchique. Par exemple, des niveaux
distincts pourraient être dédiés à la gestion des commandes de produits, à la facturation, et à
la logistique. Cette structuration aide à isoler les fonctions dans des services dédiés qui sup-
portent efficacement les opérations commerciales, permettant des mises à jour indépendantes
et minimisant les interférences entre services.

6.1.2 Pattern de Décomposition par Sous-Domaine

Basé sur le Domain-Driven Design (DDD), ce pattern divise le domaine d’affaires com-
plexe en sous-domaines plus petits et gérables, facilitant la gestion et le développement ciblé
des fonctionnalités. Les sous-domaines sont généralement classifiés comme suit:

• Noyau: Le cœur des stratégies commerciales et le différentiateur clé de l’entreprise.

27
 • Soutien: Fonctions qui supportent le noyau mais peuvent être externalisées ou inter-
nalisées selon les besoins.

• Générique: Fonctions standard gérées par des solutions logicielles standards.

Cette segmentation permet à chaque service de se concentrer sur des responsabilités claires
et bien définies, améliorant ainsi la cohérence et la qualité du service.

6.1.3 Nouveaux Patterns de Décomposition

• Pattern de Service Autonome: Chaque service opère de manière indépendante avec
sa propre base de données et logique métier, réduisant les dépendances et améliorant
la résilience et l’évolutivité [19].

• Pattern de Service par Équipe: Services développés par des équipes dédiées, re-
sponsables de l’intégralité du cycle de vie du service. Cette approche renforce la pro-
priété et la responsabilité, accélérant le développement et améliorant la qualité [20].

6.2 Les Patterns De Messagerie Transactionnelle

Les patterns de messagerie transactionnelle jouent un rôle crucial dans les architectures
microservices, en assurant la cohérence des données et en facilitant la gestion des transactions
dans des systèmes distribués. Ces patterns permettent des communications fiables entre
services indépendants. Nous détaillons ici trois patterns principaux utilisés couramment.

6.2.1 Pattern Boîte D’envoi Transactionnelle

Ce pattern est utilisé principalement avec les bases de données relationnelles pour gérer
les transactions. Il consiste à insérer un message ou un événement dans une “boîte d’envoi” au
sein de la base de données lorsqu’une transaction locale est effectuée. Ce mécanisme garantit
que chaque transaction est accompagnée d’un message qui peut être utilisé pour déclencher
d’autres processus ou opérations. Pour les bases de données NoSQL, ce pattern est adapté
pour ajouter les messages ou événements directement à l’attribut de l’enregistrement mis à
jour.

6.2.2 Pattern Journal Des Transactions

Ce pattern implique l’enregistrement de chaque transaction dans un journal de la base
de données. Par exemple, MySQL utilise le mécanisme de binlog et PostgreSQL utilise le

28
Write-Ahead Logging (WAL). Ces journaux sont ensuite traités et envoyés à une file d’at-
tente pour être gérés de manière asynchrone, facilitant ainsi la réplication des données ou la
synchronisation entre différents services.

6.2.3 Pattern Éditeur De Sondage

Dans ce pattern, les messages ne sont pas insérés directement dans la file d’attente au
moment de la transaction. Au lieu de cela, une tâche périodique sonde la base de données
pour détecter les nouvelles entrées ou les modifications non traitées. Ce pattern est utilisé
lorsque les mécanismes de push direct ne sont pas disponibles ou souhaitables, assurant que
tous les événements sont capturés et traités, même si cela peut introduire un délai.

6.3 Les Patterns de Gestion de Données

Les patterns de gestion de données dans les architectures microservices sont essentiels pour
optimiser la cohérence, l’efficacité et la scalabilité tout en minimisant les dépendances entre
les services. Ces patterns facilitent également la maintenance et l’évolution des systèmes.
Voici une exploration détaillée de trois patterns primordiaux :

6.3.1 Pattern de Base de Données pour Chaque Service

Chaque microservice dans ce modèle opère avec sa propre base de données, permettant une
complète autonomie en termes de gestion des données. Ce cloisonnement favorise l’indépen-
dance des services, ce qui est crucial pour le déploiement et la mise à jour sans interruption
des autres composants du système.

• Avantages :

– Scalabilité accrue : Chaque service peut être scalé indépendamment en fonction

de ses besoins en ressources.
– Développement isolé : Les développeurs peuvent mettre à jour ou modifier la base
de données d’un service sans impacter les autres, ce qui accélère les cycles de
développement.
– Maintenance simplifiée : Les problèmes de données sont isolés au service concerné,
facilitant les diagnostics et les corrections.

6.3.2 Pattern de Base de Données Partagée

Ce pattern implique que plusieurs microservices partagent la même base de données.
Bien que cela puisse simplifier la migration des architectures monolithiques et réutiliser les

29
schémas de données existants, il introduit un niveau de couplage qui peut compromettre
l’indépendance des services.

• Avantages :

– Migration facilitée : Les entreprises peuvent migrer vers des microservices sans
redéfinir entièrement leur modèle de données.
– Réutilisation des schémas : Économise le temps et les ressources en évitant de
redévelopper les schémas de base de données.

6.3.3 Pattern SAGA

Le pattern SAGA est une approche pour gérer les transactions qui s’étendent sur plusieurs
microservices, en les décomposant en transactions locales plus petites. Chaque action locale
publie des événements qui déclenchent la prochaine action dans la séquence de transactions.
En cas d’échec, des actions compensatoires sont déclenchées pour revenir à un état cohérent.

• Utilisation :

– Gestion des échecs : Permet de rétablir la cohérence après un échec transactionnel

en exécutant des transactions compensatoires.
– Maintien de la cohérence : Assure que l’ensemble du système reste cohérent même
en cas de défaillances partielles.

Note : Pour compléter ces stratégies, l’implémentation du pattern CQRS (Command

Query Responsibility Segregation) est souvent recommandée. Cela permet de séparer les
responsabilités de lecture et d’écriture, optimisant ainsi les performances et la maintenabilité
de chaque microservice.

6.4 Les Patterns de Déploiement

Les patterns de déploiement pour les architectures de microservices sont cruciaux pour
assurer une distribution efficace et fiable des services dans un environnement de production.
Ces patterns aident à optimiser l’utilisation des ressources, à améliorer la fiabilité du système,
et à faciliter le scaling horizontal.

6.4.1 Pattern Multi-Service par Hôte

Ce pattern implique l’exécution de plusieurs services sur un seul hôte, comme une machine
virtuelle dédiée. Cette approche est particulièrement utile dans des environnements où les
ressources de calcul sont abondantes et peu coûteuses.

30
 Avantages :

• Utilisation optimisée des ressources : Les ressources de l’hôte sont pleinement utilisées,
ce qui peut réduire les coûts d’infrastructure.

• Déploiement simplifié : Moins de machines à gérer peut simplifier le processus de

déploiement et de maintenance.

• Scalabilité horizontale : Permet de scaler plus facilement en ajoutant plus de services

sur le même hôte ou en augmentant le nombre d’hôtes.

Inconvénients :

• Couplage potentiel : La défaillance d’un hôte peut affecter plusieurs services, augmen-
tant le risque de points de défaillance uniques.

• Conflits de ressources : Les services partageant un même hôte peuvent entrer en com-
pétition pour les ressources, ce qui peut entraîner des problèmes de performance.

6.4.2 Pattern Un Seul Service par Hôte

Dans ce modèle, chaque service est isolé dans son propre hôte, souvent une machine
virtuelle ou un conteneur. Cette approche maximise l’isolation entre les services.
Avantages :

• Isolation complète : Chaque service fonctionne dans un environnement cloisonné, ce

qui minimise les interférences et maximise la sécurité.

• Réduction des conflits de ressources : Aucun service ne partage ses ressources, ce qui
élimine les conflits potentiels et garantit une performance plus prévisible.

• Facilité de monitoring et de maintenance : L’isolation facilite le suivi et la maintenance

de chaque service individuellement.

Inconvénients :

• Utilisation inefficace des ressources : Peut entraîner une sous-utilisation des ressources,
surtout si les services ne nécessitent pas les capacités complètes de l’hôte.

• Coûts plus élevés : Nécessite potentiellement plus d’hôtes, ce qui peut augmenter les
coûts d’infrastructure.

31
6.5 Les Patterns d’API Externes

6.5.1 API-Gateway
L’API-Gateway est un élément central dans les architectures modernes de microservices,
agissant comme intermédiaire entre les clients externes et les services internes. Inspiré des
principes de l’architecture orientée services (SOA), il remplace les architectures traditionnelles
basées sur un bus de services d’entreprise (ESB). L’API-Gateway simplifie les interactions
client-service, en gérant l’acheminement des requêtes, la transformation des protocoles, et la
mise en œuvre de logiques communes telles que l’authentification.
Fonctionnalités clés de l’API-Gateway :

• Routage des demandes: Oriente les requêtes clients vers les microservices appro-
priés.

• Agrégation des réponses: Combine les réponses de divers microservices pour fournir
une réponse unifiée.

• Transformation des protocoles: Adapte les formats de données pour assurer la

compatibilité inter-systèmes.

• Sécurité: Centralise la gestion des identités et des accès pour sécuriser les services.

• Équilibrage de charge: Répartit la charge de travail de manière équilibrée entre les

services disponibles.

Avantages :

• Flexibilité d’intégration, scalabilité accrue et personnalisation des API.

Inconvénients :

• Risque de goulot d’étranglement et complexité accrue de la gestion.

6.5.2 API-Gateway / Backends Pour Frontends (BFF)

Cette variante de l’API-Gateway propose des gateways dédiés à chaque type de client,
optimisant les interactions spécifiques à chaque plateforme (web, mobile, etc.). Chaque
BFF est conçu pour améliorer l’expérience utilisateur par une personnalisation profonde des
interactions client-service.
Avantages :

• Meilleure expérience utilisateur par des optimisations spécifiques et une réduction de

la charge sur les clients.

32
 Inconvénients :
• Duplication des fonctionnalités et complexité opérationnelle accrue.
Remarque : Vous pourriez envisager d’inclure une illustration ici pour montrer comment
ces patterns fonctionnent au sein d’une architecture de microservices.

6.6 Les Patterns de Découverte de Service

Les Patterns de Découverte de Service dans les architectures microservices sont cruciaux
pour la gestion dynamique de la localisation et la communication entre services distribués. Ils
garantissent que les instances de service peuvent être découvertes et communiquer efficace-
ment malgré les déploiements fréquents dans des environnements évolutifs comme le cloud.
Voici les principaux patterns utilisés pour la découverte de service :

6.6.1 Pattern de Découverte Côté Client

Ce pattern confère au client la responsabilité de découvrir les services. Le client, con-
naissant l’adresse de chaque instance de service ou utilisant un algorithme d’équilibrage de
charge, sélectionne directement l’instance à utiliser.
Avantages:
• Autonomie du client, réduisant la latence et simplifiant la configuration.

• Flexibilité accrue avec moins de dépendance à un service centralisé.

Inconvénients:
• Augmentation du couplage entre le client et les services.

• Complexité accrue dans la gestion de la logique de découverte et d’équilibrage.

6.6.2 Pattern de Découverte Côté Serveur

Un registre de services central joue le rôle de médiateur pour résoudre les adresses des
services, à la manière d’un serveur DNS pour les adresses IP.
Avantages:
• Simplification de la configuration des clients.

• Gestion centralisée de la santé des services, éliminant les instances défaillantes du pool.
Inconvénients:
• Risque de point unique de défaillance avec le registre.

• Nécessité d’une gestion opérationnelle constante du registre.

33
6.6.3 Pattern Registre de Services
Ce pattern implique un registre actif où chaque service s’enregistre à son démarrage et se
retire à son arrêt, permettant une interrogation efficace par les clients ou un intermédiaire.
Avantages:

• Liste toujours actualisée des services disponibles.

• Efficacité améliorée lors de l’interrogation pour les adresses des services.

Inconvénients:

• Gestion complexe de l’état du registre pour éviter des données obsolètes.

Applications typiques: Des systèmes tels qu’Eureka Server et Apache ZooKeeper sont
souvent utilisés pour implémenter ces patterns, offrant des fonctionnalités avancées pour la
gestion des dynamiques de service dans des environnements distribués.

6.7 Les Patterns de Sécurité

Les patterns de sécurité dans les architectures microservices sont cruciaux pour assurer la
protection des données, l’authentification des utilisateurs, et la gestion des autorisations dans
un environnement distribué. Ces patterns facilitent la mise en place de mesures de sécurité
robustes tout en maintenant la flexibilité et l’évolutivité des services.

6.7.1 Pattern d’Authentification par Jeton

Ce pattern utilise des jetons, souvent des JWT (JSON Web Tokens), pour authentifier
les utilisateurs et transmettre des informations sécurisées entre les services.
Avantages:

• Sécurité renforcée: Les jetons peuvent être chiffrés pour assurer la confidentialité des
données.

• Sans état: Idéal pour les architectures distribuées car ils ne nécessitent pas de stockage
de session côté serveur.

• Interopérabilité: Facilité d’utilisation à travers différents langages et plateformes.

Inconvénients:

• Gestion des jetons: Nécessite un système robuste pour émettre, renouveler et révoquer
les jetons efficacement.

• Complexité: La mise en œuvre de la logique de validation des jetons peut être complexe.

34
6.7.2 Pattern de Porte de Sécurité (Security Gateway)
Similaire à l’API Gateway, le Security Gateway gère toutes les requêtes entrantes pour
l’authentification et l’autorisation avant qu’elles atteignent les microservices.
Avantages:

• Point de contrôle centralisé: Simplifie la gestion de la sécurité en concentrant les poli-

tiques de sécurité à un seul point.

• Réduction des vulnérabilités: Minimise le risque d’attaques directes sur les microser-
vices.

Inconvénients:

• Point de défaillance unique: Si le gateway tombe en panne, l’accès à tout le système

peut être compromis.

• Latence accrue: Peut introduire un délai supplémentaire dans le traitement des deman-
des.

6.7.3 Pattern de Chiffrement des Données

Ce pattern implique le chiffrement des données sensibles à la source avant leur stockage
ou leur transmission.
Avantages:

• Protection des données: Assure que les données compromisées restent indéchiffrables
sans la clé appropriée.

• Conformité réglementaire: Aide à répondre aux exigences de protection des données

personnelles.

Inconvénients:

• Performance: Le processus de chiffrement et de déchiffrement peut introduire une la-

tence significative.

• Gestion des clés: Nécessite une gestion sécurisée des clés de chiffrement, ajoutant à la
complexité et au coût.

35
6.7.4 Pattern d’Audit et de Suivi
Ce pattern garantit que toutes les actions critiques ou accès aux données sensibles sont
enregistrés.
Avantages:

• Traçabilité: Permet de retracer les actions en cas de problème de sécurité ou pour des
audits réglementaires.

• Détecter les anomalies: Les logs peuvent être analysés pour détecter des comportements
inhabituels ou malveillants.

Inconvénients:

• Volume de données: Peut générer un volume énorme de données à stocker et analyser.

• Performance: Peut impacter les performances du système si non optimisé correctement.

On peut resumer tout les patterns selon Le schéma suivant ( 6.1):

Figure 6.1: Resumer de tous les patterns de microservices

36
 Part III

Contribution

37
Section 7

Introduction

Dans ce chapitre, nous détaillons les aspects techniques et stratégiques impliqués dans
le développement et la migration de l’application ”ShellOnYou” de sa version monolithique
initiale (v6) à une architecture basée sur les microservices (v7). Nous commencerons par
une exploration approfondie de l’environnement de développement, couvrant à la fois le
matériel et les logiciels utilisés, ainsi que les frameworks et les technologies qui ont facilité
cette transformation. Cette discussion inclura également les motivations derrière le choix
de chaque technologie et la manière dont elles se sont intégrées pour former une solution
cohérente. Ensuite, nous présenterons une analyse détaillée du processus de migration, en
expliquant les étapes de la décomposition de l’application monolithique en services distincts
et interopérables, suivant les principes du Domain-Driven Design (DDD) et soutenus par
une analyse statique rigoureuse du code existant. Ce processus a non seulement permis une
isolation efficace des responsabilités entre les différents composants de l’application mais a
également amélioré sa maintenabilité et sa scalabilité.

38
Section 8

Présentation du Système

8.1 Introduction à ShellOnYou

L’application ‘ShellOnYou”, communément abrégée SOY”, est une plateforme éducative
web spécifiquement conçue pour l’enseignement et l’apprentissage interactif du Shell Unix.
En tant qu’outil pédagogique, SOY se distingue par sa capacité à engager activement les
étudiants à travers des exercices pratiques qui simulent des scénarios réels d’utilisation du
Shell Unix.
Le principal atout de ShellOnYou réside dans son interactivité. Les enseignants peuvent
créer et publier des exercices personnalisés qui sont immédiatement disponibles pour les
étudiants. Chaque exercice est accompagné de scripts d’évaluation automatisés qui exécutent
les commandes soumises par les étudiants et fournissent un feedback instantané, critiquant
non seulement la justesse des réponses mais aussi la méthode et l’efficacité des commandes
utilisées.
En plus de ces fonctionnalités d’apprentissage et d’évaluation, ShellOnYou intègre des out-
ils sociaux qui enrichissent l’expérience utilisateur. Par exemple, la fonctionnalité ‘Thanks”,
permet aux étudiants de reconnaître l’aide ou les conseils utiles fournis par leurs pairs, fa-
vorisant ainsi une atmosphère collaborative. Les commentaires intégrés permettent également
une interaction en continu, où les étudiants peuvent discuter des défis des exercices, partager
des astuces, ou demander de l’aide supplémentaire.
L’objectif de ShellOnYou est de rendre l’apprentissage du Shell Unix accessible, en-
gageant, et communautaire, en offrant une plateforme où les compétences essentielles peuvent
être développées dans un environnement stimulant et soutenu.

39
8.2 Fonctionnement général
Dans sa configuration initiale, l’application “ShellOnYou” était conçue comme une ar-
chitecture monolithique, centralisant toutes les opérations et fonctionnalités en un seul et
même bloc de code. Ce modèle d’architecture facilitait les interactions entre les différents
composants de l’application, notamment la création d’exercices par les enseignants, la soumis-
sion de réponses par les étudiants, et l’évaluation automatique des réponses via des scripts
Python.

8.2.1 Architecture Monolithique de l’Application ShellOnYou (SOY)

L’architecture de l’application ShellOnYou dans sa version monolithique suit un modèle
classique à trois couches : interface utilisateur (SOY Interface), contrôleur (SOY Controller),
modèle (SOY Model) et base de données (SOY Database). Ce schéma (voir la figure 8.1)
illustre cette architecture de manière simplifiée, mettant en lumière les interactions entre ces
différentes couches.

8.2.1.1 SOY Interface

L’interface utilisateur (SOY Interface) représente la couche front-end de l’application,

développée principalement avec React. Elle offre aux utilisateurs (enseignants, étudiants)
une interface graphique interactive pour interagir avec l’application. Par exemple, les utilisa-
teurs peuvent se connecter, accéder à leurs exercices, soumettre des réponses et recevoir des
feedbacks via cette interface. React permet la gestion efficace des états de l’application et
le rafraîchissement dynamique de l’interface sans rechargement de page complet, améliorant
ainsi l’expérience utilisateur.

8.2.1.2 SOY Controller

La couche des contrôleurs (SOY Controller) est responsable de la gestion des requêtes
métiers. Elle se situe entre l’interface utilisateur et le modèle de données. Les contrôleurs
interprètent les requêtes des utilisateurs, envoient les informations pertinentes au modèle
pour traitement et retournent les résultats à l’interface.
Quelques exemples de contrôleurs dans l’application SOY incluent :

• ExerciseController : Gère toutes les opérations liées aux exercices, telles que la
création, la mise à jour, la suppression et la récupération des exercices.

• UserController : Responsable de la gestion des utilisateurs, notamment l’authentifi-

cation, la création de comptes et la gestion des profils.

40
 Figure 8.1: Schéma général de l’architecture monolithique de l’application ShellOnYou

Les contrôleurs jouent un rôle clé dans l’orchestration de la logique métier en assurant que
les bonnes données sont transmises et récupérées de la couche d’accès aux données (modèle).

8.2.1.3 SOY Model

La couche modèle (SOY Model) ou couche d’accès aux données est chargée de l’interac-
tion avec la base de données PostgreSQL. Le modèle définit la structure des données et les
relations entre elles, et offre des méthodes pour lire, écrire, mettre à jour et supprimer des
enregistrements dans la base de données.
Parmi les exemples de modèles dans l’application SOY, nous avons :

• UserModel : Définit la structure des données utilisateur, telles que l’ID, le nom,
l’email, et les rôles d’accès.

• ExerciseModel : Représente les données liées aux exercices, incluant l’ID de l’exercice,
les compétences associées, et les niveaux de difficulté.

41
 La couche modèle isole la logique de manipulation des données de la logique métier,
rendant le code plus modulaire et maintenable.

8.2.1.4 SOY Database

La base de données PostgreSQL (SOY Database) est le référentiel central où toutes les
données de l’application sont stockées. Cette base de données est structurée selon des scripts
SQL exécutés dans un ordre bien précis pour créer et remplir les tables nécessaires à l’appli-
cation.
L’ordre d’exécution des scripts SQL est crucial pour garantir l’intégrité des données et
des relations. Voici quelques exemples des scripts utilisés dans l’application SOY :

• 01_schema.sql : Crée la structure de base des tables.

• 02_data.sql : Insère les données initiales dans les tables.

• 03_session.sql : Gère les sessions utilisateur.

• 04_add_field_plagesession.sql : Ajoute des champs spécifiques pour la gestion

des plages de session.

• 20_add-leaderboard.sql : Script final qui ajoute des fonctionnalités supplémentaires

comme les classements.

Ces scripts sont exécutés séquentiellement pour bâtir la base de données et l’adapter aux
nouvelles exigences fonctionnelles à chaque évolution de l’application.

8.2.2 Intégration et interactions

Les interactions entre Node.js et Python, deux technologies clés de l’application, étaient
orchestrées à travers des appels systèmes. Node.js gérait le serveur backend et les requêtes
utilisateur, tandis que Python était utilisé pour exécuter les scripts d’évaluation des com-
mandes Shell soumises par les étudiants. Cette intégration permettait une exécution fluide
des scripts d’évaluation au sein de l’environnement de l’application.

8.2.3 Problèmes de performance

Toutefois, ce modèle monolithique présentait des limites significatives, notamment en ter-
mes de performance et de scalabilité. Sous des charges élevées, particulièrement durant les
périodes de pic d’utilisation, comme les sessions d’examen ou les devoirs en temps limité,
l’application monolithique subissait des ralentissements. Les appels systèmes entre Node.js

42
et Python, bien que fonctionnels, commençaient à devenir un goulot d’étranglement, impac-
tant le temps de réponse de l’application et l’expérience utilisateur.

8.2.4 Conséquences et anticipation

Ces défis de performance sous haute charge ont souligné la nécessité d’une architecture
plus robuste et scalable. La dépendance aux appels systèmes et la centralisation des processus
de gestion des données et de logique applicative posaient des risques de pannes et de difficultés
lors des mises à jour ou des modifications du code.
En réponse à ces défis, la décision a été prise de migrer vers une architecture de mi-
croservices, envisagée pour améliorer la performance, la maintenabilité et l’évolutivité de
l’application. Cette transition est discutée plus en détail dans les sections suivantes.

8.3 Évolution et Améliorations des Versions Précédentes

L’évolution de l’application ShellOnYou, de la version 1 à la version 6, illustre un développe-
ment itératif où l’accent a été mis sur l’amélioration fonctionnelle et l’amélioration de l’inter-
face utilisateur. Initialement conçue pour fournir une expérience d’apprentissage interactive
du Shell Unix, chaque nouvelle version a apporté des fonctionnalités plus raffinées et des
interfaces plus intuitives pour répondre aux besoins des utilisateurs finaux, principalement
des étudiants et des enseignants dans un environnement éducatif.

8.3.1 Ajout de Fonctionnalités:

Au fil des versions, ShellOnYou a intégré des outils d’analyse de code, des systèmes de
soumission et de feedback en temps réel, et des fonctionnalités de personnalisation pour les
enseignants permettant de créer et de gérer des exercices de manière plus dynamique. Des
fonctionnalités telles que le suivi des progrès des étudiants et des tableaux de bord pour les
enseignants ont été ajoutés pour enrichir l’expérience pédagogique.

8.3.2 Mise à jour de l’Interface Utilisateur:

L’interface utilisateur a été régulièrement mise à jour pour rendre l’application plus ac-
cessible et agréable. Les mises à jour ont inclus des améliorations de l’interface graphique
pour faciliter la navigation dans l’application, une meilleure visualisation des résultats des

43
exercices, et l’introduction de composants interactifs pour une interaction plus engageante.

8.3.3 Stabilité du Stack Technologique:

Malgré ces améliorations fonctionnelles et esthétiques, l’architecture sous-jacente de Shel-
lOnYou est restée principalement monolithique, avec peu de changements dans le stack tech-
nologique global. L’application a continué à s’appuyer sur Node.js pour le backend et des
scripts Python pour l’évaluation des exercices, sans migration significative vers de nouvelles
technologies ou architectures distribuées.

8.3.4 Incrémentation Basée sur les Retours:

Chaque mise à jour de version a été influencée par les retours des utilisateurs, collectés via
des enquêtes, des forums de discussion, et des sessions de feedback en direct. Cela a permis
à l’équipe de développement de prioriser les améliorations qui répondaient directement aux
besoins des utilisateurs, assurant que l’application restait pertinente et utile pour son public
cible.

8.3.5 Visualisation des Données:

La figure 8.2 détaille le schéma de la base de données de la version 6, montrant comment
les données étaient structurées avant la transition vers une architecture de microservices. Ce
schéma révèle la complexité et l’interdépendance des différents éléments de données, soulig-
nant les défis de maintenir et de mettre à jour une application monolithique à grande échelle.

Cette phase de développement monolithique a jeté les bases nécessaires pour comprendre
les limitations du système et les domaines nécessitant une refonte architecturale, conduisant
à la décision stratégique de migrer vers une architecture de microservices.

8.4 De Monolithique (v6) à Microservices (v7)

8.4.1 Analyse Initiale et Décision de Migration

La décision de migrer l’application ShellOnYou de sa structure monolithique (version 6)
vers une architecture de microservices (version 7) a été motivée par une nécessité d’améliorer

44
 Figure 8.2: schéma de la base de données de la v6

la scalabilité et la maintenabilité de l’application. Le processus a commencé par une anal-

yse approfondie des composants fonctionnels existants, identifiant les points de friction, no-
tamment les goulots d’étranglement de performance et les difficultés de déploiement qui
émergeaient avec l’accroissement des utilisateurs et des fonctionnalités.

45
 Figure 8.3: schéma simplifié DB v6

8.4.2 Domain-Driven Design (DDD)

L’application des principes de Domain-Driven Design (DDD) a été essentielle pour la
segmentation efficace des fonctionnalités de l’application en différents microservices. Ce
cadre de conception a guidé l’équipe dans la modélisation autour des limites contextuelles
délimitées, permettant de créer des services avec des responsabilités bien définies, réduisant
ainsi la complexité et les dépendances croisées entre composants.

8.4.2.1 Application du Domain-Driven Design (DDD) dans notre Projet

L’application du DDD dans le cadre de la migration de ShellOnYou a joué un rôle clé dans
la segmentation des fonctionnalités de l’application monolithique en microservices autonomes.
En identifiant les ”domaines contextuels” (bounded contexts), nous avons pu délimiter les
différentes responsabilités métiers de manière claire et concise. Cette démarche a permis de
réduire la complexité de l’application en créant des services distincts, avec des responsabilités
bien définies, tout en minimisant les dépendances entre les composants.
Dans le cas de ShellOnYou, quatre domaines contextuels principaux ont été identifiés, ce
qui a guidé la création des quatre microservices suivants :

46
 • user : Gère les informations des utilisateurs, leur authentification, leurs rôles, et leurs
sessions.

• skill : Traite la gestion des compétences et des niveaux associés aux exercices.

• student : S’occupe de la gestion des interactions des étudiants avec les exercices, y
compris les soumissions et les évaluations.

• teacher : Facilite la création et la gestion des exercices et des sessions par les en-
seignants.

8.4.2.2 Identification des Domaines Contextuels

L’application de DDD a permis de structurer l’analyse des composants fonctionnels de

l’application en identifiant les quatre principaux domaines contextuels suivants :

8.4.2.2.1 1. Contexte des Utilisateurs Le premier domaine contextuel identifié con-

cerne la gestion des utilisateurs. Il regroupe toutes les fonctionnalités relatives à la gestion
des comptes utilisateurs, y compris l’authentification, la création et la gestion de profils, ainsi
que l’attribution des rôles. Le microservice ms-user est responsable de l’implémentation des
opérations sur les entités utilisateur. Cela comprend, par exemple, la création d’un utilisateur
lors de son inscription, la gestion de son login et la gestion de ses informations personnelles
et de ses rôles dans le système.

8.4.2.2.2 2. Contexte des Compétences Le second domaine contextuel concerne la

gestion des compétences des utilisateurs, particulièrement en relation avec les exercices. Ce
domaine regroupe les opérations de définition, de mise à jour, et de gestion des compétences,
ainsi que l’association des compétences aux exercices. Le microservice ms-skill prend en
charge toutes ces interactions, permettant aux étudiants et enseignants de suivre et de gérer
les compétences acquises ou à acquérir dans le cadre de leurs activités pédagogiques.

8.4.2.2.3 3. Contexte des Étudiants et de leurs Productions Le troisième do-

maine contextuel concerne les étudiants et leurs productions académiques. Ce domaine gère
les soumissions des exercices par les étudiants, les évaluations automatiques effectuées à l’aide
de scripts Python, ainsi que la gestion des retours (feedback). Le microservice ms-exercise-
student est responsable de la gestion des interactions des étudiants avec les exercices et les
sessions éducatives, en facilitant la soumission et l’évaluation de leurs productions (state-
ments). Ce microservice permet aussi de suivre les résultats des étudiants et d’analyser leur
performance.

47
8.4.2.2.4 4. Contexte des Enseignants et des Exercices (ms-exercise-teacher)
Le dernier domaine contextuel se concentre sur les enseignants et la création d’exercices et
de sessions. Ce contexte regroupe les fonctionnalités permettant aux enseignants de créer
des exercices, de gérer les sessions éducatives, et de suivre la progression des étudiants. Le
microservice ms-exercise-teacher implémente ces fonctionnalités, facilitant la gestion des
cours par les enseignants, leur permettant de modifier, publier et surveiller les exercices
et sessions. Il fournit également aux enseignants des outils pour suivre la progression des
étudiants et ajuster le contenu pédagogique en fonction des résultats.

Figure 8.4: Segmentation de l’Application Monolithique en Microservices avec Domain-

Driven Design (DDD)

8.4.2.3 Bénéfices du DDD dans la Migration vers les Microservices

Grâce à l’approche DDD, chaque microservice peut évoluer indépendamment des autres,
ce qui facilite le développement, les tests, et le déploiement continu. La migration vers cette
architecture microservices a permis de résoudre les limitations inhérentes à l’architecture
monolithique, en améliorant considérablement la capacité de ShellOnYou à évoluer avec le
nombre croissant d’utilisateurs et de fonctionnalités.
Cette méthodologie nous a permis de mieux comprendre les domaines métiers de l’appli-
cation et d’effectuer une transition efficace vers des microservices bien délimités et indépen-
dants.

48
8.4.3 Analyse Statique du Code
Parallèlement, une analyse statique du code a été utilisée pour évaluer la qualité du code
existant et identifier les patterns de code réutilisables ou nécessitant une refonte. Cela a
aidé à détecter les anomalies et à assurer que les nouvelles implémentations respectent les
standards de qualité et les bonnes pratiques de développement.

8.4.4 Tableau de Transaction

Dans le cadre de la migration de ShellOnYou, le tableau des transactions initialement créé
pour le système monolithique a joué un rôle crucial dans la compréhension des interactions
entre les différentes fonctionnalités de l’application. Ce tableau nous a permis de clarifier les
dépendances entre les entités, les actions réalisées et les données échangées. Grâce à cette
analyse, nous avons pu identifier quatre domaines contextuels principaux, chacun représen-
tant un microservice, à savoir : ms-user, ms-skill, ms-exercise-4-student, et ms-exercise-4-
teacher.

8.4.4.1 Ms-exercise-4-teacher

Le microservice ms-exercise-4-teacher est dédié à la gestion des interactions des en-

seignants avec le système, notamment la création, la modification, et la suppression des
exercices. Les transactions gérées par ce microservice incluent la création d’exercices, la
mise à jour des informations associées, et la gestion des compétences des étudiants. Chaque
transaction a été associée à des entités spécifiques (par exemple exercise, exerciselevel), et le
microservice effectue des actions précises telles que l’insertion ou la mise à jour de données.
Par exemple, la transaction Create exercise crée un nouvel exercice et ajoute des enreg-
istrements dans exerciselevel pour attribuer des niveaux de compétence aux exercices créés.
Ce microservice est donc un pivot pour la gestion des ressources pédagogiques fournies par
les enseignants.

49
Transaction Affected Enti- Description Actions
Name ties
Create exercise exercise, exer- Crée un nouvel exer-
ciselevel cice dans la table ex- • Insérer un nouvel en-
ercise et ajoute un en- registrement dans la
registrement dans ex- table exercise
erciselevel avec ex_id,
• Récupérer l’ID du
skill_code, nam_id
nouvel exercice inséré

• Insérer un nouvel
enregistrement dans
exerciselevel avec
ex_id, skill_code,
nam_id (DEFAULT
VALUE 1: beginner)

Get all exercises exercise, exer- Cette transaction

ciselevel, skills, récupère tous les • Sélectionner tous les
usersoy exercices avec les exercices
compétences et les
• JOIN exerciselevel et
informations sur
skills
l’auteur
• Récupérer les infor-
mations de l’auteur
par author_id depuis
soyuser

50
Transaction Affected Enti- Description Actions
Name ties
Update exercise exercise, exer- Met à jour un exer-
ciselevel cice et met à jour les • Mettre à jour l’exer-
compétences dans ex- cice dans la table ex-
erciselevel ercise

• Supprimer tous les en-

registrements dans ex-
erciselevel correspon-
dant à l’exercice mis à
jour

• Insérer de nouveaux
enregistrements avec
de nouvelles com-
pétences (ex_id,
skill_code) dans
exerciselevel

Delete exercise exercise, exer- Supprime un exercice

ciselevel et les lignes dans ex- • Vérifier l’auteur (seul
erciselevel correspon- l’auteur de l’exercice
dant à l’exercice sup- est autorisé à le sup-
primé primer + Admin)

• Supprimer les enreg-

istrements de exer-
ciselevel par ex_id

• Supprimer l’exercice
de la table exercise où
ex_id

51
Transaction Affected Enti- Description Actions
Name ties
Get exercise exercise, soyuser Récupère un exercice
par id + infos de l’au- • Récupérer l’exer-
teur cice depuis la table
exercise par id

• Récupérer les infos

de l’auteur depuis
soyuser

Get all sessions session, soyuser Récupère toutes les

sessions avec les in- • Récupérer toutes les
fos de l’auteur depuis sessions depuis ses-
soyuser sion

• Récupérer les in-

fos de l’auteur par
author_id depuis
soyuser

Get one session session, userses- Vérifie si l’utilisateur

sion est inscrit à cette ses- • Lire la session depuis
sion, puis la récupère session par sessionId

• Vérifier l’inscription
de userId à ses-
sionId depuis la table
usersession

52
Transaction Affected Enti- Description Actions
Name ties
Get session stats session, exercise, Récupère les stats de
sequence_ex- la session (score des • Récupérer la session
ercises, exer- productions, etc.) et par sessionId depuis
ciseproduction, vérifie l’auteur (seul session
soyuser l’enseignant qui a créé
• Récupérer la liste de
la session peut consul-
tous les exercices de la
ter les stats)
session en utilisant se-
quence, sequence_ex-
ercises, exercises

• Récupérer les infos

de l’étudiant pour
chaque production
depuis soyuser

Update session session, soyuser Met à jour et retourne

la session avec les in- • Vérifier les nouvelles
fos de l’auteur depuis données avant la mise
soyuser à jour (date, heure,
etc.)

• Mettre à jour la ses-

sion

• Récupérer les infos

de l’auteur depuis
soyuser

• Retourner la session
mise à jour

Delete session session Vérifie les permissions

de l’utilisateur (seul • Supprimer usersession
l’auteur peut sup- non implémenté
primer sa session),
supprimer la session

53
 Transaction Affected Enti- Description Actions
Name ties
Get session stu- session, userses- Récupère les sessions
dent sion auxquelles un étudi- • Récupérer les sessions
ant est inscrit auxquelles un étudi-
ant est inscrit

Table 8.1: Transactions du microservice ms-exercise-4-teacher

8.4.4.2 Ms-exercise-4-student

Le microservice ms-exercise-4-student s’occupe des interactions des étudiants avec les

exercices, notamment la soumission et l’évaluation de leurs productions. Les transactions as-
sociées à ce microservice impliquent la gestion des productions d’exercices et des déclarations
des étudiants (student statement), ainsi que la récupération et la suppression des soumissions
effectuées.
Chaque transaction est spécifiquement liée à des entités telles que studentstatement et
exerciseproduction. Par exemple, la transaction Create student statement crée une déclaration
d’étudiant après avoir vérifié l’existence de l’exercice, de la session et la disponibilité de
l’étudiant dans celle-ci. Cette segmentation permet de garantir que les fonctionnalités liées
aux étudiants sont isolées et correctement gérées.

Transaction Affected Enti- Description Actions

Name ties
Create student studentstate- Crée un état étudiant
statement ment, session après vérification • Préparer les données
(GET), exer- si la session est
• Vérifier l’existence de
cise (GET), chronométrée, la
l’énoncé
sequences disponibilité, l’exer-
(GET) JOIN cice existe • Évaluer et enregistrer
sequences_ex- la production
ercises, exer-
ciseproduction
(GET)

54
Transaction Affected Enti- Description Actions
Name ties
Get student studentstate- Récupère un état étu-
statement ment (GET) diant par sessionId, • Récupérer l’énoncé
userId, exerciseId de l’étudiant par
sessionId, userId,
exerciseId

Update student studentState- Met à jour un état étu-

statement ment (UP- diant • Mettre à jour l’état
DATE) étudiant par ses-
sionId, userId, exerci-
seId

Delete student studentstate- Supprime un état étu-

statement ment (Delete), diant par session, util- • Supprimer la produc-
exerciseproduc- isateur, exercice tion d’exercice dans
tion (Delete) exerciseproduction où
sessionId, userId, ex-
erciseId

• Supprimer l’état de
studentstatement où
sessionId, userId,
exerciseId

Create exercise exercisepro- Crée et évalue les

production duction, stu- productions d’exerci- • Préparer les données
dentstatement ces soumises par les
• Vérifier l’existence de
(GET) utilisateurs
l’énoncé

• Évaluer et enregistrer
la production

55
Transaction Affected Enti- Description Actions
Name ties
Get exercise pro- exerciseproduc- Récupère la produc-
duction tion (GET) tion d’exercice par Id • Récupérer la produc-
depuis exerciseproduc- tion d’exercice par Id
tion
Delete exercise exerciseproduc- Supprime la produc-
production tion (Delete) tion d’exercice par Id • Supprimer la produc-
tion d’exercice par Id

Get all ex pro- exerciseproduc- Récupère toutes les

duction by stu- tion (GET) productions d’exercice • Récupérer toutes les
dent soumises par un étu- productions d’exer-
diant dans une session cice par user_id et
(par user_id et session session id
id)
Get all ex pro- exerciseproduc- Récupère toutes les
duction related tion (GET) productions pour un • Récupérer toutes les
to ex exercice dans une ses- productions pour un
sion (par exerciseID et exercice par exerci-
sessionID) seID et sessionID

Get all ex pro- exerciseproduc- Récupère toutes les

duction by stu- tion (GET) productions soumises • Récupérer toutes les
dent and ex par un étudiant pour productions soumises
un exercice dans une par un étudiant
session (par userId, pour un exercice par
exerciseId, sessionId) userId, exerciseId,
sessionId

56
 Transaction Affected Enti- Description Actions
Name ties
Evaluate exer- exerciseproduc- Évalue une production
cise production tion (GET) d’exercice soumise par • Évaluer une pro-
un étudiant pour duction d’exercice
(LMS). Cela inclut le soumise par un
traitement des fichiers étudiant
liés à la soumission :
production d’exercice
elle-même, modèle
d’archive et énoncé
Generate state- studentstate- Génère un énoncé
ment (In exer- ment (generate pour un exercice. • Générer un énoncé
cise production) function) Cela utilise ModelStu- pour un exercice avec
dentStatement pour ModelStudentState-
générer l’énoncé et les ment
fichiers associés

Table 8.2: Transactions du microservice ms-exercise-4-student

8.4.4.3 Ms-user

Le microservice ms-user prend en charge toutes les transactions relatives à la gestion

des utilisateurs et des rôles associés. Il gère la création d’utilisateurs, la vérification des
jetons d’authentification, la réinitialisation des mots de passe, et les connexions utilisateurs.
Ce microservice s’assure que toutes les données des utilisateurs, y compris leurs rôles et
permissions, sont stockées de manière sécurisée et gérées efficacement.
Les transactions incluent, par exemple, la création d’un nouvel utilisateur (Create user)
avec un processus d’activation via e-mail, ou la gestion des rôles utilisateur via la transaction
Get all users with roles. Ce service est crucial pour la gestion des identités et des autorisations
au sein de l’application.

57
Transaction Affected Enti- Description Actions
Name ties
Create user soyuser Crée un nouvel util-
isateur puis envoie un • Vérifier l’email : s’il
e-mail d’activation à existe déjà
l’utilisateur
• Vérifier la correspon-
dance du mot de passe

• Hacher le mot de
passe

• Créer l’utilisateur

• Envoyer un e-mail
d’activation

Get all users soyuser (GET), Récupère tous les util-

with roles userrole (GET) isateurs ainsi que leurs • Obtenir tous les
rôles associés utilisateurs depuis
soyuser

• Obtenir tous les rôles

depuis userrole

• Associer chaque util-

isateur à un rôle

• JOIN !!

58
Transaction Affected Enti- Description Actions
Name ties
Get user skills skill, exercise- Récupère les com-
level, exer- pétences acquises • JOIN : exercisepro-
ciseproduction par l’utilisateur en duction, exerciselevel,
(JOIN), exercise fonction de leurs skill
productions d’exer-
• Traduire les compé-
cice avec un score
tences en fonction de
supérieur ou égal à
la locale (fr, en)
50, puis récupère les
détails de l’exercice • Récupérer l’exer-
correspondant cice correspondant
pour chaque compé-
tence depuis la table
exercise

Get user soyuser Récupère un utilisa-

teur par userId depuis • Récupérer un utilisa-
soyuser teur par userId

Activate user soyuser Active un utilisateur

par son nonce • Vérifier la validité du
nonce

• Activer l’utilisa-
teur en définissant
nonce=NULL et
enabled=TRUE

Update user pro- soyuser Met à jour le profil de

file l’utilisateur par userId • Vérifier les données

• Vérifier si l’utilisateur
existe

• Mettre à jour

59
Transaction Affected Enti- Description Actions
Name ties
Login soyuser Authentifie l’utilisa-
teur et génère des • Vérifier l’email et le
jetons mot de passe

• Générer le jeton d’ac-

cès et le jeton d’actu-
alisation

Logout / Déconnexion en supp-

rimant les jetons asso- • Extraire le jeton des
ciés à l’utilisateur cookies

• Supprimer le jeton
d’actualisation de to-
kenList (stockage en
mémoire)

Verify token soyuser (GET) Vérifie la validité d’un

jeton d’actualisation • Extraire le jeton
extrait des cookies (split)
de la requête. Si
• Vérifier le jeton
un jeton est trouvé,
(jwt.verify())
il est décodé pour
extraire l’email, et un • Décoder le jeton,
nouveau jeton d’accès obtenir l’email et
est généré récupérer les informa-
tions de l’utilisateur

• Générer un nouveau
jeton d’accès et le
stocker dans token-
List

60
Transaction Affected Enti- Description Actions
Name ties
Request pass- soyuser Gère le processus de
word reset demande de réinitiali- • Vérifier si l’email ex-
sation de mot de passe iste

• Récupérer les infor-

mations de l’utilisa-
teur

• Générer un nouveau
nonce pour l’utilisa-
teur

• Mettre à jour le nonce

de l’utilisateur dans la
base de données

• Envoyer un e-mail
à l’utilisateur pour
réinitialiser son mot
de passe

Reset password soyuser Gère le processus de

réinitialisation du mot • Obtenir l’utilisateur
de passe d’un utilisa- par nonce
teur
• Vérifier la correspon-
dance du mot de passe

• Hacher le mot de
passe

• Mettre à jour les don-

nées de l’utilisateur
avec également un
nouveau nonce

61
 Transaction Affected Enti- Description Actions
Name ties
Update user soyuser, userrole Met à jour les infor-
mations de l’utilisa- • Vérifier les nouvelles
teur (réservé à l’ad- données
ministrateur)
• Vérifier si l’utilisateur
existe

• Mettre à jour l’utilisa-

teur

• Obtenir le rôle associé

à l’utilisateur depuis
userrole

• Retourner le nouvel
utilisateur avec son
rôle associé

Delete user soyuser Supprime un utilisa-

teur par userId • Supprimer un utilisa-
teur par userId depuis
soyuser

Get all thanks / thanks Gérer les remer-

Create thank / ciements
Get number of
thanks

Table 8.3: Transactions du microservice ms-user

8.4.4.4 Ms-skill

Le microservice ms-skill est responsable de la gestion des compétences et des niveaux

associés aux exercices. Il traite les transactions qui impliquent la gestion des compétences
des utilisateurs et les relie aux exercices auxquels elles sont appliquées.
Par exemple, la transaction Create skill permet de créer et d’enregistrer une nouvelle
compétence, tandis que la transaction Get skill by exercise permet de récupérer les compé-
tences associées à un exercice spécifique. Ce microservice est essentiel pour la gestion des

62
compétences des étudiants et l’organisation des parcours d’apprentissage.

Transaction Affected Enti- Description Actions

Name ties
Get all skills by Skill, theme Récupère toutes les
locale (GET) compétences par lo- • Récupérer toutes les
cale avec leur thème compétences par lo-
cale

• Récupérer les thèmes

depuis theme

• Attacher chaque
thème à la compé-
tence correspondante

Get skill skill Récupère une compé-

tence par skillCode • Récupérer une com-
pétence par skillCode

Get theme theme Récupère un thème

par locale • Récupérer un thème
par locale

Create skill skill Créer et enregistrer

une nouvelle compé- • Créer et enregistrer
tence dans la table une nouvelle compé-
skill tence dans la table
skill

63
Transaction Affected Enti- Description Actions
Name ties
Update skill skill Mettre à jour et enreg-
istrer la compétence • Récupérer la compé-
mise à jour tence par skillCode

• Vérifier si la compé-
tence existe

• Mettre à jour et en-

registrer la nouvelle
compétence

Delete skill skill (Delete), Supprimer une com-

exerciselevel pétence de la table • Supprimer tous les
(Delete) skill, mais d’abord liens avec la compé-
supprimer tous les tence dans exercise-
liens avec la compé- level
tence dans la table
• Supprimer la compé-
ExerciseLevel.
tence elle-même

Get skill by exer- skill, exercise- Récupère les compé-

cise level (GET) tences pour un exer- • Récupérer les compé-
(JOIN) cice en utilisant JOIN tences pour un exer-
avec exerciselevel cice en utilisant JOIN
avec exerciselevel

64
Transaction Affected Enti- Description Actions
Name ties
Create all by ex- exerciselevel Lie plusieurs compé-
ercise (INSERT, GET) tences à un exercice. • Parcourir la liste des
compétences fournies
dans le corps de la re-
quête

• Lier chaque compé-

tence à un exercice en
l’insérant dans exer-
ciselevel

• Récupérer les lignes

insérées

Delete all exer- exerciselevel Supprimer tous les

cise level by ex- (delete) niveaux d’exercice par • Supprimer tous les
ercise exerciseID niveaux d’exercice par
exerciseID

Update all skills skill (UP- Mettre à jour toutes

by exercise DATE), exer- les compétences asso- • Récupérer toutes les
ciselevel (GET) ciées à un exercice compétences associées
(JOIN) à un exercice

• Mettre à jour les com-

pétences avec les nou-
velles données

Create profile profile Créer un nouveau pro-

fil et l’enregistrer dans • Créer et enregistrer
la table profile un nouveau profil
dans la table profile

65
Transaction Affected Enti- Description Actions
Name ties
Update profile profile Mettre à jour un profil
par profileID • Vérifier les nouvelles
données

• Vérifier si le profil ex-

iste par profileID

• Sauvegarder et re-
tourner le profil mis à
jour

Delete profile profile Supprimer un profil

de la table profile • Supprimer un profil
par profileID (ne sup- par profileID
prime pas les enfants
associés)
Get all profiles profile Récupère tous les pro-
fils depuis la table pro- • Récupérer tous les
file profils depuis la table
profile

Get profile profile Récupère un profil par

profileID • Récupérer un profil
par profileID

Table 8.4: Transactions du microservice ms-skill

8.4.5 Définition des Microservices

• Ms-user : Gère l’authentification et les profils des utilisateurs. Ce service s’occupe
de toutes les transactions liées à la gestion des utilisateurs, comme la création de
comptes, s’assurant que les données des utilisateurs sont gérées de manière sécurisée et
centralisée.

• Ms-skill : Responsable de la gestion des compétences et des niveaux associés aux

exercices. Il traite les transactions qui impliquent la compétence des utilisateurs, aidant

66
 à structurer les parcours d’apprentissage personnalisés.

• Ms-exercise-4-student : Ce service s’occupe spécifiquement des interactions des étu-

diants avec les exercices, traitant les soumissions, les évaluations et les retours. Il utilise
des scripts Python pour évaluer automatiquement les réponses soumises par les étudi-
ants.

• Ms-exercise-4-teacher : Facilite la création, la gestion et la mise à jour des exercices

par les enseignants. Il fournit des outils pour que les enseignants puissent organiser des
sessions éducatives, surveiller les progrès des étudiants et ajuster le contenu pédagogique
en conséquence et session.

8.4.6 Visualisation de l’Architecture

Le schéma suivant illustre la décomposition en microservices après l’analyse. Ce dia-
gramme montre comment les différentes transactions sont désormais gérées par les microser-
vices spécifiques, reflétant la segmentation basée sur le Domain-Driven Design et les principes
de séparation des responsabilités.
Deux schémas distincts sont utilisés pour représenter cette décomposition. Le premier
schéma (figure 8.5) est une vue simplifiée qui montre les microservices principaux et leurs
interactions de base. Cette vue simplifiée permet une compréhension rapide de la structure
générale et des flux principaux de l’application.
Le second schéma (figure 8.6) est plus détaillé et inclut toutes les relations entre les
entités au sein des microservices. Il montre précisément comment les tables de bases de
données sont organisées et comment elles interagissent au sein de chaque microservice, offrant
une vue complète des dépendances et des interactions au niveau de la donnée.
Ces visualisations fournissent une compréhension claire de la structure microservices de
l’application ShellOnYou, et aident à apprécier la manière dont le Domain-Driven Design a
été appliqué pour améliorer l’architecture de l’application. Les schémas sont essentiels pour
montrer l’efficacité de la segmentation et la cohérence avec les principes de design, tout en
assurant que le tableau des transactions guide la répartition adéquate des fonctionnalités.
Cette méthode structurée n’a pas seulement facilité une transition efficace vers une archi-
tecture de microservices, mais a également établi une base robuste pour l’évolutivité future,
améliorant significativement la maintenabilité et la performance de l’application ShellOnYou.
Le tableau des transactions a été un outil indispensable pour assurer que chaque fonctionnal-
ité était correctement assignée et que les interactions entre services étaient optimisées pour
une efficacité maximale.

67
Figure 8.5: Vue simplifiée de la décomposition en microservices de l’application ShellOnYou

68
Figure 8.6: Vue détaillée de la décomposition en microservices de l’application ShellOnYou,
montrant les interactions détaillées entre les entités

69
Section 9

Refonte Technique

9.1 Migration de JavaScript à TypeScript

9.1.1 Contexte JavaScript

JavaScript est un langage de script polyvalent utilisé pour le développement web dy-
namique. Malgré sa popularité, il présente des limites en termes de sécurité de type, ce qui
peut conduire à des erreurs à l’exécution.

9.1.2 Introduction à TypeScript

TypeScript, développé par Microsoft, étend JavaScript en ajoutant des types statiques.
Ce langage transcompilé améliore la maintenance et la performance du développement en
facilitant la détection précoce des erreurs et en offrant une meilleure autocomplétion lors de
la rédaction du code.

70
9.1.3 Avantages de TypeScript
Le passage à TypeScript procure de multiples avantages tels que :

• Amélioration de la maintenabilité et de la lisibilité du code grâce à des types explicites.

• Réduction des erreurs de runtime par la vérification de type au moment de la compila-

tion.

• Meilleure intégration avec les IDEs modernes, offrant une expérience de développement
enrichie avec l’autocomplétion et le refactoring.

9.1.4 Défis de la Migration

La migration vers TypeScript, bien que bénéfique, présente plusieurs défis :

• Nécessité de refondre ou adapter les bibliothèques JavaScript existantes pour être com-
patibles avec les types TypeScript.

• Potentielle augmentation du temps de développement initial due à la courbe d’appren-

tissage et aux efforts d’adaptation du code existant.

9.2 Introduction de la Couche Service

Pour améliorer l’architecture de l’application, une couche service a été introduite dans
chaque microservice. Cette couche est responsable de la logique métier, séparant clairement
les préoccupations de la gestion des requêtes et de l’accès aux données. Voici la structure
typique adoptée pour chaque microservice :

9.2.1 Structure de Microservice

La refonte a impliqué l’introduction d’une architecture divisée en plusieurs couches claires
dans chaque microservice, facilitant ainsi une séparation efficace des responsabilités et une
meilleure maintenabilité du code.

• Routes : Définit les endpoints de l’API et dirige les requêtes vers les contrôleurs
appropriés.

• Controllers : Orchestrent les opérations de traitement des requêtes, faisant le pont

entre les routes et les services.

• Services : Contiennent la logique métier et les règles d’application, interagissant avec

les modèles pour manipuler les données.

71
 • Models : Représentent la structure des données et fournissent des méthodes pour
accéder à ces données, généralement via des opérations de base de données.

Figure 9.1: Structure du microservice Ms-skill illustrant l’organisation des composants in-
ternes.

9.3 Impact de la Refonte sur la Performance et la Main-

tenabilité
La structuration en microservices et l’introduction de TypeScript ont non seulement
amélioré la sécurité et la robustesse de l’application mais ont également posé les bases d’une
évolutivité future et d’une facilité de maintenance, essentielles pour répondre aux exigences
croissantes des utilisateurs et des nouveaux développements technologiques.

72
Section 10

Analyse du Résultat

10.1 Analyse du Résultat

La phase finale de notre projet a consisté à évaluer la qualité du code refondu en utilisant
SonarQube, un outil reconnu pour son efficacité dans l’analyse de la qualité du code source.
SonarQube nous a permis de mesurer la santé de notre code selon plusieurs critères, incluant
la sécurité, la maintenabilité, et l’efficacité.

10.2 SonarQube: Un Outil d’Analyse de Code

SonarQube est une plateforme open source largement utilisée pour effectuer des analyses
statiques de code source. Elle aide les développeurs à détecter les bugs, les vulnérabilités de
sécurité, et les mauvaises pratiques de programmation au début du cycle de développement.
SonarQube prend en charge plusieurs langages de programmation et intègre parfaitement
avec des environnements de développement continu pour fournir des retours immédiats sur
la qualité du code produit. [21].

10.3 Résultats de l’Analyse SonarQube

Les résultats obtenus avec SonarQube ont montré une amélioration significative dans la
qualité du code après la migration vers les microservices. Les métriques de qualité, incluant la
sécurité, la robustesse, et la maintenabilité, ont toutes été respectées, démontrant l’efficacité
de notre architecture refondue. (voir figures 10.1, 10.2, 10.3, et 10.4).

10.4 Conclusion
Les résultats obtenus ont montré que tous les microservices, ainsi que l’agrégat des mi-
croservices, respectaient les critères de qualité fixés au départ. Les analyses de SonarQube

73
ont confirmé que notre architecture de microservices était non seulement fonctionnelle mais
également optimisée pour la performance et la sécurité.

Figure 10.1: Résultats SonarQube : Front, Gateway, Student

Figure 10.2: Analyse SonarQube : ms-skill

Figure 10.3: SonarQube : Student et Figure 10.4: SonarQube : Skill, User, Ag-
Teacher gregate

74
Section 11

Déploiement des Microservices avec Ku-

bernetes

11.1 Introduction
Dans cette section, nous détaillons les étapes suivies pour déployer les microservices de
l’application ”ShellOnYou” en utilisant Kubernetes, Minikube, et Docker. Le but principal
de cette orchestration est de gérer et de scaler efficacement les services au sein d’un cluster
Kubernetes.

11.2 Développement des Microservices

Chaque microservice, tel que ms-user, ms-skill, ms-exercise-teacher, etc., a été
développé en suivant une architecture microservices. Nous avons utilisé Node.js et Express
pour le backend, PostgreSQL pour la base de données, et React pour le frontend. Ces mi-
croservices ont été conteneurisés avec Docker afin de faciliter leur déploiement et leur gestion.

11.3 Création des Images Docker

Les images Docker ont été créées pour chaque microservice. Cela incluait la rédaction de
Dockerfiles spécifiques, comprenant la compilation des fichiers TypeScript en JavaScript,
l’installation des dépendances, et la configuration des environnements d’exécution. Une fois
les images créées, elles ont été taguées et poussées sur Docker Hub. Par exemple :

docker build -t dockerhub-username/ms-user:v1.0 .

docker push dockerhub-username/ms-user:v1.0

75
11.4 Gestion des Services Kubernetes
Pour permettre aux microservices de communiquer entre eux et avec l’extérieur, nous
avons défini des services Kubernetes à travers des fichiers service.yaml. Ces fichiers définis-
saient les types de services, notamment :

• ClusterIP pour les communications internes entre les microservices.

• NodePort pour exposer certains services à l’extérieur du cluster, facilitant ainsi l’accès
depuis un navigateur ou une autre interface utilisateur.

11.5 Gestion des Variables d’Environnement

Les microservices nécessitant des variables d’environnement sensibles (comme les infor-
mations d’identification de la base de données ou des clés API) ont été configurés à l’aide de
ConfigMaps et Secrets dans Kubernetes. Cela nous a permis de séparer les configurations
sensibles des images Docker, tout en assurant leur sécurité au moment de l’exécution.

11.6 Reconstruction et Redéploiement des Microser-

vices
À chaque modification dans le code d’un microservice, l’image Docker correspondante
a été reconstruite et mise à jour sur Docker Hub. Ensuite, nous avons déclenché un redé-
ploiement des microservices dans Kubernetes en utilisant la commande suivante :

kubectl rollout restart deployment/ms-user

Kubernetes a pris en charge le redéploiement des conteneurs sans causer d’interruption ma-
jeure du service.

11.7 Tests et Vérifications

Après chaque déploiement ou mise à jour, nous avons effectué des vérifications en consul-
tant les logs des pods avec kubectl logs et en vérifiant l’état des pods avec kubectl get
pods. Cela nous a permis de nous assurer que chaque microservice fonctionnait correctement
et communiquait efficacement avec les autres.

76
Figure 11.1: Exemple de fichier deployment.yaml (ms-user-deployment.yaml)

77
Section 12

Création des Guides d’Installation (V6

et V7)

Dans le cadre du projet Shell On You, une des contributions majeures a été la création
de guides d’installation clairs et détaillés pour la mise en place de l’application, aussi bien
avant qu’après la migration vers une architecture microservices. Ces documents facilitent
non seulement l’installation, mais aussi la configuration et l’utilisation de l’environnement de
développement. Ils constituent une ressource précieuse pour les développeurs et utilisateurs
souhaitant déployer l’application localement ou sur des serveurs.

12.1 Guide d’Installation V6

Avant de procéder à la migration de Shell On You vers une architecture microservices
(V7), un guide d’installation détaillé pour la version monolithique (V6) a été créé. Ce doc-
ument avait pour objectif d’aider les développeurs à installer l’application en utilisant des
conteneurs Docker et Docker Compose, tout en configurant correctement l’environnement de
développement.
Le guide contenait les éléments suivants :

• Prérequis : Installation de Docker et Docker Compose.

• Téléchargement des Repositories : Instructions pour cloner les différentes branches

des microservices (comme exercise, gateway, front-react, etc.).

• Configuration : Explication des variables d’environnement via des fichiers comme

variables.env.template et docker-compose.yml.

• Lancement des Conteneurs : Commandes pour démarrer l’application avec Docker

Compose.

78
 • Résolution des Problèmes Courants : Solutions pour des erreurs fréquentes liées
aux versions de Node.js et à la configuration des conteneurs.

Ce guide a permis de standardiser l’installation de l’application pour les développeurs,

garantissant un environnement de travail cohérent pour tous les contributeurs.

12.2 Guide d’Installation V7 (Post-Migration)

Suite à la migration de l’application vers une architecture microservices (V7), un nouveau
guide d’installation a été élaboré. Ce guide a été adapté pour tenir compte de la décompo-
sition de l’application en plusieurs microservices, chacun étant encapsulé dans un conteneur
Docker distinct. Les principaux changements par rapport au guide de la V6 incluent :

• Microservices Décomposés : Chaque service (comme ms-skill, ms-gateway, ms-

user) a son propre processus d’installation et de configuration.

• Mise à jour des Scripts de Configuration : Les fichiers de configuration (variables.env,

docker-compose.yml, etc.) ont été adaptés pour refléter la nouvelle architecture dis-
tribuée.

Ce second guide a été essentiel pour faciliter la transition vers la nouvelle architecture
microservices et pour permettre aux équipes de développement de s’adapter rapidement aux
nouvelles méthodes de déploiement.

79
Section 13

Gestion de Projet

La gestion efficace du projet a été un élément clé de la réussite de la migration de Shel-

lOnYou vers une architecture microservices. Ce chapitre se concentre sur les outils et les
méthodes utilisés pour organiser les tâches, faciliter la collaboration, et assurer une commu-
nication fluide entre les membres de l’équipe.

13.1 Organisation des Tâches avec Trello et GitLab Is-

sues
La planification et le suivi des tâches ont été réalisés grâce à une combinaison de Trello et
GitLab Issues. Ces deux outils ont permis une gestion claire des tâches, en offrant des fonc-
tionnalités telles que les tableaux kanban, le suivi des temps et l’organisation par étiquettes.

13.1.1 Trello
Trello a été utilisé pour gérer la vue d’ensemble des tâches. Chaque étape du projet, de
la conception à l’implémentation des microservices, était organisée en colonnes représentant
les différents statuts des tâches : TO DO, DOING, BLOCKED, et DONE. Chaque carte
Trello représentait une tâche spécifique, avec des échéances, des checklists détaillées et des
assignations de membres d’équipe.

13.1.2 GitLab Issues

Pour la gestion plus technique et le suivi des bugs ou améliorations, GitLab Issues a été
utilisé. Chaque problème (issue) était classé par type (bug, db, back, refactor ...), et assigné
à un membre de l’équipe pour traitement. Les tags ont permis de mieux catégoriser et filtrer
les tâches en fonction des priorités ou des sprints en cours.

80
 Figure 13.1: Vue de l’espace de travail Trello

Figure 13.2: Aperçu de la gestion des tâches dans GitLab

13.2 Communication et Collaboration avec Mattermost

La communication efficace au sein de l’équipe a été facilitée par Mattermost, un outil
de messagerie d’équipe open-source. Différents canaux ont été créés pour organiser les dis-
cussions en fonction des sujets et des équipes concernées : Canal Base de Données, Canal
Documentation ...

81
13.3 Réunions Virtuelles avec Zoom
Dans les cas où les réunions en présentiel étaient impossibles, l’équipe a utilisé Zoom
pour organiser des réunions virtuelles. Zoom a permis de rassembler toute l’équipe, quel
que soit l’emplacement, pour des réunions hebdomadaires de suivi, ainsi que des sessions de
résolution de problèmes techniques plus approfondies.

13.4 Bilan de la Gestion de Projet

L’utilisation de ces outils a permis une gestion efficace et collaborative du projet. Grâce
à la combinaison de Trello pour la gestion des tâches, GitLab Issues pour le suivi technique,
et Mattermost pour la communication, chaque membre de l’équipe pouvait accéder aux
informations nécessaires en temps réel. De plus, les réunions Zoom ont permis de résoudre
rapidement les problèmes complexes et de maintenir une cohésion d’équipe malgré la distance.
Cette gestion de projet, bien structurée et collaborative, a joué un rôle crucial dans la
réussite de la migration de ShellOnYou vers une architecture microservices, assurant une
exécution fluide des différentes phases du projet.

82
Section 14

Environnement et Outils de Développe-

ment

14.1 Environnement Matériel

Le développement a été effectué sur un ordinateur ACER ASPIRE équipé d’un processeur
Intel Core i7-8550U à 1.8 GHz et de 8 GB de RAM, fournissant une plateforme stable pour
tous les besoins de développement et de test.

14.2 Environnement logiciel (Langages, Bibliothèques

et Frameworks)

14.2.1 Node.js
Node.js est un environnement d’exécution JavaScript côté serveur basé sur le moteur
JavaScript V8 de Chrome. Il est conçu pour construire des applications réseau évolutives et
efficaces. Node.js utilise un modèle d’entrées/sorties non bloquant et orienté événement, ce
qui le rend léger et efficace, parfait pour les applications gérant de nombreuses données en
temps réel sur des dispositifs distribués 1 .

14.2.2 React
React est une bibliothèque JavaScript pour construire des interfaces utilisateur. Dévelop-
pée par Facebook, React permet de créer des vues rendues de manière réactive pour chaque
état dans une application, permettant ainsi une mise à jour et un rendu efficaces des com-
posants appropriés lorsque les données changent. Sa force réside dans la capacité de gérer

1
https://en.wikipedia.org/wiki/Node.js

83
efficacement le DOM virtuel pour optimiser les interactions et les mises à jour de l’interface
utilisateur 2 .

14.2.3 PostgreSQL
PostgreSQL est un système de gestion de base de données relationnelle objet robuste et
complet. Il est reconnu pour sa conformité aux standards et son support étendu de fonc-
tionnalités SQL avancées, telles que les transactions sécurisées, les sous-requêtes complexes,
et les clés étrangères. Sa fiabilité, sa flexibilité et son support actif par une communauté
ouverte en font une base de données de choix pour les applications professionnelles 3 .

14.2.4 Visual Studio Code (VSCode)

Visual Studio Code est un éditeur de code source développé par Microsoft. Il est léger
mais puissant, offrant un support natif pour un large éventail de langages de programmation
et de frameworks. Avec ses fonctionnalités telles que le débogage intégré, le contrôle Git, la
complétion syntaxique, le refactoring de code, et les snippets, VSCode améliore significative-
ment l’efficacité des développeurs dans le développement d’applications 4 .

14.2.5 Docker
Docker est une plateforme de conteneurisation qui permet de développer, déployer et
exécuter des applications dans des conteneurs légers et portables. Les conteneurs Docker
encapsulent une application avec toutes ses dépendances dans un conteneur isolé, ce qui
garantit que l’application fonctionnera uniformément dans n’importe quel environnement de
machine. Cette technologie est cruciale pour assurer la cohérence des environnements de
développement, de test et de production 5 .

14.2.6 GitLab
GitLab est une plateforme de gestion de versions et de CI/CD (Continuous Integra-
tion/Continuous Delivery) qui supporte le développement de logiciels avec le contrôle de
version, la gestion des tâches, et les revues de code, ainsi que le déploiement continu. Elle
est utilisée pour collaborer sur des projets de code et automatiser la chaîne de déploiement
des applications, facilitant ainsi les processus de développement de logiciels complexes 6 .

2
https://en.wikipedia.org/wiki/React_(JavaScript_library)
3
https://en.wikipedia.org/wiki/PostgreSQL
4
https://en.wikipedia.org/wiki/Visual_Studio_Code
5
https://en.wikipedia.org/wiki/Docker_(software)
6
https://en.wikipedia.org/wiki/GitLab

84
 Ces outils et technologies forment la base sur laquelle l’application ”ShellOnYou” a été
développée et migrée de son ancienne architecture monolithique à une solution basée sur les
microservices, en utilisant des méthodes modernes et efficaces pour répondre aux exigences
actuelles des applications web.

85
 Part IV

Conclusion et perspectives

86
Section 15

Conclusion et perspectives

15.1 Récapitulatif des Principales Réalisations

Au cours de ce projet, nous avons entrepris une série de développements et de rénovations
techniques visant à transformer l’application ShellOnYou de sa forme monolithique vers une
architecture basée sur les microservices. Cette transformation a non seulement répondu aux
exigences initiales de scalabilité et de maintenabilité mais a également posé les bases pour
des améliorations futures. Voici les points saillants de ce que nous avons accompli :

• Migration de l’Architecture : La transition de l’architecture monolithique vers une

structure en microservices, guidée par des principes de Domain-Driven Design (DDD)
et une analyse statique rigoureuse du code.

• Amélioration du Code : Refactoring du code de JavaScript à TypeScript, apportant

des améliorations significatives en termes de sécurité des types et de qualité du code.

• Intégration de Nouvelles Technologies : Adoption de technologies modernes

comme Docker et GitLab pour la conteneurisation des services et l’automatisation du
pipeline CI/CD, améliorant ainsi les processus de développement et de déploiement.

• Analyse de Qualité avec SonarQube : Utilisation de SonarQube pour surveiller et

améliorer continuellement la qualité du code, ce qui a aidé à maintenir des standards
élevés tout au long du développement.

Chaque étape de ce projet a été conçue pour aligner l’application avec les meilleures pra-
tiques de l’industrie et pour répondre de manière proactive aux défis technologiques émer-
gents.

87
15.2 Perspectives
Alors que notre projet ShellOnYou a atteint des jalons significatifs dans l’amélioration de
la scalabilité et de la maintenabilité grâce à la migration vers les microservices, des possibilités
d’amélioration continue se présentent pour assurer que l’application reste à la pointe de
la technologie. Voici quelques-unes des principales orientations que nous envisageons pour
l’avenir :

• Exploration de nouveaux patterns de microservices : Bien que nous ayons

adopté une architecture basique de microservices, l’exploration de patterns plus avancés,
tels que les SAGAs, les API Gateways et les BFFs (Backends For Frontends), pour-
rait offrir une meilleure gestion des transactions distribuées et une amélioration de
l’expérience utilisateur.

• Adoption de nouvelles technologies d’orchestration : Avec l’augmentation du

nombre de microservices, l’orchestration devient un défi. L’adoption de technologies
comme Kubernetes pourrait simplifier la gestion des conteneurs, améliorer la fiabilité
et l’efficacité des déploiements en production.

• Utilisation d’un ORM : L’intégration d’un ORM (Object-Relational Mapping) pour

gérer les interactions entre les bases de données et notre code pourrait réduire la com-
plexité du code de base de données et améliorer la maintenabilité.

• Automatisation accrue : Renforcer l’automatisation dans les tests, le déploiement et

la surveillance pour minimiser les erreurs humaines et accélérer les cycles de développe-
ment.

• Amélioration continue de la sécurité : Avec l’évolution des menaces de sécurité,

une attention continue sera nécessaire pour sécuriser à la fois les codes et les infrastruc-
tures, en adoptant des pratiques telles que l’intégration de scanners de sécurité dans le
pipeline CI/CD.

Ces initiatives visent non seulement à améliorer l’efficacité et la robustesse de l’application

mais aussi à anticiper et répondre aux exigences futures des utilisateurs et des marchés
technologiques en constante évolution.

88
Bibliography

[1] A. Megargel and V. Shankararaman. “Migrating from Monoliths to Cloud-Based Mi-

croservices: A Banking Industry Example.” In: Software Engineering in the Era of Cloud
Computing. Research Collection School Of Information Systems, 2020, pp. 85–108.
[2] Gustav Johansson. “Investigating differences in response time and error rate between a
monolithic and a microservice based architecture.” MA thesis. KTH, School of Electrical
Engineering and Computer Science (EECS), 2019, p. 13.
[3] Miika Kalske. “Transforming monolithic architecture towards microservice architec-
ture.” MA thesis. 2018.
[4] M. Fowler. Monolith First. martinfowler.com. June 2015. url: https://martinfowler.
com/bliki/MonolithFirst.html.
[5] Alan Megargel, Venky Shankararaman, and David K. Walker. “Migrating from Mono-
liths to Cloud-Based Microservices: A Banking Industry Example.” In: Software Engi-
neering in the Era of Cloud Computing. Ed. by Muthu Ramachandran and Zaigham
Mahmood. Cham: Springer International Publishing, 2020, pp. 85–108. isbn: 978-3-
030-33624-0. doi: 10.1007/978-3-030-33624-0_4. url: https://doi.org/10.1007/
978-3-030-33624-0_4.
[6] A. Martini and J. Bosch. “On the interest of architectural technical debt: Uncovering
the contagious debt phenomenon.” In: Software: Practice and Experience 47 (2017),
e1877. doi: 10.1002/smr.1877.
[7] Z. Dehghani. Data Monolith to Mesh. Martin Fowler. May 2019. url: https : / /
martinfowler.com/articles/data-monolith-to-mesh.html.
[8] M. Mazzara et al. “Microservices: Migration of a Mission Critical System.” In: IEEE
Transactions on Services Computing 14.5 (Sept. 2021).
[9] M. Li. IN5320: Lecture 2: Information systems and complexity. Oslo, Apr. 2020.

89
[10] Thomas Erl. Service-Oriented Architecture: Concepts, Technology, and Design. Prentice
Hall, 2005.
[11] Nicolai M Josuttis. SOA in Practice: The Art of Distributed System Design. O’Reilly
Media, 2007.
[12] Dirk Krafzig, Karl Banke, and Dirk Slama. Enterprise SOA: Service-Oriented Archi-
tecture Best Practices. Prentice Hall, 2004.
[13] Michael P Papazoglou and Willem-Jan van den Heuvel. “Service-oriented architectures:
approaches, technologies and research issues.” In: The VLDB Journal—The Interna-
tional Journal on Very Large Data Bases 16.3 (2007), pp. 389–415.
[14] Sam Newman. Monolith to Microservices Evolutionary Patterns to Transform Your
Monolith. O’Reilly Media, 2022.
[15] Martin Fowler and James Lewis. “Microservices: a definition of this new architec-
tural term.” In: ThoughtWorks (2014). url: https://martinfowler.com/articles/
microservices.html.
[16] James Lewis and Martin Fowler. “Microservices.” In: ThoughtWorks (2014). url: https:
//martinfowler.com/microservices/.
[17] Nicola Dragoni et al. Microservices: Yesterday, Today, and Tomorrow. Springer, 2017.
[18] Martin Kleppmann. Designing Data-Intensive Applications: The Big Ideas Behind Re-
liable, Scalable, and Maintainable Systems. O’Reilly Media, Inc., 2017.
[19] Davide Taibi, Valentina Lenarduzzi, and Claus Pahl. “Architectural Patterns for Mi-
croservices: A Systematic Mapping Study.” In: Proceedings of the 6th International
Conference on Model-Driven Engineering and Software Development (Mar. 2018). doi:
10.5220/0006798302210232.
[20] Chris Richardson. Microservices Patterns: With examples in Java. Manning Publi-
cations, 2018. isbn: 9781617294549. url: https : / / books . google . dz / books ? id =
UeK1swEACAAJ.
[21] SonarSource. SonarQube Official Website. Accessed: 2024-08-28. 2024. url: https :
//www.sonarqube.org.

90