Université de la Manouba

École Supérieure d’Économie Numérique

Rapport
De projet de fin d'études

Présenté en vue de l'obtention du diplôme de

Licence appliqué en Informatique appliquée à la gestion

Sujet
Conception et développement d’une plateforme d’analyse de log

Élaboré par:

Agha Mohamed Mehdi

Boubaker Allaedine

Organisme d’accueil : VERMEG

Encadré par
Encadrante Académique Mme. Inès Thabet
Encadrant professionnel M. Tarek Guermazi
Encadrante pédagogique Mme. Inès Gam

Année universitaire : 2017-2018

 Remerciements
A l’éternel, DIEU le tout puissant, qui nous ‘a donné la force et la patience de réaliser ce
modeste travail.

Je tiens à remercier très chaleureusement notre encadrant Madame le professeur INES

THABET pour la confiance qu’il nous ’a donné en acceptant de nous ’encadrer, ainsi pour ses
précieux conseils, son aide et sa patience du début à la fin de ce travail. C’est un grand
honneur pour nous, le fait que vous avez accepté d'encadrer notre projet de fin d’études.

Je tiens aussi à remercier mon encadrant à la société VERMEG, Monsieur Tarek Guermazi
pour son aimable accueil au sein de son équipe. Qu’il trouve ici notre profonde gratitude pour
son encadrement sérieux et son soutien inlassable.

Nos remerciements s’étendent également à Monsieur MOHAMED BEN BRAHIM le chef de

projet de l’équipe. Nous lui remercions pour ses conseils et son encouragement.

J’exprime toute ma reconnaissance et gratitude aux membres du jury pour l’intérêt qu’ils ont
appuyé à notre travail en acceptant d’analyser mon travail.

Un grand merci pour toutes les personnes qui ont contribué de près ou de loin à la réussite de
ce travail.

Qu’il nous soit enfin permis d’adresser une pensée spéciale à nos familles pour leurs
amours, leur soutiens et leur encouragements.
 DEDICACES
Je dédie ce travail

A la source de tendresse, d’amour et de générosité, A ma très chère mère

AMEL,

A mon père parfait MUSTAPHA,

Qui ont été toujours présents par leurs sacrifices inoubliables, aucune dédicace
ne pourrait exprimer mon amour que j’ai toujours eu pour vous, les prunelles
de mes yeux,

A ma sœur Imen,

Pour son partage sans

égal,

A mes grands-parents, mes tantes et oncles,

Et en particulier ma tante AWATEF pour son encouragement

continu Veuillez apprécier dans ce travail tout mon respect,

A mes amies et sœurs AZIZ, OMAR, FARES, YOUSSEF, OURSOUENE,

EMNA, KENZA, GHOFRANE et FATMA

Pour leur appui moral durant cette période, je présente mon profond
attachement avec tous mes souhaits de réussite

Mehdi
 A mon père Hedi,

L’homme de référence, le géant dans l’ombre de qui j’ai fait mes premiers pas,
celui qui m’a appris patiemment tant de choses, qui m’a donné l’éducation et
les armes pour affronter sereinement la vie, toujours positif et débordant
d’optimisme, toujours à l’écoute, avec qui j’ai partagé tant de joies, qui m’a
soutenu dans tant d’épreuves. Adieu Papa et merci pour tout.

A ma mère Mounira

Pour tout leur soutien, pour tout leur sacrifice, pour leur amour et pour tout
l’enseignement qu’ils m’ont transmis.

A mon frère Sirajeddine et ma sœur Dorra,

Avec tous les souhaits d’un grand succès dans leur vie.

A mes amis et mes collègues,

Qui ont contribué à mon épanouissement .Merci d’être toujours près de moi,
merci de m’avoir aidé chaque jour à avancer.

Allaedine
 Table des matières
Introduction générale.............................................................................................................. 1
Chapitre 1 : Contexte Général.................................................................................................3
1. Introduction...................................................................................................................... 3
2. Entreprise d’accueil.......................................................................................................... 3
2.1.Produits de VERMEG................................................................................................4
2.2. Unité d’accueil........................................................................................................... 5
3. Présentation de projet......................................................................................................6
3.1. Cadre du stage.......................................................................................................... 6
3.2.Problématique............................................................................................................ 6
3.3. Objectifs..................................................................................................................... 6
3.4. Travail demandé........................................................................................................6
4. Etude de l’existant............................................................................................................ 7
4.1.Log............................................................................................................................. 7
4.2. Analyseurs de log existants.......................................................................................7
4.3. Notion du fichier Log..................................................................................................8
5. Etude d’analyseurs de log existants.................................................................................8
5.1. ELK.....................................................................................................................................8
5.2. Graylog...................................................................................................................... 9
5.3.Log Surfer................................................................................................................ 10
6. Critique de l’existant......................................................................................................10
7. Solution Proposée.......................................................................................................... 11
8. Méthodologies de travail................................................................................................11
8.1.Méthodologie agiles.................................................................................................11
8.2.Méthodologie agile adoptée : Scrum........................................................................12
8.2.1.Justification du choix de la méthodologie..........................................................13
8.2.2.Les rôles de la méthode Scrum.........................................................................13
8.2.3.Équipe du projet................................................................................................14
9. Langage de modélisation UML (Unified Modeling Language)........................................15
10. Conclusion................................................................................................................... 16
Chapitre 2 : Analyse du projet...............................................................................................17
 1. Introduction.................................................................................................................... 17
2. Recensement des besoins.............................................................................................17
2.1. Identification des acteurs.........................................................................................17
2.2. Besoins fonctionnels................................................................................................17
3. Structure et découpage de projet..................................................................................18
3.1. Identification de l’équipe SCRUM............................................................................18
3.2. Backlog de produit...................................................................................................18
3.3.Planification des sprints du projet............................................................................19
4. Diagramme de cas d’utilisation général..........................................................................20
4. Conclusion..................................................................................................................... 21
Chapitre 3 Sprint I «Demande d’une analyse d’un fichier log»..............................................22
1. Introduction.................................................................................................................... 22
2. Spécification fonctionnelle..............................................................................................22
2.1. Sprint backlog.......................................................................................................... 22
2.2.Prototypage des interfaces......................................................................................24
3. Diagramme des cas d’utilisation du premier sprint.........................................................25
4. Analyse des cas d’utilisation..........................................................................................25
4.1. Analyse de cas « S’authentifier ».............................................................................25
4.2. Analyse de cas « Demande une analyse »..............................................................27
5. Conception..................................................................................................................... 30
6. codage........................................................................................................................... 31
7. Test................................................................................................................................ 32
8. Revue du sprint.............................................................................................................. 34
9. Conclusion..................................................................................................................... 35
Chapitre 4 Sprint 2 «Gestion des utilisateurs»......................................................................36
1. Introduction.................................................................................................................... 36
2. Sprint fonctionnelle.........................................................................................................36
2.1. Sprint backlog.......................................................................................................... 36
2.2.Prototypages des interfaces.....................................................................................37
3. Spécification fonctionnelle..............................................................................................39
4. Analyse des cas d’utilisations.........................................................................................39
4.1. Analyse du cas « Consulter les statistiques »..........................................................39
4.2. Analyse du cas « Gérer des utilisateurs »................................................................41
 5. Diagramme de classe globale........................................................................................45
6. codage........................................................................................................................... 46
7. Test................................................................................................................................ 48
8. Conclusion..................................................................................................................... 50
Chapitre 5: Phase de clôture.................................................................................................51
1. Introduction.................................................................................................................... 51
2. Environnement logiciel...................................................................................................51
3. Conception Architecturale..............................................................................................54
3.1. Choix de l’architecture de l’application.....................................................................54
3.2. Architecture MVC.....................................................................................................54
4. Diagramme de déploiement...........................................................................................56
5. Conclusion..................................................................................................................... 56
Conclusion générale............................................................................................................. 58
Références bibliographiques.................................................................................................60
 Table des illustrations
Figure 1.1: Vermeg Logo.........................................................................................................4
Figure 1.2 : Palmyra Logo.......................................................................................................4
Figure 1.3:Organisation de VERMEG......................................................................................5
Figure 4:Equipe et rôles........................................................................................................ 18
Figure 5:Plannification des sprints.........................................................................................20
Figure 6:Diagramme de cas d'utilisation générale.................................................................21
Figure 7:Prototype de l'interface « S'authentifier »................................................................24
Figure 8:Prototype de l'interface demande une analyse........................................................24
Figure 9: Raffinement du cas d'utilisation du premier sprint...................................................25
Figure 10:Diagramme de séquence système du cas « S'authentifier ».................................26
Figure 11:Diagramme de séquence détaillé du cas « S'authentifier »..................................27
Figure 12:Diagramme de classes participantes du cas « S'authentifier »..............................27
Figure 13:Diagramme de séquence système du cas « Demande une analyse »..................29
Figure 14:Diagramme de séquence détaillé du cas « Demande une analyse »....................29
Figure 15:Diagramme de classe globale du premier sprint....................................................30
Figure 16:Interface d'authentification.....................................................................................32
Figure 17:Interface de contrôle d'authentification..................................................................33
Figure 18:Interface demande d’une analyse..........................................................................33
Figure 19:Interface de résultat d'une analyse........................................................................34
Figure 20:Prototype de l'interface « consulter les statistiques »............................................37
Figure 21:Prototype de l'interface « consulter les utilisateurs ».............................................38
Figure 22:Prototype de l'interface « modifier un utilisateur ».................................................38
Figure 23:Prototype de l'interface ajouter un utilisateur.........................................................38
Figure 24:Diagramme de cas d'utilisation du deuxième sprint...............................................39
Figure 25:Diagramme de séquence système du cas « Consulter les statistiques »..............40
Figure 26:Diagramme de séquence détaillé du cas Consulter les statistiques......................40
Figure 27:Diagramme de classes participantes du cas Consulter les statistiques.................41
Figure 28:Diagramme de séquence système du cas « Gérer des utilisateurs »....................43
Figure 29:Diagramme de séquence détaillé du cas « Gérer les utilisateurs ».......................44
Figure 30:Digramme de classes participantes du cas « Gérer les utilisateurs »....................45
Figure 31:Diagramme de classe globale du deuxième sprint.........................................................46
Figure 32:Interface de consultation des utilisateurs...............................................................48
Figure 33:Interface d'ajout d'un nouvel utilisateur..................................................................49
Figure 34:Interface de modification d'un utilisateur existant..................................................49
Figure 41: Architecture MVC.................................................................................................55
Figure 42: Architecture MVC.................................................................................................55
Figure 43:Daigramme de déploiement...................................................................................56
Liste des tableaux
 Introduction générale

Introduction générale
Avec l’avancement fulminant d’internet, la sécurité informatique augmente de plus en plus dans les
entreprises qui n’abandonnent à immortaliser et transvaser un bloc extraordinaire de données critiques
à travers leurs réseaux locaux ou étendus.

La perpétuité de l’entreprise gratte par une disponibilité permanente de son système

d’information. Cette réalité influe de nos jours le comportement des entreprises qui devient de
plus en plus mature sur la sécurité du système d’information qui est un élément assurément
essentiel.

Les efforts de sécurisation ne peuvent pas être efficaces que si ces investissements sont
correctement étudiés et ciblés, en mettant en place les moyens de protection qui apportent un
niveau de sécurité favorable adapté aux enjeux de l’entreprise.

Dans le cadre de notre projet de fin d’étude nous sommes menés à développer une plateforme
d’analyse log au sein de la société VERMEG. Cette plateforme a pour but de faciliter la
compréhension de fichier log et pour détecter les applications contenant le plus d’erreurs.
Ce rapport présente l’ensemble des étapes suivies pour développer la solution. Il contient cinq
chapitres organisés comme suit :

- Le premier chapitre est consacré à la présentation de contexte général. Nous

commençons par la présentation de l’organisme d’accueil et le projet en présentant les
problématiques et les objectifs. Ensuite, nous passons à l’étude et à la critique de
l’existant pour enfin proposer une solution adéquate. La méthodologie utilisée sera
également définie à la fin de ce chapitre pour nous permettre de réaliser
convenablement notre travail.

Le second chapitre exprimera la phase de « planification et architecture » qui

expliquera les besoins fonctionnels ainsi le backlog de produit.

Le troisième chapitre constituera le premier sprint intitulé «Analyse d’un fichier log
et statistiques».

Nous enchainerons ensuite avec le second sprint « Gestion des utilisateurs et

authentification »

Pour finir, un chapitre qui contient la phase de clôture qui représente les
environnements de notre travail et par une conclusion générale.
10
 Chapitre 1 Contexte
général

Chapitre 1 : Contexte Général

1. Introduction
L’idée d’un projet vient généralement d’un besoin exprimé par la société. Dans ce premier
chapitre, nous commençons par la présentation de l’organisme d’accueil. Ensuite, nous
passons à la présentation du projet en décrivant la problématique et les objectifs de notre
projet, et pour terminer, nous spécifions la méthodologie de gestion de projet et la
méthodologie du développement.

2. Entreprise d’accueil
Notre projet a été réalisé au sein de l’entreprise VERMEG qui a été créé en 1994, initialement
de nom BFI et a été séparé de BFI (Banque de financement et d'investissement) en 2002.

Groupe international basé en France, Belgique, Luxembourg et Tunisie, composé de plus de

700 collaborateurs et disposant de clients dans plus de 20 pays, Vermeg est spécialisée dans
l'édition de logiciels financiers.

Depuis plus de 20 ans, Vermeg propose des solutions logicielles innovantes adaptées aux
problématiques de ses clients, qu'ils soient assureurs de personnes avec les
solutions Solife et Soliam for Asset Owners, sociétés de gestion ou banques privées avec la
solution Soliam for Wealth Managers, spécialistes des infrastructures de marché et des
métiers titres avec la suite Megara.

Vermeg est également partenaire de la transformation digitale en finance et assurance, avec

l'offre digital financier services, appuyée sur des composants financiers, des méthodes agiles
'Time-to-Market', ainsi que des composants digitaux, articulés autour du Framework de
Vermeg, Palmyra.

Passionnés par les Technologies autant que par l'humain, les collaborateurs de Vermeg sont
engagés dans un programme RSE d'entreprise, 'Empowered by Vermeg', visant aux actions de
développement personnel, sociétal et environnemental.
VERMEG a participé pleinement à la création de l’association TACT, qui regroupe des
acteurs clés du marché tunisien, afin de former près de 1.000 diplômes par an dans les métiers
de l’ITO (Information Technology Outsourching).

Enfin le groupe est un champion de la diversité en Tunisie : 40% de son effectif est composé
de femmes, ce qui place VERMEG première entreprise en diversité dans le marché des TIC.

Figure 1.1: Vermeg Logo

2.1. Produits de VERMEG

1. Palmyra : Palmyra est un Framework J2EE (Java Enterprise Edition) compatible SOA
(Architecture Orienté Service) qui incorpore des composants ainsi que des services
web réutilisables. Etant basé principalement sur l’ingénierie dirigée par les modules,
Palmyra génère des applications entières à partir de modèles UML préalablement
définis. L’idée est d’automatiser la projection des modèles métier d’une application
sur n’importe quelle plateforme. L’automatisation de la génération de code constitue
donc un atout essentiel pour l’équipe de développement.

Figure 1.2 : Palmyra Logo

2. La suite MEGARA (FMSS) : C’est une plate-forme modulaire pour le traitement des
titres, destinée essentiellement aux institutions financières. Elle propose un nombre de
modules pouvant être implémentés séparément. MEGARA comporte ces composants :
 MEGACOR : C’est un logiciel qui automatise la plupart des opérations sur titres et
est compatible ISO 15022. Le label SwiftReady Corporate Action Gold lui a été
décerné.
  MEGACUSTODY : C’est un logiciel de livraison, lui aussi récompensé par le label
SWIFTTRADY Securities Settlement Gold.
 MEGALEND : C’est un logiciel pour le suivi des prêt/emprunt de titres.
 MEGATRADE : Il consiste à un système de centralisation et de gestion des ordres de
ventes/achats
3. Soliam (WAM) : C’est une solution de gestion de portefeuilles pour les gestionnaires
d’actifs institutionnels de fortune.
4. SoLife (PI) : Une solution d’administration de polices d’assurance vie et un portail
web à destination des clients finaux/brokers. Ayant une présence internationale en
Belgique, France, Irlande, Luxembourg, Pays-Bas, Suisse, Royaume-Uni, Tunisie et
des clients dans plus de 23 pays
 SoLife et Soliam sont considérés comme les deux produits phares de Vermeg.

2.2. Unité d’accueil

L’entreprise se compose de quatre départements représentés par la figure1.3:
 Marketing et Sales :Ce département est responsable de tout ce qui est marketing, la
gestion des ventes et de la prospection.
 Customer Services : Cette branche gère les relations avec le client et comprend
également une cellule de veille technologique.
 Recherche et Développement : Ce secteur gère le développement et effectue les tests
et la validation des applications.
 Support : Responsable du support IT, de l’assistance à l’installation et l’utilisation des
produits livrés et des mises à jour.
Dans l’entreprise VERMEG on est situé dans le département Recherche et Développement

Figure 1.3:Organisation de VERMEG

2.3Organisation de l’entreprise

VERMEG Groupe compte 4 principales unités à savoir :

 Pension and Insurance (PI).
 Wealth and Assest Management (WAM).
 Financial Markets and Securities Services (FMSS).
 Digital Financial Services (DFS).

3. Présentation de projet

Ce stage effectué au sein de l’entreprise Vermeg Tunis, s’inscrit dans le cadre du projet de fin
d’études pour l’obtention du diplôme de licence en informatique de gestion de l’ESEN.

Le stage est effectué de 12/02/2018 au 11/05/2018.

3.1. Problématique
Parfois les clients de Vermeg leur souffrent des crushs et des bugs des applications lors des
opérations financières et il est difficile de trouver les sources des bugs.

De plus Vermeg, utilise des outils de surveillance et d’analyse payants .Ses couts
d’installation et de maintenance sont énormes. De plus les utilisateurs de l’équipe de Palmyra
trouvent des difficultés au niveau de l’utilisation de ces outils de surveillance de logs.

D’où l’idée de créer une plateforme d’analyse des fichiers de log dédiée à la société et
l’équipe de Palmyra en particulier.

3.2. Objectifs
L’objectif principal est le développement d’une plateforme d’analyse de log qui facilite aux
utilisateurs et les analystes d’analyser les fichiers logs en se basant sur des filtres bien
déterminés au niveau de l’application et de visualise leurs résultat en les combinant avec
d’autres filtres et de gérer des statistiques sur les résultats obtenus .

3.3. Travail demandé

Le projet sur lequel nous allons travailler consiste à concevoir et développer une plateforme d’analyse
de fichier de log du Framework Palmyra dans Vermeg. Il s’agit de mettre en place une solution web
qui se charge d’analyser des fichiers logs.
Cette analyse va être programmée en se basant sur des filtres (date adresse IP, adresse MAC,
description). Afin d’atteindre ces objectifs, nous avons suivi un processus de développement
itératif et incrémental. D’ailleurs, comme l’évolution rapide et incrémentale est l’enjeu
principal de notre projet, nous avons adopté une méthodologie agile.

4. Etude de l’existant
4.1. Log
Dans le domaine informatique, le terme log désigne un type de fichier dont son rôle principal
consiste à stocker un historique des événements.

Le log s’apparente ainsi à un journal de bord horodaté, qui ordonne les différents événements
qui se sont produits sur un ordinateur, un serveur, il permet ainsi d’analyser heure par heure,
voire minute par minute l’activité interne d’un processus.

Ainsi, il est principalement utilisé pour tenter d’identifier les raisons et/ou l’origine d’une
panne informatique.

https://www.journaldunet.fr/web-tech/dictionnaire-du-webmastering/1203463-
log- definition-traduction/

4.2. Analyseurs de log existants

Afin d’atteindre les objectifs de notre projet, l’étude du système existant et des différents
moyens mis à notre disposition est une étape inévitable. En effet, il faut d’abord décortiquer
les fonctionnalités déjà développés.

Ensuite, nous pouvons dégager les solutions qui peuvent faire face aux problèmes liées aux
solutions existantes. De ce fait, nous allons, d’une part, présenter les notions de fichier log.

D’autre part, nous allons étudier les solutions d’analyse des fichiers de logs existants
, comprendre leurs mode de fonctionnement et dégager les faiblesses et les limites qui ont
motivé le lancement de ce projet pour détailler, finalement, les solutions possibles et celle
retenue.
5. Etude d’analyseurs de log existants
Sur le marché plusieurs logiciels pour l’analyse des fichiers log payants ou open source.
Parmi ces logiciels nous retrouvons :

5.1. ELK

La stack ELK est une solution open source, de la société elastic,composée de trois produits
que sont Elasticsearch, Logstash et Kibana, qui permettent de parser, indexer et présenter
de gros volumes de données issues de vos logs sous forme de dashbords et de faire des
recherches au sein de vos logs comme vous pourriez le faire avec un moteur de recherche.

La figure 2.1 montre un aperçu de l’interface de Kibana après avoir passé les logs par
Logstash et Elasticsearch.
https://blog.netapsys.fr/vos-logs-passent-la-seconde-avec-elk-elasticsearch-logstash-
kibana/comment-page-1/

Figure 2.1 : Aperçu de l’interface Kibana

Après avoir stocké les fichiers logs, il faut les envoyer vers Elasticsearch, ce dernier est un
moteur de recherche libre et open source, il permet d’indexer les données à partir des
requêtes HTTP en utilisons une interface de type API web.

Nous expliquons l’utilisation d’ELK par la figure 2.2 :

Figure 2.2 : Utilisation d’ELK

5.2. Graylog
https://korben.info/graylog-un-outil-de-centralisation-et-danalyse-de-logs.html

Graylog est un outil open source baptisé, il est capable de collecter, indexer et analyser des
données structurées et non structurées en provenance de diverse sources.

Ce logiciel permet :

 L’accès à l’interface web nécessite un login et un mot de passe ce qui permet d’assurer une
certaine sécurité.
 Il permet d’analyser les logs en temps réel.

Figure 2.3: Aperçu de l’interface Graylog

5.3. Log Surfer

Log surfer est un programme simple et efficace qui permet de surveiller les fichiers logs en
temps réel et envoyer des alertes lorsque des anomalies se produisent. Contrairement à
d’autres systèmes de supervision, Log surfer peut être modifié et réglé afin d’envoyer
uniquement des alertes simples contenant toutes les informations pertinentes et non pas un
déluge de courriels à l’opérateur.
Log surfer peut être utilisé pour déceler les défauts et les événements de sécurité avant qu’ils
ne deviennent des problèmes graves.

6. Critique de l’existant
Nous résumons dans le tableau 3.1 les différences entre les outils citées dans la section
précédente :

Critères fonctionnels ELK Graylog Log Surfer

Analyse des fichiers Logs Oui Oui Oui
Notification par mail Oui Non Oui

Complexité Oui Non Non

Gratuit Oui Oui Oui
Temps réel Oui Oui Oui

Tableau 1 : Etude Comparative

Chacune de ces applications ont des inconvénients tels que pour la première solution
KIBANA qui est complexe et nécessite une formation pour pouvoir la comprendre de ses
utilisateurs.

Graylog est utilisable seulement sur le système d’exploitation Linux.

Concernant Log surfer, il est très difficile à configurer et permet que l’envoie des alertes en
temps réel au lieu de la programmer.

Ainsi, cet outil doit être utilisé uniquement par des développeurs chevronnés
7. Solution Proposée
Dans le but de rendre la lecture des fichiers logs génères par le Framework Palmyra plus
lisibles, simples et plus Compréhensibles.

Vermeg et l’équipe Palmyra a décidé de mettre en place une application web qui permet
d’analyser les fichiers logs en temps réel. Notre application va permettre aux analystes de
Vermeg et à l’équipe Palmyra d’avoir plusieurs interfaces d’analyse des fichiers log avec
plusieurs filtres sur les niveaux et des recherches par certain critères.

8. Méthodologies de travail
8.1. Méthodologie agiles
Une méthode Agile est une approche itérative et collaborative, capable de prendre en compte
les besoins initiaux du client et ceux liés aux évolutions.
La méthode Agile se base sur un cycle de développement qui porte le client au centre. Le
client est impliqué dans la réalisation du début à la fin du projet. Grâce à la méthode agile le
demandeur obtient une meilleure visibilité de la gestion des travaux qu’avec une méthode
classique.
L’implication du client dans le processus permet à l’équipe d’obtenir un feedback
régulier afin d’appliquer directement les changements nécessaires.
Cette méthode vise à accélérer le développement d’un logiciel. De plus, elle assure la
réalisation d’un logiciel fonctionnel tout au long de la durée de sa création.
Le principe de base consiste à proposer une version minimale du logiciel puis à intégrer des
fonctionnalités supplémentaires à cette base, par processus itératif. Le processus itératif
regroupe une séquence d’instructions à répéter autant de fois que possible, selon le besoin. En
ce qui concerne la réalisation d’un logiciel, les instructions à répéter sont les suivantes :

 Les tests unitaires à la fin de chaque itération

 Le développement
 L’intégration
 La relecture et amélioration des codes

https://www.ideematic.com/actualites/2015/01/methodes-agiles-definition/
 a. Les quatre valeurs fondamentales Agiles

 Individus et interactions au lieu de processus et outils.

 Logiciel fonctionnel au lieu de documentation massive.
 Collaboration du client au lieu de négociation de contrats.
 Réagir au changement au lieu de suivre le plan.

b. Les principales méthodes agiles

Parmi les méthodes agiles nous citons :
 SCRUM

 Extreme Programming (XP)

 Crystal Clear

 Adaptive Software Développement (ASD)

c. Les principes de méthodes agiles
 Satisfaire le client est la priorité
 Accueillir les demandes de changement « à bras ouverts »
 Livrer le plus souvent possible des versions opérationnelles de l’application
 Assurer une coopération permanente entre Client et Equipe projet
 Construire des projets autour d’individus motivés
 Privilégier la conversation en face à face
 Mesurer l’avancement du projet en termes de fonctionnalités de l’application
 Faire avancer le projet à un rythme soutenable et constant
 Porter une attention continue à l’excellence technique et à la conception
 Favoriser la simplicité
 Responsabiliser les équipes: les meilleures architectures, spécifications
et conceptions émergent d’équipes auto organisées.
 Ajuster, à intervalles réguliers, son comportement, ses processus pour être plus
efficace

8.2. Méthodologie agile adoptée : Scrum

ineumann.developpez.com/tutoriels/alm/agile_scrum/

Pour bien conduire notre projet est nous assurer du bon déroulement des différents
phases, nous avons opté SCRUM comme une méthodologie de conception et de
développement pour les raisons suivantes.
La méthode Scrum est une méthode agile, créée en 2002, dont le nom est un terme Emprunté
au rugby qui signifie « la mêlée ». Elle s’appuie sur le découpage des projets en itérations
encore nommées « sprints ». Un sprint peut avoir une durée qui varie généralement entre deux
semaines et un mois.
Avant chaque sprint, les tâches sont estimées en temps et en complexité à l’aide de
Certaines pratiques comme le « planning poker ». Ces estimations permettent à la fois de
planifier les livraisons, mais aussi d’estimer le coût de ces tâches auprès du client.
Cette méthodologie est basée sur des itérations qu’on appelle sprint.

Figure1.5 Méthode Scrum

https://www.pentalog.fr/notre-demarche/methode-agile-scrum.htm

8.2.1. Justification du choix de la méthodologie

Dans le cas de notre projet, après avoir étudié les différentes méthodes, nous avons
choisi pour SCRUM comme méthode de gestion de projet car elle est la mieux adaptée et la
mieux qui dispose une organisation adaptée et d’un état d’esprit Agile, il se base sur une
démarche itérative et incrémentale et permet de créer rapidement des incréments de produit
fonctionnels et de qualité en mettant l’accent sur un objectif clair à chaque itération.
Le choix de Scrum comme une méthode de pilotage pour notre projet s’est basé sur les atouts
de ce dernier.
Il est léger et simple à comprendre, ce qui permet de démarrer rapidement en Agilité.
Il se caractérise par une capacité d’adaptation au changement grâce à des itérations courtes,
une transparence, une souplesse et une capacité de réagir.
En effet cette méthode est entièrement développée et testée pour de courtes itérations et des
besoins évolutifs.

8.2.2. Les rôles de la méthode Scrum

La méthode Scrum définit trois rôles pour un projet.
  Le Product Owner : Il s’agit du représentant officiel du client au sein d’un projet
Scrum. Il est l’interlocuteur principal du Scrum Master et des membres de l’équipe. Il
définit les besoins du produit et rédige les spécifications. Il peut se faire aider de
responsables fonctionnels pour la rédaction des spécifications. Il est également chargé
de définir et prioriser les users stories pour chaque sprint.

 Le scrum master : Il s’agit d’une personne chargée de veiller à la mise en application

de la méthode et au respect de ses objectifs. Il ne s’agit pas d’un chef de Projet, mais
d’une personne chargée de lever les obstacles éventuels qui empêcherait l’avancement
de l’équipe et du projet pendant les différents sprints.
 L’équipe : Ce sont les personnes chargées de la réalisation du sprint et d’un produit
utilisable en fin de sprint. Il peut s’agir de développeurs, architectes, personnes
chargées de faire des tests fonctionnels.
8.2.3. Équipe du projet
L’équipe de notre projet se compose de :

 Product Owner : Equipe Palmyra

 Scrum Master : Tarek Guermazi
 Scrum Team:Agha Mohamed Mehdi&Boubaker Allaedine

a. Les artéfacts dans Scrum

Les principaux artéfacts dans SCRUM sont :

Le « Product Backlog » : (Carnet de produits) :

C’est un outil de collecte des fonctionnalités attendues ou exigées par le client (User
Story), et qui évolue à chaque Sprint.
http://geekandmore.fr/tag/scrum

Le « Sprint Backlog » : (Carnet d'itération)

Il contient la liste des tâches qui doit être accomplie pour mettre en œuvre les
fonctionnalités prévues pour un Sprint particulier. Idéalement, chaque tâche dans un
 sprint est relativement courte et peut-être captée par un membre de l'équipe plutôt que
d'être affecté.
https://confluence.atlassian.com/agile/glossary/sprint-backlog.

9. Langage de modélisation UML (Unified Modeling Language)

UML est avant tout un support de communication performant, qui facilite la représentation et
la compréhension de solutions objet

- sa notation graphique permet d'exprimer visuellement une solution objet, ce qui facilite la
comparaison et l'évaluation de solutions

- l'aspect formel de sa notation, limite les ambiguïtés et les incompréhensions ;

- son indépendance par rapport aux langages de programmation, aux domaines d'application
et aux processus, en font un langage universel.

La notation graphique d'UML n'est que le support du langage. La véritable force d'UML, c'est
qu'il repose sur un métamodèle. En d'autres termes : la puissance et l'intérêt d'UML reposent
sur le fait qu'il normalise la sémantique des concepts qu'il véhicule.
UML permet de représenter un système selon différentes vues complémentaires :
les diagrammes.

Un diagramme UML est une représentation graphique, qui s'intéresse à un aspect précis du
modèle ; c'est une perspective du modèle.

https://www.memoireonline.com/10/10/3952/m_Gestion-des-unites-
denseignement-dans-le-cadre-de-la-reforme-LMD--luniversite-de-
Lome8.html
10. Conclusion
Pendant ce chapitre, nous avons introduit l’organisme d’accueil VERMEG, ses
services et son organisation. Par ailleurs, nous avons pu retirer le contexte général du projet et
présenter le choix de la méthodologie de développement et le langage de modélisation. Le
chapitre suivant sera consacré à la phase de l’analyse de projet mettant l’accent sur l’étude
préliminaire des besoins, identification des besoins ainsi que la représentation des besoins et
la planification des sprints.
 Chapitre 2 Analyse du
projet

Chapitre 2 : Planification et
architecture

1. Introduction
Dans ce chapitre, nous décrivons les besoins fonctionnels, non fonctionnels et architecturaux.
Ensuite nous joignons la modélisation des besoins de l’application ainsi que les diagrammes
de cas d’utilisation.

2. Recensement des besoins

2.1. Identification des acteurs

Un acteur est une personne qui a une tâche essentielle et déterminante dans une
action. Dans le cadre de ce projet, nous avons identifié les 2 acteurs
suivants l’administrateur et l’analyste qui interagissent avec notre système. Tous ces
derniers doivent s’authentifier pour consulter les statistiques, sélectionner un modèle
d’analyse ainsi qu’une demande d’analyse. Enfin l’administrateur est le seul acteur qui
a la possibilité de gérer l’utilisateur en modifiant un utilisateur existant ou ajoutant un
nouvel utilisateur.

2.2. Besoins fonctionnels

Les besoins fonctionnels doivent répondre aux exigences de notre future application en termes
de fonctionnalités, et comme notre projet consiste à développer une application de conception
et développement d’une plateforme qui est capable d’analyser les fichiers log.

Cette application doit couvrir les besoins fonctionnels suivants:

 Authentification : L’utilisateur de cette plateforme doit s’authentifier pour accéder à la

plateforme.
 Consulter les statistiques : L’utilisateur a l’autorisation de consulter les statistiques de
ses dernières analyses après avoir s’être authentifié.
 Sélectionner un modèle : Tous les acteurs doivent sélectionner un modèle d’analyse
pour analyser un fichier désiré
  Demande d’analyse : L’acteur peut faire une analyse d’un fichier log
 Configuration : L’utilisateur a l’autorisation de faire la configuration
 Gestion des utilisateurs : L’administrateur est le seul acteur qui a l’autorisation de
gérer les utilisateurs en ajoutant un nouvel utilisateur ou de modifier un utilisateur
existant.

3. Structure et découpage du projet

3.1. Identification de l’équipe SCRUM
L’un des participants les plus impressionnants dans SCRUM, c’est l’effectif de SCRUM. Cette
équipe, bien constituée, assure l’efficacité et la flexibilité d’une équipe précieuse toute en
sauvegardant la collaboration, la clarté et l’inspiration dans le but d’atteindre tous les objectifs du
projet.

Figure 4:Equipe et rôles

3.2. Backlog du
produit

Le backlog de produit est l’un des plus importantes artéfacts de Scrum que nous l’avons présenté
dans le premier chapitre.
Comme nous avons dit que c’est une représentation des occurrences et de fonctionnalités aspirées,
nous allons présenter ci-dessous le backlog produit de notre plateforme :
 Tableau 2 : Backlog produit

Thème ID User Stories Description Priorité Complexité Effort

1 Consulter les En tant que utilisateur je 2 ++ 8

statistiques peux consulter les
statistiques

Demande une analyse 2 Demande une En tant que utilisateur je 1 +++++ 13

d’un fichier Log analyse veux demander une analyse
de fichier log.

Consulter les En tant que administrateur je 5 + 2

utilisateurs peux consulter tous les
3 utilisateurs.

Gestion des utilisateurs

Ajouter un En tant que administrateur je 3 +++ 3

utilisateur peux ajouter un utilisateur.
4

Modifier un En tant que administrateur je 4 +++ 5

utilisateur peux modifier un utilisateur.
5
existant

Authentification 6 S’authentifier En tant 6 + 1

qu’utilisateur je
dois m’authentifier
pour accéder à mon
espace personnel
en sécurité.

3.2. Planification des sprints du projet

La partie de planification des sprints reste primordiale pour la bonne gestion

d’un projet, elle permet d’avoir un cheminement optimisé pour le découpage et
l’affectation des fonctions selon les priorités, le temps et l’effectif pour que le
produit réponde bien aux besoins cités par le Product Owner.
 « Le sprint est une période d’un mois au maximum, au bout de laquelle
l’équipe délivre un incrément du produit, potentiellement livrable. Une fois la
durée choisie, elle reste constante pendant toute la durée du développement.
Un nouveau sprint démarre dès la fin du précédent. »
https://www.oriade.net/?page_id=250
La planification des sprints de notre projet est établie dans la figure suivante :

Figure 5:Plannification des sprints

4. Diagramme de cas d’utilisation général

La figure 6 présente le diagramme de cas d’utilisation général de notre plateforme d’analyse
de log.

Nous y retrouvons les acteurs principaux et leurs rôles.

 Figure 6:Diagramme de cas d'utilisation général

5. Prototypage des interfaces

a) Prototype de l’interface d’authentification

Figure 7:Prototype de l'interface d l'authentification

 b) Prototype de l’interface statistique

Figure 8:Prototype de l'interface statistique

c) Prototype de l’interface analyse d’un fichier log

Figure 9: Prototype de l'interface d'analyse d'un fichier log

 d) Prototype de l’interface de la page de gestion des utilisateurs

Figure 10:Prototypage de l'interface de la page de gestion des utilisateurs

e) Prototypage de l’interface d’ajout d’un nouvel utilisateur

Figure 11:Prototypage de l'ajout d'un nouvel utilisateur

 f) Prototypage de modification d’un utilisateur existant

Figure 12:Prototypage de modification d'un utilisateur existant

6. Conclusion
Dans ce chapitre, nous avons pu dans un premier lieu déterminé les acteurs, les besoins
fonctionnels et non fonctionnels de notre projet. Nous avons également identifié l’équipe,
défini le backlog produit et planifier des sprints.
 Chapitre 3 Sprint 1 « demande d’une analyse d’un fichier log
»»

Chapitre 3 Sprint 1 «Analyse d’un

fichier log et statistiques»

1. Introduction
Comme déjà énoncé dans la section organisation des sprints du chapitre précédent, le projet se
disperse en unités de temps nommées sprints au bout desquelles l’équipe est obligé d’aboutir
à un produit éventuellement livrable.
Ce chapitre s’intéresse au premier sprint de notre projet «Demande une analyse log ».

2. Spécification fonctionnelle
Lors de la première phase de chaque sprint, la spécification fonctionnelle s’exprime
par un diagramme de cas d’utilisation .Celui-ci donne une vue extérieure du système
et définit les liens entre les utilisateurs et les fonctionnalités que propose celui-ci.

2.1. Sprint backlog

Le backlog de sprint est une liste de tâches identifiées par l'équipe Scrum à compléter
lors du sprint Scrum. Au cours de la réunion de planification du sprint, l'équipe
sélectionne un certain nombre d'éléments de backlog de produit, généralement sous la
forme d'user stories, et identifie les tâches nécessaires pour compléter chaque histoire
d'utilisateur. https://translate.google.tn/translate?

hl=fr&sl=en&u=https://www.mountai
ngoatsoftware.com/agile/scrum/scrum-tools/sprint-backlog&prev=search
Le tableau suivant présente le backlog de notre premier sprint :
 Tableau 3 : Backlog du premier sprint

ID Nom de user User story ID Tache Affectation

USER
Story Story Tache

1 Consulter les En tant 1.1 Réaliser les AllaEddine Boubaker

statistiques qu’utilisateur diagrammes de cas
je peux d’utilisation, de classe,
consulter les de séquence système et
statistiques de séquences détaillées
du cas « Consulter les
statistiques »

1.2 Développer le cas Mohamed Mehdi

« Consulter les Agha
statistiques »

1.3 Tester le cas « Consulter AllaEddine Boubaker

les statistiques»

2 Demande En tant 2.1 Réaliser les Mohamed Mehdi

qu’utilisateur diagrammes de cas Agha
une analyse je peux d’utilisation, de classe,
analyser un de séquence système et
fichier log de séquences détaillées
du cas « Demander une
analyse »

2.2 Développer le cas AllaEddine Boubaker

« demander une
analyse »

2.3 Tester le cas « Mohamed Mehdi

demander une analyse» Agha
3. Diagramme des cas d’utilisation du premier sprint

Le diagramme de cas d’utilisation est une représentation UML d’une façon statique et globale
le comportement fonctionnel d’un système. La figure ci-dessous schématise le raffinement du
diagramme de cas d’utilisation du premier sprint

Figure 9: Cas d'utilisation du premier sprint

4. Analyse des cas d’utilisation

4.1. Analyse de cas « Consulter les statistiques »

a) Description textuelle du cas « Consulter les statistiques »

Le tableau 3 représente une description textuelle du cas d’utilisation «Consulter les

statistiques»
 Tableau 4 : Description de cas d’utilisation « Consulter les statistiques »

Etapes Description

Résumé
Acteurs : analyste
Titre : Consulter les statistiques.
Description : le système permet à ce niveau l’administrateur,
analyste et référent projet qui veulent consulter leurs statistiques.
Pré-conditions L’analyste s’est connecté à la plateforme.
La plateforme est opérationnelle.
Scénario nominal
L’utilisateur s’authentifie.
L’administrateur, l’analyste et le référent projet consulte leurs
statistiques
Scénario alternatif Le système affiche un espace de travail vide puisque l’utilisateur
n’jamais analysé un fichier log.
Post-conditions L’acteur consulte les statiques.
Le système attend désormais qu’il exécute une nouvelle action.

b) Diagramme de séquence système du cas « Consulter les statistiques »

La figure ci-dessous présente le diagramme de séquence système du cas de consultation des

statistiques.

Figure 25:Diagramme de séquence système du cas « Consulter les statistiques »

4.2. Analyse de cas « Demande une analyse »

a) Description textuelle du cas « Demande une analyse »

Le tableau 4 représente une description textuelle du cas d’utilisation « S’authentifier »

 Tableau 5 : Description de cas d’utilisation « Demande une analyse »

Etapes Description

Résumé
Acteur : Analyste
Titre : demande une analyse
Description : le système permet à ce niveau à l’administrateur et l’analyste
d’analyser un fichier log.
Pré-conditions
L’utilisateur s’est connecté à la plateforme.
La plateforme est opérationnelle.

Scénario nominal
1. L’analyste s’authentifie.
2. Le système affiche l’espace de travail de chaque utilisateur.
3. L’acteur entre dans l’interface « Request analyses » et donne le chemin
de fichier log à analyser.
4. Le système affiche le résultat de l’analyse

Scénario Néant
alternatif

Post-conditions Le système affiche le résultat de l’analyse.

Le système attend désormais qu’il exécute une nouvelle action.

b) Diagramme de séquence système du cas « Demande une analyse »

La figure 13 présente le diagramme de séquence système du cas « Demande une analyse »

 Figure 13:Diagramme de séquence système du cas « Demande une analyse »

5. Conception des cas d’utilisation

Après avoir réalisé les diagrammes de séquence système et les descriptions textuelles des cas
d’utilisation dans la section précédente, nous allons consacrer cette section à la réalisation des
diagrammes de classes participantes des cas raffinés les plus importants ainsi leurs diagrammes de
séquence détaillés et un diagramme de classes d’objets du premier sprint.
5.1 Conception du cas d’utilisation « Consulter les statistiques »

a) Diagramme de séquence détaillé du cas « Consulter les statistiques »

Cette figure présente le diagramme de séquence détaillé du cas de consultation des

statistiques
 Figure 26:Diagramme de séquence détaillé du cas Consulter les statistiques
b) Diagramme de classes participantes du cas « Consulter les statistiques »

Figure 27:Diagramme de classes participantes du cas Consulter les statistiques

5.2Conception du cas d’utilisation « Demande d’une analyse »

 a) Diagramme de séquence détaillée du cas « Demande une analyse »

La figure ci-dessous présente le diagramme de séquence détaillé cas « Demande une analyse

Figure 14:Diagramme de séquence détaillé du cas « Demande une analyse »

b) Diagramme de classes participantes du cas « Demande une analyse »

Ce diagramme nous présente le diagramme de classes participantes du cas « demander

une analyse »
 Figure 15:Diagramme de classes participantes du cas demande une analyse

5. Diagramme de classe global

Dans la figure ci-après, nous présentons alors le diagramme de classe décrivant la structure
statique du premier sprint.
 Figure 15:Diagramme de classe globale du premier sprint

6. Codage
Dans le schéma ci-dessous nous présentons les tables de notre base de données. Cette transformation au
schéma relationnel se fait en tenant compte aux règles de passages suivantes :

 Règle 1 : Toute entité devient une relation ayant un identifiant nommé clé primaire. Chaque propriété
se transforme en attribut.

 Règle 2 : Toute association hiérarchique (de type [1, n]) se traduit par une clé étrangère. La clé
primaire correspondant à l'entité père (côté 1) migre comme clé étrangère dans la relation
correspondant à l'entité fils (côté n).

 Règles 3: Toute association non hiérarchique (de type [n, n] ou de dimension > 2) devient une
relation. La clé primaire est formée par la concaténation (juxtaposition) l'ensemble des identifiants des
entités reliées. Toutes les propriétés éventuelles deviennent des attributs qui ne peuvent pas faire
partie de la clé.
https://www.developpez.net/forums/d1594435/general-
developpement/alm/modelisation/schema/passage-modele-entite-association-modele-
relationnel/

 Schéma de la base de données «User»

Attribut Type Contrainte

idAnalyste Long Primary Key
lastName String Not null
firstName String Not null
Password String Not null
Mail String Not null

 Schéma de la base de données « Log »

Attribut Type Contrainte

idLog Long Primary Key
pathFile String Not null

 Schéma de la base de données « Record »

Attribut Type Contrainte

idRecord Long Pimary Key
date&time String Not null
Ipsource String Not null
Level String Not null
Description String Not null
Ipmac String Not null

7. Test

 Interface demande d’une analyse

Cette interface présente l’interface de demande d’une analyse

Figure 18:Interface demande d’une analyse

  Interface de résultat d’une analyse
Cette figure présente l’interface du résultat d’une analyse

Figure 19:Interface de résultat d'une analyse

8. Revue du sprint

La revue de sprint est une réunion réalisée à la fin de chaque sprint, dont la
durée maximale est d’une heure par semaine de sprint donc deux heures dans
notre projet.
La motivation de la revue de sprint est d’inspecter l’incrément du logiciel
réalisé au courant du sprint passé et réajuster le backlog du produit si
nécessaire.
Au cours de la revue du premier sprint, nous avons partagé le travail développé
au cours du sprint écoulé avec product owner avec qui on a traité les user
stories du sprint backlog une par une pour vérifier la validité de ce qui a été
fait. Tous les user stories de ce sprint ont été validés et testés, et le « product
owner » a accepté les fonctionnalités présentées.
9. Conclusion
Durant ce chapitre, nous avons manifesté clairement les items du Backlog du premier sprint
afin d’améliorer l’achèvement des objectifs de notre projet en franchissant de la phase
d’analyse jusqu’à la phase de test. Dans le chapitre suivant, vous allez détecter comment nous
allons concrétiser le second sprint de notre projet.
 Chapitre 4 Sprint 2 « Gestion des utilisateurs
»

Chapitre 4 Sprint 2 «Gestion des

utilisateurs et
authentification»
1. Introduction
Après avoir réalisé le premier sprint, cette partie sera consacrée à la réalisation du second,
nous allons analyser les « user stories » en donnant une description détaillée de chaque cas
d’utilisation « user story », présenter la gestion des utilisateurs faisant partie de ce sprint et
même de l’application entière .Finalement nous allons réaliser le user story de
l’authentification. Nous y présentons également la conception globale du sprint. Enfin, nous
terminons par la phase de codage et de test.

2. Spécification fonctionnelle
C’est au niveau de ce sprint que nous allons réaliser la tache de gestion des utilisateurs et
d’authentification.

2.1. Sprint backlog

ID Nom de user User story ID Tache Affectation

USER
Story Story Tache

1 S’authentifier 1.1 Réaliser les AllaEddine

En tant que diagrammes de cas Boubaker
utilisateur je d’utilisation, de classe,
de séquence système
peux consulter
et de séquences
les statistiques détaillées du cas
« Consulter les
après avoir statistiques »
analysé un
fichier
1.2 Développer le cas Mohamed Mehdi
« Consulter les Agha
statistiques »
 1.3 Examiner le cas AllaEddine
« Consulter les Boubaker
statistiques »

2 Gestion des En tant 2.1 Réaliser les Mohamed Mehdi

utilisateurs qu’administrateur diagrammes de cas Agha
d’utilisation, de classe,
je peux gérer les
de séquence système
utilisateurs en et de séquences
consultant les détaillées du cas
« Gestion
données des
utilisateurs, en des utilisateurs »
2.2 Développer le cas AllaEddine
modifiant un
« Gestion Boubaker
utilisateur
des utilisateurs »
existant ou
d’ajouter un
2.3 Tester le cas « Gestion Mohamed Mehdi
nouvel utilisateur des utilisateurs » Agha
3. Spécification fonctionnelle
La figure 24 présente le diagramme de cas d’utilisation du sprint 2.

Figure 24:Diagramme de cas d'utilisation du deuxième sprint

4. Analyse des cas d’utilisations

4.1. Analyse du cas « S’authentifier »
a) Description textuelle du cas « S’authentifier »
Résumé Acteur : analyse, administrateur
Titre : S’authentifier
Description : le système identifie à ce niveau l’administrateur et
l’analyste qui veulent utiliser la plateforme
Pré-conditions
La système est opérationnelle.

Scénario nominal 1. L’analyste entre ses paramètres de connexion (mail et mot de

passe)
2. Le système vérifie les informations saisies.
3. Le système affiche l’espace de travail de chaque utilisateur.

Scénario alternatif 2. a Les données sont erronées.

1. Le système affiche un message d’erreur et retourne à l’étape 1
Post-conditions L’administrateur ajoute un utilisateur.
Ou modifie un utilisateur existant
Le système attend désormais qu’il exécute une nouvelle action.
 b) Diagramme de séquence utilisé « S’authentifier »

Figure 2:Diagramme de séquence du cas «  S'authentifier »

4.2. Analyse du cas « Gérer des utilisateurs »

a) Description textuelle du cas « Gérer des utilisateurs »
Tableau 6 : Description textuelle du cas « Gérer les utilisateurs »

Résumé Acteur : administrateur

Titre : Gérer des utilisateurs
Description : le système permet à ce niveau l’administrateur de
gérer les utilisateurs
Pré-conditions L’administrateur doit mettre à jour un utilisateur existant
L’administrateur doit ajouter un nouvel utilisateur
L’administrateur s’est connecté à la plateforme.
La plateforme est opérationnelle.
Scénario nominal 1. L’administrateur clique sur le bouton « manage
analystes ».
2. Le système affiche l’interface de gestion des
utilisateurs
3. Si l’administrateur doit mettre à jour un utilisateur
3.1 L’administrateur choisit un utilisateur et clique sur le
bouton « update »
3.2 Le formulaire de l’utilisateur est affiché
3.3 L’administrateur modifier l’utilisateur
3.4 L’administrateur enregistre la modification
4. Si l’administrateur ajoute un nouvel utilisateur
4.1 L’administrateur clique sur le bouton d’ajout
4.2 Un formulaire d’ajout s’affiche
4.3 L’administrateur remplit le formulaire
4.4 L’administrateur enregistre les données
5. Sinon
5.1 L’administrateur consulte tous les utilisateurs.
Scénario alternatif Le système affiche un message erroné.

Post-conditions Les données de l’utilisateur sont

mises à jour
Le système attend désormais qu’il exécute une nouvelle action.
 b) Description textuelle du cas « Modifier un utilisateur »

Tableau 7 : Description de cas d’utilisation « Modifier un utilisateur »

Résumé Acteur : administrateur

Titre : Modifier un utilisateur
Description : le système permet à ce niveau l’administrateur de
modifier un utilisateur existant.
Pré-conditions L’administrateur doit mettre à jour un utilisateur existant
L’administrateur s’est connecté à la plateforme.
La plateforme est opérationnelle.

Scénario nominal 6. L’administrateur clique sur le bouton « manage

analystes ».
7. Le système affiche l’interface de gestion des
utilisateurs
8. L’administrateur choisit un utilisateur
9. Le formulaire de modification est ouvert
10. L’administrateur modifie les données
11. L’administrateur enregistre les modifications

Scénario alternatif Le système affiche un message erroné.

Post-conditions Les données de l’utilisateur sont

mises à jour
Le système attend désormais qu’il exécute une nouvelle action.
a) Description textuelle du cas « Ajouter un utilisateur »

Tableau 8 : Description du cas d’utilisation «Ajouter un utilisateur »

Résumé Acteur : administrateur

Titre : Ajouter un utilisateur
Description : le système permet à ce niveau l’administrateur
d’ajouter un utilisateur
Pré-conditions L’administrateur doit ajouter un utilisateur
L’administrateur s’est connecté à la plateforme.
La plateforme est opérationnelle.

Scénario nominal 1. L’administrateur clique sur le bouton « manage

analystes ».
2. Le système affiche l’interface de gestion des
utilisateurs
3. L’administrateur clique sur le bouton d’ajout
4. Le formulaire d’ajout est ouvert
5. L’administrateur remplit le formulaire
6. L’administrateur enregistre les données.

Scénario alternatif Le système affiche un message erroné.

Post-conditions Un utilisateur ajouté dans la base de

la plateforme
Le système attend désormais qu’il exécute une nouvelle action.
b) Description textuelle du cas « Consulter les utilisateurs »
Tableau 9 : Description textuelle du cas « Consulter les utilisateurs »
Résumé Acteur : administrateur
Titre : Consulter les utilisateurs
Description : le système permet à ce niveau l’administrateur de
consulter les utilisateurs
Pré-conditions L’administrateur s’est connecté à la plateforme.
La plateforme est opérationnelle.

Scénario nominal 1. L’administrateur clique sur le bouton « manage

analystes ».
2. Le système affiche l’interface de gestion des
utilisateurs
3. L’administrateur consulte tous les utilisateurs

Scénario alternatif Le système affiche un message erroné.

Post-conditions Le système attend désormais qu’il exécute une nouvelle action.

c) Digramme de séquence système du cas « Gérer les utilisateurs »

 Figure 28:Diagramme de séquence système du cas « Gérer des utilisateurs »

d) Diagramme de séquence détaille du cas « Ajouter un utilisateur »

 Figure 29:Diagramme de séquence système du cas « Ajouter un utilisateur »

e) Diagramme de séquence du cas « Modifier un utilisateur »

Figure 30:Diagramme de séquence système du cas «  Modifier un utilisateur »

 f) Diagramme de séquence du cas « Consulter un utilisateur »

Figure 31:Digramme de séquence système du cas « Consulter les utilisateurs »

6. Conception des cas d’utilisation

a) Diagramme de séquence détaillé du cas « S’authentifier »

La figure 11 nous a présenté le diagramme de séquence détaillé du cas « s’authentifier »

 Figure 11:Diagramme de séquence détaillé du cas « S'authentifier »

b) Digramme de classes participantes du cas « S’authentifier »

La figure ci –dessous présente le diagramme de classes participantes du cas « s’authentifier »

Figure 12:Diagramme de classes participantes du cas « S'authentifier »

c) Diagramme de séquence système détaillé du cas « gérer les utilisateurs »

Figure 29:Diagramme de séquence détaillé du cas « Gérer les utilisateurs »

d) Diagramme de séquence système du cas « Ajouter un utilisateur »
 Figure 30:Diagramme de séquence détaillé du cas « Ajouter un utilisateur »
e) Diagramme de séquence système détaillé du cas « Modifier un utilisateur »

Figure 31:Diagramme de cas détaillé du cas « Modifier un utilisateur »

f) Diagramme de séquence système détaillé du cas « Consulter les statistiques »

Figure 32:Diagramme de séquence détaillé du cas « Consulter les utilisateurs »

g) Diagramme de classes participantes du cas « Gérer les utilisateurs »

 Figure 33:Digramme de classes participantes du cas « Gérer les utilisateurs »
h) Diagramme de classes participantes du cas «  Modifier un utilisateur »
 Figure32:Diagramme de classes participantes du cas « Modifier un utilisateur »
i) Diagramme de classes participantes du cas « Ajouter un utilisateur »
 Figure33:Diagramme de classes participantes du cas « Ajouter un utilisateur »
j) Diagramme de classes participantes du cas Consulter les utilisateurs
 Figure 34:Diagramme des classes participantes du cas Consulter les utilisateurs

5. Diagramme de classe globale

La figure 31 présente le diagramme de classe globale du deuxième sprint
Figure 35:Diagramme de classe globale du deuxième sprint
 6. codage

Dans le schéma ci-dessous nous présentons les tables de notre base de données

 Schéma de la base de données «Administrateur»

Attribut Type Contrainte

idAdministrateur Long Primary Key
lastName String Not null
firstName String Not null
Password String Not null
Mail String Not null

 Schéma de la base de données « Group »

Attribut Type Contrainte

idGroup Long Primary Key
nameGroup String Not null

 Schéma de la base de données « Groupes_users »

Attribut Type Contrainte

idUser Long Foreign Key

idGroup Long Foreign Key

7. Test

 Interface d’authentification

Figure 36:Interface d'authentification

 Interface de contrôle dans la phase d’authentification

Cette interface présente le contrôle appliqué sur la phase de l’authentification

Figure 37:Interface de contrôle d'authentification

 Cette interface présente la phase consultation des utilisateurs
 Interface de consultation des utilisateurs

Figure 38:Interface de consultation des utilisateurs

Cette figure présente la phase d’ajout d’un utilisateur

 Interface d’ajout d’un nouvel utilisateur

Figure 39:Interface d'ajout d'un nouvel utilisateur

Cette figure présente la phase de modification d’un utilisateur

 Interface de modification d’un utilisateur existant

Figure 40:Interface de modification d'un utilisateur existant

8. Conclusion
Dans ce chapitre, nous nous sommes intéressés à la réalisation des fonctionnalités de notre
solution et les déroulements de chacun du second sprint. Nous avons aussi achevé e
réalisation de toute notre application à travers ce sprint et fourni un livrable à notre product
owner.
 Chapitre 5 : Phase de
clôture

Chapitre 5: Phase de clôture

1. Introduction
Dans ce dernier chapitre notre objectif est de présenter la phase ultime d’un cycle de
développement avec scrum. Au début nous commençons pour citer les différents outils
bureautiques, technologiques et environnement de développement que nous avons adopté
dans la création de notre plateforme. Nous finirons par la présentation du déploiement de
l’application.

I. Environnement de développement
1. Environnement matériel
Le tableau ci-dessous présente les matériels utilisés

Tableau 7 : Environnement matériel

Caractéristique 1 2
Ordinateur HP HP
Propriétaire Agha Mohamed Mehdi Boubaker Allaedine
Processeur Core i3 Core i3
Ram 4Go 4 G0
Disque dur 500 Go 1TO
Système d’exploitation Windows 7 Windows 10 Professional 64
Professional 64 bits bits

2. Environnement logiciel

 Eclipse est un projet de la Fondation Eclipse visant à développer tout un

environnement de développement libre, extensible, universel et polyvalent.

Son objectif est de produire et fournir divers outils gravitant autour de la réalisation de
logiciel, englobant les activités de codage logiciel proprement dites (avec notamment
un environnement de développement intégré) mais aussi de modélisation, de conception,
de test, de reporting, etc. Son environnement de développement notamment vise à la
généricité pour lui permettre de supporter n'importe quel langage de programmation.
Le projet Eclipse est pour cela organisé en un ensemble cohérent de projets logiciels distincts,
sa spécificité tenant à son architecture totalement développée autour de la notion de plugin (en
conformité avec la norme OSGi) : toutes les fonctionnalités de l'atelier logicieldoivent être
développées en tant que plug-in bâti autour de l'IDE Eclipse Platform.
http://dictionnaire.sensagent.leparisien.fr/Eclipse%20(logiciel)/fr-fr/

 Visual code studio est un nouveau type d'outil qui combine la simplicité d'un
éditeur de code avec ce dont les développeurs ont besoin pour leur cycle principal
d'édition- construction-débogage. Le code fournit une prise en charge complète de
l'édition et du débogage, un modèle d'extensibilité et une intégration légère avec les
outils existants.

VS Code est mis à jour tous les mois avec de nouvelles fonctionnalités et corrections de
bugs. Vous pouvez le télécharger pour Windows, macOS et Linux sur le site Webde VS
Code . Pour obtenir les dernières versions chaque jour, vous pouvez installer la version
Insiders de VS Code . Cela construit à partir de la branche principale et est mis à jour au
moins tous les jours.

https://translate.googleusercontent.com/translate_c?depth=1&hl=fr&prev=search&rurl=transl
ate.google.tn&sl=en&sp=nmt4&u=https://github.com/Microsoft/vscode&xid=17259,1570002
1,15700124,15700149,15700168,15700173,15700186,15700189,15700201&usg=ALkJrhj2r
G.PQfAITvH2r5yux1YtZm46IA

 Wampest une plate-forme de développement Web sous Windows pour des

applications Web dynamiques à l’aide du serveur Apache2, du langage de scripts PHP
et d’une base de données MySQL. Il possède également PHPMyAdmin pour gérer
plus facilement vos bases de données.

http://www.wampserver.com/

 PhpMyAdminUn des outils permettant de manipuler une base de données MySQL.

Il est livré avec WAMP.
  Postman L'application Postman est un outil pratique pour tester une API dans API
Gateway. Les instructions suivantes vous guident dans les principales étapes
d'utilisation de l'application Postman pour appeler une API.
 Word est le logiciel phare de la suite Bureautique Microsoft Office. C'est l'un des
logiciels les plus utilisés dans le monde et permet de rédiger des lettres, CV, rapports
et tous types de documents texte. Word permet de mettre en page vos documents, de
générer des sommaires, de numéroter automatiquement des pages, corriger
automatiquement la grammaire et l'orthographe, de créer des schémas, de faire du
publipostage. Word est plutôt bien conçu et facile à prendre en main, il vous permettra
de rédiger lettres et courriers, ou encore de mettre en forme votre CV.
https://cours-informatique-gratuit.fr/dictionnaire/microsoft-office-word/

3. Choix technologiques
 Spring est un socle pour le développement d'applications, principalement d'entreprises
mais pas obligatoirement. Il fournit de nombreuses fonctionnalités parfois redondantes
ou qui peuvent être configurées ou utilisées de plusieurs manières : ceci laisse le choix
au développeur d'utiliser la solution qui lui convient le mieux et/ou qui répond aux
besoins.

Spring est ainsi un des Framework les plus répandus dans le monde Java, sa
popularité a grandie au profit de la complexité de Java EE notamment pour ses versions
antérieures à la version 5

Spring s’appuie sur un concept important des quels nous avons tiré profit dans notre
solution.

 Angular 5 Après une sortie au mois de mars 2017 d’Angular 4, il est déjà temps
d’accueillir Angular 5 en attendant Angular 6 prévu pour mars 2018. Pour ceux qui
l’ignorent, Angular c'est le nom d’un outil mis à disposition par Google qui sert à
donner du bonheur aux développeurs d’application javascript. Du bonheur car l’outil
est complet, la communauté nombreuse et qu’il nous permet de nous concentrer avec
plaisir sur les problématiques client.
4. Conception Architecturale

4.1. Choix de l’architecture de l’application

Pour tout projet difficile, l’architecture nous permet une bonne manipulation des ressources
pour avoir une bonne solution qui répond bien aux besoins définis.
Ainsi, nous avons fixé notre choix l’architecture logicielle Client/serveur 3 tiers pour notre
application.

4.2. Architecture MVC

//http://www.memoireonline.com/04/15/9014/m_Mise-en-place-dun-systeme-dinformation-
geographique-pour-la-propriete-fonciere-au-Camerou8.html

L’architecture MVC (modèle, vue et contrôleur) est un concept très puissant qui
intervient dans la réalisation d’une application. Son principal intérêt est la séparation des
données (modèle), de l’affichage (vue) et des actions (contrôleur).
Ce concept peut très bien être appliqué à un site internet. De nombreux sites internet disposent
d’une plateforme d’administration pour modifier facilement les contenus. Il est bien évident
que l’utilisateur qui va utiliser ce système pour créer des pages ne doit pas modifier la
structure complète du site, ni les actions ni l’affichage. Pour qu’il ne modifie que les données,
celles-ci doivent alors être isolées. C’est sur ce constat que se base le système MVC. Chaque
partie est bien distincte. Les données peuvent provenir d’une source quelconque et la vue peut
être conçue par des webdesigners n’ayant pas de connaissance en programmation.
L’approche MVC apporte de réels avantages :
 Une conception claire et efficace grâce à la séparation des données de la vue et du
contrôleur

 Un gain de temps de maintenance et d’évolution du site

 Figure40: Architecture MVC
https://mouradev.wordpress.com/tag/patron-darchitecture-logicielle/

Nous avons appliqué cette architecture à notre travail parce qu’elle nous offre de réels avantages
notamment la bonne organisation des données, la conception claire composée par la vue et le
contrôleur et le gain de temps voire la maintenabilité de l’application.

Cette architecture est représentée par la figure suivante :

Figure 41: Architecture MVC

https://www.google.tn/search?q=architecture+mvc&rlz=1C1AVNG_frTN7
17TN717&source=lnms&tbm=isch&sa=X&ved=0ahUKEwj60MuesILbAh
XNZlAKHQDTCgUQ_AUICigB&biw=1366&bih=637#imgrc=dUWHY3eA
g2IHxM:
5. Diagramme de déploiement

Dans le contexte du langage de modélisation unifié (UML), un diagramme de déploiement

fait partie de la catégorie des diagrammes structurels et décrit un aspect du système lui-même.
Dans le cas présent, le diagramme de déploiement décrit le déploiement physique sur des
composants matériels des informations générées par le logiciel. L'information qui est générée
par le logiciel est appelée artefact. À ne pas confondre avec l'utilisation qui est faite du terme
dans d'autres approches de modélisation comme le BPMN.

Les diagrammes de déploiement sont constitués de plusieurs formes UML. Les boîtes en trois
dimensions, appelées nœuds, représentent les composants du système, qu'ils soient logiciels
ou matériels. Les lignes entre les nœuds indiquent les relations et les petites formes à
l'intérieur des boîtes représentent les artefacts logiciels qui sont déployés.

https://www.lucidchart.com/pages/fr/tutoriel-sur-les-diagrammes-de-
d%C3%A9ploiement

La figurer 43 présente le diagramme de déploiement de notre plateforme

Figure 42:Diagramme de déploiement

6. Conclusion
Ce chapitre nous a permis de mettre en avant les phases nécessaires à la
réalisation de notre application à savoir les outils de développement matériels
et logiciels, aussi que l’architecture du système. Nous avons présente
finalement le diagramme de déploiement.
 Conclusion Générale

Conclusion générale
Notre stage au sein de l’entreprise VERMEG a été non seulement une opportunité pour nous
d’explorer et mettre en pratique nos connaissances acquises lors de notre cursus universitaire
à l’ESEN, mais aussi, un atout pour nous intégrer au sein du milieu professionnel du
développement informatique qui joue un rôle primordial dans notre formation.

Pendant ce stage, avons appris comment comment planifier, diriger notre temps et mettre en
pratique nos connaissances pour aboutir à nos objectifs et c’est également grâce à la présence
et au support de nos encadrants.

L’objectif de ce projet de fin d’étude était de réaliser la conception et le développement d’une

plateforme qui permet d’analyser un fichier log.

Nous avons contraintes dans la phase de développement. En effet nous avons passé beaucoup
de temps pour comprendre et maitriser les langages utilisés puisqu’nous n’avons pas eu la
chance de les étudier lors de notre formation.

Nous avons commencé dans ce rapport par la description du contexte général de notre stage
qui a eu lieu au sein de l’entreprise VERMEG suivie d’un deuxième chapitre d’analyse du
projet dans lequel nous avons défini le cadre de projet et établi le choix de la méthodologie
Agile « SCRUM ».

Les deux chapitres suivants : « Sprint1 : Analyse d’un fichier log et statistiques » et «
Sprint2 : Gestion utilisateurs et authentification », étaient le cœur de notre travail. Nous y
avons effectué une spécification des user stories, une schématisation des diagrammes des cas
d’utilisations et la conception de ces derniers, le codage, les tests, le rétrospective et la revue
de sprints.

Ensuite, le dernier chapitre de ce rapport était une phase de clôture au cours de laquelle nous
avons présenté les langages les outils de programmations utilisés pour la réalisation de notre
application et le diagramme de déploiement.
 Conclusion Générale

Cependant, nous pouvons toujours y apporter quelques améliorations qui feront de cette
application une application meilleure. En ce qui concerne la côté ergonomique de
l’application, nous pouvons également ajouter la partie de demande automatique qui oblige
la plateforme de faire une analyse synchronisé dès que les lignes d’un fichier log dépassent
une limite bien déterminée.

.
 Références bibliographiques

Références bibliographiques