REPUBLIC OF CAMEROON

Peace-Work-Fatherland

MINISTERE DE L’ENSEIGNEMENT SUPERIEUR MINISTRY OF HIGHER EDUCATION

UNIVERSITE DE YAOUNDE I UNIVERSITY OF YAOUNDE I

IIiTapez une équation ici. DE IIiTapez une équation ici.
ECOLE NATIONALE SUPERIEUR NATIONAL ADVANCED SCHOOL OF

POLYTECHNIQUE ENGINEERING
DEPARTEMENT DU GENIE INFORMATIQUE DEPARTEMENT OF COMPUTER ENGINEERING

RESTRUCTURATION LOGIQUE DU SYSTEME INFORMATIQUE VIA

LES MICROSERVICES

Mémoire de fin d’études/Master of Engineering

Présenté et soutenu par :

KAMDEM KAMGAING DONALD KEVIN

En vue de l’obtention du :

Diplôme de master professionnelle en gestion des systèmes d’information

Sous la direction de :

Professeur KANMOGNE

Devant le jury composé de :

- Président : Pr. MBIANDA PATRICE, maître de conférences des universités UY II SOA

- Rapporteur : Pr. KANMOGNE ABRAHAM, maître de conférences des universités UY I

- Examinateur : Dr. NGUENANG LOUIS BERNARD, Enseignant d’informatique UY I

ANNEE Académique 2021 - 2022

 KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de
I
Gestion
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 DÉDICACE :

A ma
mère

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

II
Gestion
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 REMERCIEMENTS :

Nous voulons exprimer notre gratitude et reconnaissance à tous ceux qui ont participé de
près ou de loin directement ou indirectement à l’élaboration de ce document notamment :

❖ Au seigneur et sauveur EMMANUEL JESUS CHRIST DE NAZARETH pour la

force, le courage, le sacrifice et l’endurance dans ce travail ;

❖ Au président directeur Général de l’institut siantou M. WANTOU SIANTOU

LUCIEN qui par sa foi en ses étudiants, ne cesse de nous prodiguer des conseils et
réussit à mener à bout la lourde et difficile mission qui lui est confiée ;
❖ Mon encadreur académique professeur KANMOGNE pour l’accompagnement et les
recommandations ;
❖ Au président de jury professeur MBIANDA PATRICE pour l’appréciation
constructive, les critiques et suggestion sur ce travail ;
❖ A Monsieur NGUENANG LOUIS BERNARD docteur et enseignant d’informatique
pour l’appréciation constructive, les critiques et suggestion sur ce travail ;
❖ Mon encadreur technique monsieur M. Neussie Michel pour ses recommandations,
son temps disponible et son suivi ;
❖ A tout le personnel administratif et professoral de l’institut siantou supérieur pour
l’encadrement, le suivi, les efforts, la qualité de la formation ;
❖ A tout le personnel administratif et professoral de l’école nationale supérieur
polytechnique ;
❖ Ma maman Mme MAANDJO BERNADETTE épouse KAMDEM qui m’a toujours
soutenu financièrement, moralement, spirituellement ;
❖ A toute ma famille pour leur soutien morale et attention ;
❖ Nos remerciements à tous nos camarades de l’Institut supérieur siantou pour les
échanges entretenus ;
❖ A tous ceux qui de près ou de loin ont contribué d’une manière quelconque à
l’achèvement de ce travail.

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

III
Gestion
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 GLOSSAIRE :

API: application programming interface

DDD: domain driven design

EDI: environnement de développement intégré

JSON : JavaScript Object Notation

OMG: Object Management Group

REST: Representational state transfer

RPC: Remote procedure call

SGBD: Système de gestion des bases de données

UML: Unified Modeling Language

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

IV
Gestion
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 RÉSUMÉ :

Dans un besoin de flexibilité constante prenant en comptes une meilleure économie

(matériel, logiciel …), les exigences liées à la sécurité, au droit, à la concurrence, les équipes
projets en charge de produire des applications informatiques se doivent de définir une politique
d’organisation et de travail adéquat. Dans cet ordre d’idée, Le présent mémoire traite d’une
organisation du système informatique basé sur les microservices. Il apporte des solutions
scientifiques et opérationnelles à la problématique d’évolution des systèmes informatiques à un
cout réduit dans des délais de plus en plus court tout en veillant à la sécurité des informations
et du matériel. Pour ce faite, la méthodologie abordée s’est articulée sur :

Le passage du monolithique au microservice ;

Les modes de communications et protocoles utilisable pour les microservices ;
Le rappel de quelques outils de modélisation fournis par UML.

Un Accent est mis sur les concepts clés, les mises en garde, les démarches et
l’expérimentation relatif à la mise en œuvre de l’architecture microservices afin de permettre la
compréhension et la nécessité de cette structuration au sein de la société moderne actuelle. Pour
illustrer les démarches proposées, une mise en application opérant sur le système informatique
de gestion des emplois du temps dans l’enseignement supérieur a été réalisée et des résultats au
meilleur rendement ont été obtenus.

Mots-clés : microservices, modélisation, monolithique, politique d‘organisation, sécurité

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

V
Gestion
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 ABSTRACT :

In a need for constant flexibility taking into account a better economy (hardware, software
...), the requirements related to security, law, competition, the project teams in charge of
producing computer applications must define an adequate organization and work policy. In this
vein, this dissertation deals with an organization of the computer system based on
microservices. It provides scientific and operational solutions to the problem of evolution of
computer systems at a reduced cost in increasingly current deadlines while ensuring the security
of information and equipment. For this purpose, the methodology addressed was based on:

The transition from monolithic to microservice;

Communication modes and protocols that can be used for microservices;
The reminder of some modeling tools provided by UML.

Emphasis is placed on the key concepts, caveats, approaches and experimentation related
to the implementation of microservices architecture in order to allow the understanding and
necessity of this structuring within today's modern society. To illustrate the proposed
approaches, an implementation operating on the computerized time management system was
carried out and results with the best performance were obtained.

Keywords: microservices, modeling, monolithic, organization and work policy, security

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

VI
Gestion
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 LISTE DES FIGURES :

Figure 1.1 : Exemple d'architecture de système informatique ................................................................................ 3

Figure 2.1 : Avantages et inconvénients des SOA ((25) page 24) ............................................................................ 8
Figure 3.1: exemple d'architecture monolithique ................................................................................................. 13
Figure 3.2 : phases de développement d’un projet avec une approche DDD ........................................................ 14
Figure 3.3 : fonctionnement du microservice de configuration ............................................................................. 17
Figure 3.4 : fonctionnement du microservice de registre ...................................................................................... 18
Figure 3.5 : hiérarchie des diagrammes UML 2.5 (28) .......................................................................................... 13
Figure 3.6 : formalisme d'un acteur ...................................................................................................................... 14
Figure 3.7 : formalisme d'un cas d'utilisation ........................................................................................................ 14
Figure 3.8 : formalisme d’une relation d'association ............................................................................................ 15
Figure 3.9 : formalisme de la généralisation ......................................................................................................... 15
Figure 3.10 : généralisation de A par B ................................................................................................................. 15
Figure 3.11 : formalisme d'une relation d'inclusion .............................................................................................. 15
Figure 3.12 : extension de A par B ......................................................................................................................... 15
Figure 3.13 : formalisme de la relation d'inclusion ............................................................................................... 15
Figure 3.14 : formalisme d'une activité ................................................................................................................. 16
Figure 3.15 : formalisme d'une transition ............................................................................................................. 16
Figure 3.16 : formalisme d'un couloir .................................................................................................................... 16
Figure 3.17 : formalisme du point d'entrée ........................................................................................................... 16
Figure 3.18 : formalisme de sortie d'une activité .................................................................................................. 16
Figure 3.19 : formalisme de sortie d'un flux .......................................................................................................... 16
Figure 3.20 : formalisme de la barre de synchronisation ...................................................................................... 17
Figure 3.21 : Formalisme du losange .................................................................................................................... 17
Figure 3.22 : Formalisme et composante d'une classe .......................................................................................... 17
Figure 3.23 : formalisme d'un paquet en représentation globale ......................................................................... 18
Figure 3.24 : représentation UML d'un composant ............................................................................................... 19
Figure 3.25 : représentation UML d'un nœud ....................................................................................................... 19
Figure 4.1 : exemple de formulaire pour la création d'un microservice pour la gestion des processus métiers ... 21
Figure 4.2 : formulaire de création du microservice de registre ............................................................................ 22
Figure 4.3 : formulaire de création du microservice load balancer ....................................................................... 22
Figure 4.4 : commande de création et de paramétrage du répertoire de stockage des fichiers de configuration
du projet ................................................................................................................................................................ 23

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

VII
Gestion
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 Figure 4.5 : formulaire de création du microservice de configuration .................................................................. 24
Figure 4.6 : diagramme de cas d'utilisation du sous-système de gestion des comptes composante du système
GESTIME ................................................................................................................................................................ 25
Figure 4.7 : diagramme d'activité cas d'utilisation "s'authentifier" ...................................................................... 27
Figure 4.8 : diagramme de classe du sous-système de gestion des profils d'utilisateurs composante du système
GESTIME ................................................................................................................................................................ 28
Figure 4.9 : diagramme de cas d'utilisation pour la gestion des infrastructures .................................................. 29
Figure 4.10 : usecase diagram pour la gestion des emplois du temps .................................................................. 31
Figure 4.11 : diagramme de séquence l'ajout de dépendance .............................................................................. 32
Figure 4.12 : diagramme de classe du noyau centrale du système GESTIME ....................................................... 33
Figure 4.13 : diagramme de cas d'utilisation pour la gestion du calendrier académique ..................................... 34
Figure 4.14 : diagramme de séquence du scenario nominale pour la gestion des jours ouvrables ...................... 35
Figure 4.15 : diagramme de classe pour la gestion du calendrier académique .................................................... 36
Figure 4.16: diagramme de déploiement globale du système .............................................................................. 36
Figure 4.17 : exemple de requête JSON adressé au microservices des utilisateurs ............................................... 37

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

VIII
Gestion
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 LISTE DES TABLEAUX :

Tableau 2.1 : Plateformes et Framework de développement des microservices ((25) page 22) ............................. 7
Tableau 2.2 : Différences entre microservices et SOA ((25) page 25 et 26) ............................................................ 9

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

IX
Gestion
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 SOMMAIRE :

.................................................................................................................................................... 1

DÉDICACE : ........................................................................................................................... II

REMERCIEMENTS : .......................................................................................................... III

GLOSSAIRE : ........................................................................................................................ IV

RÉSUMÉ : ............................................................................................................................... V

ABSTRACT : .......................................................................................................................... VI

LISTE DES FIGURES : ...................................................................................................... VII

LISTE DES TABLEAUX : .................................................................................................... IX

SOMMAIRE : .......................................................................................................................... X

INTRODUCTION GÉNÉRALE : .......................................................................................... 1

CHAPITRE I : CONTEXTE ET PROBLEMATIQUE ....................................................... 2

CHAPITRE II : REVUE DE LITTERATURE ..................................................................... 5

CHAPITRE III : METHODOLOGIE ................................................................................. 12

CHAPITRE IV : RESULTAT ET DISCUSSIONS ............................................................ 20

CONCLUSION GENERALE ET PERPECTIVES : .......................................................... 38

BIBLIOGRAPHIE : ................................................................................................................ X

TABLE DE MATIERE .......................................................................................................XIII

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

X
Gestion
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 INTRODUCTION GÉNÉRALE :

L’informatique a connu des étapes évolutives importantes réorganisées et définit dans des
domaines tel que le génie logiciel. De nombreux modèles et démarches sont aujourd’hui laissés
au choix des ingénieurs sur le terrain. Ceux-ci adoptent ce qui leur semblent convenables face
aux problèmes qu’ils auront à résoudre en fonctions de plusieurs paramètres parmi lesquelles :

Le cout qui renvoie aux ressources matériels, humains et financiers nécessaire pour
exécuter le cahier de charge ;
Le délai qui fait référence au temps nécessaire pour l’accomplissement des différentes
taches ;
La qualité : elle se définit comme l’appréciation faite sur le produit à la lumière des
spécifications scientifiques, des normes, des impacts diverses (environnementale,
sociale …) et de l’opinion des différentes parties prenantes au projet …

Dans cette thématique, l’on assiste à la création des applications qualifiées de « tout en
un » encore appelé applications monolithiques qui bien que présentant des avantages pour des
systèmes de petite envergure, posent à la longue des problèmes de sécurité (confidentialité,
disponibilité), de maintenabilité (corrective, évolutive …), de surachat de ressources
matérielles… Dès lors, l’alternative des microservices s’illustre comme une piste permettant de
remédier à des problématiques liées à la maintenance, la sécurité, les dépenses diverses, tout en
s’adaptant à une société en constante mutation.

Dans ce document il sera question de présenter le contexte de travail au chapitre un, de

faire une revue sur les technologies antérieures dans l’optique de montrer la place des
microservices au chapitre deux ,de donner des démarches relatives aux bonnes pratiques pour
la mise sur pieds des microservices (procédés de migration, sécurité des informations,
architecture, monitoring, modélisation) au chapitre trois et enfin de procéder à une mise en
œuvre sur une système informatique choisi pour une bonne illustration et expérimentation en
temps réel pour une bonne appréciation des prévisions théoriques.

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

1
Gestion
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 CHAPITRE I : CONTEXTE ET PROBLEMATIQUE

Introduction :
Afin de garantir un rendement de qualité via les outils informatiques répondant aux
besoins recensés d’un système d’information tout en tenant compte des contraintes liées à la
sécurité (confidentialité, disponibilité, intégrité, authenticité, non répudiation), l’on procède à
une étude minutieuse des opérations automatiquement réalisables en s’appuyant sur des
méthodes d’analyses ayant fait leur preuve ceci dans le but de produire des applications
informatiques adéquats. Les contraintes liées à la sécurité et aux futures taches de maintenances
recommandent une subdivision logique des applications et une sauvegarde sur plusieurs
serveurs afin d’éviter :

Une paralysie complète du système liée aux multiples accés concurrents ;

Une difficulté de mise à niveau du système informatique ;
…;

A ce titre les applications informatiques développées suivant la philosophie « tout en

un » nécessitent une refonte en ce sens qu’elles ne permettent pas de faire respecter aisément
les exigences précédemment énumérées. Dans ce chapitre nous parlerons d’un exemple pratique
de création d’application « tout en un » pour ensuite ressortir des questionnements liés aux
inconvénients qu’elle présente.

I – Analyse du fonctionnement d’une application de gestion des services d’un

réseau de communication :
Supposons que nous désirons un système informatique pour la gestion des services rendus
du réseau Orange Cameroun. De façon générale nous aurons :

La gestion du service d’appel ;

La gestion du service de messagerie ;
La gestion du service de connexion internet ;
La gestion du service de monnaie électronique.

Bien qu’ils pourraient exister d’autres fonctionnalités fournis par Orange Cameroun, nous
nous limiterons à ces 4 fonctionnalités. Pour une équipe projet en charge de la mise en

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

2
Gestion
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 application du système informatique fournissant ces quatre fonctionnalités l’on pourrait obtenir
une architecture globale représenté ainsi qu’il suit :

Gestion Gestion d’
des appels internet

Client 1

Service de
Service de
monnaie
messagerie Base de données
électronique

Client n
Serveur

Figure 1.1 : Exemple d'architecture de système informatique

En s’intéressant à la conception du serveur l’on a à partir du moment où le projet est

énorme, un grossissement de l’application. Dès cet instant, la mise en œuvre précédente dite
monolithique (parce que regroupant ses fonctionnalités ou bien tout en un) présente des
inconvénients donc entre autres :

La centralisation de toutes les fonctionnalités entrainant des problèmes de performance

et de panne généralisée sur le système ;
La contrainte d’uniformité technologique entrainant des restrictions dans la sélection
des membres de l’équipe de développement et imposant un cout supplémentaire destiné
à former les ingénieurs à la maitrise d’une seule technologie ;
Une attente longue du client du faite que l’application est livrée en bloc. Ceci rend la
conception de l’application basée sur une architecture monolithique inadaptée aux
méthodes argiles ;
Une mise en production prenant beaucoup de temps ;
Une difficulté de test de l’application ;
Une difficulté de maintenance ;

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

3
Gestion
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 Des défauts pour ce qui est des garanties relatives à la confidentialité de l’architecture
du système informatique et la disponibilité des informations.

A la lumière de tout ce qui vient d’être établie, Aux vues des constantes mutations de
l’environnements, il convient de faire appel à des philosophies alternatives pour anticiper des
problèmes précédemment détaillés certains d’une gravité extrême pouvant exposer aux
poursuites judiciaires.

II. Alternatives technologiques :

Nous avons établi précédemment les limites liées à l’architecture adoptée en ce sens
qu’elle ne convenait pas au macro projet et à une démarche agile. Face aux problèmes
précédemment recensés, les ingénieurs ont posé les bases d’une nouvelle architecture beaucoup
plus flexibles résolvant les problématiques rencontrées par la philosophie du « tout en un ». Les
microservices s’illustrent donc comme la technologie du futur avec pour avantages :

Une décentralisation des constituants d’un macro projet ;

Une diversité de connaissances technologiques admises dans un projet ;
Une facilité de maintenance ;
Une décentralisation plus aisée du système informatique ;
…

Conclusion :
Au travers de l’étude de cas précèdent, l’on a mis en lumière des défauts de réalisation
du système informatique entrainant des difficultés diverses sur le long terme. Nous pouvons
donc dire que les applications « tout en un tout » dans certaines conditions s’avère être de
mauvaise qualité, inefficace et non efficient. En raison de nouvelles pratiques et technologies
naissantes apportant chacune leurs lots d’innovations et proposant des alternatives pour
solutionner les problèmes existant sur d’autre technologies existantes sur le marché, l’on peut
se demander quels sont les précautions à prendre solutionner les inconvénients rencontrés dans
les applications monolithiques ?

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

4
Gestion
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 CHAPITRE II : REVUE DE LITTERATURE

Introduction :
Afin de présenter l’intérêt d’un travail suivant une démarche scientifique, l’on doit
prendre en compte les travaux précédemment réalisés en lien avec le sujet sur lequel on
travaille. L’objectif de cette démarche consiste à mettre en lumière les innovations apportées
par ces travaux sans pour autant retomber dans les problèmes rencontrés et parfois même résolu
par les travaux précédents avec un gain de temps en acquérant une expertise. Dans cet ordre
d’idée, le présent chapitre traitera sur des technologies de développement et déploiement
d’application informatique au sein des grandes entreprises de la place pour mettre en évidence
des limites relatives à leur approche pour ensuite présenter des ajustements liés à l’adoption des
microservices.

I. Comprendre les microservices :

Selon la figure 1 les applications monolithiques, généralement complexes, traitent d’un
grand nombre de tâches connexes et diverses. Les inconvénients précédemment établis liés à
ce style d’applications ont contribué à l’essor majeur des architectures orientées service (SOA)
permettant plus de souplesse dans la gestion des systèmes d’informations. Toutefois face au
problème d’évolutivité des SOA, les microservices sont apparues, permettant une grande agilité
dans les développements grâce à des principes de conception comme des composants
faiblement couplés et fortement cohésifs avec une responsabilité unique. Cependant, les
microservices ont leurs lots de contraintes

1. Environnement de développement logiciel :

Les microservices étant au cœur de l’actualité technologique, les concepteurs d’API,
Framework et langage de programmation ont possédé à des créations et mises à jour importantes
pour pourvoir adapter leur système à cette nouveauté. Le tableau suivant donne une liste non
exhaustive d’environnement au développement des microservices.

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

5
Gestion
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 Tableau 2.1 : Plateformes et Framework de développement des microservices ((25) page 22)

Framework Description
Spinnaker (Enterprise) Plateforme open source avec divers outils pour la livraison continue.
Netflix OSS (Center) Ensemble des outils open source permettant de construire et de déployer les services.
Spring (VMware) Framework JAVA de développement de microservices.
Dropwizard (Dropwizard) Framework largement utilisé pour développer des microservices en Java
Vertx (Fox) Boîte à outils pour la création des systèmes distribués réactifs sur la machine virtuelle Java.
Lagom (Odersky) Framework open source pour la construction de systèmes de microservices réactifs en Java ou Scala.
OpenFaaS (Ellis) Framework permettant aux développeurs de déployer facilement des fonctions et des microservices événementiels sur Kubernetes.
Azure Functions (Azure) Outils de Microsoft de création d’une architecture de microservices.
Kubeless (Framework) Boîte à outils basée sur les ressources Kubernetes pour fournir une surveillance et un dépannage des services.
Goa (Design) Framework pour la création de microservices et d’API.
Kubernetes (Google) Outils et ressources open source, permettant de gérer des applications conteneurisées sur plusieurs hôtes.
Drone (Drone.io) Système de livraison continue basé sur la technologie des conteneurs.
Fuge (microservice shell) Environnement d’exécution pour les développeurs des microservices.
Seneca (Framework) Boîte à outils pour écrire des microservices et organiser la logique métier d’une application.
Bitbucket (Atlassian) Environnement servant à planifier des projets, collaborer sur du code, le tester et le déployer.
Aws (Amazon) Plateforme de création et de construction des microservices.

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou

de Gestion
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022 7
 2. Microservices versus SOA :
Les microservices et le SOA disposent d’un ensemble de caractéristiques communes bien
qu’ils soient des styles architecturaux différents. Nombreux sont les travaux présentant les
différences et les similitudes entre ces deux architectures. Certains considèrent les
microservices comme une représentation moderne de l’architecture SOA. D’autre à l’exemple
de Martin Fowler estiment les microservices comme un sous ensemble du SOA.

Les fonctions métier sont exposées sous forme de services

indépendants

Avantages La réutilisation des services augmente la qualité des logiciels

La réduction des coûts de développement et de maintenance

logicielle en tant que services

SOA

Les mises à jour ne sont plus faciles à réaliser

La maintenance et le déploiement quotidiens deviennent trop

Inconvénients
risqués

Les composants sont conséquents et complexes

Figure 2.1 : Avantages et inconvénients des SOA ((25) page 24)

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

8
Gestion
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 Tableau 2.2 : Différences entre microservices et SOA ((25) page 25 et 26)

Critères Microservices SOA

Communication Une couche de gestion API pour effectuer des S’appuie sur son middleware ESB
communications simples, pris en charge par les servant pour la communication entre les
microservices composants connectés
Protocole Utilisent des protocoles de messagerie légers tels Utilise plusieurs protocoles de messages
que les protocoles comme HTTP/REST, JSON tels que SOAP, JMS, XML, et HTTP
DevOps Livraison continue et méthodes agiles Livraison continue non prise en compte
de manière naturelle
Taille des services Petits services à granularité fine Des petits services aux gros services
Indépendance Tourne autour d’une fonctionnalité de services Aucune exigence d’indépendance
indépendants
Gestion Gestion décentralisée et indépendante offrant une Gestion centralisée et dépendante des
seule capacité métier, faiblement connectée et autres services
autonome
Déploiement Pas de serveur d’applications dédié, déploiement Utilisation d’une Plateforme commune,
individuel, simple et rapide déploiement monolithique de plusieurs
services
UI Interface pour chaque microservice Une interface unique pour tous les
services
Stockage Bases de données indépendantes Base de données partagée
Infrastructure Petite taille Grande taille
Rôle Fonctionnement indépendant Partage des ressources entre les services
Flexibilité Flexibilité grâce à des développements et Flexibilité par orchestration de services
déploiements rapides et indépendants
Focus Concept de contexte limité Réutilisation des fonctions métiers
Architecture Pour un projet Á l’échelle de plusieurs projets
Conteneurs Utilisation inhérente de conteneurs pour les Utilisation de conteneurs moins
microservices populaire
Méthode Conception dirigée par domaine et pratiques Analyse et conception orientées objet
agiles

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

9
Gestion
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 II. Adopter les microservices :
Migrer de l’architecture existante vers les microservices en entreprises ou encore adopter
les microservices de façon native passent par des techniques diverses s’appuyant sur l’analyse
du code et/ou sur la modélisation des processus métiers. L’intérêt d’une telle décision doit être
motiver par les avantages obtenus via l’utilisation des microservices. Toutefois les démarches
pilotées et stratégique doivent être choisie judicieusement afin d’éviter des problèmes
complexifiant le travail.

1. Environement matériels de deploiement des microservices :

L’un des points forts des microservices est le faite que la consommation des
ressources sur la long terme est économique, rationnalisé et modifiable avec des nouvelles
technologies émergentes. De ce faite l’environnement matériels ou l’on avait déployé
l’application monolithique s’avère être adapté aux microservices remplaçant celui-ci.

2. Environnement logiciel de deploiement des microservices :

Les composants logiciels nécessaires à la mise en œuvre d’un microservice sont très
variés et non contraignante. En effet l’interdépendance recherché à la création des
microservices passent par l’utilisation des protocoles de communication libres, légers,
standardisés, multiplateformes. Rappelons qu’il n’y a pas de besoin de formations de l’équipe
de développeur afin de s’uniformiser sur une technologie précise pour mettre sur pieds ses
microservices. Ici chacun développe dans le langage, le Framework et sur l’IDE qu’il maitrise
le mieux et/ou qu’il trouve adéquat à la tâche qu’il doit réaliser.

1. Environemment réseau des microservices :

Alors qu’au sein des monolithes la latence est applicative, le point difficile dans la
mise en place des microservices se situe au niveau du réseau. De ce fait l’on doit tenir compte
pour ce qui est de la communication des microservices de la sécurité (signature et chiffrement
des données), de la catégorie des protocoles de communication (éviter des protocoles restreint
à une technologie particulière), du mode de communication (synchrone ou asynchrone pour
minimiser l’impact sur les performances) …

III. Synthèse :
Bien que dans la course du développement en application informatique les choix sont
opérés en fonction de plusieurs facteurs pour un meilleur rendement, il n’existe pas de démarche

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

10
Gestion
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 parfaite car chacune d’elle comme les microservices ont leurs lots d’exigences et peuvent
parfois être inadapté à certains contextes. Toutefois les microservices sont très adaptés au
système distribué et permet de mettre à profit la multitude d’acteurs pour l’équipe projet en
apportant une cohésion, une coopération et une diversité des connaissances.

Conclusion :
A la lumière des évolutions technologiques au service du développement d’application
informatique, l’on a établi un besoin de maintenabilité, d’évolutivité, de diversité, de cohésion
donnant ainsi une place importante au microservice. Toutefois en raison des règles
caractéristiques d’un microservice recherché lors de sa mise en place, il convient de se
demander par quels moyens pratiques et démarches adéquats l’on doit y parvenir ?

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

11
Gestion
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 CHAPITRE III : METHODOLOGIE

Introduction :
Bien qu’en apportant une grande flexibilité pour la mise en place d’un système
informatique, les microservices ont aussi leurs lots de bonne pratique afin de ne pas se retrouver
dans des pièges rendant ainsi très complexes le système informatique mise en place. Il convient
donc de comprendre comment partir d’une architecture monolithique à une disposition
microservice, comment les organiser entre eux, comment les faire communiquer … Dans ce
chapitre il sera question de répondre aux précédentes questions afin de tirer profit de toute ses
qualités.

I. Définition et caractéristique d’un microservice :

Les microservices sont une technique de développement logiciel , un style architectural
permettant de structurer une application comme un ensemble de service :

Faiblement couplés ;
Autonome ;
Petit et focalisé sur une et une seule responsabilité ;
Organisé autour des capacités métiers ;
Produit et non plus projet ;
Endpoint évolués et ayant des canaux de communications pauvres ;
Ayant une gouvernance décentralisée ;
Ayant un management de donnée décentralisée (chaque microservice a accès à sa propre
base de données) ;
Ayant une automatisation de l’infrastructure ;
Design for Failure (un microservice qui échoue ne doit pas faire tomber l’ensemble du
système) ;
Remplaçable de manière indépendante ;
Mise à jour de manière indépendante.

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

12
Gestion
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 II. Passage du monolithe au microservices :
Dans la mise en place des applications, un monolithe désigne un programme formé d’un
seul bloc ayant des composants interconnectés et dépendant les uns des autres.

Figure 3.1: exemple d'architecture monolithique

Aux vues des limites précédemment établies, il convient d’opérer une transformation de
cette disposition en microservices. Pour parvenir à cela, l’on doit se focaliser sur trois axes
fondamentaux dans le découpage à savoir :

La simplicité : cette règle stipule que le microservice doit couvrir un ensemble de

fonctionnalité simple et cohérent ;
L’isolation : dans une architecture à base de microservice, une anomalie sur un
microservice ne doit l’affecter que lui et lui seul ;
L’indépendance : le microservice doit posséder tout ce qui est nécessaire à son
fonctionnement.

Deux principales techniques sont proposées afin d’arriver à garantir ces axes.

1. La méthode Domain driven design (DDD :(18)

Le domain driven design fait référence à une conception pilotée par le métier afin
d’arriver à un langage commun compréhensible aussi bien par les experts que par les équipes
d’ingénieurs. Pour parvenir à cette compréhension globale, le DDD se sert de ubiquitous

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

13
Gestion
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 language qui veut que dans le code source, chaque classe, objet, méthode, variable soit nommés
de façon à retranscrire au plus près les réalités métiers. Adopter une approche DDD commence
par :

La Compréhension du métier obtenu via :

▪ L’interview des spécialistes métiers ;
▪ L’extraction de l’information essentielle ;
▪ La mise en place d’une ébauche du métier au travers d’un workflow ;
▪ Communication bilatérale feedback pour affiner le croquis. ;
La modélisation ici on souligne la nécessité d’organiser l’information, de le
systématiser, de l’atomiser (ramener au niveau granulaire), de regrouper cette
granularité en modules logiques, et les traiter un à un.
La communication qui se rapporte à la sensibilisation des parties prenantes.

Les phases de développement d’un projet avec une approche DDD sont :

Modélisation
du métier

Affinage du
modèle métier Conception

& architecture

refactorisation

Test unitaire &

intégration Développement

Figure 3.2 : phases de développement d’un projet avec une approche DDD

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

14
Gestion
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 Ici nous pouvons remarquer la forte compatibilité existante entre une approche agile et
l’approche DDD du point de vue de la livraison des valeurs métiers de manière itérative et
incrémentale.

2. La méthode seams :
La méthode seams est une approche intervenant dans la phase de développement afin
d’identifier dans le code source de l’application des portions isolables sur lequel l’on peut
travailler sans impact sur le reste de la codebase. Les portions précédemment obtenues seront
transformées par la suite en microservice.

III. Communication entre microservices :

Tandis que dans l’architecture monolithique l’on a une latence applicative, les
microservices quant à eux utilisent une communication réseau pour échanger les informations.
La mise en œuvre de la communication entre des microservices est l’aspect primordiale le plus
complexe à réaliser. Il convient donc de voire en détail les moyens de communications mise à
disposition pour trouver un diagramme de déploiement adéquat du système informatique à
évoluer.

1. La communication synchrone :
Dans ce mode d’échange, le microservice A demandant des informations au microservice
B cesse tout autre activité en attendant que le microservice B lui réponde. La mise en œuvre de
ce type de communication entraine donc une dépendance entre microservice car si B est
indisponible, A le devient aussi. En raison du caractère d’isolation recherché lors de la mise sur
pied d’un microservice, ce mode de communication doit être bien réfléchi et correspondre à nos
besoins. Plusieurs mécanismes de communication s’offrent à nous. L’on peut citer :

RPC (protocole réseau permettant de faire des appels de procédures sur un ordinateur
distant à l'aide d'un serveur d’applications) : il s’agit d’un protocole peut recommander
dans le processus de communication des microservices en raison des variations
développées et incompatible entre elle. Son utilisation pourrait nous rendre esclave
d’une technologie comme c’est le cas avec java RMI ;
REST : il s’agit d’un style d’architecture logicielle définissant un ensemble de
contrainte à utiliser pour les services web.
SOAP
CORBA

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

15
Gestion
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 2. La communication asynchrone :
Afin d’échanger les informations avec extérieur tout en effectuant parallèlement d’autre
opération en attendant les résultats, l’on utilise la communication asynchrone. Dans ce mode
de communication, la requête est émise à destination d’un broker qui la rangera dans une file
d’attente. Ce broker joue le rôle d’intermédiaire entre l’expéditeur et le destinataire. C’est lui
qui par la suite contactera le véritable destinataire de la requête. Celui répondra au broker au
moment opportun. Une fois l’information reçu et stockée dans la file d’attente, elle pourra être
consommée par les services qui en auront besoin. Tous les échanges effectués avec le broker
pourront éventuellement engendrer les accusés de réception à destination des services
concernés. Pour réaliser ce type de communication l’on dispose d’un grand nombre de protocole
tel que TCP, AMQP, STOMP, MQTT …

IV. Communication clients - microservices :

1. Le load balancing : (9)
La répartition de charge ou load balancing est une technique utilisée en informatique pour
distribuer le travail entre plusieurs serveurs, processus, ordinateurs, disques, lignes ou autres
ressources. L’utilisation du load balancing possède plusieurs avantages tel que l’amélioration
du temps des services, la possibilité de garder le système ininterrompu pendant les opérations
de maintenance, l’augmentation de la qualité des services... Le load balancing traite des
demandes extérieur de plusieurs clients pour les rédiger vers le microservice concerné donc
l’instance est le mieux approprié. Ce jugement de disponibilité est effectué à l’aide des
algorithmes d’ordonnancement approprié et/ou prédéfini à son lancement. Les procédés
algorithmique standard de mise en place du load balancing sont les suivants :

L’approche par hachage, ici on détermine le serveur à privilégier en fonction des clés
désignées, telles que http ou informations d’adressage IP ;
L’approche basée sur le moins de connexion, dans cette approche le load balancer
repartit les charges en fonction de la quantité de requête traitée par les serveurs de façon
à ce que qu’il n’y ait pas un serveur qui est plus de charge de travail que l’autre.
L’algorithme du temps de réponse le plus court : cette approche utilise des
communications continue entre les serveurs et le load balancer afin de calculer le débit
pour en déduire le serveur le plus apte à traiter la prochaine requête issue d’un client.
Le round robin : cet algorithme transmet les requêtes sur des serveurs cycliquement de
façon séquentielle.

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

16
Gestion
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 V. Deploiement des microservices :
1. Le microservice de configuration :
Lors de la création des microservices, il existe des fichiers permettant de renseigner des
informations essentielles tel que les paramètres liés au SGBD utilisé, le nom de la base de
données, le nom d’utilisateur, le mot de passe … De tels paramètres enregistrés au sein mêmes
du microservice impose un redémarrage de celui-ci s’ils sont appelés à subir des modifications
(configuration à froid). De plus il existe des paramètres qui pourraient être générale à tout les
microservices par conséquent, s’ils doivent subir des modifications dans le cadre ou ils ont été
inscrits dans chaque microservice, il faudra le faire sur l’ensemble de ces microservices.
Puisque le microservice conçu se veut être simple et au vu d’une bonne gestion des accès
concurrents recherchés, l’on se doit de mettre sur pied un microservice centralisant la gestion
des configurations de son pack de microservice et permettant les configurations de chaque
microservice à chaud.

Demande des informations de connexion

Transfert des informations de connexion

Nom :
Adresse ip :

Numéro de port :

Pilote SGBD

Nom d’utilisateur

Mot de passe

Figure 3.3 : fonctionnement du microservice de configuration

2. Le microservice de registre :
Afin de communiquer avec l’extérieur (partie frontend), la Gateway qui est à la fois un
microservice jouant le rôle de proxy et de load balancer a besoin de connaitre les informations
tel que l’adresse ip et le numéro de port à contacter. Pour cette raison, lors de la conception des
microservices l’on recommande la mise sur pied d’un microservice annuaire ayant ces
informations essentielles.

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

17
Gestion
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 Transfert des informations de connexion

Nom :

Adresse ip :

Numéro de port :

Figure 3.4 : fonctionnement du microservice de registre

VI. Modélisation :
Afin de produire un système informatique efficacement, les parties prenantes se doivent
de communiquer par des moyens adéquats dans le but de se comprendre, de collecter et
d’organiser le travail. Dans cette thématique des langages techniques spécialisés dans un
domaine ont été mis sur pied. Ils nous permettent de s’affranchir des littératures encombrantes
tout en étant bien compris par les différentes équipes projets. Dans le cadre du développement
logiciel, on retient Merise qui en plus de fournir un langage est une méthode d’analyse, UML
qui est issue l’unification d’un certain nombre de langage préexistant dans la modélisation
informatique. Toutefois, merise est une méthode en voie de disparition du fait notamment de
son inadaptabilité au paradigme orienté objet et ai peut connue hors de la zone francophone.

1. Présentation du langage UML :

UML est un langage de modélisation standardisé et adopté par OMG destiné à une
visualisation graphique à base des pictogrammes exploités dans le développement logiciel et
les conceptions orientées objet. La version actuelle d’UML 2.5 propose 14 types de diagrammes
scindés en un premier bloc de 7 pour les diagrammes statiques ou structurel, et un second bloc
de 7 pour les diagrammes de comportement.

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

18
Gestion
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 Diagramme

Diagramme structurel Diagramme de comportement

Diagramme Diagramme de Diagramme de Diagramme de Diagramme Diagramme Diagramme

de classe paquetage composant cas d’utilisation d’activité d’interaction d’états transition

Diagramme Diagramme de
d’objet déploiement
Diagramme de Diagramme de Diagramme de Diagramme de vue
communication temps séquence d’ensemble global
Diagramme de Diagramme de interaction
structure composite profils

Figure 3.5 : hiérarchie des diagrammes UML 2.5 (28)

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou

de Gestion
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022 13
 i. Diagramme des cas d’utilisations :
Il permet d’identifier les fonctionnalités fournies par le système (cas d’utilisation), les
utilisateurs qui interagissent avec le système et les interactions entre ces derniers. Les cas
d’utilisations sont souvent exploités dans la phase d’analyse pour définir les besoins de « haut
niveau ». Les objectifs principaux des diagrammes de cas d’utilisations sont :

Fournir une vue de haut niveau de ce que fait le système ;

Identifier les utilisateurs (acteurs) du système ;
Déterminer les secteurs nécessitant les interfaces hommes-machines.

Représentation graphique :

Dans un diagramme de cas d’utilisation on retrouve :

L’acteur : il s’agit d’une représentation de rôle joué sur le système par une entité
extérieure (personne, autre système …) au système. On distingue :
Les acteurs principaux qui sont ceux qui utilisent les fonctionnalités principales
du système ;
Les acteurs secondaires destinés aux tâches administratives ou de maintenance ;
Les matériaux externes ;
Les autres systèmes ;

Actor role Name

Figure 3.6 : formalisme d'un acteur

Le(s) cas d’utilisation(s) : il(s) correspond(ent) à un(des)objectif(s) du système ou à une

représentation d’une fonctionnalité fourni par le système typiquement sous la forme
verbe --objet ;

use case name

Figure 3.7 : formalisme d'un cas d'utilisation

Les relations : elles sont utilisées pour établir un lien entre un acteur et un cas
d’utilisation (associations) ou entre deux cas d’utilisations ou encore entre deux acteurs
(généralisation) ;

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

Gestion 14
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 Figure 3.8 : formalisme d’une relation d'association

La généralisation ou l’héritage est une relation permettant de lier deux acteurs

A et B ou deux cas d’utilisation A et B tel que si A est une généralisation de B
alors B accomplit toutes les fonctionnalités de A ;

Figure 3.9 : formalisme de la généralisation

<Texte par
A B
défaut>

Figure 3.2 : généralisation de A par B

Un cas d’utilisation A est une extension du cas d’utilisation B si l’exécution du

cas d’utilisation A peut déclencher optionnellement l’exécution du cas
d’utilisation B ;
<<extend>>

Figure 3.3 : formalisme d'une relation d'inclusion

<<extend>>
B
A

Figure 3.4 : extension de A par B

Un cas d’utilisation A est une inclusion du cas d’utilisation B si l’exécution du

cas d’utilisation A entraine obligatoirement l’exécution du cas d’utilisation B.

<<include>>

Figure 3.5 : formalisme de la relation d'inclusion

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

Gestion 15
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 ii. Le Diagramme d’activités :
Le diagramme d’activité est un diagramme UML utilisé pour documenter le déroulement
des opérations d’un système de haut en bas.

Composantes :

Dans un diagramme d’activité on trouve :

L’activité : elle marque une action faite par un objet ;

Activite_1

Figure 3.6 : formalisme d'une activité

La transition : elle définit le passage d’une activité à une autre ;

Figure 3.7 : formalisme d'une transition

Le couloir : Dans un diagramme d’activité chaque activité est réalisée par un acteur.
Ainsi on utilise donc les couloirs pour rattacher l’activité à l’acteur qui le réalise ;

couloir

Figure 3.8 : formalisme d'un couloir

Les états : ce sont les points d’entrés et les différents points de sortis du diagramme ;

Figure 3.9 : formalisme du point d'entrée

Figure 3.18 : formalisme de sortie d'une activité

Figure 3.19 : formalisme de sortie d'un flux

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

Gestion 16
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 La barre de synchronisation : elle permet de définir les activités qui peuvent être faite
en parallèle ;

Figure 3.10 : formalisme de la barre de synchronisation

Le losange : il est utilisé pour réaliser des opérations nécessitant des tests sur des
conditions bien précises.

condition

Figure 3.11 : Formalisme du losange

iii. Le Diagramme de vue d’ensemble global d’interaction :

Le diagramme de vue d’ensemble global d’interaction est un diagramme d’activité axé
sur la représentation des fragment tel que:

Des choix de fragment d’interaction ;

Des déroulements parallèles de fragments d’interactions ;
Des boucles de fragments d’interactions.

iv. Le Diagramme de classe :

C’est sans doute le diagramme le plus puissant d’UML. Elle permet de représenter
l’ensemble des informations finalisées qui sont gérées par un domaine.

Composantes :

Dans un diagramme de classe on trouve :

Des classes : Il s’agit d’un type abstrait caractérisé par des propriétés (attributs et
méthodes) communes à un ensemble d’objets ;

Opérateur de Visibilité

Figure 3.12 : Formalisme et composante d'une classe

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

Gestion 17
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 Les relations : Elles sont de plusieurs types dans un diagramme de classe. L’on peut
citer :
L’association : elle représente une relation structurelle entre classes d’objets ;
L’agrégation : c’est une variante de l’association qui est non symétrique dans
laquelle l’une des extrémités joue un rôle prédominant par rapport à l’autre
extrémité ;
La composition : elle est un cas particulier d’agrégation dans laquelle la vie des
composants est liée à celle des agrégats ;
La généralisation : elle met en évidence les caractères communs existant entre
deux classes ;
Les multiplicités : définition du nombre d’instance de l’association pour une instance
de classe.

v. Le Diagramme de paquetage :
Il sert à représenter les dépendances entre paquetages. Un paquetage est le regroupement
des éléments de modélisation aussi appelés membres portant sur un sous ensemble du système.

Composantes :

Dans un diagramme de paquetage on trouve :

Le paquage ;

Package name

Figure 3.13 : formalisme d'un paquet en représentation globale

Les membres : il est représenté par un rectangle ;

Les relations (access, import) son symbole est identique à celle de l’inclusion dans le
diagramme de cas d’utilisation ;

vi. Le Diagramme de déploiement :

Il modélise les composants matériels utilisés pour implémenter un système et
l’association entre ces composants. Ils peuvent être utilisés dans la conception pour documenter
l’architecture physique d’un système.

Composantes :

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

Gestion 18
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 Dans un diagramme de composant on trouve :

Des composants : un composant représente une entité logicielle ou matérielle (Fichier

de code source, programmes, documents, fichiers de ressource) ;

component

Figure 3.14 : représentation UML d'un composant

Des nœuds : un nœud représente un ensemble d’élément matériel du système ;

Noeud

Figure 3.15 : représentation UML d'un nœud

Des associations indiquant une ligne de communication entre les éléments matériels ;

Conclusion :
S’agissant d’aborder les éléments clés relatifs à l’expérimentation axée sur les
microservices, l’on a procédé à un rappel des éléments nécessaires à sa conception couvrant la
modélisation par une bonne compréhension du métier au spécifications matériels et techniques
du système informatique à mettre sur pied, Les contraintes techniques relatives à leur
communication, leur déploiement, et la transformation monolithique.

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

Gestion 19
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 CHAPITRE IV : RESULTAT ET DISCUSSIONS

Introduction :
Afin d’apporter une démonstration des hypothèses scientifiques énoncées, l’on procède à
la phase d’expérimentation afin de prouver la fiabilité de ces hypothèses obtenant ainsi une
meilleure appréciation des résultats obtenus par rapport à ce qui était prévu. Fort des notions
précédemment vues, il est question pour nous dans ce chapitre de mettre en application une
architecture microservice sur un système informatique judicieusement choisie de la conception
au développement dans le but de mieux l’apprécier sur le terrain et d’acquérir les notions
pratiques relatif à l’organisation humaine, logiciel et matériel.

I. Création, paramétrage et lancement des microservices :

A la lumière des éléments abordés dans la méthodologie, pour une séparation appropriée
des taches (processus métiers, configuration liées au microservices, journalisation va un
annuaire), Un système informatique aura un minimum de quatre microservices le premier en
charge de la centralisation de la configuration de chaque microservice (microservice de
configuration) , le deuxième en charge du recensement des données issues des microservices
en fonctionnement (microservice d’annuaire), le troisième étant le microservice automatisant
les processus métiers et le dernier représente le microservice load balancer pour l’aiguillage des
requêtes issues du client et la gestion de certains paramètre de sécurité. Tout ces microservices
précédemment cités doivent être démarrés dans l’ordre dans lesquelles ils ont été énumérés.

Via le langage java et en se servant du framework spring la création des microservices est
facilitée à l’aide du mécanisme d’injection des dépendances. La méthode universelle de création
d’un microservice consiste à :

Se rendre sur le site start.spring.io ;

Remplir le formulaire de gauche correspondant à ses outils de développement donc on
dispose ou qu’on voudrait utiliser ;
Choisir ses dépendances relatives aux fonctionnalités du microservice en cliquant sur le
bouton « Add dependencies ». Une dépendance est un lien référencé dans un fichier
(pom.xml pour un projet spring maven) permettant le téléchargement d’un ensemble de

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

Gestion 20
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 bibliothèques donnant accès à un certain nombre de classe de paquet et d’annotation
lambda développés pour une orientation bien défini ;
Obtenir le projet zippé en cliquant sur le bouton generate ;
Dézipper le projet et l’importer dans un EDI java de son choix ;
Procéder au codage ;

Figure 4.1 : exemple de formulaire pour la création d'un microservice pour la gestion des processus
métiers

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

Gestion 21
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 Figure 4.2 : formulaire de création du microservice de registre

Figure 4.3 : formulaire de création du microservice load balancer

Les présents microservices étant développés en java une fois le jar généré depuis notre
EDI et prêt pour l’environnement de production, on effectue la commande suivante pour le
lancement d’un microservice :

Java -jar nom_du_microservice.jar [--option]

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

Gestion 22
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 1. Création et paramétrage du microservice de configuration :
Pour mettre sur pied le microservice en charge de la configuration, l’on prépare le
répertoire de centralisation des fichiers de configuration liés à chaque microservice. Celui-ci
peut être local ou distant.

Figure 4.4 : commande de création et de paramétrage du répertoire de stockage des fichiers de

configuration du projet

Par la suite avec spring cloud, la création du microservice de configuration peut

s’effectuer de la manière suivante

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

Gestion 23
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 Figure 4.5 : formulaire de création du microservice de configuration

Le projet Zippé obtenu est importé dans un EDI de son choix ou l’on fera le codage
convenable.

II. Application au système informatique de gestion des emplois du temps :

Précédemment il a été établi que la mise en place des microservices acceptait les
technologies diverses. Dans le cadre de ce projet, la phase de développement a été mise en
application avec Java via le Framework spring.

1. Modélisation :
Après la collecte des informations relatifs au divers secteurs (emploi du temps, discipline,
notes, scolarité) concernant un étudiant, L’on a pu établi 7 blocs en ce qui concerne la gestion
des emplois du temps. A l’issue de l’analyse l’on a obtenu :

a) Le système de gestion des comptes utilisateurs :

i. Diagramme de cas d’utilisation :

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

Gestion 24
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 systéme de gestion des comptes

modifier profil

créer un compte

Utilisateur

<<include>>
créer un groupe
d'utilisateur

<<include>>

attribuer un
privilége
<<include>>

associer un <<include>>
utilisateur à un s'authentifier
groupe

<<include>>

Administrateur
modifier une entité <<include>>

<<extend>>
modifier un
compte modifier un
groupe
rechercher une entité

<<extend>>

activer/
desactiver/
une entité

activer/
activer/
desactiver
desactiver un groupe d
un compte 'utilisateur

Figure 4.6 : diagramme de cas d'utilisation du sous-système de gestion des comptes composante du
système GESTIME

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

Gestion 25
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 Description narrative des cas d’utilisations :

Cas d’utilisation « Modifier un profil »

But : permettre à un utilisateur de modifier son profil.

Présupposé : avoir un compte utilisateur.

Pré condition : l’administrateur s’est authentifié.

Déclencheur : clique sur l’option « modifier un profil ».

Dialogue :

Scenario nominal :
1. L’utilisateur choisit l’option « modifier un profil » ;
2. Le système affiche la page de modification de profil ;
3. L’utilisateur remplit les nouvelles informations et valide ;
4. Le système vérifie les informations, enregistre la modification et notifie l’utilisateur.
Scénario alternatif :
1. A l’étape 3 du scénario nominal, L’utilisateur annule l’opération, retour à l’étape 1.
2. A l’étape 4 du scénario nominal, il existe des données manquantes, notification à
l’utilisateur et retour à l’étape 3.
3. Après un certain temps d’inactivité, retour à l’authentification.

Post condition :

Cas du succès

Le profil a été modifié avec succès et le système est retourné sur la page d’exploration.

Cas de l'échec

Les modifications effectuées n’ont pas été prises en compte et le système a retourné un message
d’erreur.

Arrêt :

Les données saisies sont correctes et le système a modifié le profil ou les formulaires
rendus est incomplet voir possède des incohérences et le système a fourni un message d’erreur.

ii. Diagramme d’activité :

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

Gestion 26
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 Activité pour cas d’utilisation « s’authentifier » :

client http systéme (frontend + microservices ) SGBD

transmmettre des données existence du token

<<ok>>

validité du token

<<ok>>

<<! ok>>
<<! ok>>

presentation formulaire de
connexion

remplir le formulaire

recupérer les infos

interroger la base de transmettre les resultats

données

analyser les infos clientes

<<!valide>>
<<valide>>

message d'erreur

fabriquer et envoyer le
token

récuperer et sauvergarder
le token

Figure 4.7 : diagramme d'activité cas d'utilisation "s'authentifier"

iii. Diagramme de classe :

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

Gestion 27
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 1..1 Téléphone
0..*
- numero : int
Personne
- num_cni : String
- photo : String
- nom : String
- prenom : String
- nationalite : String
email
- valeur : String
1..1

1..1 0..*

0..1

Compte groupe
- login : String 0..* - identifiant : int
- password : String 1..* - nom : String

0..*
Droit
- pouvoir : int

0..*

Privilége
- key : int
- nom : String
- num_classe : int

Figure 4.8 : diagramme de classe du sous-système de gestion des profils d'utilisateurs composante du
système GESTIME

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

Gestion 28
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 b) Gestion des infrastructures :

i. Diagramme de cas d’utilisation :

division des infrastructures

reserver un local

client
<<include>>

ajouter un local

<<extend>>

<<extend>>
modifier un local

gérer un local

<<include>> s'authentifier

div inf <<extend>>

consulter un local
supprimer un local

Figure 4.9 : diagramme de cas d'utilisation pour la gestion des infrastructures

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

Gestion 29
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 c) Gestion de l’emploi du temps :

i. Diagramme de cas d’utilisation :

Diagramme de classe

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

Gestion 30
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 Figure 4.10 : usecase diagram pour la gestion des emplois du temps

Description narrative des cas d’utilisations :

a. Editer le cahier de texte

But : permet au système de connaitre l’évolution des cours afin de créer l’emploi du temps de
façon organisé et intelligent.

Présupposé : avoir un compte utilisateur.

Pré condition : s’authentifier.

Déclencheur : cliquer sur « gestion du cahier de texte ».

Dialogue :

Scenario nominal :
1. Le responsable de classe clique sur l’option « gestion du cahier de texte »
2. Le système affiche les différentes UV de la classe que l’internaute dirige
3. Le responsable de classe choisit une UV sur la liste qui lui est présenté
4. Le Système lui présente la liste des différents cahiers de texte et un bouton « + »
pour éventuelle ajout. Il s’agit des cahiers de texte déjà rempli pour éventuelle
modification ou suppression, des cahiers de texte à remplir et semi rempli par le
système.
5. Le responsable de classe clique sur un cahier de texte ou sur le bouton « + » pour un
éventuel ajout.
6. Le système présente le formulaire relatif à sa sélection
7. Le responsable de classe rempli le formulaire ou clique sur la poubelle pour la
suppression
8. Le responsable de classe confirme son travail via le bouton « ok »
Scénario alternatif :
1. A l’étape 7 du scénario nominale, l’utilisateur commet des erreurs sur le formulaire ;
- Le système renvoie un message d’alerte à l’étape 8.
- L’utilisateur clique sur le bouton « ok » du message d’alerte
- L’utilisateur corrige les zones d’erreur et relance l’étape 8 du scénario nominal.

Post condition :

Cas du succès

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

Gestion 31
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 Le responsable de classe a consulté et édité à bien le cahier de texte
Cas de l'échec

Le responsable de classe a consulté le cahier de texte mais n’a pu transmettre les

nouvelles notifications : le système a retourné un message d’erreur

Arrêt :

Le système a retourné la liste du cahier de texte ou le message d’erreur.

ii. Diagramme de séquence pour l’édition des dépendances : scénario nominale pour
l’ajout
DiagrammeSequence_1

Systéme SGBD

Enseignant

ref
<<ref s'authentifier>>
s'identifier()

choisir gestion des dépendances

présentation du menu déroulant

choisir l'option ajouter

demande d'information

envoie des résultats

présentation du formulaire

remplir le formulaire
sauvergarde des données

envoie du rapport d'état

transmission de l'AR

Figure 4.11 : diagramme de séquence l'ajout de dépendance

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

Gestion 32
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
Gestion
iii.

Salle_de_cour Dat
- numero : char - valeur : Date
- capacité : int - ouvrabilté : boolean

Etudiant en 5iéme année option GSI.

1..1
1..1

KAMDEM KAMGAING DONALD KEVIN

Ens
Diagramme de classe :

1..* 0..*
Personne - matricule : String Cahier de texte
- spécialité : String 1..1 Gestime
- Login : String - munber : int
- num_cni : String - identifiant : int - horaire : Dat
1..* 0..1
- password : String - durée : int - chapitre : String
1..1 - valide : byte 1..1
- telephone : int 1..* - detail : String
1..*
- nom : String Etudiant - durée : int
1..*
- prenom : String - matricule : String 1..*
- email : String
- nationalite : String
0..*

1..* 1..1 0..* Dependance

Uv - atteint : boolean
Administrateur Classe
Chef_etab
- filiére : String 1..* 1..* - code : int
- codepin : int - spécialité : String 0..*
- niveaux : byte - nom : String
Cuve - numero : char
- statut : boolean

1..*
Cuv
- credit : int
1..* - heure_de_cours : int

Figure 4.12 : diagramme de classe du noyau centrale du système GESTIME

Année Académique 2021 – 2022

Institut universitaire siantou de

33
 d) Gestion du calendrier académique :

i. Diagramme de cas d’utilisation :

Figure 4.13 : diagramme de cas d'utilisation pour la gestion du calendrier académique

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

Gestion 34
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 ii. Diagramme de séquence pour la gestion des ouvrables scénario nominale :

DiagrammeSequence_1

Systéme SGBD

Chef d'établissement

ref
<<ref s'authentifier>>
scénario nominale()

choisir calendrier académique

présentation du menu déroulant

choisir l'option personaliser

demande d'information

envoie des résultats

présentation du calendrier

loop selection des jours ouvrables

cliquer sur le bouton ok sauvergarde des données

envoie du rapport d'état

transmission de l'AR

Figure 4.14 : diagramme de séquence du scenario nominale pour la gestion des jours ouvrables

iii. Diagramme de classe :

Personne
- Login : String
- num_cni : String
- password : String
- telephone : int Dat
Ens
- nom : String - valeur : Date
- prenom : String - matricule : String 1..*
- ouvrable : boolean
- email : String - spécialité : String 1..*
- nationalite : String

Time
Decision
0..* - heure : byte
- choix : boolean - minute : byte
1..*
- seconde : byte
- valide : boolean

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

Gestion 35
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 Figure 4.15 : diagramme de classe pour la gestion du calendrier académique

e) Diagramme de déploiement :

serveur d'application

PC

fichier .scss
Navigateur

fichier .exe fichier .jar fichier .ts serveur nodejs fichier d'images

fichier .html

serveur de microservices
serveur de base de données

fichiers . jar fichiers . class

BD MYSQl

pom.xml fichiers.properties
fichier .mdb fichier .config

smartphone

interface GSM

APK

Base de données local

fichiers

navigateur

Figure 4.16: diagramme de déploiement globale du système

2. Résultat des tests :

Comme le montre le diagramme de déploiement précédent les microservices produits sont
application ne disposant pas d’interface graphique toutefois ils communiquent aux autres
composantes par le canal des méthodes du protocole http et reçoivent le corps des requêtes au
format JSON. A l’aide d’un client web te que postman. On obtient c’est résultat :

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

Gestion 36
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 Adresse du serveur
Corps de la requête
Méthode http d’envoi

Réponse du serveur

Figure 4.17 : exemple de requête JSON adressé au microservices des utilisateurs

Conclusion :
Dans l’optique d’apporter une démonstration visant à acquérir quelques pratiques
techniques de mise en œuvre des microservices tout en appréciant les performances et la
flexibilité obtenues en comparaison du monolithique, l’on a en servant du Framework spring
obtenue un développement rapide des microservices opérant dans le système de gestion des
emplois du temps. Il convient de noter qu’une étude métier ayant permis la compréhension du
système d’information a été réalisé en amont et qu’il s’en suivi une traduction technique des
éléments obtenus via le langage UML. Rappelons toutefois qu’en raison d’une charge réseau
importante, il serait judicieux de réaliser une étude comparative des performances en rapport à
l’encodage des données et une étude des vulnérabilités de cette architecture sur la sécurité des
informations.

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

Gestion 37
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 CONCLUSION GENERALE ET PERPECTIVES :

I. CONCLUSION :
S’étant orienté vers la problématique relative à l’évolution des systèmes informatiques à
un cout réduit dans des délais de plus en plus cours tout en veillant à la sécurité des informations
et du matériel, le présent document a présenté les microservices comme étant une solution de
développement logiciel efficace et économique. Toutefois il faut noter que des bonnes pratiques
et démarches s’imposent raison pour laquelle dans la partie méthodologie des connaissances
relatives à la modélisation, au mode et protocole de communication, au domain drivin design
pour une transformation architecturale ont été abordées. A la lumière des résultats obtenues au
chapitre quatre l’on peut bien qu’attestant le rendement dans la production d’application
soulevé des questions concernant la confidentialité et l’intégrité des données.

II. PERSPECTIVES :
Les résultats obtenus montrent que les microservices constituent un excellent moyen pour
faire croitre le niveau d’automatisme des systèmes d’informations en société et pour optimiser
le temps de réponse et de traitement de certains algorithmes usuels dans la mesure où celui-ci
est au cœur des systèmes distribués. L’application de la démarche microservice pour la mise en
place des opérations courantes (système informatique pour les élections diverses, système de
gestion des notes , discipline , identifications et recensement des personnes, authentifications
des pièces citoyennes … ) permettrait un gain de productivité dans les délais de réalisation , de
rendement dans les temps de réponse des systèmes informatiques ainsi qu’une connaissance
spécialisée dans les domaines de l’informatique (celui qui veut se spécialiser en backend n’aura
plus besoin de connaissance de certains élément du frontend en d’autre terme les microservices
permettent un niveau d’abstraction des composants et de l’équipe technique avancé tout en
gardant une réelle communication).

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

Gestion 38
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 BIBLIOGRAPHIE :

Ahmadvand, M. and Ibrahim, A. (2016). Requirements reconciliation for scalable and secure
microservice (de)composition. In IEEE International Requirements Engineering conference
(RE), pages 68–73. IEEE Computer Society.

[Amazon] Amazon, I. Services et produits de cloud amazon | AWS.

https://aws.amazon.com/fr/.

[Atlassian] Atlassian. Bitbucket | the git solution for professional teams.

https://bitbucket.org/product.

[Azure] Azure, M. Services de cloud computing | microsoft azure.

https://azure.microsoft.com/fr-fr/.

[Center] Center, S. Netflix open source software center. https://netflix.github.io/.

Chris, R. (2018). Pattern : Microservice architecture. Internet].[Citerad 7 febr., 2018].

Tillgänglig från : http ://microservices. io/patterns/microservices. html.

[Design] Design, G. . https://github.com/goadesign/goa/.

Djogic, E., Ribic, S., and Donko, D. (2018a). Monolithic to microservices redesign of event
driven integration platform. In 2018 41st International Convention on Information and
communication Technology, Electronics and Microelectronics (MIPRO), pages 1411– 1414.
IEEE

[9] dnsstuff, introduction sur le load balancing https://www.dnsstuff.com/what-is-server-load-

balancing

[Drone.io] Drone.io. Automate software testing and delivery. https://www.drone.io/.

[Dropwizard] Dropwizard. Java framework. https://www.dropwizard.io/en/latest/.

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

Gestion X
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 [Ellis] Ellis, A. Serverless functions made simple with kubernetess.
https://www.openfaas.com/.

[Enterprise] Enterprise, A. Spinnaker. https://spinnaker.io/.

[Fox] Fox, T. Jvm framework. https://vertx.io/.

[Framework] Framework, S.Seneca, a microservices toolkit for node.js. https://senecajs.org/.

Fowler, M. (2015b). Microservice trade-offs. Dosegljivo: https ://martinfowler.

com/articles/microservice-trade-offs. html.

[Google] Google. Production-grade container orchestration. https://kubernetes.io/.

[18] les dieux du code , https://lesdieuxducode.com/blog/2019/7/introduction-au-domain-

driven-design

[microservice shell] microservice shell, T. Fuge, an execution environment for micro service
development with node.js. https://fuge.io/.

[Odersky] Odersky, M. Lagom - microservices framework.

https://www.lagomframework.com/.

OpenClassrooms, Construction des microservices via java avec le Framework spring,

https://openclassrooms.com/fr/courses/4668056-construisez-des-microservices

OpenClassrooms, mise en œuvre de la communication synchrone via l’API

REST,https://openclassrooms.com/fr/courses/6573181-adoptez-les-api-rest-pour-vos-projets-
web

Openclassrooms, optimisation et déploiement des

microservices,https://openclassrooms.com/fr/courses/4668216-optimisez-votre-architecture-
microservices

Spring, découverte de spring, https://spring.io/quickstart

[25] Mohamed Taoufik DAOUD, (2021). Vers une approche d’identification automatique de
microservices pour les besoins de migration de systèmes d’information. Thèse de doctorat,
Université Claude Bernard Lyon 1, France, 127 p.

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

Gestion XI
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 Video2Brain, Formation pratique d’UML 2.5,
http://fichiers.telechargercomplet.fr/2018/02/telechargement-video2brain-decouvrir-la-
modelisation-uml-23/

[VMware] VMware, I. Spring | microservices. https://spring.io/microservices.

[28]Wikipedia,https://fr.wikipedia.org/wiki/UML_(informatique)#/media/Fichier:Uml_diagra
m-fr.png

Net Microservices : Architecture for Containerized .Net Applications

• Auteur(s) : Cesar de la Torre, Bill Wagner, Mike Rousos

• PUBLISHED BY Microsoft Developer Division, .NET and Visual Studio product teams
• Copyright © 2020 by Microsoft Corporation

Programmer en Java

• Auteur(s) : Claude Delannoy

• Edition : Eyrolles
• Date de parution : 23/11/2017

UML 2.5

Initiation, exemples et exercices corrigés 5ème édition

• Auteur(s) : Laurent Debrauwer

• Edition : ENI
• Date de parution : 11/03/2020

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

Gestion XII
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 TABLE DE MATIERE

Table des matières

.................................................................................................................................................... 1

DÉDICACE : ........................................................................................................................... II

REMERCIEMENTS : .......................................................................................................... III

GLOSSAIRE : ........................................................................................................................ IV

RÉSUMÉ : ............................................................................................................................... V

ABSTRACT : .......................................................................................................................... VI

LISTE DES FIGURES : ...................................................................................................... VII

LISTE DES TABLEAUX : .................................................................................................... IX

SOMMAIRE : .......................................................................................................................... X

INTRODUCTION GÉNÉRALE : .......................................................................................... 1

CHAPITRE I : CONTEXTE ET PROBLEMATIQUE ....................................................... 2

Introduction : .......................................................................................................................... 2

I – Analyse du fonctionnement d’une application de gestion des services d’un réseau de

communication : ..................................................................................................................... 2

II. Alternatives technologiques : ......................................................................................... 4

Conclusion :............................................................................................................................ 4

CHAPITRE II : REVUE DE LITTERATURE ..................................................................... 5

Introduction : .......................................................................................................................... 5

I. Comprendre les microservices : ..................................................................................... 5

1. Environnement de développement logiciel : .......................................................................... 5

2. Microservices versus SOA :................................................................................................... 8

II. Adopter les microservices : .......................................................................................... 10

1. Environement matériels de deploiement des microservices : .............................................. 10

2. Environnement logiciel de deploiement des microservices : ............................................... 10

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

Gestion XIII
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022
 1. Environemment réseau des microservices : ......................................................................... 10

III. Synthèse : ................................................................................................................. 10

Conclusion :.......................................................................................................................... 11

CHAPITRE III : METHODOLOGIE ................................................................................. 12

Introduction : ........................................................................................................................ 12

I. Définition et caractéristique d’un microservice : ................................................................. 12

II. Passage du monolithe au microservices : ............................................................................. 13

III. Communication entre microservices :.................................................................................. 15

IV. Communication clients - microservices : ............................................................................. 16

V. Deploiement des microservices : ......................................................................................... 17

VI. Modélisation : ...................................................................................................................... 18

Conclusion :.......................................................................................................................... 19

CHAPITRE IV : RESULTAT ET DISCUSSIONS ............................................................ 20

Introduction : ........................................................................................................................ 20

I. Création, paramétrage et lancement des microservices : ............................................. 20

1. Création et paramétrage du microservice de configuration : ............................................... 23

II. Application au système informatique de gestion des emplois du temps : .................... 24

1. Modélisation : ...................................................................................................................... 24

2. Résultat des tests : ................................................................................................................ 36

Conclusion :.......................................................................................................................... 37

CONCLUSION GENERALE ET PERPECTIVES : .......................................................... 38

I. CONCLUSION : .......................................................................................................... 38

II. PERSPECTIVES :........................................................................................................ 38

BIBLIOGRAPHIE : ................................................................................................................ X

TABLE DE MATIERE .......................................................................................................XIII

KAMDEM KAMGAING DONALD KEVIN Institut universitaire siantou de

Gestion XIV
Etudiant en 5iéme année option GSI. Année Académique 2021 – 2022