Université Tunis El Manar

Ecole Nationale d’Ingenieurs

de Tunis

Département Technologies de l’Information et de la

Communication
Rapport de projet de fin d’études

Élève ingénieur : Fekih Syrine

Concevoir et développer un agent

HealthCheck pour iObeya

Soutenu le 25/09/2024
Devant le jury :

Président : M. Wady Naanaa

Rapporteur : Mme Sonia Alouane
Encadrant professionnel : M. Moslah Hamza
Encadrant académique : Mme Abir Gallas

Réalisé au sein de iObeya

Année universitaire 2023-2024

Signatures

J’autorise l’étudiante Fekih Syrine à déposer son rapport de stage en vue d’une
soutenance.

Entreprise: iObeya
Encadrant professionnel : M. Hamza Moslah

J’autorise l’étudiante Fekih Syrine à déposer son rapport de stage en vue d’une
soutenance.

Encadrant Académique : Mme Abir Gallas

 Résumé

Le projet consiste à concevoir et implémenter un système de supervision en temps réel

pour iObeya, utilisé par l’équipe On-Premise. Ce système surveille efficacement les per-
formances de l’application, les journaux et les tâches programmées, centralisant des infor-
mations clés telles que les licences, les plugins activés, les bases de données, ainsi que des
métriques critiques (temps CPU, durée des requêtes, mémoire JVM). Il permet d’analyser
les logs d’activité et d’erreurs en temps réel avec une classification automatique des erreurs
et des suggestions d’actions correctives. En parallèle, il suit l’exécution des tâches pro-
grammées, telles que les jobs de migration et de purge, avec des visualisations des durées
et de l’utilisation du stockage. L’architecture repose sur des microservices modernes uti-
lisant Java, Spring Boot, Kafka, Elasticsearch, React et Docker pour garantir la fiabilité,
l’évolutivité et la maintenabilité du système.

Mots-clés : Supervision, métriques, journaux, tâches programmées, monitoring en temps

réel.

Abstract

The project involves designing and implementing a real-time monitoring system for iObeya,
used by the On-Premise team. The system efficiently tracks application performance, logs,
and scheduled tasks, centralizing key information like licenses, enabled plugins, databases,
and critical metrics (CPU time, query duration, JVM memory). It provides real-time er-
ror and activity log analysis with automatic error classification and corrective action
suggestions. Additionally, it monitors scheduled tasks, such as migration and purge jobs,
offering visualizations of execution times and storage usage. The system is built on a
modern microservices architecture using Java, Spring Boot, Kafka, Elasticsearch, React,
and Docker to ensure reliability, scalability, and maintainability.

Keywords : Monitoring, metrics, logs, scheduled tasks, real-time monitoring.

 Remerciements

Je tiens à exprimer ma gratitude à tous ceux qui m’ont soutenue et qui m’ont offert
la possibilité à bien mener ce projet de fin d’études et de terminer mon parcours en tant
qu’étudiante en ingénierie logicielle.

Je voudrais adresser mes remerciements les plus sincères au directeur de l’entreprise, M.

Christophe Cosnefroy, ainsi qu’au responsable de l’ingénierie, M. Mohamed Ama-
mou, pour avoir fourni le cadre nécessaire à ce projet. J’aimerais également exprimer
ma profonde gratitude à mes superviseurs directs, M. Dhaou Bourouis et M. Hamza
Moslah, pour leur expertise technique et leurs efforts continus. Les conseils qu’ils m’ont
partagés lors des réunions quotidiennes ont été inestimables tout au long de mon stage
de fin d’études.

Je suis également profondément reconnaissante à Mme Abir Gallas, mon encadrant

académique, pour sa disponibilité, ses conseils et son assistance. Ses encouragements et
son soutien m’ont permis de progresser avec confiance, et je lui suis extrêmement recon-
naissante pour l’attention particulière qu’elle a portée à mon projet.

Enfin, ma sincère gratitude aux membres du jury d’honneur pour avoir pris le temps
d’examiner mon travail.

i
 Table des matières

Remerciements i

Liste des acronymes vii

Introduction générale 1

1 Cadre général du projet 3

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Présentation de l’organisation d’accueil . . . . . . . . . . . . . . . . . . . . 3
1.1.1 iObeya . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2 Structure organisationnelle . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.3 Pôles d’activité et développement . . . . . . . . . . . . . . . . . . . 4
1.1.4 Modes de commercialisation d’iObeya . . . . . . . . . . . . . . . . . 5
1.2 Présentation du Projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Énoncé du problème . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2 Objectif du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Méthodologie de développement . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1 Scrum avec la plate-forme iObeya . . . . . . . . . . . . . . . . . . . 6
1.3.2 Rituels et réunions scrum dans l’équipe iObeya : . . . . . . . . . . . 9
1.4 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.4.1 Systèmes de supervision actuels chez iObeya Online . . . . . . . . . 15
1.4.2 Systèmes de supervision actuels chez iObeya On-prem . . . . . . . . 16
1.4.3 Les outils de supervision sur le marché . . . . . . . . . . . . . . . . 18
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2 Analyse et spécification des besoins 20

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1 Capture des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1.1 Acteur de l’application . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1.2 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . 21

ii
Table des matières Table des matières

2.1.3 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2 Analyse de besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.1 Diagramme de cas d’utilisation général . . . . . . . . . . . . . . . . 23
2.2.2 Diagramme d’activité général . . . . . . . . . . . . . . . . . . . . . 32
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3 Conception 35
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.1 Motivation pour les architectures Big Data . . . . . . . . . . . . . . . . . . 35
3.1.1 Défis des données massives . . . . . . . . . . . . . . . . . . . . . . . 35
3.1.2 Avantages des architectures Big Data . . . . . . . . . . . . . . . . . 36
3.2 Architectures Big Data temps réel . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.1 Architecture Lambda . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.2 Architecture Kappa . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2.3 Choix de l’architecture . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2.4 Les composants de l’architecture . . . . . . . . . . . . . . . . . . . . 40
3.3 Conception globale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.3.1 Diagramme de paquetage relatif à la partie serveur d’iObeya . . . . 41
3.3.2 Diagramme de paquetage relatif à la couche Streaming . . . . . . . 41
3.3.3 Diagramme de paquetage relatif à la couche Service . . . . . . . . . 42
3.4 Conception détaillée de l’addon Healthcheck . . . . . . . . . . . . . . . . . 44
3.4.1 Diagramme de séquence relatif à l’authentification . . . . . . . . . . 44
3.4.2 Diagramme de séquence “Extraction les journaux de l’activité de
l’utilisateurs” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.4.3 Diagramme de séquence “Extraction des métriques reliés aux tâches
programmées“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4 Implémention 48
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.1 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . . 48
4.1.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . 48
4.1.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2.1 Interface information système iObeya . . . . . . . . . . . . . . . . . 52
4.2.2 Interface des métriques de l’infrastructure iObeya . . . . . . . . . . 53
4.2.3 Interface journaux d’iObeya . . . . . . . . . . . . . . . . . . . . . . 54
4.2.4 Interface métriques des taches programmées d’iObeya . . . . . . . . 56
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Conclusion générale et perspectives 58

Annexe 61

iii
 Table des figures

1.1 Organigramme de la structure d’iObeya du département R&D . . . . . . . 4

1.2 Visualisation d’une salle dans iObeya . . . . . . . . . . . . . . . . . . . . . 7
1.3 Exemple d’un panneau de type DCM . . . . . . . . . . . . . . . . . . . . . 8
1.4 Outils iObeya à insérer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5 La carte story de iObeya . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6 Aperçu de planification des sprints 1 et 2 avec leur story points . . . . . . 10
1.7 Aperçu de planification des sprints 3 et 4 avec leur story points . . . . . . 11
1.8 Aperçu de planification des sprints 5, 6 et 7 avec leur story points . . . . . 12
1.9 Aperçu de planification des sprints 8 et 9 avec leur story points . . . . . . 13
1.10 Tableau de progression des taches du projet Healthcheck . . . . . . . . . . 14
1.11 Exemple d’une interface des logs affichés en temps réel dans Datadog pour
l’un des clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.12 Exemple d’une interface des métriques affichées dans Datadog pour l’un
des clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.1 Diagramme de cas d’utilisation général . . . . . . . . . . . . . . . . . . . . 23

2.2 Diagramme cas d’utilisation relative à la CU ”Visualiser les métriques en
temps réel” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3 Diagramme cas d’utilisation relative à la CU ”Visualiser les journaux métriques
en temps réel” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.4 Diagramme d’activité relatif au fonctionnement général du Healthcheck . . 33

3.1 Architecture Lambda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.2 Architecture Kappa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3 Architecture Lambda du Healthcheck agent . . . . . . . . . . . . . . . . . 40
3.4 Diagramme de paquetage relatif à la couche d’exposition des données de la
plate-forme iObeya . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.5 Diagramme de paquetage relatif au Streaming Layer . . . . . . . . . . . . . 43
3.6 Diagramme de paquetage relatif au Service Layer . . . . . . . . . . . . . . 44
3.7 Diagramme de séquence relatif à l’authentification . . . . . . . . . . . . . . 45

iv
Table des figures Table des figures

3.8 Diagramme de séquence relatif à l’extraction les journaux de l’activité de

l’utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.9 Diagramme de séquence relatif à l’extraction des métriques reliés aux tâches
programmées exemple du job Migration . . . . . . . . . . . . . . . . . . . . 47

4.1 Génération du token depuis iObeya Client . . . . . . . . . . . . . . . . . . 51

4.2 Interface de saisie du Token pour accéder à Healthcheck . . . . . . . . . . . 52
4.3 Interface relative aux informations système de iObeya . . . . . . . . . . . . 53
4.4 Interface relative aux métriques de l’infrastructure iObeya . . . . . . . . . 54
4.5 Interface d’ajout d’une charte d’une métrique inexistante . . . . . . . . . . 54
4.6 Interface des journaux d’activité et des erreurs en temps réel . . . . . . . . 55
4.7 Exemple de pop up de prédiction du label d’erreur ainsi que les actions
correctives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.8 Interface de suivi des métriques des tâches programmées d’iObeya, affichant
la durée et le stockage utilisé pour les jobs de migration et de purge. . . . . 57
4.9 Exemple d’un panneau de rétrospective Starfish . . . . . . . . . . . . . . . 61
4.10 Exemple d’un panneau de ma première Sprint demo . . . . . . . . . . . . . 62

v
 Liste des tableaux

1.1 Comparaison des outils de supervision On-prem . . . . . . . . . . . . . . . 18

2.1 Scénario nominal du CU Consulter les données du système iObeya . . . . . 24

2.2 Scénario nominal du CU Visualiser les métriques en temps réel . . . . . . . 25
2.3 Scénario nominal du CU Consulter les journaux en temps réel . . . . . . . 25
2.4 Scénario nominal du CU Identifier les types d’erreurs . . . . . . . . . . . . 26
2.5 Scénario nominal du CU Lancer des actions correctives pour les erreurs . . 27
2.6 Scénario nominal du CU Visualiser les métriques systèmes . . . . . . . . . 29
2.7 Scénario nominal du CU visualiser les métriques des tâches programmées . 30
2.8 Scenario nominal du CU Consulter les journaux d’activité . . . . . . . . . 31
2.9 Scénario nominal du CU Consulter les journaux d’erreur . . . . . . . . . . 32

3.1 Comparaison entre l’architecture Lambda et l’architecture Kappa . . . . . 39

vi
 Liste des acronymes

API (Application Programming Interface)

CPU (Central Processing Unit)

CU (Cas d’Utilisation)

ELK (Elasticsearch, Logstash, Kibana)

ETL (Extract, Transform, Load)

HTTP (Hypertext Transfer Protocol)

IA (Intelligence Artificielle, Artificial Intelligence)

IOT (Internet of Things)

JVM (Java Virtual Machine)

JWT (JSON Web Token)

LTS (Long Term Support)

NLP (Natural Language Processing)

On-prem (On-premises)

RAM (Random Access Memory)

R&D (Research and Development)

SQL (Structured Query Language)

SSD (Solid State Drive)

vii
 Introduction générale

Dans le monde numérique d’aujourd’hui, les données jouent un rôle crucial dans la
prise de décision et l’optimisation des processus. Avec l’explosion des volumes de données,
le terme ”Big Data” a émergé pour désigner les vastes quantités d’informations générées
à des vitesses élevées et dans des formats variés. Les entreprises, en particulier, génèrent
et collectent des données à partir de diverses sources, dont les fichiers de logs, qui sont
des enregistrements des activités et événements se produisant au sein des systèmes in-
formatiques. Les logs sont des fichiers générés par les systèmes informatiques pour enre-
gistrer une multitude d’informations, telles que les activités des utilisateurs, les erreurs
du système, les transactions commerciales et les interactions avec les bases de données.
Ces fichiers sont souvent volumineux et complexes, mais ils contiennent des informations
essentielles qui peuvent fournir des insights précieux pour divers domaines tels que la
sécurité informatique, la gestion des performances et l’analyse prédictive.

L’analyse des fichiers logs permet aux entreprises d’obtenir une vision détaillée de leurs
opérations quotidiennes. Par exemple, en surveillant les logs en temps réel, il est possible
de détecter rapidement des anomalies ou des comportements suspects, permettant ainsi
une réponse rapide aux incidents de sécurité. De plus, en analysant les tendances histo-
riques des logs, les entreprises peuvent identifier des modèles récurrents et anticiper des
problèmes potentiels avant qu’ils ne deviennent critiques, améliorant ainsi la fiabilité et
la disponibilité de leurs systèmes.

Dans le cadre de ce projet de fin d’études, nous nous sommes intéressés à l’exploitation
des logs de l’application iObeya afin d’extraire des informations utiles pour divers cas
d’utilisation chez les clients, allant de la surveillance en temps réel à la prédiction des er-
reurs et à la proposition de solutions automatisées. L’objectif principal est de démontrer
comment les techniques et technologies de Big Data peuvent être appliquées pour trans-
former des fichiers logs bruts en données exploitables, apportant ainsi une valeur ajoutée
considérable à l’entreprise.

Pour atteindre cet objectif, nous avons mis en place une architecture basée sur des techno-
logies modernes telles que Spark Streaming pour le traitement en temps réel, Kafka pour

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

la gestion des flux de données, et Elasticsearch pour le stockage et la recherche des logs.
Ces outils, combinés à des techniques avancées d’apprentissage automatique, nous ont
permis de développer des solutions capables de classifier les logs, d’identifier les anomalies
et de suggérer des actions correctives de manière proactive.

Ce rapport de stage comporte quatre chapitres comme suit :

Le premier chapitre présente brièvement l’organisme hôte et le cadre général de ce projet.

Il aborde ensuite la méthodologie de gestion de projet appliquée et les rituels associés à
la méthodologie, ainsi que l’étude de l’existant.

Le deuxième chapitre décrit une spécification détaillée des exigences fonctionnelles et non
fonctionnelles globales de la solution. Il décrit notamment l’analyse des cas d’utilisation.

Le troisième chapitre présente les architectures Big Data temps réel et la solution suggérée.
Ensuite, il met l’accent sur la vision conceptuelle du projet via une présentation de l’ar-
chitecture globale et détaillée de notre solution avec des diagrammes de paquetage et de
séquence.

Le quatrième chapitre illustre la réalisation de l’application. Je citerai les différentes tech-

nologies utilisées dans notre application, ainsi que les interfaces utilisateur.

Finalement, le rapport se clôt par une conclusion générale qui résume le travail effectué
et ouvre quelques perspectives.

2
 CHAPITRE 1

Cadre général du projet

Introduction
Ce chapitre introduit l’organisation iObeya, son fonctionnement et ses activités, ainsi
que le projet d’amélioration des systèmes de supervision. Il décrit la méthodologie Scrum
utilisée et examine les solutions de supervision existantes, tant chez iObeya que sur le
marché.

1.1 Présentation de l’organisation d’accueil

Cette section présente l’organisme d’accueil iObeya ainsi que son domaine d’activité
et son produit.

1.1.1 iObeya
iObeya [1], fondée à l’origine sous le nom de KAP-IT par Cyril Daloz et Julian Revel,
développe des logiciels depuis 2005. Le concept d’iObeya s’inspire du terme japonais
≪ Obeya ≫, qui signifie ≪ grande pièce ≫. En 2012, KAP-IT a collaboré avec le groupe

Stellantis, qui exprimait le besoin de digitaliser ses salles dédiées au développement de

produits, ce qui a conduit à la création d’iObeya. Depuis, plusieurs entreprises, telles que
Sanofi et Airbus, ont adopté les Obeyas virtuelles, contribuant ainsi à une adoption plus
large de ce concept dans différents secteurs industriels.

1.1.2 Structure organisationnelle

L’organisation d’iObeya, comme le montre la figure 1.1, repose sur une structure matri-
cielle qui combine une gestion par projet et une gestion fonctionnelle. Parmi les différents
sites, celui de Tunisie joue un rôle clé dans le développement des solutions de l’entreprise.
Le site de Tunisie se concentre sur la recherche et développement (RD). Au sein de ce

3
Chapitre 1. Cadre général du projet 1.1. Présentation de l’organisation d’accueil

Figure 1.1 : Organigramme de la structure d’iObeya du département R&D

site, le département RD participe à la conception, au développement et à l’optimisation

des fonctionnalités des applications de l’entreprise. Je fais partie de l’équipe On-Prem
au sein du département RD. Cette équipe se concentre sur les solutions déployées sur
site (on-premises), qui sont proposées en complément des solutions cloud, en fonction des
exigences en matière de sécurité, de conformité ou de performance. L’équipe On-Prem
est chargée d’adapter les fonctionnalités d’iObeya aux environnements locaux des clients.
La collaboration entre les différents sites d’iObeya, y compris celui de Tunisie, permet de
maintenir une coordination globale tout en tenant compte des compétences spécifiques de
chaque équipe.

1.1.3 Pôles d’activité et développement

iObeya propose une gamme de services et de solutions destinés à répondre aux be-
soins variés des entreprises, qu’elles soient grandes, moyennes ou petites. Ses activités
principales se concentrent sur deux domaines : le développement de logiciels sur me-
sure et l’amélioration continue de sa plateforme de management visuel. D’une part, le
développement de logiciels sur mesure est un aspect central des activités de l’entreprise.
iObeya conçoit des applications adaptées aux exigences spécifiques de chaque client. Ces
solutions visent à optimiser les processus internes, à faciliter la gestion des flux d’infor-
mations complexes et à améliorer la collaboration au sein des organisations. D’autre part,
iObeya investit dans l’édition et l’amélioration continue de sa plateforme, actuellement
dans sa version 4.36. Cette application, axée sur le management visuel, vise à transformer

4
Chapitre 1. Cadre général du projet 1.2. Présentation du Projet

la gestion et la collaboration au sein des entreprises. Elle facilite l’accès aux informations
clés et soutient une prise de décision collective plus éclairée. En tenant compte des retours
des utilisateurs et en s’adaptant aux nouveaux besoins, iObeya veille à ce que sa plate-
forme reste à jour avec les évolutions du marché. Cet engagement dans le développement
de solutions sur mesure et dans l’amélioration de sa plateforme reflète l’objectif de l’en-
treprise de soutenir les entreprises dans leur transition numérique.

1.1.4 Modes de commercialisation d’iObeya

La plateforme iObeya est conçue pour répondre aux besoins variés de ses clients grâce
à des modèles de livraison flexibles. L’entreprise propose deux principales façons d’accéder
à ses solutions de management visuel :

• Package On-Premises : Les clients peuvent opter pour le package on-premises

(on-prem), qui leur permet d’héberger la plateforme iObeya au sein de leur propre in-
frastructure informatique. Ce modèle est idéal pour les organisations qui privilégient
le contrôle des données, la sécurité et la conformité aux politiques internes.

• Abonnement en Ligne : Alternativement, les clients peuvent choisir le modèle

en ligne, où iObeya héberge la plateforme dans le cloud. Cette option offre plus de
flexibilité et une facilité d’accès, avec des mises à jour régulières et une maintenance
assurée par iObeya.

Ces deux modèles garantissent qu’iObeya peut répondre aux exigences diverses de sa
clientèle, qu’elle ait besoin d’un contrôle strict de son environnement ou qu’elle préfère
une approche plus légère avec des services hébergés dans le cloud.

1.2 Présentation du Projet

Ce projet a été réalisé dans le cadre d’un stage de fin d’études en vue de l’obtention
du diplôme national d’ingénieur en informatique auprès de l’École Nationale d’Ingénieurs
de Tunis. Il a été élaboré sur une durée de six mois, du 1er février au 31 juillet 2024, chez
iObeya.

1.2.1 Énoncé du problème

Le principal défi auquel est confrontée la plate-forme iObeya pour les clients ≪ On-
Premises ≫ est de permettre aux équipes techniques et aux décideurs d’identifier rapide-
ment les anomalies, d’optimiser les performances et de faciliter la prise de décision basée
sur les données. Actuellement, l’outil iObeya génère une multitude de journaux et de
métriques lors de son utilisation. Cependant, ces données restent largement inexploitées
par iObeya, ce qui représente une opportunité significative d’amélioration.
Pour répondre à ce défi, il serait crucial de développer des fonctionnalités avancées d’ana-
lyse et de visualisation des données intégrées directement dans la plate-forme. Cela per-
mettrait non seulement de détecter rapidement les anomalies, mais aussi de comprendre

5
Chapitre 1. Cadre général du projet 1.3. Méthodologie de développement

les tendances d’utilisation, de prévoir les problèmes potentiels et de fournir des recom-
mandations proactives pour optimiser les performances.
De plus, en mettant en place des tableaux de bord personnalisables, les décideurs pour-
raient obtenir une vue d’ensemble des métriques clés en temps réel, facilitant ainsi une
prise de décision plus éclairée et basée sur des faits concrets. Des algorithmes de ma-
chine learning pourraient être utilisés pour analyser les journaux et métriques, détecter
les schémas anormaux et proposer des actions correctives avant que des problèmes majeurs
n’émergent.
En intégrant ces capacités analytiques, iObeya pourrait non seulement améliorer l’effica-
cité opérationnelle de ses clients ≪ On-Premises ≫, mais également renforcer leur confiance
dans la plate-forme en démontrant une réelle valeur ajoutée par l’exploitation intelli-
gente des données. Cela transformerait les journaux et les métriques générés en un atout
stratégique, permettant une gestion proactive et optimisée des environnements de travail
collaboratifs.

1.2.2 Objectif du projet

L’objectif principal du projet est de mettre en place une infrastructure permettant de
transporter les données générées par iObeya vers un tableau de bord pour les exploiter
en visualisant les métriques et les journaux en temps réel. Pour ce faire, je développerai
une application qui interprète et présente ces données sous forme de graphiques. Cela
offrira aux administrateurs la capacité de surveiller en temps réel les performances de la
plate-forme, d’identifier immédiatement les problèmes potentiels et de réagir rapidement
afin de minimiser les interruptions de service.
En intégrant des alertes configurables et des analyses avancées, le tableau de bord sera
capable de signaler automatiquement tout comportement anormal ou incident, ce qui
facilitera une intervention rapide. Grâce à cette infrastructure, les administrateurs dis-
poseront d’un outil puissant pour optimiser la gestion de la plate-forme, en ayant une
visibilité continue sur l’état du système et en étant capables d’anticiper et de résoudre
les problèmes avant qu’ils n’affectent les utilisateurs. Cette approche proactive permettra
non seulement de maintenir des performances élevées, mais aussi de renforcer la fiabilité
et la stabilité de la plate-forme iObeya.

1.3 Méthodologie de développement

Afin d’atteindre les objectifs mentionnés précédemment, nous avons adopté la méthodologie
Scrum. Cette section détaille concrètement comment nous appliquons les pratiques Scrum,
en mettant en avant l’utilisation des tableaux de planification (planning boards) et en
décrivant les activités clés.

1.3.1 Scrum avec la plate-forme iObeya

iObeya est une plate-forme de collaboration visuelle spécialement conçue pour soutenir
les équipes qui adoptent des méthodologies agiles comme Scrum et Kanban. En intégrant

6
Chapitre 1. Cadre général du projet 1.3. Méthodologie de développement

des tableaux virtuels, iObeya permet aux équipes de gérer efficacement leurs projets en
suivant les principes de l’agilité. Les principales fonctionnalités de la plate-forme qui
facilitent l’application de Scrum incluent :

• Tableaux Scrum et Kanban : iObeya propose des tableaux virtuels adaptés à

la gestion de projets Agile, permettant aux équipes de suivre l’évolution des tâches,
de visualiser les sprints et de gérer les backlogs de manière fluide et interactive.

• Réunions virtuelles : La plateforme offre des espaces collaboratifs pour les

réunions d’équipe, telles que les daily stand-ups, les rétrospectives et les revues de
sprint, assurant une synchronisation efficace même pour les équipes distribuées.

• Cartes mentales et diagrammes : Ces outils sont intégrés pour faciliter la

planification stratégique, le brainstorming et la conceptualisation de nouvelles idées,
essentiels pour la phase de planification des sprints.

• Intégrations : iObeya s’intègre facilement avec des outils couramment utilisés

dans les environnements Scrum comme Jira, Confluence et Microsoft Teams, permet-
tant une harmonisation des processus de travail et une communication transparente.

La force d’iObeya réside dans sa capacité à s’adapter aux besoins spécifiques de chaque
équipe Scrum. En permettant la création de salles virtuelles dédiées aux projets, iObeya
aide les équipes à visualiser leur travail, à suivre l’avancement des tâches et à collaborer en
temps réel, quel que soit le lieu où se trouvent les membres de l’équipe. Une salle virtuelle
est illustrée par la figure 1.2.

Figure 1.2 : Visualisation d’une salle dans iObeya

7
Chapitre 1. Cadre général du projet 1.3. Méthodologie de développement

En pratique, chaque salle dans iObeya est constituée de panneaux numériques où les
équipes peuvent créer et organiser leurs éléments de gestion visuelle. Ces panneaux,
illustrés dans la figure 1.3, de tailles variées, sont les supports de travail sur lesquels
les équipes collaborent, planifient et exécutent leurs projets Scrum.
L’utilisateur peut y ajouter du contenu, interagir avec les éléments grâce à divers modes
et utilitaires, et ainsi gérer efficacement ses activités quotidiennes.

Figure 1.3 : Exemple d’un panneau de type DCM

Les outils variés disponibles dans iObeya, appelés iObeya Tools, enrichissent cette expérience
en offrant des fonctionnalités supplémentaires pour une gestion agile optimale. Ces ou-
tils illustrés par la figure 1.4 permettent de personnaliser les panneaux et de répondre
précisément aux besoins de chaque sprint, rendant iObeya indispensable pour les équipes
Scrum modernes.

Figure 1.4 : Outils iObeya à insérer

8
Chapitre 1. Cadre général du projet 1.3. Méthodologie de développement

1.3.2 Rituels et réunions scrum dans l’équipe iObeya :

Dans le cadre de la méthodologie Scrum, notre équipe suit une série de rituels et
de réunions essentielles pour assurer une gestion efficace des projets et une coordination
fluide entre les membres. Ces cérémonies, qui rythment notre travail quotidien, sont sou-
tenues par la plateforme iObeya, optimisant ainsi chaque étape du processus agile.

• Planification des Sprints : La planification des sprints [2] est une réunion clé
où l’équipe Scrum détermine le travail à réaliser au cours du prochain sprint. Au
sein de mon équipe On-prem, notre réunion de sprint-planning dure une heure où
toute l’équipe se réunit sur site. Nous utilisons au cours de cette réunion le tableau
Team Board de iObeya dans lequel des cartes dites ”Story” sont insérer et les ”Story
points”[3], des unités de mesure qui permettent d’estimer l’effort global nécessaire
pour implémenter intégralement une tâche du backlog produit, sont fixés. Cette
carte est illustrée dans la figure 1.5.

Figure 1.5 : La carte story de iObeya

9
Chapitre 1. Cadre général du projet 1.3. Méthodologie de développement

Les figures 1.6, 1.7 , 1.8 et 1.9illustrent les planifications détaillées des sprints pour
mon projet, segmentées en plusieurs itérations. Chaque itération couvre une période
spécifique, permettant une gestion agile et itérative du projet.

– Itération 1 (1er février - 21 février) : Cette première itération est dédiée à

l’onboarding et à la formation sur le produit iObeya ainsi que sur les outils ETL
existants. L’objectif est de maı̂triser les technologies qui seront utilisées tout
au long du projet et de se familiariser avec les processus de gestion des données
ainsi qu’avec le fonctionnement d’iObeya, afin de garantir une compréhension
commune des enjeux du projet.

– Itération 2 (22 février - 13 mars) : L’objectif principal de cette itération

est l’analyse des patterns dans les fichiers de logs générés par le système. J’ai
développé des parsers pour structurer les données brutes, facilitant ainsi les
prochaines étapes de traitement. Une compréhension approfondie des logs est
essentielle pour créer des pipelines de traitement adaptés et fiables.

Figure 1.6 : Aperçu de planification des sprints 1 et 2 avec leur story points

10
Chapitre 1. Cadre général du projet 1.3. Méthodologie de développement

– Itération 3 (14 mars - 3 avril) : Cette itération se concentre exclusivement

sur la configuration et le test de Kafka dans l’environnement iObeya. L’objectif
est de s’assurer que le système est capable de gérer efficacement la collecte et la
transmission des logs générés par les différentes composantes de l’application.
Cela inclut la mise en place des brokers et des topics nécessaires pour garantir
un flux de données continu et sans perte.
– Itération 4 (4 avril - 24 avril) : L’itération 4 est dédiée à la configu-
ration de Spark et à la mise en place de services de traitement par lot. Ces
services sont responsables du traitement des différentes données (logs d’erreurs
et logs d’activité). L’objectif est de configurer Spark pour traiter efficacement
les données en temps réel et en lots, ce qui permettra de transformer les logs
en informations exploitables.

– Itération 5 (25 avril - 15 mai) : Durant cette itération, j’ai développé

des API pour stocker et lire les données depuis Elasticsearch. Cela permet de
garantir que toutes les données traitées soient centralisées dans une base de
données optimisée pour la recherche et l’analyse, facilitant l’accès aux données
en temps réel. La performance de lecture et d’écriture dans Elasticsearch est
un point clé à valider dans cette phase.

Figure 1.7 : Aperçu de planification des sprints 3 et 4 avec leur story points

11
Chapitre 1. Cadre général du projet 1.3. Méthodologie de développement

– Itération 6 (16 mai - 5 juin) : Cette itération se concentre sur la mise en

place de l’interface utilisateur du tableau de bord en utilisant le framework
React. Cette interface doit être interactive et permettre aux utilisateurs de
visualiser les données en temps réel, avec une présentation claire des métriques
clés et des logs d’erreur. Les différents composants du tableau de bord doivent
être conçus pour s’adapter aux besoins de supervision.

– Itération 7 (6 juin - 26 juin) : L’intégration des API dans le tableau de

bord est au cœur de cette itération. Il s’agit de connecter les services backend
(Kafka, Spark, Elasticsearch) à l’interface React pour rendre le tableau de bord
dynamique et interactif. L’objectif est de permettre une visualisation en temps
réel des logs et des métriques, tout en garantissant une expérience utilisateur
fluide et réactive.

Figure 1.8 : Aperçu de planification des sprints 5, 6 et 7 avec leur story points

12
Chapitre 1. Cadre général du projet 1.3. Méthodologie de développement

– Itération 8 (27 juin - 17 juillet) : Cette itération se focalise sur la recherche

et la lecture de travaux académiques concernant la classification des erreurs via
des modèles d’intelligence artificielle, notamment dans le cadre des modèles de
traitement automatique du langage (NLP). L’équipe doit explorer les modèles
potentiellement applicables aux données de logs et évaluer leur pertinence pour
une classification efficace des erreurs dans l’environnement iObeya.

– Itération 9 (18 juillet - 31 juillet) : L’itération finale combine le fine-

tuning d’un modèle d’intelligence artificielle pour la classification des logs et son
intégration dans le tableau de bord. Une API sera développée pour exposer ce
modèle, permettant au tableau de bord d’interagir avec l’IA en temps réel. Une
popup sera ajoutée à l’interface React, offrant aux utilisateurs des prédictions
sur les erreurs détectées ainsi que des suggestions d’actions correctives, incluant
les jobs à lancer pour résoudre ces erreurs. Cette phase marque l’intégration
complète du modèle d’IA dans le système de supervision.

Figure 1.9 : Aperçu de planification des sprints 8 et 9 avec leur story points

13
Chapitre 1. Cadre général du projet 1.4. Étude de l’existant

• Réunions quotidiennes (Daily Scrum) : Les réunions quotidiennes [2] per-

mettent à l’équipe de se synchroniser et de planifier les prochaines 24 heures. Pour ce
faire, nous utilisons un deuxième tableau du produit iObeya appelé Kanban board.
Ce tableau nous permet de suivre les tâches de l’équipe.
Le tableau Kanban relatif à mon projet est illustré ci-dessus par la figure 1.10 .

Figure 1.10 : Tableau de progression des taches du projet Healthcheck

• Rétrospective (Rétro) : À la fin de chaque sprint, nous organisons une rétrospective

où l’équipe Scrum examine son propre fonctionnement et ses pratiques afin d’iden-
tifier ce qui a bien fonctionné, ce qui n’a pas fonctionné et ce qui peut être amélioré
pour le prochain sprint. La figure 4.9 dans l’annexe présente l’un des panneaux
permettant de mener la session rétrospective.

• Sprint Démo (Sprint Review) : À la fin de chaque sprint, l’équipe organise

une Sprint Démo. Cette réunion a pour but de présenter le travail accompli durant
le sprint. La réunion est enregistrée pour pouvoir diffuser les nouveautés à ceux
que cela pourrait intéresser. La figure 4.10 dans l’annexe montre un panneau de ma
première Sprint Démo.

• Synchro Dev (Synchronisation des Développeurs) : En plus des cérémonies

classiques de Scrum, notre équipe intègre des sessions de Synchronisation des Développeurs
(Synchro Dev). Ces réunions informelles se tiennent deux fois par mois pour per-
mettre aux développeurs de discuter en profondeur des problèmes techniques, de par-
tager des connaissances et de coordonner leurs efforts sur des tâches interdépendantes.

1.4 Étude de l’existant

Cette section fournit une analyse détaillée du système actuel de supervision de la pla-
teforme iObeya, en mettant en lumière les outils et processus en place. Ensuite, nous

14
Chapitre 1. Cadre général du projet 1.4. Étude de l’existant

examinerons les outils de supervision disponibles sur le marché, en comparant leurs fonc-
tionnalités et en évaluant leur pertinence par rapport aux besoins spécifiques de la plate-
forme iObeya.

1.4.1 Systèmes de supervision actuels chez iObeya Online

iObeya Online a mis en place un système de supervision avancé pour assurer la per-
formance, la sécurité, et la disponibilité continue de ses services. L’outil principal utilisé
pour cette supervision est Datadog, une plateforme moderne de monitoring et d’analytics
conçue pour les environnements cloud.

Datadog offre une visibilité complète sur l’ensemble des infrastructures et applications
d’iObeya Online comme ilustré par la figure 1.11 et 1.12. Grâce à ses capacités d’intégration
avec diverses technologies, il permet de surveiller en temps réel les performances des ser-
veurs, des bases de données, et des applications, ainsi que de détecter les anomalies po-
tentielles avant qu’elles n’impactent les utilisateurs finaux.

Les principales fonctionnalités de Datadog, telles que le monitoring des logs, des métriques,
et des traces, sont essentielles pour maintenir une qualité de service élevée. En effet, Da-
tadog collecte, analyse, et visualise des données provenant de différentes sources, offrant
ainsi une vue unifiée de l’état du système. Cette capacité à centraliser les informations
permet aux équipes techniques de réagir rapidement en cas de problème, réduisant ainsi
le temps de résolution et minimisant les interruptions de service.

Figure 1.11 : Exemple d’une interface des logs affichés en temps réel dans Datadog pour
l’un des clients

En plus du monitoring classique, iObeya Online utilise également Datadog pour la ges-
tion des alertes. Les seuils critiques sont définis pour divers indicateurs de performance,

15
Chapitre 1. Cadre général du projet 1.4. Étude de l’existant

et des notifications sont envoyées automatiquement aux équipes concernées en cas de

dépassement. Cela permet une intervention rapide et préventive, garantissant ainsi une
disponibilité maximale du service.

Enfin, Datadog contribue également à l’amélioration continue des services d’iObeya Online
en fournissant des insights précieux sur les tendances d’utilisation et les performances his-
toriques. Ces analyses permettent d’anticiper les besoins futurs, d’optimiser les ressources,
et de planifier les évolutions de l’infrastructure en fonction des exigences croissantes des
utilisateurs.

Ainsi, grâce à Datadog, iObeya Online s’assure de maintenir un niveau de supervision

élevé, crucial pour la satisfaction de ses clients et le bon fonctionnement de ses opérations
quotidiennes.

Figure 1.12 : Exemple d’une interface des métriques affichées dans Datadog pour l’un
des clients

1.4.2 Systèmes de supervision actuels chez iObeya On-prem

Pour iObeya On-prem, la situation de supervision est quelque peu différente par rap-
port à iObeya Online. En effet, bien que Datadog soit un outil de choix pour la supervision
des environnements cloud et soit largement utilisé par iObeya Online pour ses capacités
étendues en monitoring et en gestion des alertes, son intégration avec des environnements
on-premises, comme celui de iObeya On-prem, présente des défis spécifiques.

L’un des principaux obstacles à l’utilisation de Datadog dans un contexte on-premise

est lié à la nature même des déploiements sur site. Les environnements on-premises, par
définition, ne disposent pas de la même flexibilité et des mêmes capacités d’intégration
que les environnements cloud. Datadog, étant optimisé pour des environnements cloud

16
Chapitre 1. Cadre général du projet 1.4. Étude de l’existant

et des architectures basées sur des services, requiert souvent des configurations et des
intégrations spécifiques qui ne sont pas toujours compatibles avec les systèmes sur site ou
qui peuvent nécessiter des ajustements importants.
Ainsi, pour répondre efficacement aux besoins de supervision d’iObeya On-prem, il est
essentiel d’explorer des solutions conçues pour les environnements sur site, permettant
une intégration fluide et une gestion optimale des systèmes locaux tout en respectant les
contraintes spécifiques du déploiement on-premises.

Les tableaux de bord actuellement en place fournissent des visualisations des données
collectées par des outils tels que Prometheus et Grafana. Ces tableaux de bord incluent
des graphiques et des indicateurs de performance tels que :

• Temps moyen d’utilisation des services : Affiche l’utilisation des ressources du

serveur SQL, y compris la charge CPU, l’utilisation de la mémoire et les opérations
de lecture/écriture.

• Taux d’utilisation de la JVM : Affiche l’utilisation des ressources du serveur Ca-

talina, y compris la charge CPU, l’utilisation de la mémoire et les opérations de
lecture/écriture, le Garbage collector,...

Cependant, malgré ces outils de surveillance avancés, plusieurs aspects restent à améliorer
pour une gestion plus complète et efficace du système On-prem :

• Collecte des Logs : Actuellement, les logs générés par les services et applications
ne sont pas intégrés dans les tableaux de bord de supervision. Il est nécessaire de
mettre en place une solution pour collecter, centraliser et analyser les logs afin
d’améliorer la détection des anomalies et la gestion des incidents.

• Alertes et Notifications : Les alertes basées sur les métriques sont limitées et
nécessitent une personnalisation plus fine pour couvrir tous les scénarios critiques.
L’intégration d’un système d’alerte plus sophistiqué permettrait de mieux réagir aux
incidents et de prévenir les pannes potentielles.

• Tableaux de Bord Dynamiques : Les tableaux de bord actuels offrent une vue
statique des données. L’ajout de fonctionnalités dynamiques telles que la personna-
lisation en temps réel et l’interaction avec les données permettrait une analyse plus
approfondie et une réponse plus rapide aux problèmes.

• Intégration et Automatisation : L’intégration des outils de supervision avec

les processus de déploiement et de gestion permettrait une automatisation accrue,
réduisant ainsi le besoin d’interventions manuelles et améliorant l’efficacité opérationnelle.

En adressant ces lacunes, iObeya pourra améliorer la surveillance de ses systèmes On-
premises et garantir une gestion plus proactive et réactive des infrastructures locales.

17
Chapitre 1. Cadre général du projet 1.4. Étude de l’existant

1.4.3 Les outils de supervision sur le marché

Plusieurs outils de supervision sont disponibles pour la gestion des métriques, des
logs et des alertes dans les systèmes On-prem, tels que Prometheus, Grafana et ELK
(Elasticsearch, Logstash, Kibana).

Prometheus et Grafana offrent ensemble une solution complète de surveillance des

métriques. Prometheus collecte et stocke les données temporelles, tandis que Grafana
permet leur visualisation. Cependant, ces outils sont limités aux métriques et ne gèrent
pas efficacement les logs ou les métriques personnalisées.

ELK, quant à lui, est idéal pour la gestion des logs. Elasticsearch assure la recherche
et l’analyse, Logstash collecte et transforme les données, et Kibana offre des visualisa-
tions interactives. Toutefois, ELK peut manquer d’intégration fluide avec les systèmes de
métriques et de personnalisation.

Malgré leurs capacités respectives, aucun de ces outils ne fournit une solution complète
intégrant à la fois des métriques détaillées, des logs, et des capacités de personnalisation
des métriques adaptées aux besoins spécifiques d’iObeya On-prem. Pour combler cette
lacune, il devient nécessaire de développer un système de supervision intégré qui combine
les forces de ces outils tout en répondant aux exigences uniques de l’environnement On-
prem d’iObeya.

C’est dans ce contexte que le système de supervision personnalisé, appelé Healthcheck,

entre en jeu. Healthcheck a été conçu pour offrir une solution complète et intégrée, capable
de gérer non seulement les métriques et les logs, mais aussi de fournir des métriques per-
sonnalisées adaptées aux besoins spécifiques de l’entreprise. En combinant les meilleures
fonctionnalités des outils existants tout en surmontant leurs limitations, Healthcheck vise
à offrir une vue d’ensemble cohérente et adaptée à la réalité de la supervision On-prem.

Table 1.1 : Comparaison des outils de supervision On-prem

Fonctionnalités Prometheus ELK Healthcheck

& Grafana (Elasticsearch, (solution
Logstash, personnalisée)
Kibana)
Surveillance des ✓ ✗ ✓
métriques
Gestion des logs ✗ ✓ ✓
Visualisations interac- ✓ ✓ ✓
tives
Personnalisation des ✗ ✗ ✓
métriques

18
Chapitre 1. Cadre général du projet 1.4. Étude de l’existant

Conclusion
Ce chapitre a présenté iObeya, son organisation et ses activités, ainsi que le projet
et ses objectifs d’amélioration des systèmes de supervision. La méthodologie Scrum a
été décrite, ainsi que l’état des solutions de supervision actuelles chez iObeya et sur le
marché. Dans le chapitre suivant, nous procédons à l’identification des besoins identifiés
ainsi qu’une analyse générale du système.

19
 CHAPITRE 2

Analyse et spécification des besoins

Introduction
Au niveau de ce chapitre, je procède à l’étude de l’existant, puis je détaillerai les
différents besoins fonctionnels et non fonctionnels afin d’analyser correctement les problèmes
à résoudre. Je clôturai enfin par les cas d’utilisation.

2.1 Capture des besoins

Cette section décrit les besoins fonctionnels et non fonctionnels du projet en recueillant,
analysant et formalisant les attentes et exigences des parties prenantes afin de s’assurer
que le produit final répondra pleinement aux besoins identifiés.

2.1.1 Acteur de l’application

L’application est conçue avec un modèle d’interaction simple, impliquant un unique
acteur. Cet acteur, que nous nommons Utilisateur, n’est soumis à aucune catégorisation
particulière ni à des rôles complexes. Son interaction avec l’application est directe et
unifiée, ce qui permet de simplifier à la fois l’expérience utilisateur et la gestion des accès.
Le choix de n’avoir qu’un seul type d’acteur résulte d’une volonté de rendre l’applica-
tion accessible et facile à utiliser. Ainsi, l’utilisateur peut effectuer l’ensemble des actions
prévues par l’application sans avoir à passer par un processus de gestion de rôles ou de
droits d’accès spécifiques. Cette approche est particulièrement adaptée aux environne-
ments où la simplicité et la rapidité d’accès sont prioritaires, sans que cela n’impacte les
fonctionnalités essentielles.

20
Chapitre 2. Analyse et spécification des besoins 2.1. Capture des besoins

2.1.2 Besoins fonctionnels

Afin de garantir une solution de supervision efficace et adaptée aux besoins spécifiques
d’iObeya On-prem, il est essentiel de définir clairement les exigences fonctionnelles du
système. Ces besoins détermineront les capacités fondamentales de la plate-forme, en
assurant une gestion optimisée des utilisateurs, la collecte et l’analyse des données, ainsi
que la visualisation des informations critiques.

• Extraire les informations système relatives à la plate-forme iObeya : Les

administrateurs et les développeurs doivent pouvoir consulter toutes les informations
statiques concernant iObeya et ses plugins. Cela inclut des données telles que les
configurations du système, les versions des logiciels, et les détails sur les composants
installés. Cette fonctionnalité est essentielle pour une gestion efficace des ressources
et pour s’assurer que la plate-forme est correctement configurée et mise à jour.

• Extraire les métriques : L’utilisateur doit avoir une visibilité claire sur l’utilisa-
tion des ressources à travers des graphiques et des tableaux de bord. Les métriques
clés incluent l’utilisation de la CPU, la mémoire, et les opérations de lecture/écriture.
Cette fonctionnalité permet de surveiller en temps réel les performances du système,
d’identifier les goulets d’étranglement, et de prendre des mesures pro actives pour
éviter les problèmes de performance. L’utilisateur doit aussi avoir accès aux métriques
relatives aux tâches lancées manuellement ou programmées sur la plate-forme iO-
beya. Cela inclut des informations telles que le temps d’exécution, la fréquence des
tâches, et les résultats obtenus. Cette fonctionnalité permet d’évaluer la performance
des tâches, d’optimiser les processus opérationnels, et de garantir que les tâches sont
exécutées efficacement et conformément aux attentes.

• Extraire les journaux : L’utilisateur doit pouvoir consulter les actions se

déroulant sur la plateforme iObeya en temps réel. Les journaux doivent inclure
des informations sur les opérations effectuées, les accès utilisateur, les modifications
apportées ainsi que les erreurs rencontrées. Cette fonctionnalité est cruciale pour
garantir une traçabilité complète des activités et des erreurs, permettant une ana-
lyse approfondie des événements et la résolution des problèmes. L’utilisateur doit
aussi être en mesure de consulter les erreurs qui se produisent sur la plate-forme
iObeya en temps réel. Les journaux d’erreur doivent fournir des détails sur la nature
des erreurs, les messages d’erreur, et les contextes dans lesquels elles se produisent.
En outre, il est nécessaire de pouvoir lancer des actions correctives directement de-
puis les journaux d’erreur pour résoudre rapidement les problèmes et maintenir la
continuité du service.

• Identifier les types d’erreurs : Afin de faciliter la gestion des erreurs, le système
doit être capable de catégoriser les différents types d’erreurs rencontrées sur la plate-
forme iObeya. Cette fonctionnalité doit permettre de classer les erreurs en catégories
telles que les erreurs de configuration, les erreurs liées aux ressources, les erreurs
d’application, et les erreurs de sécurité. En identifiant les types d’erreurs, les admi-
nistrateurs et les développeurs peuvent mieux comprendre les causes sous-jacentes

21
Chapitre 2. Analyse et spécification des besoins 2.1. Capture des besoins

des problèmes, prioriser les actions correctives, et mettre en place des stratégies
préventives pour minimiser la récurrence des erreurs. Une classification précise des
erreurs permet également d’améliorer la documentation et le support technique, en
facilitant la recherche de solutions adaptées et en optimisant le temps de résolution
des problèmes.

• Lancer des actions correctives : Le système doit offrir la possibilité de lancer

manuellement des actions correctives lorsque des anomalies sont détectées. Ces ac-
tions peuvent inclure la ré-initialisation des services, l’application de correctifs, la
modification de configurations, ou la relance de tâches programmées. La capacité à
initier des actions correctives directement depuis les journaux d’erreurs ou les alertes
de performance est essentielle pour garantir une réponse rapide aux problèmes,
réduire le temps d’indisponibilité, et améliorer la fiabilité de la plate-forme iObeya.

2.1.3 Besoins non fonctionnels

En complément des besoins fonctionnels, il est également essentiel de prendre en
compte les besoins non fonctionnels qui garantiront la robustesse, la sécurité, et la per-
formance globale du système de supervision d’iObeya On-prem. Ces exigences définissent
les critères de qualité auxquels le système doit répondre pour assurer une expérience uti-
lisateur optimale et une fiabilité à long terme. Les exigences non fonctionnelles de notre
projet sont présentées comme suit :

• L’ergonomie :Le système doit fournir aux utilisateurs des interfaces ergono-
miques et conviviales. Nous avons mis en place un design axé sur l’utilisateur avec
des interfaces épurées et des graphiques interactifs. Par exemple, les chartes des
métriques sont conçues pour être lisibles et personnalisables, permettant aux uti-
lisateurs de visualiser rapidement l’état des ressources du système. De plus, les
boutons d’action sont positionnés de manière stratégique pour faciliter la prise de
décisions rapides.

• Maintenabilité : Le système doit être facilement maintenable pour permettre

l’évolution du tableau de bord avec l’ajout de nouvelles fonctionnalités. Pour cela,
j’ai adopté une architecture modulaire qui facilite l’intégration de nouveaux modules
sans perturber les fonctionnalités existantes. Par exemple, le système permet l’ajout
de nouvelles métriques ou l’intégration de plugins supplémentaires avec un minimum
d’effort, garantissant ainsi une évolution continue du produit.

• Performance : Le système doit offrir des temps de réponse rapides et une faible
latence lors de l’accès aux données et aux fonctionnalités. Pour garantir cette per-
formance, nous avons mis en place une architecture en temps réel basée sur des
pipelines qui traitent les données instantanément à travers des topics dédiés. Cela
permet aux utilisateurs d’accéder aux métriques, journaux, et autres informations
de manière quasi instantanée, assurant ainsi une réactivité optimale du système,
même en cas de forte charge.

22
Chapitre 2. Analyse et spécification des besoins 2.2. Analyse de besoins

2.2 Analyse de besoins

Cette section a pour objectif de décrire les grandes lignes de la conception générale, en
s’appuyant sur des diagrammes d’utilisation globale et d’activité pour illustrer comment
les différents éléments du système interagissent et collaborent pour atteindre les objectifs
définis dans les besoins fonctionnels et non fonctionnels.

2.2.1 Diagramme de cas d’utilisation général

Le diagramme des cas d’utilisation montre les différentes fonctionnalités nécessaires au
produit. Je présente à travers la figure 2.1 une vue globale du comportement fonctionnel
de mon application.

Figure 2.1 : Diagramme de cas d’utilisation général

23
Chapitre 2. Analyse et spécification des besoins 2.2. Analyse de besoins

Description textuelle des cas d’utilisation

• Cas d’utilisation : Consulter les données du système iObeya
Pré conditions

– Le système Healthcheck est en fonctionnement.

– L’application iObeya est en fonctionnement.
– L’utilisateur est authentifié et possède les droits nécessaires pour consulter les
données du système.

Scénario nominal

Acteur (Utilisateur) Système Healthcheck

1.1. L’utilisateur accède à l’interface de
consultation des données du système
iObeya.
2. Le système affiche les données dispo-
nibles (état des services, configuration
système, etc.).
3. L’utilisateur sélectionne la catégorie
de données à consulter.
4. Le système récupère et affiche les
données correspondant à la sélection de
l’utilisateur.

Table 2.1 : Scénario nominal du CU Consulter les données du système iObeya

Enchaı̂nements alternatifs

A1 : Erreur d’accès aux données : Si une erreur se produit lors de la récupération

des données, le système affiche un message d’erreur à l’utilisateur.
A2 : Utilisateur sans droits suffisants : Si l’utilisateur ne dispose pas des droits
nécessaires pour consulter certaines données, le système lui affiche un mes-
sage d’avertissement précisant qu’il n’a pas l’autorisation pour accéder à ces
informations.

Post-condition
L’utilisateur a consulté les données du système iObeya en temps réel.

• Cas d’utilisation : Visualiser les métriques en temps réel

Pré-conditions

– Le système Healthcheck est en fonctionnement.

– L’application iObeya est en fonctionnement.
– L’utilisateur est authentifié.

24
Chapitre 2. Analyse et spécification des besoins 2.2. Analyse de besoins

– Les métriques sont disponibles et mises à jour en temps réel.

Scénario nominal

Acteur (Utilisateur) Système Healthcheck

1. L’utilisateur accède à un interface
qui concerne des métriques.
2. Le système affiche un tableau de bord
contenant les métriques en temps réel.
5. L’utilisateur consulte les graphiques 6. Le système actualise les gra-
et analyse les performances reliées à ces phiques périodiquement pour afficher
chartes. les données les plus récentes.

Table 2.2 : Scénario nominal du CU Visualiser les métriques en temps réel

Enchaı̂nements alternatifs

A1 : Métriques non disponibles : Si les métriques ne sont pas disponibles, le système

affiche les chartes à l’utilisateur jusqu’au dernière disponibilité de ces métriques.

Post-condition
L’utilisateur a visualisé les métriques du système iObeya en temps réel.

• Cas d’utilisation : Consulter les journaux en temps réel

Pré conditions

– Le système iObeya est en fonctionnement.

– L’utilisateur est authentifié.
– Les journaux doivent être accessibles et disponibles en temps réel.

Scénario nominal

Acteur (Utilisateur) Système Healthcheck

1. L’utilisateur accède à l’interface des
journaux en temps réel.
2. Le système affiche les journaux
récents avec les informations de times-
tamp, niveau de gravité, et message.

Table 2.3 : Scénario nominal du CU Consulter les journaux en temps réel

Enchaı̂nements alternatifs

A1 : Journaux non disponibles : Si les journaux ne sont pas disponibles, le système

informe l’utilisateur que les données ne peuvent pas être récupérées pour le
moment.

25
Chapitre 2. Analyse et spécification des besoins 2.2. Analyse de besoins

Post-condition
L’utilisateur a consulté les journaux en temps réel.

• Cas d’utilisation : Identifier les types d’erreurs

Pré conditions

– L’utilisateur a accès aux journaux en temps réel.

– L’utilisateur doit avoir accès aux outils d’analyse d’erreurs.

Scénario nominal

Acteur (Utilisateur) Système Healthcheck

1. L’utilisateur accède à l’interface de
gestion des erreurs.
2. Le système affiche un aperçu des er-
reurs détectées dans les journaux en
temps réel.
3. L’utilisateur sélectionne une erreur
pour obtenir plus de détails sur le type
d’erreur.
4. Le système affiche les détails de l’er-
reur, y compris son type prédit (erreur
de base de données, erreur d’authenti-
fication, etc.).

Table 2.4 : Scénario nominal du CU Identifier les types d’erreurs

Enchaı̂nements alternatifs

A1 : Aucun type d’erreur identifiable : Si le système ne peut pas identifier le type

d’erreur, un message indique à l’utilisateur qu’il est nécessaire d’effectuer une
analyse manuelle plus poussée.

Post-condition
L’utilisateur a identifié le type d’erreur rencontré dans le système en temps réel.

• Cas d’utilisation : Lancer des actions correctives pour les erreurs

Pré conditions

– Une ou plusieurs erreurs doivent avoir été identifiées.

– Des actions correctives doivent être définies et prêtes à être exécutées.

Scénario nominal

26
Chapitre 2. Analyse et spécification des besoins 2.2. Analyse de besoins

Acteur (Utilisateur) Système Healthcheck

1. L’utilisateur sélectionne une erreur
spécifique et choisit ”Lancer des actions
correctives”.
2. Le système propose une liste d’ac-
tions correctives disponibles en fonc-
tion du type d’erreur identifié.
3. L’utilisateur sélectionne une action
corrective à lancer.
4. Le système exécute l’action correc-
tive choisie et informe l’utilisateur de
l’état d’avancement.

Table 2.5 : Scénario nominal du CU Lancer des actions correctives pour les erreurs

Enchaı̂nements alternatifs

A1 : Action corrective échouée : Si l’action corrective échoue, le système affiche

un message d’erreur indiquant l’échec de l’opération et propose une nouvelle
tentative ou une action alternative.

Post-condition
L’utilisateur a lancé avec succès une ou plusieurs actions correctives pour résoudre
les erreurs détectées.

Diagramme cas d’utilisation relative à la CU ”Visualiser les métriques en

temps réel”
L’utilisateur dispose d’une interface qui lui permet de suivre en temps réel l’évolution
des différentes métriques générées par le système comme illustré par la figure 2.2. Cette
fonctionnalité lui offre une vision globale de l’état de l’infrastructure et des services as-
sociés. L’utilisateur peut choisir de visualiser les métriques systèmes, telles que l’utilisation
du CPU, de la mémoire ou encore de la bande passante réseau, afin de vérifier la perfor-
mance globale du système. De plus, il peut également visualiser les métriques des tâches
programmées pour surveiller l’exécution et les performances des tâches périodiques ou
automatiques, en analysant leur temps d’exécution, leur succès ou leur échec. Cette vue
instantanée permet de réagir rapidement aux éventuels dysfonctionnements ou surcharges.

27
Chapitre 2. Analyse et spécification des besoins 2.2. Analyse de besoins

Figure 2.2 : Diagramme cas d’utilisation relative à la CU ”Visualiser les métriques en

temps réel”

Description textuelle des cas d’utilisations

• Cas d’utilisation : Visualiser les métriques systèmes
Pré conditions

– L’application iObeya est en fonctionnement

– Le système Healthcheck est en fonctionnement.
– L’utilisateur est authentifié.
– Les métriques du système sont disponibles en temps réel.

Scénario nominal

28
Chapitre 2. Analyse et spécification des besoins 2.2. Analyse de besoins

Acteur (Utilisateur) Système Healthcheck

1. L’utilisateur accède à l’interface des
métriques systèmes.
2. Le système affiche les métriques clés
du système (utilisation CPU, RAM, ..).
3. L’utilisateur consulte les métriques
et peut les surveiller en temps réel.
4. Le système met à jour les métriques
de manière continue en fonction des
nouvelles données.

Table 2.6 : Scénario nominal du CU Visualiser les métriques systèmes

Enchaı̂nements alternatifs

A1 : Métriques systèmes indisponibles : Si les données des métriques systèmes ne

peuvent pas être récupérées, le système affiche un message indiquant que les
données sont temporairement inaccessibles.

Post-condition
L’utilisateur a consulté les métriques systèmes mises à jour en temps réel.

• Cas d’utilisation : Visualiser les métriques des tâches programmées

Pré conditions

– L’application iObeya est en fonctionnement

– Le système Healthcheck est en fonctionnement.
– L’utilisateur est authentifié.
– Des tâches programmées sont définies et ont été lancées et les métriques as-
sociées sont disponibles.

Scénario nominal

29
Chapitre 2. Analyse et spécification des besoins 2.2. Analyse de besoins

Acteur (Utilisateur) Système Healthcheck

1. L’utilisateur accède à l’interface des
métriques des tâches programmées.
2. Le système affiche les métriques
spécifiques aux tâches programmées
(durée d’exécution, stockage utilisé,
etc.).
3.3. L’utilisateur consulte les différentes
métriques des tâches programmées.
4. Le système met à jour ces métriques
à chaque nouvelle exécution d’une
tâche programmée.

Table 2.7 : Scénario nominal du CU visualiser les métriques des tâches programmées

Enchaı̂nements alternatifs

A1 : Métriques des tâches programmées indisponibles

Si les métriques des tâches programmées ne sont pas disponibles, les chartes
relatifs à ces métriques restent figées jusqu’au dernier instant de récupération
des données disponibles.

Post-condition
L’utilisateur a visualisé les métriques des tâches programmées et surveille leur
évolution.

Diagramme cas d’utilisation relative à la CU ”Visualiser les journaux en temps

réel”
L’utilisateur a la possibilité d’accéder à une interface qui affiche en temps réel les
différents journaux générés par le système, à savoir les journaux d’activité et les journaux
d’erreur comme le montre la figure 2.3. Cette fonctionnalité permet à l’utilisateur d’obtenir
une vue instantanée de l’état du système. L’utilisateur peut, à tout moment, choisir de
consulter les journaux d’activité pour suivre les actions exécutées par les utilisateurs et les
événements courants, ou de consulter les journaux d’erreur pour repérer et diagnostiquer
rapidement les incidents techniques qui surviennent.

Description textuelle des cas d’utilisations

• Cas d’utilisation : Consulter les journaux d’activité
Pré conditions

– Le système Healthcheck est en fonctionnement.

– L’utilisateur est authentifié.
– Les journaux d’activité sont collectés et accessibles en temps réel.

30
Chapitre 2. Analyse et spécification des besoins 2.2. Analyse de besoins

Figure 2.3 : Diagramme cas d’utilisation relative à la CU ”Visualiser les journaux

métriques en temps réel”

Scénario nominal

Acteur (Utilisateur) Système Healthcheck

1. L’utilisateur accède à l’interface des
journaux d’activité.
2. Le système récupère et affiche les
journaux d’activité (ex. actions des uti-
lisateurs, événements système non cri-
tiques).
3. L’utilisateur consulte les journaux
d’activité affichés.
4. Le système met à jour les journaux
d’activité en temps réel à mesure que
de nouvelles actions sont enregistrées.

Table 2.8 : Scenario nominal du CU Consulter les journaux d’activité

Enchaı̂nements alternatifs

A1 : Journaux d’activité indisponibles : Si les journaux d’activité ne peuvent pas

être récupérés, les dernières activités récupérées restent affichées.

Post-condition

31
Chapitre 2. Analyse et spécification des besoins 2.2. Analyse de besoins

L’utilisateur a visualisé les journaux d’activité en temps réel et peut les surveiller.

• Cas d’utilisation : Consulter les journaux d’erreur

Pré conditions

– Le système Healthcheck est en fonctionnement.

– L’utilisateur est authentifié.
– Les journaux d’erreur sont collectés suite à un déclenchement d’erreur.

Scénario nominal

Acteur (Utilisateur) Système Healthcheck

1. L’utilisateur accède à l’interface des
journaux d’erreur.
2. Le système récupère et affiche les
journaux d’erreur (ex. erreurs d’appli-
cation, anomalies critiques).
3. L’utilisateur consulte les journaux
d’erreur affichés.
4. Le système met à jour les journaux
d’erreur en temps réel à mesure que de
nouvelles erreurs sont générées.

Table 2.9 : Scénario nominal du CU Consulter les journaux d’erreur

Enchaı̂nements alternatifs

A1 : Journaux d’erreur indisponibles : Si les journaux d’erreur sont inaccessibles,

les erreurs les plus récents sont affichées.

Post-condition
L’utilisateur a consulté les journaux d’erreur en temps réel et peut surveiller les
nouvelles erreurs.

2.2.2 Diagramme d’activité général

Le diagramme d’activité général illustre le flux de travail et les processus métier
supportés par le système. Il aide à comprendre les étapes nécessaires pour accomplir
chaque tâche et à identifier les points de décision et les interactions entre les activités. La
figure 2.4 ci-après illustre le diagramme relatif aux activités du Healthcheck.

32
 Chapitre 2. Analyse et spécification des besoins 2.2. Analyse de besoins

Figure 2.4 : Diagramme d’activité relatif au fonctionnement général du Healthcheck

Chemin 1 : lorsque l’application iObeya est démarrée, elle expose les métriques relatives à l’in-
frastructure, comme l’utilisation des ressources du système. Ces métriques sont en-
suite envoyées vers Prometheus, une plateforme de surveillance qui collecte et stocke
les données de performance. Ce processus permet de suivre en temps réel l’état de
l’infrastructure et de réagir rapidement en cas de défaillances ou de surcharges dans
le système.

Chemin 2 : Parallèlement au fonctionnement de l’application, iObeya génère en continu des

journaux qui retracent à la fois les activités du système et les erreurs rencontrées.
Les journaux d’erreur sont immédiatement injectés dans un topic dédié pour un
traitement plus approfondi. Une fois traités, ces journaux sont persistés dans un
index d’erreur, où ils sont stockés de manière permanente pour faciliter les futures
analyses et la génération de rapports sur les incidents. De leur côté, les journaux
d’activité, qui reflètent les actions des utilisateurs et du système, sont également
injectés dans un topic spécifique. Ces journaux sont ensuite extraits, uniformisés,
et filtrés afin d’assurer une cohérence dans le format et de ne conserver que les
informations pertinentes. Après filtration, les messages sont reformulés pour être

33
 Chapitre 2. Analyse et spécification des besoins 2.2. Analyse de besoins

plus clairs et compréhensibles, puis stockés dans un index d’activité où ils pourront
être consultés pour des audits ou des rapports sur l’utilisation du système.

Chemin 3 : L’application iObeya permet d’exposer les informations systèmes statiques qui sont
essentielles pour le suivi et la gestion de la plateforme. Ces informations incluent,
par exemple, l’état de la base de données, les plugins activés, les détails de la licence
utilisée, ainsi que d’autres métadonnées importantes. Ces données sont ensuite ren-
dues accessibles via des APIs de lecture pour être consultées en temps réel par des
administrateurs ou des systèmes de supervision

Une fois que les tous ces données ont été traitées et stockées, le système expose des
APIs de lecture. Ces APIs permettent à d’autres applications ou services d’accéder aux
données de journaux et aux métriques de manière efficace et sécurisée. Ces informations
sont ensuite consommées dans un dashboard en temps réel, offrant ainsi une vue claire
et actualisée de l’état du système. Le tableau de bord permet aux administrateurs de
superviser les performances, d’identifier rapidement les erreurs, et de prendre les mesures
nécessaires pour assurer le bon fonctionnement de l’application.

Conclusion
Dans ce chapitre, j’ai présenté les besoins fonctionnels et non fonctionnels de la solution
proposée, le diagramme de cas d’utilisation global ainsi que sa description textuelle. En
outre, j’ai exposées les flux de données à travers un diagramme d’activité relatifs à notre
application. Le chapitre suivant étudiera le côté architectural et technique de la solution.

34
 CHAPITRE 3

Conception

Introduction
Dans ce chapitre, le choix de l’architecture de l’application et de ses composants sera
d’abord justifié. Ensuite, la conception générale sera élaborée, et enfin, la conception
détaillée sera présentée.

3.1 Motivation pour les architectures Big Data

Avec la croissance exponentielle des volumes de données générées par les entreprises et
les utilisateurs, les architectures Big Data sont devenues essentielles pour gérer, analyser et
tirer des insights des grandes quantités de données. Cette section explore les motivations
pour adopter ces architectures en détaillant les défis associés aux données massives et en
expliquant comment les architectures Big Data répondent à ces défis.

3.1.1 Défis des données massives

1. Volume de données :Le volume des données générées par les applications mo-
dernes et les dispositifs IoT est en constante augmentation[4]. Selon un rapport de
Statista, la quantité de données générées dans le monde a atteint 79 zettaoctets
en 2021 et devrait continuer à croı̂tre [Statista, 2021]. La gestion efficace de ces
données massives nécessite des architectures capables de stocker, traiter et analyser
ces informations à grande échelle.

2. Vitesse de traitement :Les données sont générées en temps réel et doivent être
traitées rapidement pour permettre des décisions basées sur des informations ac-
tuelles. Les systèmes traditionnels, conçus pour des traitements par lots, ne sont

35
Chapitre 3. Conception 3.1. Motivation pour les architectures Big Data

souvent pas adaptés pour gérer des flux de données en temps réel. La vitesse à la-
quelle les données doivent être traitées impose l’utilisation d’architectures capables
de supporter des traitements en continu et des analyses instantanées.

3. Scalabilité : Les systèmes doivent pouvoir évoluer horizontalement pour gérer

l’augmentation continue des données sans compromettre la performance [5]. Les
architectures traditionnelles peuvent devenir un goulot d’étranglement à mesure
que les exigences de traitement augmentent. Les solutions Big Data offrent une sca-
labilité horizontale en ajoutant de nouveaux nœuds au cluster, permettant ainsi
d’équilibrer la charge.

3.1.2 Avantages des architectures Big Data

1. Flexibilité et adaptabilité :Les architectures Big Data, telles que Lambda et
Kappa, offrent une grande flexibilité pour traiter différents types de données et
répondre à des besoins variés. Par exemple, l’architecture Lambda [4] combine le
traitement par lots et le traitement en temps réel pour fournir une solution complète
pour diverses exigences analytiques. L’architecture Kappa simplifie cette approche
en traitant toutes les données en continu, éliminant le besoin de traitement par lots.

2. Performance Optimisée :Les architectures Big Data exploitent des technologies

de traitement parallèle et distribué pour améliorer les performances. Par exemple,
Apache Spark utilise le traitement en mémoire pour accélérer les tâches de trai-
tement par rapport aux systèmes basés sur disque [Zaharia et al., 2016]. Cette
amélioration des performances est essentielle pour répondre aux exigences de trai-
tement en temps réel et d’analyse de grandes quantités de données.

3. Résilience et tolérance aux pannes : Les systèmes Big Data [6] sont conçus
pour être résilients et tolérants aux pannes. Par exemple, Apache Hadoop et Apache
Spark, deux technologies couramment utilisées, offrent des mécanismes pour assurer
la continuité du traitement des données même en cas de défaillance d’un nœud [7].
Cette tolérance aux pannes est cruciale pour maintenir la disponibilité et l’intégrité
des données.

4. Support pour l’analyse avancée : Les architectures Big Data [6] facilitent l’intégration
de techniques d’analyse avancées, telles que l’apprentissage automatique et l’in-
telligence artificielle. Les frameworks comme TensorFlow et PyTorch peuvent être
intégrés avec des systèmes Big Data pour exécuter des modèles d’apprentissage auto-
matique à grande échelle, permettant ainsi des analyses prédictives et prescriptives.

36
Chapitre 3. Conception 3.2. Architectures Big Data temps réel

3.2 Architectures Big Data temps réel

Dans cette section nous exposons les architectures relatives aux contexte de Big data
temps réel pour faire par la suite le choix le plus adéquat.Nous explorons à travers cette
partie les différentes architectures de traitement des données Big Data, en mettant l’accent
sur l’architecture Lambda et l’architecture Kappa.

3.2.1 Architecture Lambda

L’architecture Lambda [4], représenté par la figure 3.1 se compose de trois couches
principales : la couche d’injection de données, la couche de traitement en temps réel, et
la couche de traitement batch. Chaque couche joue un rôle spécifique dans le traitement
des données. L’architecture Lambda permet de traiter les données à la fois en temps réel
et en mode batch, en utilisant des pipelines de données distincts pour chaque type de
traitement.

Avantages :

– Traitement en temps réel et en batch : Offre la flexibilité de traiter les données

instantanément et de réaliser des analyses approfondies sur les données histo-
riques.
– Scalabilité : Peut s’adapter facilement à des augmentations significatives du
volume de données.
– Tolérance aux pannes : Conception distribuée assurant une haute disponibilité
du système.
– Flexibilité : Permet l’utilisation de diverses technologies et outils pour optimiser
chaque couche du système.

Inconvénients :

– Complexité : Implémentation et maintenance plus complexes en raison de la

gestion de deux pipelines de données distincts.

37
Chapitre 3. Conception 3.2. Architectures Big Data temps réel

Figure 3.1 : Architecture Lambda

[8]

3.2.2 Architecture Kappa

L’architecture Kappa [4], représenté par la figure 3.2 est une simplification de l’archi-
tecture Lambda, se concentrant uniquement sur le traitement en temps réel des données.
Elle n’utilise qu’un seul pipeline de traitement des données en continu.

Avantages :

– Simplicité : Moins complexe à implémenter et à maintenir que l’architecture

Lambda, car elle ne nécessite qu’un seul pipeline de données.
– Traitement en temps réel : Optimisée pour les applications nécessitant des
analyses rapides et continues des données en flux.
– Scalabilité : Peut également s’adapter à des volumes de données croissants.

Inconvénients :

– Limité aux scénarios de traitement en temps réel : Moins flexible pour les
analyses historiques approfondies comparé à l’architecture Lambda.

38
Chapitre 3. Conception 3.2. Architectures Big Data temps réel

Figure 3.2 : Architecture Kappa

[8]

Afin de mieux comprendre les différences entre les architectures Lambda et Kappa
dans le traitement des données Big Data en temps réel, le tableau 3.1 présente une compa-
raison détaillée de leurs principaux aspects, avantages, inconvénients et cas d’utilisation.

Aspect Architecture Lambda Architecture Kappa

✓Temps réel
Traitement des ✓Temps réel seulement
✓Batch
données
✓Traitement temps réel et batch
✓Simplicité
✓Scalabilité
Avantages ✓Optimisée pour le temps réel
✓Tolérance aux pannes
✓Scalabilité
✓Flexibilité technologique
× Limité aux analyses temps réel
Inconvénients × Complexité accrue × Moins adapté aux analyses
historiques
✓Scénarios de temps réel ✓Flux de données temps réel
Cas d’utilisation
✓Analyses batch historiques × Pas de traitement batch

Table 3.1 : Comparaison entre l’architecture Lambda et l’architecture Kappa

39
Chapitre 3. Conception 3.2. Architectures Big Data temps réel

3.2.3 Choix de l’architecture

Après avoir évalué les architectures Lambda et Kappa, l’architecture Lambda a été
retenue pour répondre aux besoins spécifiques de notre projet, qui consiste à implémenter
un processus ETL (Extract, Transform, Load) pour une application permettant de visua-
liser des métriques et des logs (erreurs et activité) en temps réel. Notre solution a besoin
de la gestion des flux de données, le traitement des données en temps réel ainsi qu’un
batching pour implémenter le module intelligent, le stockage et la recherche, l’exposition
des API. Ci-dessous la figure 3.3.

Figure 3.3 : Architecture Lambda du Healthcheck agent

3.2.4 Les composants de l’architecture

L’architecture Lambda se compose de plusieurs composants clés, chacun jouant un rôle
spécifique dans le traitement des données. Ces composants sont généralement organisés
en trois couches principales :

1. Couche d’injection de données : Les données des journaux sont collectées et ache-
minées vers le système du Healthcheck pour assurer un transfert de données fiable
et scalable.

2. Couche de traitement en temps réel : Les données sont traitées en temps réel per-
mettant une unification et analyse instantanée des journaux.

3. Couche de stockage : Les résultats du traitement en temps réel sont stockés dans
une base de données optimisée pour les requêtes rapides de recherche dans un texte.

40
Chapitre 3. Conception 3.3. Conception globale

4. Couche de service : Les résultats des traitements en temps réel et batch sont exposés
via des API, permettant au dashboard client d’accéder aux données et aux analyses
de manière efficace et sécurisée.

5. Couche de traitement batch : Les données sont traitées par lots à intervalles réguliers
permettant des analyses un peu plus complexe sur de grandes quantités de données
des journaux historiques. Les résultats du traitement batch sont stockés dans des
data lakes ou des entrepôts de données pour un stockage à long terme et une analyse
approfondie.

6. Couche d’entraı̂nement de modèles de Machine Learning : Les données traitées par

batch sont utilisées pour entraı̂ner des modèles de machine learning. Ces modèles
sont ensuite déployés pour faire des prédictions en temps réel.

3.3 Conception globale

Dans cette section, nous présentons une conception globale dont le diagramme de classe
du module Healthcheck, le diagramme de paquetage, et le diagramme de déploiement.
Ensuite, je passe vers une conception plus détaillée pour mettre en avant le fonctionnement
de chaque cas d’utilisation.

3.3.1 Diagramme de paquetage relatif à la partie serveur d’iO-

beya
Afin d’exposer les informations systèmes relatives à la plate-forme iObeya, j’ai utilisé
des services existant et j’ai ajouté des fonctionnalités et des services. La figure 3.4 décrit le
diagramme de paquetage qui présente l’architecture des composants du système iObeya,
décomposé en deux sous-paquetages principaux : server-api et server-core.

Dans server-api, le paquetage com.iobeya.service contient l’interface HealthCheckService,

tandis que com.iobeya.dao inclut HealthDao pour l’accès aux données de santé. Le pa-
quetage com.iobeya.api héberge trois interfaces clés : PluginManager pour la gestion des
plugins, LicenseManager pour la gestion des licences, et UserManager pour la gestion des
utilisateurs.

Dans server-core, com.iobeya.service.remoting.impl fournit l’implémentation Healthcheck-

ServiceImpl pour HealthCheckService.

Les relations d’utilisation et d’implémentation entre ces composants montrent comment

ils interagissent pour offrir les fonctionnalités nécessaires, mettant en avant une structure
modulaire et organisée

3.3.2 Diagramme de paquetage relatif à la couche Streaming

Le diagramme de paquetage représenté par la figure 3.5, relatif au service de la couche
Streaming Layer, présente l’architecture de l’application com.iobeya.plugins.healthcheck-

41
Chapitre 3. Conception 3.3. Conception globale

Figure 3.4 : Diagramme de paquetage relatif à la couche d’exposition des données de la

plate-forme iObeya

addon.StreamingApp, qui est structurée en plusieurs composants interconnectés.

Le composant principal, StreamingConsumer, contient le point d’entrée de l’application

avec la méthode main(String[]) et utilise divers services et entités pour ses opérations.

Les données de logs, représentées par LogData dans le paquetage entity, sont traitées et
filtrées par EventFilter du paquetage processors.

Les services situés dans le paquetage service, tels que ElasticSavingService, SparkStrea-
mingService, et CustomDateSerializer, sont utilisés pour gérer les flux de données et les
opérations de sérialisation.

Les propriétés de configuration nécessaires à Kafka, Spark Streaming, et Elasticsearch

sont contenues dans le paquetage properties, avec KafkaProperties, SparkStreamingPro-
perties, et ElasticsearchProperties.

Ces composants interagissent de manière cohérente pour permettre la collecte, le traite-

ment, et le stockage des journaux dans un environnement de streaming.

3.3.3 Diagramme de paquetage relatif à la couche Service

Le diagramme de paquetage fourni par la figure 3.6 représente l’architecture du mo-
dule HealthcheckAPI.

Tout d’abord, le paquetage ElasticDataMappingAppApplication agit comme le point

d’entrée principal de l’application. Ce composant joue un rôle crucial en initialisant et
en configurant les divers modules et services nécessaires au fonctionnement de l’applica-
tion.

42
Chapitre 3. Conception 3.3. Conception globale

Figure 3.5 : Diagramme de paquetage relatif au Streaming Layer

Dans le paquetage controller, plusieurs contrôleurs spécifiques sont définis pour gérer
différentes responsabilités fonctionnelles. Le PurgeJobController s’occupe des requêtes
liées à la purge des données, fournissant des API pour l’initiation et la gestion de ces
processus. De même, le MigrationJobController gère les requêtes associées à la migration
des données, tandis que l’ElasticsearchController gère les interactions avec Elasticsearch,
incluant les requêtes de recherche, d’indexation et de gestion des données.
Le paquetage service contient le ElasticsearchService, un composant central qui encap-
sule la logique métier pour interagir avec Elasticsearch. Ce service est utilisé par les
contrôleurs pour exécuter des opérations telles que la recherche, l’indexation et la mise à
jour des données. Il joue un rôle essentiel dans l’orchestration des fonctionnalités offertes
par l’application.

Dans le paquetage utils, divers utilitaires sont regroupés pour fournir des fonctions réutilisables.
Parmi eux, le JobsUtils assiste dans les tâches spécifiques de purge et de migration des
jobs, tandis que RestTemplateConfig assure la configuration des templates REST utilisés
pour les appels externes, gérant ainsi les paramètres des requêtes HTTP sortantes. Le pa-
quetage Config centralise les configurations globales et spécifiques de l’application, telles
que les paramètres de connexion à Elasticsearch et à d’autres services externes.

Les interactions entre ces composants sont clairement définies : les contrôleurs utilisent le
service ElasticsearchService pour manipuler les données dans Elasticsearch, tandis que ce
dernier fait appel aux utilitaires du paquetage utils pour des fonctionnalités spécifiques.
Enfin, le paquetage principal ElasticDataMappingAppApplication coordonne l’ensemble
du système en initialisant et en configurant les contrôleurs, les services et les utilitaires
nécessaires.

43
Chapitre 3. Conception 3.4. Conception détaillée de l’addon Healthcheck

Figure 3.6 : Diagramme de paquetage relatif au Service Layer

3.4 Conception détaillée de l’addon Healthcheck

Cette section est consacrée à une conception détaillée visant à mettre en avant le
fonctionnement de chaque cas d’utilisation. Nous approfondirons chaque fonctionnalité et
service, en expliquant les interactions spécifiques et les flux de données pour chaque cas
d’utilisation identifié.

3.4.1 Diagramme de séquence relatif à l’authentification

L’authentification d’un utilisateur se fait par le biais d’un token JWT généré par
la plate-forme iObeya comme l’illustre la figure 3.7. L’authentification est présentée par
le biais de l’identification de l’utilisateur, une fois qu’il est identifié et admet un rôle
particulier le service de sécurité génère un JWT unique pour cet utilisateur et renvoie une
requête contenant le JWT. Le jeton est ensuite envoyé avec chaque requête que le client
fera à l’application, qui autorisera, ou non, le client à accéder à ses services, en fonction
de la validité du jeton.

44
Chapitre 3. Conception 3.4. Conception détaillée de l’addon Healthcheck

Figure 3.7 : Diagramme de séquence relatif à l’authentification

3.4.2 Diagramme de séquence “Extraction les journaux de l’ac-

tivité de l’utilisateurs”
Le processus d’extraction des journaux de l’activité des utilisateurs commence par
l’authentification de celui-ci. Une fois l’utilisateur connecté au système via le module
d’authentification, son identité est vérifiée pour s’assurer qu’il dispose des autorisations
nécessaires pour effectuer les actions demandées. Après une authentification réussie, l’uti-
lisateur interagit avec le système en initiant soit des actions au niveau des panneaux soit
en lançant des taches systèmes manuellement. Le système iObeya lui-même peut lancer
des taches d’une manière programmée. Ces actions et ces taches engendrent la génération
des journaux d’activité.

L’agent de vérification de l’état du système, nommé Healthcheck Agent, s’abonne alors

au topic lui permettant de recevoir les journaux publiés. Une fois les logs reçus, l’agent
commence leur traitement. Ce traitement comprend plusieurs étapes, à commencer par
la transformation des logs ensuite, les logs transformés sont filtrés pour ne conserver que
les logs pertinents.

45
Chapitre 3. Conception 3.4. Conception détaillée de l’addon Healthcheck

Figure 3.8 : Diagramme de séquence relatif à l’extraction les journaux de l’activité de

l’utilisateurs

Les logs filtrés sont ensuite sauvegardés en envoyant les données au composant d’indexa-
tion pour stockage. Le composant d’indexation, représenté par Index, reçoit ces logs et
les enregistre de manière permanente. Une confirmation (OK) est alors renvoyée pour
indiquer que les logs ont été correctement enregistrés.

Ce processus démontré par la figure 3.8assure que les journaux d’activité des utilisateurs
sont collectés, traités et stockés de manière efficace et sécurisée, permettant ainsi une
surveillance continue et une analyse approfondie de l’activité des utilisateurs.

3.4.3 Diagramme de séquence “Extraction des métriques reliés

aux tâches programmées“
Les taches programmées au niveau de la plate-forme iObeya sont des taches lancées et
exécutées d’une manière planifiée ou manuelle par l’utilisateur.

Le processus d’extraction des métriques relatives à ces tâches est illustré par la figure 3.9.
Il commence par une demande initiée depuis le tableau de bord, qui a déjà récupérer le
token depuis l’authentification réussie. L’agent de vérification de la santé reçoit un appel

46
Chapitre 3. Conception 3.4. Conception détaillée de l’addon Healthcheck

d’une méthode comme “fetchMigrationHistory()“ pour récupérer l’historique des tâches.

Ensuite, l’agent envoie une requête vers l’index qui renvoie les résultats de la recherche
(Hits).

L’agent de vérification de la santé applique ensuite un filtre aux données reçues pour
extraire uniquement les informations relatives aux job indiqué par le dashboard. Enfin,
les métriques spécifiques sont extraites et la liste des métriques extraites est renvoyée au
tableau de bord, complétant ainsi le processus.

Figure 3.9 : Diagramme de séquence relatif à l’extraction des métriques reliés aux tâches
programmées exemple du job Migration

Conclusion
Dans ce chapitre, la conception globale de notre application a été détaillée. Un exa-
men approfondi des différentes architectures possibles a été réalisé, en comparant les
approches Lambda et Kappa pour répondre aux besoins spécifiques du projet. Ensuite,
les diagrammes de paquetage ont été détaillés, fournissant une visualisation claire de la
structure et des interactions entre les différents modules du système. Le chapitre suivant
se concentrera sur l’implémentation de l’application.

47
 CHAPITRE 4

Implémention

Introduction
Ce chapitre contient le dernier volet de ce rapport. Son objectif est de présenter
le travail terminé. Tout d’abord, nous présentons l’architecture technique du système, les
logiciels ainsi que les différents outils de développement utilisés. Dans un deuxième temps,
nous illustrons la réalisation de notre travail par des imprimés d’écran des interfaces les
plus importantes de notre application.

4.1 Environnement de développement

Dans cette section, je présenterai brièvement les caractéristiques de l’environnement
de travail que j’ai utilisé pendant le développement de ce projet.

4.1.1 Environnement matériel

Pour développer cette application dans les conditions les plus favorables, j’ai disposé
de la configuration matérielle suivante : Un ordinateur portable DELL Latitude 3540,
équipé de 16 Go de RAM, de 250 Go de stockage SSD et d’Ubuntu 16.04 LTS comme
système d’exploitation.

4.1.2 Environnement logiciel

Dans cette section, j’expose l’environnement logiciel entourant notre solution. Tout
d’abord, nous introduirons les langages de programmation utilisés, puis nous détaillerons
les différentes API et bibliothèques nécessaires à la réalisation de notre projet.

48
Chapitre 4. Implémention 4.1. Environnement de développement

Langages de programmation
Dans le cadre du développement de notre projet, nous avons utilisé plusieurs langages de
programmation adaptés aux besoins spécifiques de chaque composant de notre application.
• Java 17[9] : Le cœur de notre application backend a été développé en utilisant
Java 17. Ce choix a été motivé par la robustesse et la maturité de Java, ainsi que
par son vaste écosystème et ses bibliothèques riches, qui facilitent le développement
d’applications d’entreprise. Java 17, en tant que version LTS (Long Term Support),
offre une stabilité à long terme et de nombreuses améliorations de performance et
de sécurité, essentielles pour le développement de notre plateforme.

• JavaScript [10] et React : Pour le développement de l’interface utilisateur, nous

avons utilisé JavaScript avec le framework React . Ce choix a été fait en raison
de la flexibilité de JavaScript et de la popularité de React pour le développement
de frontends dynamiques et interactifs. React, associé à Vite, un bundler moderne,
nous a permis de bénéficier de temps de compilation rapides et d’une expérience de
développement fluide.

Frameworks et APIs
Pour réaliser notre projet, nous avons intégré plusieurs frameworks et APIs, qui nous ont
permis de construire une application robuste et évolutive tout en assurant une intégration
fluide entre les différents composants.
• Spring Boot [11] : Pour le backend, nous avons utilisé Spring Boot, un framework
Java puissant qui simplifie le développement d’applications basées sur le langage
Java. Spring Boot offre des fonctionnalités telles que la gestion des dépendances,
une configuration simplifiée, et une intégration facile avec d’autres technologies, ce
qui a considérablement accéléré le développement de notre application.

• Kafka [12] : Pour la gestion de la messagerie et des flux de données en temps réel,
nous avons utilisé Kafka. Kafka est un système de streaming distribué qui nous a
permis de gérer de grandes quantités de données de manière fiable et efficace. Dans
notre projet, Kafka a été utilisé pour la transmission des logs et des messages d’ap-
plication entre les différents composants, garantissant ainsi une communication en
temps réel et une haute disponibilité.

• Spark [13] : Pour le traitement des données, en particulier les logs, nous avons
intégré la bibliothèque Spark. Spark est une plateforme de traitement de données
rapide et générale qui a permis de traiter et d’analyser des volumes importants de
données en temps réel . Cette bibliothèque a été essentielle pour le traitement ef-
ficace des logs collectés, nous permettant d’extraire des informations utiles pour la
supervision et la maintenance de l’application.

49
Chapitre 4. Implémention 4.1. Environnement de développement

• Elasticsearch [14] : Pour le stockage et la recherche de données, nous avons utilisé

Elasticsearch, un moteur de recherche et d’analyse basé sur Lucene. Elasticsearch a
été utilisé pour indexer les logs et les données de métriques, permettant ainsi une
recherche rapide et efficace. Les APIs d’Elasticsearch ont été intégrées dans notre
application backend, facilitant ainsi l’interaction avec le moteur de recherche pour
l’analyse des données.

• Prometheus API [15] : Pour la collecte et la surveillance des métriques, nous

avons utilisé Prometheus, un système de monitoring open-source. Les APIs de Pro-
metheus ont été utilisées pour extraire et surveiller les métriques de performance de
l’application. Cette intégration a été essentielle pour assurer une supervision efficace
des performances de l’application, permettant de détecter et de résoudre rapidement
les problèmes potentiels.

• React [16] avec Vite : Pour le développement du frontend, nous avons utilisé
React, un framework JavaScript populaire, en combinaison avec Vite, un outil de
construction moderne. React a permis de créer une interface utilisateur interactive
et réactive, tandis que Vite a offert une configuration de développement rapide et
optimisée. L’utilisation de Vite a permis de réduire considérablement les temps de
construction et d’améliorer l’expérience de développement.

Déploiement et Gestion du Code

• Docker [17] : Docker a été une composante essentielle dans le processus de déploiement
de mon application. En utilisant Docker, j’ai pu encapsuler mon application et toutes
ses dépendances dans des conteneurs légers et portables. Cette approche a permis
de garantir que l’application fonctionne de manière identique sur tous les environ-
nements, que ce soit en développement, en test ou en production. Docker simplifie
la gestion des environnements complexes en offrant une solution uniforme pour
l’exécution des applications. De plus, l’utilisation de Docker Compose a facilité la
gestion des services interdépendants, comme les bases de données et les serveurs
d’application, en définissant clairement leur configuration dans un fichier unique.

• GitLab [18] : GitLab a joué un rôle central dans la gestion du code source et
l’intégration continue de mon projet. En utilisant GitLab, j’ai bénéficié des fonction-
nalités avancées pour le versionnage, la collaboration et la revue de code. J’ai parti-
culièrement tiré parti des pipelines CI/CD préconfigurés, mis en place par l’ingénieur
DevOps d’iObeya, ce qui m’a permis de bénéficier d’une configuration éprouvée pour
les processus d’intégration et de déploiement. Ces pipelines automatisent les étapes
de construction, de test et de déploiement, garantissant ainsi une intégration fluide
des nouvelles modifications et une mise en production efficace. En outre, mon pro-
cessus de gestion du code a été enrichi par les revues de code effectuées par mon
manager, offrant des retours précieux pour améliorer la qualité et la clarté du code.

50
Chapitre 4. Implémention 4.2. Réalisation

L’utilisation de SonarQube pour l’analyse de code a également joué un rôle cru-

cial en fournissant des rapports détaillés sur les problèmes de qualité du code et
en aidant à maintenir un code propre et bien structuré. Ces outils combinés ont
non seulement optimisé la qualité du code, mais ont aussi renforcé la cohérence et
l’efficacité du développement en assurant une conformité continue aux meilleures
pratiques du secteur.

4.2 Réalisation
Dans cette section, nous abordons la réalisation des exigences fonctionnelles du projet
en fournissant une vue d’ensemble détaillée de l’exécution de l’application.

L’application est déployée à l’aide de Docker. Les conteneurs pour iObeya et Healthcheck
doivent être lancés pour faire fonctionner les deux composants de manière intégrée. Une
fois que tous les services sont opérationnels, l’application web sera en écoute pour le trafic
HTTP entrant, tandis que Prometheus et le reste de la pile de surveillance effectueront
des tâches programmées de collecte de métriques, de collecte des logs et des informations
systèmes.

Interface de login au healthcheck

Pour accéder à l’agent Healthcheck, nous avons besoin d’accéder à iObeya client, générer
un token comme démontré par la figure 4.1 et le copier vers notre agent dans l’interface
d’accès illustrée par la figure 4.2.

Figure 4.1 : Génération du token depuis iObeya Client

51
Chapitre 4. Implémention 4.2. Réalisation

Figure 4.2 : Interface de saisie du Token pour accéder à Healthcheck

4.2.1 Interface information système iObeya

La section ”Interface information système iObeya” concerne la présentation des informa-
tions essentielles relatives à l’état de l’application iObeya et à la gestion de la licence. Elle
fournit des données statiques et critiques sur l’état du système, la licence, et les compo-
sants fonctionnels de l’application. Elle permet aux administrateurs de suivre l’utilisation
des ressources, la configuration des plugins, l’état des composants et les détails relatifs à
la licence, facilitant ainsi la gestion quotidienne et le suivi du bon fonctionnement de la
plate-forme.

Les informations clés présentées par cette interface, illustrée par la figure 4.3, sont
comme suit :

• Version d’iObeya installée : L’interface indique la version actuelle d’iObeya

installée sur le serveur, ce qui aide à savoir si la plate-forme est à jour ou si une mise
à jour est nécessaire pour bénéficier des dernières fonctionnalités et corrections de
sécurité.

• État du système iObeya : L’interface affiche l’état de l’instance iObeya (up/-

down), permettant de savoir si la plate-forme est opérationnelle ou non. Cette in-
formation est essentielle pour une gestion pro active des interruptions potentielles
de service.

• Nombre de salles et de panneaux : Les administrateurs peuvent consulter le

nombre de salles (rooms) et de panneaux actifs sur la plate-forme, ce qui donne un
aperçu de l’utilisation globale de l’espace collaboratif au sein d’iObeya.

• Plugins installés et activés : L’interface liste les plugins installés sur l’instance

52
Chapitre 4. Implémention 4.2. Réalisation

Figure 4.3 : Interface relative aux informations système de iObeya

iObeya, en indiquant lesquels sont activés ou désactivés. Cette fonctionnalité est

utile pour s’assurer que tous les outils nécessaires au bon fonctionnement de la
plate-forme sont en place et actifs.

• Informations sur la licence : L’interface affiche le nombre de jours restants et

consommés de la licence iObeya. Cela permet aux administrateurs de surveiller
l’expiration de la licence et de prendre les mesures nécessaires pour la renouveler à
temps.

4.2.2 Interface des métriques de l’infrastructure iObeya

L’interface des métriques de l’infrastructure iObeya fournit une vue en temps réel des
performances et de l’état des composants critiques du système. Cette interface permet de
suivre et d’analyser une série de graphiques en temps réel spécifiques à l’infrastructure
comme présenté par la figure 4.4, telles que l’utilisation des ressources système, la durée
des requêtes, la gestion de la mémoire JVM, et bien d’autres.

L’interface propose un bouton interactif illustré dans la figure 4.5, permettant aux utili-
sateurs d’ajouter une nouvelle métrique à suivre. Ce bouton permet aux administrateurs
de configurer et d’afficher de nouveaux graphiques basés sur des métriques plus avancées,
adaptées aux besoins spécifiques de l’infrastructure ou aux analyses ponctuelles. Cette
fonctionnalité améliore la flexibilité de l’interface en offrant la possibilité d’élargir la sur-
veillance sans nécessiter de modification du code source.

53
Chapitre 4. Implémention 4.2. Réalisation

Figure 4.4 : Interface relative aux métriques de l’infrastructure iObeya

Figure 4.5 : Interface d’ajout d’une charte d’une métrique inexistante

4.2.3 Interface journaux d’iObeya

L’interface des journaux d’iObeya est conçue pour offrir une visualisation en temps réel
des logs d’activité et des logs d’erreur générés par le système. Cette interface joue un rôle

54
Chapitre 4. Implémention 4.2. Réalisation

essentiel dans le suivi des événements du système et la gestion des erreurs, facilitant ainsi
la supervision et la maintenance de la plateforme.

Figure 4.6 : Interface des journaux d’activité et des erreurs en temps réel

Les journaux d’activité (logs) sont collectés en temps réel comme le démontre la figure 4.6
et affichés de manière claire et concise pour l’utilisateur. Ces logs incluent des informations
filtrées sur les actions des utilisateurs, les événements système, et les interactions internes,
comme :
1. Création, modification ou suppression de contenu (panneaux, rooms, utilisateurs)

2. Authentifications et déconnexions

3. Changements dans l’état des services.

Chaque log d’activité est simplifié pour ne contenir que les informations pertinentes,
évitant ainsi la surcharge d’informations tout en restant suffisamment détaillé pour per-
mettre une compréhension rapide des événements en cours.

Les journaux d’erreur sont également affichés en temps réel et permettent de suivre les
anomalies ou pannes rencontrées dans le système. Chaque entrée de log d’erreur est cli-
quable, ce qui permet à l’utilisateur d’accéder à des informations supplémentaires sur le
type d’erreur et d’en comprendre les causes.
Une fois que l’utilisateur clique sur une erreur, un pop un est affiché comme dans la figure
4.7 et l’interface fournit une classification automatique de l’erreur basée sur des catégories
prédéfinies (par exemple : erreur SQL, problème de permissions, erreur d’authentification,
etc.). Cette classification aide à structurer les erreurs et à prioriser leur résolution en fonc-
tion de la nature du problème.

55
Chapitre 4. Implémention 4.2. Réalisation

Figure 4.7 : Exemple de pop up de prédiction du label d’erreur ainsi que les actions
correctives

L’une des fonctionnalités phares de cette interface est la suggestion d’actions correctives
pour chaque erreur détectée. Après la classification de l’erreur, l’interface affiche une série
de recommandations pour la résoudre. Ces suggestions peuvent inclure :

1. Relancer un service ou une tâche spécifique via un bouton d’action intégré dans
l’interface.

2. Vérifier et ajuster les configurations (exemple : modification de permissions, ajus-

tements de requêtes SQL).

3. Escalader l’erreur vers un niveau supérieur pour analyse approfondie, avec un lien
direct vers une documentation ou une procédure interne.

4.2.4 Interface métriques des taches programmées d’iObeya

L’interface des métriques des tâches programmées d’iObeya est spécialement conçue pour
suivre les performances de deux tâches critiques pour l’équipe On-Prem : le job de mi-
gration et le job de purge. Ces deux processus, essentiels à la maintenance et à la bonne
gestion des données, sont surveillés en continu pour garantir leur efficacité et détecter tout
problème potentiel comme illustré par la figure 4.8.

La première section de cette interface présente un compteur de temps en direct qui affiche
la durée écoulée depuis la dernière exécution de chacun des deux jobs.

La section suivante de l’interface est dédiée à un graphe temporel qui représente la fluctua-
tion de la durée des jobs au fil du temps. Ce graphique présente deux courbes distinctes :

1. Une courbe représentant le job de migration, colorée en vert.

56
Chapitre 4. Implémention 4.2. Réalisation

2. Une autre courbe représentant le job de purge, avec une couleur bleue.

Cette représentation graphique permet de comparer visuellement l’évolution des durées

des deux jobs au cours du temps. En observant les tendances, l’équipe peut identifier
des anomalies, comme une augmentation soudaine du temps d’exécution, qui pourrait
indiquer un problème de performance ou une surcharge du système. En parallèle du graphe

Figure 4.8 : Interface de suivi des métriques des tâches programmées d’iObeya, affichant
la durée et le stockage utilisé pour les jobs de migration et de purge.

de durée, un deuxième graphe présente la quantité de stockage utilisée par chaque job.
Comme pour la durée, deux courbes distinctes sont affichées :

1. Une courbe pour le job de migration, montrant l’évolution de l’espace disque utilisé
lors de chaque exécution.

2. Une courbe pour le job de purge, permettant de suivre la variation de l’espace

consommé.

L’analyse de ces données permet à l’équipe On-Prem de mieux comprendre l’impact des
tâches programmées sur l’infrastructure et d’anticiper d’éventuelles saturations du sto-
ckage.

Conclusion
Nous sommes parvenus à la fin de ce chapitre, dont l’objectif principal était de présenter
le produit final obtenu et de mettre en œuvre ma conception. Pour ce faire, j’ai exposé
l’architecture technique adoptée, les outils matériels et logiciels utilisés, et enfin, j’ai décrit
un scénario à travers les interfaces de mon système.

57
 Conclusion générale et perspectives

La satisfaction client est un facteur déterminant pour le succès des entreprises, quelle
que soit leur taille ou leur part de marché. Les entreprises investissent massivement dans
l’amélioration de leurs processus et veillent à ce que leurs prévisions stratégiques soient
soutenues par de nouvelles technologies et des avancées scientifiques.

Cela nous a amené à envisager des méthodes innovantes pour évaluer et quantifier la
satisfaction client à travers des mesures précises et des techniques avancées de traitement
du langage naturel. Ce rapport a couvert les différentes étapes de la réalisation du projet.
La première phase a consisté à analyser les processus existants et leurs faiblesses. Ensuite,
nous avons conçu l’application en détail, en respectant les exigences fonctionnelles et non
fonctionnelles. Cette conception a inclus plusieurs représentations UML et des diagrammes
de flux pour fournir une vue d’ensemble détaillée du fonctionnement de notre outil.
Nous sommes passés à la phase la plus déterminante du projet : la mise en œuvre. Tout
au long de cette phase, nous avons utilisé différents langages de programmation et tech-
nologies pour atteindre le résultat souhaité.

Ce travail a atteint les objectifs fixés, à savoir collecter des métriques, classifier les logs,
les analyser et extraire des informations significatives sur la santé du système à partir de
diverses métriques. Néanmoins, des améliorations sont encore possibles.

Une perspective d’avenir est la mise en place d’une formation plus sophistiquée de notre
modèle de classification des logs en utilisant un ensemble de données spécialement collecté
à la main. Cet ensemble de données devra être nettoyé, pré-traité et étiqueté. À terme,
ce jeu de données servirait de référence pour la formation et les expérimentations futures
sur ce sujet et les tâches NLP connexes.

58
 Références

[1] iObeya. iObeya - Digital Visual Management Solutions. 2024. url : https://www.
iobeya.com/ (visité le 07/06/2024).
[2] Claude Aubry. Scrum : le guide pratique de la méthode agile la plus populaire.
Dunod, 2015.
[3] Atlassian. Estimation de projet agile : les méthodes et outils pour estimer vos
projets. Consulté le : 5 juin 2024. 2023. url : https://www.atlassian.com/fr/
agile/project-management/estimation.
[4] Zoiner Tejada. Big Data Architectures - Azure Architecture Center. Maintained by
Microsoft Documentation Team. 2024. url : https://learn.microsoft.com/en-
us/azure/architecture/databases/guide/big-data-architectures.
[5] John Miller et al. “Scalable Big Data Architecture”. In : IEEE Transactions on
Big Data (2023).
[6] Gérard Biau et Didier Sornette. Big Data : Concepts, Technologies, and Appli-
cations. Berlin : Springer, 2017. isbn : 978-3-662-53394-1.
[7] Tom White. Hadoop : The Definitive Guide. O’Reilly Media, 2015.
[8] Microsoft Azure. Big Data Architectures on Azure. Accessed : 2024-03-04. 2024.
url : https://learn.microsoft.com/fr-fr/azure/architecture/databases/
guide/big-data-architectures.
[9] Ben Evans et David Flanagan. Java in a Nutshell : A Desktop Quick Reference.
7th edition. O’Reilly Media, 2023.
[10] Stoyan Stefanov. JavaScript Patterns : Build Better Applications with Coding and
Design Patterns. O’Reilly Media, 2010.
[11] Craig Walls. Spring Boot in Action. Manning Publications, 2016.
[12] Gwen Shapira et al. Kafka : The Definitive Guide : Real-time Data and Stream
Processing at Scale. O’Reilly Media, 2017.
[13] Bill Chambers et Matei Zaharia. Spark : The Definitive Guide : Big Data Pro-
cessing Made Simple. O’Reilly Media, 2018.

59
Références Références

[14] Radu Gheorghe, Matthew Lee Hinman et Roy Russo. Elasticsearch in Action.
Manning Publications, 2015.
[15] Brian Brazil. Prometheus : Up Running : Infrastructure and Application Perfor-
mance Monitoring. O’Reilly Media, 2018.
[16] Robin Wieruch. The Road to React : Your journey to master React.js. Indepen-
dently Published, 2022.
[17] Nigel Poulton. Docker Deep Dive. Leanpub, 2020.
[18] Jonathan Wright. Mastering GitLab CI/CD. Packt Publishing, 2021.

60
 Annexe

Figure 4.9 : Exemple d’un panneau de rétrospective Starfish

61
Annexe Annexe

Figure 4.10 : Exemple d’un panneau de ma première Sprint demo

62
Annexe Annexe

63