RAPPORT DE STAGE DE PROJET DE FIN D’ETUDES

INGENIEURS EN INFORMATIQUE

Intitulé du stage
Conception et mise en place d'un système d'authentification sécurisé pour
ADDIXO Smart Factory

Réalisé par
Nesrine OBEY

Entreprise d’accueil

Encadrant Entreprise
Mme Ferjania Ben Aissa

Encadrant SESAME
Mme Hajer Amdouni
Année Universitaire
2022-2023
Dédicace

“
”
- Nesrine

I
Remerciements

II
Résumé

Mots clés :

III
Abstract

Keywords :

IV
Table des matières

Dédicace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I

Remerciements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II

Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . III

Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IV

Introduction générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1 Initialisation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Secteurs d’activités . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.2 Organigramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1 Addixo Smart Factory . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.3 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.4 Concept de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Choix méthodologique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4.1 Les méthodes agiles . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4.2 Le Framework Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Analyse et planification du projet . . . . . . . . . . . . . . . . . . . . . . . 10

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.2 Identification des besoins . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.3 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . 12
2.3 Pilotage du projet avec Scrum . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.1 Equipe du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.2 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.3 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.1 Environnement technique . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.2 Outils de Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . 15

V
Table des matières

2.4.3 Technologies et langages utilisés . . . . . . . . . . . . . . . . . . . . 15

2.5 Architecture de la Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5.1 Architecture physique . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5.2 Architecture logicielle . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Mise en œuvre de : Release 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 Sprint1 : Configuration de keycloak . . . . . . . . . . . . . . . . . . . . . . 21
3.2.1 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Conclusion et perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Annexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

VI
Table des figures

1.1 Organigramme de l’entreprise ADDIXO . . . . . . . . . . . . . . . . . . . 4

1.2 MES, un intermédiaire entre l’ERP et l’atelier. . . . . . . . . . . . . . . . . 5
1.3 La page d’acceuil « d’ADDIXO Smart Factory » . . . . . . . . . . . . . . . 6
1.4 Le cadre de travail « Scrum ». . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1 Diagramme de cas d’utilisation global. . . . . . . . . . . . . . . . . . . . . 12

2.2 Planification prévisionnelle des sprints . . . . . . . . . . . . . . . . . . . . . 14
2.3 Keycloak dans une Architecture Micorservice. . . . . . . . . . . . . . . . . 18
2.4 Diagramme de déploiement de la solution « ADDIXO Smart Factory » . . 19
2.5 Architecture Spring Boot et intégration de keycloak . . . . . . . . . . . . 19

VII
Liste des tableaux

2.1 Équipe et rôles Scrum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Description de la machine de développement . . . . . . . . . . . . . . . . . 15
2.4 Description de la machine de développement . . . . . . . . . . . . . . . . . 15

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

VIII
Liste des algorithmes

IX
Liste des sigles et acronymes

API Application Programming Interface

HTTP Hypertext Transfer Protocol

JSON JavaScript Object Notation

REST Representational State Transfer

X
Introduction générale

Depuis son apparition au XVIIIe siècle, le domaine de l’industrie a eu plusieurs révolu-

tions de modernisation et a traversé plusieurs stades d’évolution. Une dernière révolution
en 2011, pas seulement industrielle mais aussi technologique et numérique, a permis le
monde entier de connaître l’émergence d’une toute nouvelle forme d’industrie, l’industrie
4.0.

L’industrie 4.0 a permis une connectivité aisée entre les machines de production et les
systèmes d’information ainsi, un contrôle permanent. Dans cette perspective, beaucoup
des concepts ont vu la lumière du jour, et le « Smart Factory » est bien un exemple.
« Smart Factory » signifie une usine de fabrication digitalisée à l’aide des machines de
fabrication connectées entre eux et qui sont en contrôle continu grâce à des logiciels. Dans
ce sens, le groupe « ADDIXO » qui est spécialisé dans l’industrie 4.0 veut mettre à jour son
logiciel « ADDIXO Smart Factory » avec un nouveau module pour une authentification
plus sécurisé et une gestion des roles et des permissions centralisées en externe . C’est
dans ce contexte que la société « ADDIXO » nous a confié les tâches de conception et
l’implémentation d’une solution qui donne une sécurité solide . Cette solution vise alors
à aider l’utilisateur à centraliser la gestion des roles et des permissions . Afin d’atteindre
ce but, plusieurs étapes ont été effectuées et présentées dans ce rapport.

Le présent rapport se subdivise en quatre chapitres présentant les différentes étapes de

la réalisation des tâches demandées. Le premier chapitre sert à fournir un aperçu global
sur le projet. Nous présenterons donc l’organisme d’accueil ainsi, nous discuterons la
problématique, la solution envisagée et la méthodologie adoptée pour la gestion de notre
projet. Ainsi, nous introduirons les concepts qui sous-tendent notre travail. Dans le second
chapitre, nous dévoilerons les différentes exigences de notre système et nous mettrons le
backlog de notre produit. Nous intéresserons également dans le deuxième chapitre à la
présentation de l’environnement de travail, ainsi que l’architecture de notre projet et
c’est à ce niveau aussi que nous exposerons les choix techniques pour le développement
de notre application. Le chapitre trois montrera la release initiale, qui marque le premier
stade de l’implémentation de notre système. Après, un chapitre quatre qui sera réservé à la
réalisation de la deuxième release qui regroupe les fonctionnalités permettant l’évaluation
et l’estimation des risques.

Enfin, une dernière partie du rapport sera consacrée exclusivement à la conclusion

générale qui résume les grands traits de ce travail et qui présente les perspectives futures
de perfectionnement de la solution élaborée.

1
Chapitre 1

Initialisation du projet

2
Chapitre 1. Initialisation du projet

1.1 Introduction
Dans ce chapitre, nous exposons le cadre général de notre projet. Premièrement, nous
décrirons l’organisme d’accueil et nous présentons ses secteurs d’activité, et puis, nous
dégageons les imperfections et limites du système actuel. Pour le but de montrer la solution
proposée. En guise de clôture, nous exposons la méthodologie adoptée pour la gestion de
notre projet.

1.2 Organisme d’accueil

ADDIXO [1], est un groupe français fondé en 2017 qui a une expertise dans l’ingé-
nierie multidisciplinaire pour l’industrie 4.0. Spécialisé dans l’intégration des solutions
multitechniques, ADDIXO focalise profondément sur l’industrie 4.0 tout en accablant des
divers domaines, l’ingénierie industrielle, l’ingénierie automatique et l’ingénierie informa-
tique. ADDIXO est implanté en trois sites .
— le siège social en France à Montigny-le-Bretonneux ;
— la filiale Tunisienne au parc technologique de Manouba ;
— la filiale Marocaine à Tanger.

La mission globale d’ADDIXO consiste principalement à ”[proposer aux] clients une

gamme de solutions innovantes permettant à l’usine de fonctionner de manière intégrée”
[2]

1.2.1 Secteurs d’activités

Les différents services et produits offerts par ADDIXO touchent multiples secteurs
d’activité, en trouve :
— Ingénierie de développement logiciels ;
— Ingénierie mécanique ;
— Ingénierie industrielle ;
— Ingénierie automatique ;
— Ingénierie des systèmes embarqués ;
— Le « Consulting ».

1.2.2 Organigramme
La figure 1.1 présente l’organigramme de l’entreprise ADDIXO :

3
Chapitre 1. Initialisation du projet

Fig. 1.1 : Organigramme de l’entreprise ADDIXO

— département de la gestion des Ressources humaines : le département RH est celui

qui gère les ressources humaines de l’entreprise. En fait, c’est un département qui est
toujours en relation avec toutes les autres branches et services ;
— service de ventes et marketing : le service de ventes et marketing est un département
responsable principalement de l’élargissement du champs clientèle ;
— recherche et développement : RD est un département dont sa mission principale est la
contribution à l’innovation et à la transformation digitale ;
— Digital Manufacturing : le département de « Digital Manufacturing » est responsable
au développement et à la production des solutions qui aide à la digitalisation des différents
processus de production dans les usines ;
— Smart Equipement : la réalisation des matériels intelligents qui permet de garantir
la stabilisation et l’efficacité des processus de production est faite dans le département
« Smart Equipement ».

Pour la réalisation de notre projet de fin d’études, nous avons intégré l’équipe « Smart
Factory » qui fait partie du département « Digital Manufacturing ». « Smart Factory » est
une équipe responsable du développement des solutions logicielles primordiales pour la
numérisation des usines. Ce sont des solutions qui traitent les processus de production par
la collecte des données de fabrication des usines en temps réel. Ces données sont utilisées,
par la suite, pour des divers buts, tels que : le contrôle et le suivi de l’état et de qualité
de production, et la gestion de maintenance et de traçabilité.
« Smart Factory » travaille actuellement sur le développement et l’amélioration d’un
logiciel appelé « ADDIXO Smart Factory », une ”technologie conçue nativement pour la
digitalisation des processus de production dans l’usine” [3].

1.3 Présentation du projet

Dans cette section, nous discutons le contexte général de notre projet. Nous présen-
tons donc la solution technologique « ADDIXO Smart Factory », et puis nous révélons la
problématique afin de présenter notre solution décisive.

1.3.1 Addixo Smart Factory

« ADDIXO Smart Factory » est une solution logiciel de type MES conçu pour l’in-
dustrie 4.0. Un outil MES est une solution technologique qui permet le pilotage de la

4
Chapitre 1. Initialisation du projet

production.

1.3.1.1 Industrie 4.0

L’industrie 4.0 symbolise la dernière révolution industrielle. En fait, Une révolution

industrielle est définie comme les changements majeurs et les transitions dans les fa-
brications et les processus industriels avec des nouveaux techniques innovantes. Jusqu’à
aujourd’hui, nous distinguons quatre révolutions industrielles :
— révolution industrielle 1.0 (1784) : les machines fonctionnent avec de l’eau et de la
vapeur ;
— révolution industrielle 2.0 (1870) : l’introduction des machines à l’électricité ;
— révolution industrielle 3.0 (1969) : l’introduction de l’automatisation et des ordina-
teurs ;
— révolution industrielle 4.0 (2011 - Aujourd’hui) : l’introduction des systèmes Cyber-
physiques dans laquelle des dispositifs sont contrôlés par des systèmes informatiques ;
L’industrie 4.0 a rendu possible la communication entre les machines et les systèmes à
l’intérieur des usines, ce qui relie le monde physique au monde numérique.

1.3.1.2 Manufacturing Execution System

MES est un système apparu avec le surgissement de l’industrie 4.0, qui permet le suivit
et la gestion des productions dans les usines. Celui-ci a un but principal : la supervision
des machines de fabrication en fournissant une traçabilité parfaite sur les informations de
production [4]. En fait, il y avait continuellement des difficultés de gérer des données qui
interviennent à partir des ateliers de production et qui doit interagir avec un ERP, d’où
la complexité de maintenir ”la continuité entre les données de l’ERP et les opérations en
atelier” [4]. De ce fait, un logiciel MES agit à la fois, comme étant un médiateur entre
l’ERP et l’atelier mais aussi comme un chef d’orchestre, puisqu’il faut y avoir un suivi
permanent ”de la chaîne numérique depuis la création de l’ordre de fabrication (OF)
jusqu’à l’obtention du produit final” [4]. La figure 1.2 [5] illustre le rôle du logiciel MES :

Fig. 1.2 : MES, un intermédiaire entre l’ERP et l’atelier.

« ADDIXO Smart Factory » est donc une solution MES pour la numérisation des pro-

5
Chapitre 1. Initialisation du projet

cédures de production. Ce logiciel ”agit comme un broker des informations provenant

des données et événements de l’usine, peu importent leurs sources” [3]. « Smart Factory »
est un concept utilisé pour décrire l’application de différentes combinaisons de techno-
logies modernes pour créer une capacité de fabrication hyperflexible et auto-adaptative.
« ADDIXO Smart Factory » intègre tous les mécanismes de production nécessaire, en liant
tous les parties prenantes d’un SI à savoir les acteurs, les dispositifs et les composants.
Il propose à travers un tableau de bord, une vue en temps réel sur la progression de la
production, de la qualité et de l’usage des différentes ressources. La solution « Smart Fac-
tory » d’ADDIXO a plusieurs modules, de ceux-ci nous citons :
— module « Qualité » ;
— module « Maintenance » ;
— module « Production » ;
— module « Énergie » ;
— module « Configuration » ;
— module « Vue 360° » ;
— module « Instructions de travail » ;
— module « Intégrations SI » ;
— un tableau de bord global.

La figure suivante, présente l’IHM de la page d’accueil du logiciel « ADDIXO Smart

Factory » qui englobe tous les modules et les fonctionnalités offerts par ce dernier.

Fig. 1.3 : La page d’acceuil « d’ADDIXO Smart Factory »

1.3.2 Problématique
Dans le monde de l’informatique moderne, la sécurisation des applications est devenue
un enjeu majeur. « ADDIXO Smart Factory » agit comme étant une solution moderne

6
Chapitre 1. Initialisation du projet

pour l’industrie 4.0, nous remarquons l’absence des fonctionnalités qui peuvent assurer la
sécurité des systèmes d’authentification et de gestion des accès qui jouent un rôle crucial
dans la protection des données sensibles et la prévention des attaques malveillantes. Dans
ce contexte, l’utilisation de solutions d’authentification centralisée est de plus en plus
répandue.

1.3.3 Solution proposée

Pour une application dédiée pour l’industrie la sécurité totale est exigé . De ce fait, la
solution est d’implémentation d’un nouveau serveur d’autorisation externe comme ”Key-
cloak” qui permet la centralisation des politiques d’accès. Il s’agit donc, d’élaborer un
outil qui permet de : — Offrir une API REST pour la partie administration ; — Propose
une console d’administration pour la gestion centralisée des utilisateurs ;

1.3.4 Concept de base

Dans cette section, nous définissons les concepts fondamentaux liés l’analyse de sécurité
ainsi, nous exposons des notions liées à Keycloak. Nous parlons également du but et de
l’utilité de notre serveur de sécurité dans le cadre de notre projet.

1.3.4.1 Keycloak

Keycloak est une solution open source de gestion des identités et des accès (IAM) qui
offre des fonctionnalités de Single Sign-On (SSO) pour les applications web et mobiles. Il
permet de centraliser la gestion des identités de vos utilisateurs et de contrôler l’accès à vos
applications et services en ligne. L’application agit comme un serveur d’identité central
et gère les authentifications en utilisant des protocoles tels que OAuth2, OpenID Connect
et SAML. La solution offre une grande flexibilité dans la gestion des utilisateurs et des
rôles, ainsi que pour la configuration des stratégies d’authentification et d’autorisation
pour chaque application.

1.3.4.2 Protocole OAuth 2.0

Le protocole OAuth 2.0 (Open Authorization 2.0) est un protocole d’authentification

et d’autorisation largement utilisé pour sécuriser l’accès aux ressources d’une application
ou d’un service par des tiers. Il est couramment utilisé dans le domaine de l’authentifica-
tion et de l’autorisation dans les applications web, mobiles et les services en ligne.
L’objectif principal d’OAuth 2.0 est de permettre à un utilisateur de donner des autori-
sations à une application tierce pour accéder à ses données sans partager ses identifiants
(nom d’utilisateur et mot de passe) avec cette application tierce.
OAuth 2.0 comprend des mécanismes de sécurité pour protéger les échanges d’informa-
tions sensibles. Cela inclut l’utilisation de HTTPS, la protection contre les attaques CSRF
(Cross-Site Request Forgery) et la gestion sécurisée des tokens.

7
Chapitre 1. Initialisation du projet

1.3.4.3 OpenID

OpenID est un protocole d’authentification en ligne qui permet aux utilisateurs de

s’authentifier sur différents sites web et applications à l’aide d’un seul ensemble d’identi-
fiants, sans avoir à créer des comptes distincts pour chaque service. Il s’agit d’un protocole
d’authentification décentralisé et ouvert qui vise à simplifier le processus d’authentifica-
tion sur Internet et à améliorer la sécurité des connexions en ligne

1.4 Choix méthodologique

Pour un projet informatique, le choix d’une méthodologie est une étape indispensable
qui dépend de plusieurs contraintes. Le choix d’une méthode convenable permet de main-
tenir un bon déroulement du projet, dès le début jusqu’a la fin. Dans ce sens, nous avons
adopté une méthode Agile.

1.4.1 Les méthodes agiles

Les méthodes Agiles sont des méthodologies dédiées à la gestion de projets. En fait,
elles sont menées dans un esprit collaboratif, qui ”caractérisent un mode de gestion des
projets informatiques privilégiant le dialogue entre toutes les parties prenantes, clients,
utilisateurs, développeurs et autres professionnels du projet”[10]
Les raisons pour lesquelles nous avons choisi les méthodes Agiles pour la gestion de
notre projet sont les suivantes : — nous avons besoin d’une approche itérative et incré-
mentale, puisque le processus de la réalsation de notre projet est imprévisible ;
— les méthodes Agiles nous fournissent un cycle de développement adaptatif en fonction
des besoins évolutifs du client ;
— ces méthodologies impliquent l’ensemble des collaborateurs , ce que nous permet de
bien comprendre les besoins et les exigences du projet ;
— la nécessité d’adopter une méthode empirique. En nous basant sur les faits précédents,
nous avons choisi le cadre de travail « Scrum », qui fait partie du groupe des méthodologies
Agiles.

1.4.2 Le Framework Scrum

Scrum est un « Framework » Agile ”[orienté] projet informatique dont les ressources
sont régulièrement actualisées” [11], il permet de gérer des projets avec des problèmes
complexes et adopte une approche dite empirique (un Framework qui se base sur l’expé-
rience). Ce cadre de travail vise à livrer de la durée la plus courte possible des produits
de grande valeur. Scrum se repose principalement sur les notions suivantes :

— Sprint : c’est une période de 2 à 4 semaines dont un incrément du produit doit

être prêt et potentiellement livrable ;
— Release : une « Release » est constituée par ensemble de sprints, c’est une version

8
Chapitre 1. Initialisation du projet

opérationnelle du produit ;
— Backlog du produit : il s’agit d’une liste des exigences et des fonctionnalités, fourni
par le « Product owner » ;
— User stories : les « user stories » sont un ensemble des exigences à développer écrit
au langage de l’utilisateur ;
— planification du Sprint : avant chaque sprint, une réunion de planification est
organisée pour mettre dans le « Backlog du produit » la liste des fonctionnalités et des
exigences en ordre de priorité ;
— revue du Sprint (Sprint Review) : le « Product Owner » présente l’incrément
terminé (potentiellement livrable) au client ;
— rétrospective du Sprint (Sprint Retrospective) : l’équipe de sprint inspecte en
collaboration le sprint et cherche des moyens pour s’améliorer ;
— mêlée quotidienne : Scrum exige la notion de mêlée quotidienne (Daily meeting),
c’est une réunion quotidienne, dure de 5 à 15 minutes, entre l’équipe de développement, le
« Scrum master » et le « Product owner » qui vise principalement à évaluer l’avancement
du travail ;

La figure 1.7 [12] présente une vue globale du cycle de vie du cadre de travail « Scrum ».

Fig. 1.4 : Le cadre de travail « Scrum ».

1.5 Conclusion

Après avoir présenté l’organisme d’accueil, la solution proposée, et justifier notre choix
méthodologique pour la gestion du projet, nous allons analyser dans le chapitre suivant,
notre solution de sécurité.

9
Chapitre 2

Analyse et planification du projet

10
Chapitre 2. Analyse et planification du projet

2.1 Introduction
Au niveau de ce chapitre, nous abordons la partie de la capture des besoins. Nous
pilotons ensuite notre projet avec le cadre de travail Scrum. Ainsi, nous présentons l’ar-
chitecture matérielle et logicielle de notre solution, les différents outils mais aussi les
technologies utilisés pour le développement de notre solution.

2.2 Analyse des besoins

La partie d’analyse des besoins serte à jeter les bases des exigences à satisfaire par le
système à mettre en oeuvre. Nous expliquons donc les divers besoins de notre système
tout en mettant le diagramme de cas d’utilisation globale.

2.2.1 Identification des acteurs

Chaque système d’information a impérativement un ensemble des acteurs au sein

desquels ils interagissent. On trouve les acteurs principaux qui communiquent directement
avec le système, mais aussi les acteurs secondaires dont le système informatique a besoin
pour bien terminer un tel cas d’utilisation. Dans notre cas, nous avons un utilisateur
global qui interagit avec notre système où son rôle est configurable par l’administrateur
de l’application 1

2.2.2 Identification des besoins

La spécification des besoins est une phase essentielle pour que les résultats de déve-
loppement de notre application soient bien conformes aux attentes du client. Dans cette
section, nous parlons des besoins fonctionnels et non fonctionnels que nous prévoyons
mettre en œuvre dans notre projet.

2.2.2.1 Les besoins fonctionnels

Les besoins fonctionnels ou besoin métiers, sont les besoins indispensables auxquels
doit répondre l’application. Ils sont également les actions que le système doit exécuter.
— Authentification : Chaque utilisateur (Administrateur, Manager, Responsable
qualité, Opérateur) possède un nom d’utilisateur et un mot de passe qui sont spécifique
et lui permettent de s’identifier, afin d’autoriser l’accès de cette entité à des ressources en
toutes sécurité
— Gestion des utilisateurs : Cette fonctionnalité est assuré par l’administrateur qui
doit associer un compte à chaque utilisateur .
— Gestion d’accès : Aussi l’administrateur est le responsable dans cette fonctionnalité
qui affecte les permissions pour chaque profil .

11
Chapitre 2. Analyse et planification du projet

2.2.2.2 Les besoins non fonctionnels

Nous entendons par besoins non fonctionnels les besoins qui assurent l’amélioration
de la qualité des services de l’application. Ils agissent comme un ensemble des contraintes
à garder et à prendre en considération pour éviter l’incohérence dans le système. Notre
application doit répondre aussi aux exigences suivantes :
— la convivialité : le système doit être facile d’utilisation. Il doit y avoir des interfaces
qui répondent aux principaux critères d’ergonomie ;
— la performance : la fluidité du traitement doit être maintenue dans la mesure du
possible. Par exemple, quand il s’agit de fonctionnalités critiques, nous devrons garder le
parallélisme de traitement en utilisant des « Threads » ;
— la maintenabilité : au cours de développement il faut toujours garder la notion de la
modularité. Ainsi, le code de notre application doit être clair, documenté et bien structuré
pour permettre d’éventuels développements.

2.2.3 Diagramme de cas d’utilisation

Afin de bien modéliser les besoins de notre système, nous présentons dans cette section
le diagramme du cas d’utilisation global. Le diagramme montré dans la figure 2.1 décrit
les différents besoins fonctionnels de notre solution, de sorte que chaque cas d’utilisation
représente une fonctionnalité offerte par le système à ses utilisateurs.

Fig. 2.1 : Diagramme de cas d’utilisation global.

2.3 Pilotage du projet avec Scrum

Dans cette deuxième section, nous pilotons notre projet avec le cadre de travail Scrum,
nous présentons donc l’équipe de notre projet et le backlog du produit.

12
Chapitre 2. Analyse et planification du projet

2.3.1 Equipe du projet

La méthodologie Scrum s’articule autour de trois grands rôles :
— un « Product owner » qui gère le « Product Backlog » ;
— le « Scrum master » qui assure que le framework Scrum est toujours respecté. C’est un
facilitateur dans le sens où il facilite les réunions, les ateliers et les formations des équipes
au besoin ;
— une équipe de développement, composée de trois à neuf développeurs et chargée d’im-
plémenter les différentes fonctionnalités du système.
Les différents individus qui ont contribué à la réalisation de notre application sont illustrés
par le tableau 2.1

Intervenants et partie prenantes Rôles

Monsieur Mahdi BESBES Product Owner
Madame Ferjania BEN AISSA Scrum Master
Nesrine OBEY Développeur

Tab. 2.1 : Équipe et rôles Scrum.

2.3.2 Backlog du produit

Le backlog du produit est un artefact majeur de Scrum. Il consiste à exposer les « User
Stories » qui construisent l’intégralité de la solution. En effet, chaque fonctionnalité doit
être distinguée par un identifiant, et nécessairement caractérisée par un thème (Feature),
une priorité et une approximation de l’effort requis par un « team » pour y parvenir. La
suite de Fibonnacci était notre choix pour figurer l’estimation sous la forme de points
relatifs. Ainsi, nous représentons la priorité des différents tâches en utilisant la méthode
« MoSCoW » :
— M : « Must have », toutes les fonctionnalités sont primordiales ;
— S : « Should have », les tâches fondamentales qui ne sont pas nécessaires. Elles seront
produites dès la livraison de ceux du classement « Must have » ;
— C : « Could have », il s’agit de tâches qui ne peuvent s’acquitter que s’il reste suffisam-
ment de temps ;
— W : « Wont have this Time but would like in the Future », ce sont des tâches addition-
nelles, très facultatives.
Nous récapitulons le backlog du produit de notre solution à travers le tableau 2.2. Toutes
les fonctionnalités ont été listé dans un ordre séquentiel et non prioritaire. — P = Priorité ;
— E = Estimation (Story points)

2.3.3 Diagramme de Gantt

Les thèmes ont été bien présentés dans le backlog de produits et classé dans un ordre
séquentiel. L’idée est donc d’implémenter les différentes fonctionnalités de manière sé-
quentielle en prenant en compte l’estimation de l’effort qui a déjà été attribuée. Après

13
Chapitre 2. Analyse et planification du projet

ID et Feature User story P E

1. Configuration de keycloak
2. Intégration de Keycloak
3. Gestion des identités
4. Gestion des autorisations
5. gestion des comptes
6. Intégration de l’API Gateway
En tant qu’administrateur système, je veux
installer et configurer un serveur Keycloak
pour mon application. M 12
En tant que développeur, je veux intégrer
Keycloak avec mon application pour per-
mettre l’authentification de base. M 13
En tant qu’administrateur système, je veux
gérer les identités du système. M 13
En tant que développeur, je veux mettre
en place des règles d’autorisation personna-
lisées. M 13
En tant que développeur, je veux configurer
la gestion de compte utilisateur. M 13
En tant que développeur, je veux configurer
l’API Gateway pour rediriger les demandes
d’authentification vers Keycloak. M 20

Tab. 2.2 : Backlog du produit

une réunion avec le « scrum master » et le « product owner » nous avons défini cinq sprints
chacun dure quatre semaines et deux releases. Nous mettons donc dans cette section le
planning des divers sprints que nous avons programmé dans un format graphique, via le
diagramme du GANTT (figure 2.2)

Fig. 2.2 : Planification prévisionnelle des sprints .

14
Chapitre 2. Analyse et planification du projet

2.4 Environnement de travail

Dans cette section, nous présentons les divers outils et technologies qui forment l’en-
vironnement de travail. Ainsi, nous faisons la démonstration de l’architecture matérielle
et logicielle de notre solution.

2.4.1 Environnement technique

Nous montrons dans cette partie, l’ensemble des fonctionnalités techniques qui donnent
une vision globale de la spécification matérielle sur laquelle notre application a été déve-
loppée. Nous identifions dans le tableau 2.3 les outils matériels utilisés pour la réalisation
de notre système :

PC Portable ASUS
Processeur (CPU) et Fréquence Intel Core i7-7500U 2.90 GHZ
Mémoire physique (RAM)A 8 GO
Disque Dur 256 GO - SSD
Processeur graphique (GPU) NVIDIA Geforce MX110
Système d’exploitation Windows 10 Professionnel, 64 bit

Tab. 2.3 : Description de la machine de développement

2.4.2 Outils de Réalisation

Après avoir présenté les moyens matériels, nous abordons à travers le tableau 2.4 les
différents outils utilisés pour la mise en place de notre application :

Environnement de développement intégré IntelliJ IDEA V. 2019.3.4

Système de gestion de base de données MySql
Outil de visualisation de BD MySQL Workbench V. 8.0
Outil d’automatisation de production Maven
Logiciel de gestion de versions et Forge Git - GitLab
Outil de test des API Postman
Outil de modélisation UML Draw.io

Tab. 2.4 : Description de la machine de développement

2.4.3 Technologies et langages utilisés

Nous présentons maintenant les differents langages et « frameworks » utilisés pour la

production de notre solution logicielle.

15
Chapitre 2. Analyse et planification du projet

2.4.3.1 Langages

— Java : Java est un langage de programmation orienté objet, portable qui ”fonc-
tionne aussi bien sur Windows que Mac ou Linux, et sur une myriade d’appareils”[13] ;
— TypeScript : TypeScript est un langage de programmation open source, son but
principal est d’améliorer la productivité du code Javascript ;
— HTML : Le « HyperText Markup Language » est un langage de balisage qui est ”uti-
lisé afin de créer et de représenter le contenu d’une page web et sa structure”[14] ;
— CSS :— CSS : CSS est un langage qui permet de décrire la présentation des pages
HTML.

2.4.3.2 Frameworks

— Spring Boot : Spring Boot est un « framework » de développement Java qui

est ”particulièrement recommandé pour le développement d’API”[15]. En effet, ”il s’agit
d’une version simplifiée et automatisée du framework Spring”[16] dont son objectif est
d’éliminer les configurations lourdes qui sont basées entièrement sur le langage XML ;
— Angular : Angular est un framework open source basé sur typescript. Il permet de
créer des SPAs (Single page applications).

2.4.3.3 Système de sécurité : Keycloak

Keycloak est un logiciel open source de la famille IAM : Identity and Access Manage-
ment. Le but de Keycloak est de simplifier la sécurisation des applications, des appareils
et des services au sein du système d’information. En effet, la gestion des identités et
l’authentification sont des fonctionnalités complexes que les développeurs devaient aupa-
ravant développer eux-mêmes. Ces fonctionnalités sont nativement fournies par keycloak.
Cela se traduit par moins complexité et plus de sécurité pour le système d’information, et
les développeurs peuvent désormais se concentrer sur les fonctionnalités cœur de métier.
Keycloak offre nativement plusieurs catégories de fonctionnalités majeures :
Les fonctionnalités nécessaires à la gestion des identités : Enrôlement des utilisateurs,
applications et appareils, politique de mots de passe, validation des adresses email, page
de login, page mot de passe oublié, option se souvenir de moi, MFA ou authentification
multifactorielle, etc. L’authentification comme un service. Cela signifie qu’une application
ou un appareil peut déléguer à Keycloak la responsabilité d’authentifier ses utilisateurs.
La configuration des droits d’accès aux applications. Les droits peuvent être attribués
aussi bien aux utilisateurs qu’aux applications.

Architecture Keycloak et Termes clés :

Keycloak utilise ces termes clés du OAuth 2.0 :

Client ID : Tel l’identité unique , le Client ID est un identifiant unique attribué à chaque
client d’application qui souhaite se connecter à un serveur d’authentification OAuth 2.0,
tel que Keycloak. Tout comme chaque personnage a son propre nom distinctif, le Client ID

16
Chapitre 2. Analyse et planification du projet

identifie de manière unique le client auprès du serveur d’authentification lors de l’échange

de demandes d’autorisation et de jetons.

Realm : Dans le contexte de Keycloak, un Realm est un royaume qui regroupe des
utilisateurs, des clients et des configurations de sécurité. Chaque Realm agit comme un
monde distinct avec ses propres règles d’authentification et d’autorisation. C’est comme
si chaque royaume de Game of Thrones avait son propre jeu de règles, tel qu’un Realm
pour votre application Web et un autre Realm pour votre application mobile.

Client Secret : Tel un secret bien gardé dans les intrigues complexes de Game of
Thrones, le Client Secret est une chaîne de caractères secrète utilisée pour authentifier le
client d’application auprès du serveur d’authentification. Comme un personnage aux mo-
tivations cachées, le Client Secret est utilisé dans certains flux d’authentification OAuth
2.0 pour prouver l’identité du client.

Grant Type : Tel les différents types de stratégies politiques dans Game of Thrones,
le Grant Type est un paramètre utilisé lors de l’échange d’autorisation OAuth 2.0 pour
spécifier le type de flux d’authentification utilisé. Chaque type de subvention, tel que
”password” utilisé pour les flux de nom d’utilisateur et mot de passe, et ”client creden-
tials” utilisé pour l’authentification de client à client, offre des possibilités diverses pour
sécuriser l’authentification et l’autorisation dans les systèmes distribués.

Ces termes font partie du protocole OAuth 2.0 et sont utilisés pour sécuriser l’authen-
tification et l’autorisation dans les systèmes distribués. Tout comme les divers éléments de
Game of Thrones qui s’entremêlent dans une complexité intrigante, en utilisant un Client
ID et un Client Secret appropriés, ainsi que le bon Grant Type, les clients d’application
peuvent demander et obtenir des jetons d’accès auprès du serveur d’authentification pour
accéder aux ressources protégées.
Besoins techniques :
Dans une architecture microservices, l’utilisation de Keycloak peut jouer un rôle im-
portant dans la gestion des identités et des accès,Voici quelques aspects de l’utilisation :

Gestion centralisée des identités : Keycloak permet de centraliser la gestion des uti-
lisateurs, des rôles et des autorisations. Chaque microservice peut s’intégrer à Keycloak
pour gérer l’authentification et l’autorisation des utilisateurs de manière cohérente, en fait
les différentes maisons du GOT sont regroupées sous une autorité centrale.

Intégration avec les protocoles d’authentification standard : Keycloak prend en charge

des protocoles d’authentification tels que OAuth 2.0 et OpenID Connect. Cela facilite l’in-
tégration des microservices avec Keycloak et permet une interaction sécurisée avec des
clients externes, citons au passage les différentes maisons qui collaborent pour former des
alliances stratégiques.

17
Chapitre 2. Analyse et planification du projet

Sécurité basée sur les tokens : En effet les sceaux portant les armoiries des maisons
nobles de Westeros qui garantissent l’authenticité des messages, Keycloak utilise des to-
kens, tels que les tokens d’accès JWT (JSON Web Token), pour authentifier les demandes
entre les microservices. Les microservices peuvent valider ces tokens pour garantir que
seules les demandes provenant d’utilisateurs authentifiés et autorisés sont acceptées.

Keycloak dans une architecture microservice :

En intégrant Keycloak dans une architecture microservices, nous pouvons bénéficier

d’une gestion centralisée des identités et des accès, d’une sécurité robuste, d’un SSO et
d’une facilité d’intégration avec des protocoles standard.
Cela permet d’améliorer la sécurité, la convivialité et la scalabilité de votre architecture
microservices.
Voilà un exemple d’une architecture microservice simplifiée qui intègre un serveur Key-
cloak.

Fig. 2.3 : Keycloak dans une Architecture Micorservice.

2.5 Architecture de la Solution

L’architecture d’une application fait référence à la structure générale propre à un
système informatique, à l’organisation des différents éléments du système et aux relations
entre les éléments. Dans cette partie, nous présentons l’architecture de notre application
de point de vue matériel et logiciel.

18
Chapitre 2. Analyse et planification du projet

2.5.1 Architecture physique

Pour bien présenté l’architecture physique de notre application ainsi que de la solu-
tion entière « ADDIXO Smart Factory », nous avons choisi de mettre le diagramme de
déploiement UML qui nous permettre de ”[décrire] le déploiement physique des informa-
tions générées par le logiciel sur des composants matériels”[19]. La figure 2.5 présente le
diagramme de déploiement de la solution « Smart Factory » :

Fig. 2.4 : Diagramme de déploiement de la solution « ADDIXO Smart Factory »

2.5.2 Architecture logicielle

Le « framework » Spring Boot suit une structure basée sur la séparation en couches.
De ce fait, une application « Spring Boot » se compose des quatre couches suivantes :
— Couche « Model » : pour la mise en place des entités qui seront traités par d’autres
couches ;
— Couche Contrôleur : sert à gérer les dialogues entre l’application et son utilisateur ;
— Couche « Repository » : responsable de la conversion des objets métiers en tables
dans la base de données, et vice-versa ;
— Couche Service : charger de la validation et de l’autorisation, là où ce faite ”l’im-
plémentation des traitements métiers spécifiques à l’application”[20].

Fig. 2.5 : Architecture Spring Boot et intégration de keycloak

2.6 Conclusion
Tout au long de ce chapitre, nous avons détaillé les différents besoins de notre sys-
tème, identifié l’équipe de production et présenté notre backlog du produit. Nous avons
aussi présenté l’environnement matériel et logiciel utilisé pour la mise en place de notre
système, ainsi que son architecture physique et logique. Dans le chapitre suivant, nous
allons entamer la première partie de la réalisation du projet, la Release 1.

19
Chapitre 3

Mise en œuvre de : Release 1

20
Chapitre 3. Mise en œuvre de : Release 1

3.1 Introduction
Dans ce présent chapitre, nous élaborons les deux premiers sprint. Dans ce sens, nous
mettons le backlog de chaque sprint en présentant les différents stades de production à
savoir la phase d’analyse, de conception et de réalisation.

3.2 Sprint1 : Configuration de keycloak

Le but de ce sprint consiste à mettre en oeuvre une configuration de keycloak

3.2.1 Backlog du sprint

Nous présentons à travers le tableau 3.1 le backlog du sprint ainsi que l’estimation de
l’effort par jour de chaque tâche à faire. — E = Estimation (par jour).

ID et Feature ID Tache E
1.1 Creation de realm ,client, utilisateurs 1
1.2 Création des roles 1
Configuration de keycloak
1.3 assignation des rôles 1
1.4 Génération de Token d’accès 1

Tab. 3.1 : Description de la machine de développement

21
Conclusion et perspectives

22
Conclusion et perspectives

Conclusion générale

23
Annexes

24