Soutenance 1

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.Mercid’ê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
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é indéfrisable de son système

d’information. Cette réalité influe de nos jours le comportement des entreprises qui devient de
plus en plus mature dans les apports de 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 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 plus d’erreurs.
Ce rapport présente l’ensemble des étapes suivies pour développer la solution. Il contient cinq
chapitres organisés.
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 est intitulé sur l’analyse des besoins fonctionnels, non fonctionnels et
architecturaux. Ensuite nous identifions les acteurs participants et nous modélisons les besoins
des utilisateurs via les diagrammes de cas d’utilisation.
Le troisième chapitre est réservé à la conception et à l’architecture du projet ; nous

commençons dans un premier temps par une étude préliminaire en présentant les packages de
systèmes puis le contenu de chacun de ces derniers, en second temps on présente les
diagrammes de séquences de conception détaillés, les diagrammes d’activités correspondants
aux workflow et le déploiement de l’application.
Le quatrième chapitre quant à lui est dédié à la réalisation. Celui-ci, passe par la présentation
de l’environnement matériels, logiciels et les interfaces de l’application.
1
Pour finir, un chapitre qui contient une conclusion générale de tout le rapport est nécessaire
où nous rappelons de contexte et des besoins puis on décrit le bilan de réalisations nous
proposons les futures améliorations qui peuvent être ajoutées ultérieurement.
2
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 de 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 didactique
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
au sein sous le nom BFI et a été séparé de BFI 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é 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.
3
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é.
4
 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
5
Organisation 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
3.1. Cadre du stage
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.2. Problématique
Parfois les clients de Vermeg souffrent des crushs et des bugs des applications lors des
opérations financières, donc il est difficile de trouver les bugs.
De plus Vermeg, utilise des Outils de surveillance et d’analyse payants .Ces couts
d’installation et de maintenance sont énorme, de plus les utilisateurs dans l’équipe de
Palmyra trouve des difficultés au niveau d’utilisation de ces outils de surveillance de logs.
D’où l’idée est de créer une plateforme d’analyse des fichiers de log dédié à la société et
l’équipe.
3.3. Objectifs
L’objectif principal est le développement d’une plateforme d’analyse de log qui facilite aux
utilisateurs et les analystes d’analyser ces fichiers en se basant sur des filtres bien déterminer
au niveau d’application et de filtrer leur résultat avec des autres filtres et de gérer des
statistiques .
3.4. Travail demandé

Le projet sur lequel nous allons travailler consiste à avoir une plateforme d’analyse de log de
Framework Palmyra dans Vermeg. Il s’agit de mettre en place une solution web qui se charge
d’analyser des fichiers logs.
6
Cette analyse va être programmée en se basant sur des filtres (les niveaux, date adresse IP,
adresse MAC, description et les requêtes SQL). 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.
7
4.3. Notion du fichier 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.
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
8
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 sourcebaptisé, il est capable de collecter, indexer et analyser des
données structurées et non structurées en provenance de diverse sources.
Ce logiciel offre plusieurs avantages comme :
 L’accès à l’interface web nécessite un login et un mot de passe.

 Il permet d’analyser les logs en temps réel.
Figure 2.3: Aperçu de l’interface Graylog
9
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
Chacun de ces applications ont des malaises qui ne peuvent pas l’oublier, nous citons par
exemple pour la première solution KIBANA elle est complexe et elle nécessite une
formation pour pouvoir la comprendre.
Graylog, elle est utilisable sauf sur le système d’exploitation Linux.
Concernant Log surfer, il est très difficile à configurer, il ne permet que l’envoie des alertes
en temps réel.
En effet, cet outil nécessite des collaborateurs dédiés à des taches plus complexes.
10
7. Solution Proposée
Dans le but de rendre la lecture des fichiers logs génères par le Framework Palmyra plus
lisible, simple et plus Compréhensible.
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 offres aux analystes de Vermeg et
l’équipe Palmyra la possibilité d’avoir plusieurs interfaces sur le fichier log via un filtre 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/
11
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
12
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.
13
 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
14
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.
« Burndown charts » : (Graphique d’avancement)

C’est un diagramme qui permet de visualiser l’avancement des sprints et du projet dans
sa globalité, c’est l’indicateur temporel de l’évolution des tâches en cours dans le Sprint.
L’axe vertical présente la quantité de travail à faire et l’axe horizontal les jours de travail.
http://geekandmore.fr/tag/scrum
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
15
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.
16
Chapitre 2 Analyse du projet
Chapitre 2 : Analyse du projet
1. Introduction
Pour 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 3 acteurs
suivants L’administrateur, le référent projet et l’analyste sont les figurants
interagissant dans 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. Pour le référent projet et l’administrateur, ils ont l’autorisation de faire une
configuration. Ainsi l’administrateur est le seul acteur qui a la possibilité de gérer
l’utilisateur en modifiant un utilisateur existant ou d’ajouter 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é
17
 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 de 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 équipepré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 de 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 :
18
Tableau 2 : Backlog produit
Thème ID User Stories Description Priorité Complexité
1 S’authentifier En tant que utilisateur je dois 5 ++

s’authentifier afin d’accéder à
mon espace personnel en
sécurité.
Demande une analyse d’un 2 Demande une En tant que utilisateur je veux 1 +++++
fichier Log analyse pouvoir demander une
analyse de fichier log.
Consulter les En tant que administrateur je 4 +

utilisateurs peux consulter tous les
3 utilisateurs.
Gestion des utilisateurs
Ajouter un En tant que administrateur je 2 +++

utilisateur peux ajouter un utilisateur.
4
Modifier un En tant que administrateur je 3 +++

utilisateur peux modifier un utilisateur.
5
existant
Consulter les statistiques 6 Consulter En tant qu’utilisateur je 6 +

statistiques peux consulter les
statistiques
3.3. Planification des sprints du projet
La partie de planification des sprints reste primordiale pour la bonne gestion

d’un projet, elle autorise d’avoir un cheminement optimisé pour le dépeçage et
l’affectation des fonctions selon les priorités, le temps et l’effectif pour que le
produit tente bien les besoins citées par le Product Owner.
19
« 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érale de notre plateforme d’analyse
de log.
Nous y retrouvons comme contenu les acteurs principaux et leurs rôles.
20
Figure 6:Diagramme de cas d'utilisation générale
4. Conclusion
Pendant ce chapitre, nous avons pu dans un premier lieu déterminé les acteurs, les besoins
fonctionnels et non fonctionnels de notre projet. Nous sommes ainsi avancés vers Scrum par
l’identification de l’équipe, du backlog produit et des sprints.
21
Chapitre 3 Sprint 1 « demande d’une analyse d’un fichier log »»
Chapitre 3 Sprint I «Demande d’une

analyse d’un fichier log»
1. Introduction
Comme déjà énoncer 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é de
transporter 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 :
22
Tableau 3 : Backlog du premier sprint
ID Nom de user User story ID Tache Affectation

USER
Story Tache
Story
1 Authentification En tant que 1.1 Réaliser les AllaEddine Boubaker

utilisateur je diagrammes de cas
dois d’utilisation, de classe,
m’authentifier de séquence système et
de séquences détaillées
afin de du cas « s’authentifier »
pénétrer à
mon compte
en sécurité
1.2 Développer le cas Mohamed Mehdi

« s’authentifier » Agha
1.3 Examiner le cas AllaEddine Boubaker

« s’authentifier »
2 Demande une En tant que 2.1 Réaliser les Mohamed Mehdi

analyse utilisateur je diagrammes de cas Agha
peux analyser d’utilisation, de classe,
un fichier log de séquence système et
de séquences détaillées
du cas « Demande une
analyse »
2.2 Développer le cas AllaEddine Boubaker

« demande une
analyse »
2.3 Tester le cas « demande Mohamed Mehdi

une analyse» Agha
23
2.2. Prototypage des interfaces
Ce paragraphe est dédié à l’illustration de quelques prototypes des interfaces de ce

sprint comportant les fonctionnalités nécessaires.
 Prototype de l’interface "s’authentifier"
Figure 7:Prototype de l'interface « S'authentifier »

 Prototype de l’interface "Demande une analyse "
Figure 8:Prototype de l'interface demande une analyse
24
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: Raffinement du cas d'utilisation du premier sprint
4. Analyse des cas d’utilisation
4.1. Analyse de cas « S’authentifier »
Description textuelle du cas « S’authentifier »
Le tableau 3 représente une description textuelle du cas d’utilisation « S’authentifier »
Tableau 3 : Description de cas d’utilisation « S’authentifier »
Etapes Description
Résumé
Acteur : Analyste
Titre : s’authentifier.
Description : le système identifie à ce niveau l’administrateur, analyste et
référent projet qui veulent utiliser la plateforme.
Pré-conditions L’analyste n’est pas authentifié
Le système est opérationnel.
25
Scénario
nominal L’analyste entre ses paramètres de connexion mail et mot de passe.
Le système vérifie les informations saisies.
Le système affiche l’espace de travail de chaque utilisateur.
Scénario
alternatif Les données sont erronées.
Le système affiche un message d’erreur que l’analyste n’existe pas.
Post-conditions
L’analyste est sur son espace de travail. Le système attend désormais qu’il
exécute une nouvelle action.
Diagramme de séquence système du cas « S’authentifier »

La figure 10 nous présenté le diagramme de séquence système du cas de l’authentification
Figure 10:Diagramme de séquence système du cas « S'authentifier »
Diagramme de séquence système du cas « S’authentifier »
26
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 »
Digramme de classes participantes
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 »
4.2. Analyse de cas « Demande une analyse »
27
Description textuelle du cas « Demande une analyse »
Le tableau 4 représente une description textuelle du cas d’utilisation « S’authentifier »
Tableau 4 : 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, utilisateur et
référent projet qui veulent analyser un fichier log.
Pré-conditions
L’analyste veut analyser les fichiers log.
L’utilisateur s’est connecté à la plateforme.
La plateforme est opérationnelle.
Scénario nominal
L’analyste s’authentifie.
Le système affiche l’espace de travail de chaque utilisateur.
L’acteur entre dans l’interface « Request analyses »
L’administrateur, l’analyste et le référent projet donne le chemin de
fichier log à analyser.
Ensuite, il choisit le modèle de configuration.
L’administrateur, l’analyste et le référent de projet clique sur le bouton
« analyser ».
Scénario Le système affiche un espace de travail vide puisque l’utilisateur n’jamais
alternatif
analysé un fichier log.
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.
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 »
28
Figure 13:Diagramme de séquence système du cas « Demande une analyse »
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 »
Diagramme de classes participantes du cas « Demande une analyse »
Ce diagramme nous présente le diagramme de classes participantes du cas « demander

une analyse »
29
5. Conception
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
30
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égle1 : Une entité est traduite en relation.
 Régle2 : Une association «un à plusieurs » engendre la migration de la clé primaire de
la relation mère à la relation fille en clé étrangère.
 Régle3 : Une association «plusieurs à plusieurs » est représentée par une relation dont
la clé primaire est composé par les clés primaires des relations associées.
Med. Bach Tobji. Cours Bases des données. Ecole Supérieure d’Economie Numérique Manouba.
2015.
 Schéma de la base de données «Analyste»
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 « Group »

idGroup Long PrimaryKey
nameGroup String Not null
 Schéma de la base de données « Groupes_users »

idAnalyst Long Foreign Key
idGroup Long Foreign Key
31
 Schéma de la base de données « Log »

idLog Long Primary Key
pathFile String Not null
 Schéma de la base de données « Record »

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 d’authentification
Figure 16:Interface d'authentification
32
 Interface de contrôle dans la phase d’authentification

Cette interface présente le contrôle appliqué sur la phase de l’authentification
Figure 17:Interface de contrôle d'authentification
 Interface demande d’une analyse
Cette interface présente l’interface de demande d’une analyse
Figure 18:Interface demande d’une analyse
33
 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.
34
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.
35
Chapitre 4 Sprint 2 « Gestion des utilisateurs »
Chapitre 4 Sprint 2 «Gestion des

utilisateurs»
1. Introduction
Après avoir réalisé le premier sprint, cette partie sera consacrée à la réalisation du second,
nous analysons les « user stories » en donnant une description détaillée de chaque cas
d’utilisation « user story », présentons la gestion des utilisateurs qui fait une grande partie de
ce sprint et même de l’application entière et aussi nous allons décortiquer le user story de
consultation des statistiques. Nous y présentons également la conception globale du sprint.
Enfin, nous abandonnons par la phase de codage et de test.
2. Sprint fonctionnelle
C’est au niveau de ce sprint que nous allons réaliser la tache de gestion des utilisateurs et de
consultation des statistiques
2.1. Sprint backlog
ID Nom de user User story ID Tache Affectation

USER
Story Tache
Story
1 Consulter les En tant que 1.1 Réaliser les AllaEddine

statistiques utilisateur je diagrammes de cas Boubaker
d’utilisation, de classe,
peux consulter
de séquence système
les statistiques et de séquences
détaillées du cas
après avoir « Consulter les
analysé un statistiques »
fichier
1.2 Développer le cas Mohamed Mehdi
« Consulter les Agha
statistiques »
36
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 des
données des
utilisateurs »
utilisateurs, en
2.2 Développer le cas AllaEddine
modifiant un
« Gestion des Boubaker
utilisateur utilisateurs »
existant ou
d’ajouter un
2.3 Tester le cas « Gestion Mohamed Mehdi
nouvel utilisateur des utilisateurs » Agha
2.2. Prototypages des interfaces
 Interface de consultation des statistiques
Figure 20:Prototype de l'interface « consulter les statistiques »

 Interface de consultation des utilisateurs
37
Figure 21:Prototype de l'interface « consulter les utilisateurs »

 Interface de modification des utilisateurs
Figure 22:Prototype de l'interface « modifier un utilisateur »

 Interface de création d’un nouvel utilisateur
Figure 23:Prototype de l'interface ajouter un utilisateur
38
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 « Consulter les statistiques »
Description textuelle du cas « 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.
Scénario nominal
L’utilisateur s’authentifie.
L’administrateur, l’analyste et le référent projet consulte leurs
statistiques
39
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.
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 »
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
40
Diagramme de classes participantes du cas « Consulter les statistiques »
Figure 27:Diagramme de classes participantes du cas Consulter les statistiques
4.2. Analyse du cas « Gérer des utilisateurs »

Description textuelle du cas « Gestion des utilisateurs »
Tableau 6 : Description de cas d’utilisation « Gérer des utilisateurs »
41
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 veut modifier ou ajouter un utilisateur.
L’administrateur s’est connecté à la plateforme.
Scénario nominal L’administrateur s’authentifie.

Le système affiche l’espace de travail de l’administrateur.
L’administrateur clique sur le bouton « manage analystes ».
Le système affiche l’interface de gestion des utilisateurs.
Si l’administrateur veut modifier un utilisateur existant.
L’administrateur choisit l’utilisateur à modifier.
L’administrateur clique sur le bouton « update ».
Le système affiche les informations de l’utilisateur choisi.
L’administrateur modifie les informations.
Finalement, il clique sur le bouton « Save »
Sinon, l’administrateur ajoute un nouvel utilisateur.
L’administrateur clique sur le bouton « Create ».
L’administrateur remplit le formulaire.
L’administrateur clique sur le bouton « Save ».
Scénario alternatif Le système affiche l’interface « manage analystes » vide puisque
l’utilisateur n’a pas d’utilisateurs.
Post-conditions L’administrateur ajoute un utilisateur.
Ou modifie un utilisateur existant
42
Figure 28:Diagramme de séquence système du cas « Gérer des utilisateurs »
Diagramme de séquence système détaillé du cas « gérer les utilisateurs »
43
Figure 29:Diagramme de séquence détaillé du cas « Gérer les utilisateurs »
Diagramme de classes participantes du cas « Gérer les utilisateurs »
44
Figure 30:Digramme de classes participantes du cas « Gérer les utilisateurs »
5. Diagramme de classe globale

La figure 31 présente le diagramme de classe globale du deuxième sprint
45
Figure 31: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 «Analyste»

idAnalyste Long Primary Key
46
 Schéma de la base de données «Administrateur»

idAdministrateur Long Primary Key
 Schéma de la base de données « Group »

idGroup Long Primary Key
nameGroup String Not null
 Schéma de la base de données « Groupes_users »

idAnalyst Long Foreign Key
idGroup Long Foreign Key
 Schéma de la base de données « Log »

idLog Long Primary Key
pathFile String Not null
47
 Schéma de la base de données « Record »

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
Cette interface présente la phase consultation des utilisateurs
Interface de consultation des utilisateurs
Figure 32:Interface de consultation des utilisateurs
48
Cette figure présente la phase d’ajout d’un utilisateur
 Interface d’ajout d’un nouvel utilisateur
Figure 33: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 34:Interface de modification d'un utilisateur existant
49
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 de nos sprints. Nous avons décelé cette réalisation à
travers un ensemble d’interfaces accompagnées de descriptions et interprétations.
50
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 par la citation des différents outils
bureautiques, technologiques et environnement de développement que nous avons adopté dans la
création de notre plateforme. On fermera 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 environnementde développement notamment vise à la généricité
pour lui permettre de supporter n'importe quel langage de programmation.
51
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-P QfAITvH2r5yux1YtZm46IA
 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.
52
 PostmanL'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.
53
4. Conception Architecturale
4.1. Choix de l’architecture de l’application
Egalement pour tout projet difficulteux, l’architecture nous conserve une bonne manipulation
des ressources pour avoir une bonne réponse qui répond bien aux besoins prématurément
définis.
Ainsi, nous avons fixé notre choix d’architecture logicielle de notre application ce qui
implique le choix des technologies, des produits et des serveurs utilisés. Cela fait de notre
application une application à architecture Client/serveur 3 tiers.
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
54
Figure 35: 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 36: 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:
55
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 37: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 l’architecture du système et nous avons présente le diagramme de
déploiement.
56
57
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 de notre cursus universitaire à
l’ESEN, mais aussi, un atout pour s’intégrer au sein du milieu professionnelle du
développement informatique qui joue un rôle primordiale dans notre formation.
Pendant ce stage, nous nous sommes gavés comment planifier, diriger notre temps et mettre
en pratique nos connaissances pour décrocher 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 faire 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 à étudier ces derniers.
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 le cadre de projet et établi le choix de la méthodologie Agile «
SCRUM ».
Les deux chapitres suivants : « Sprint1 : Demande d’une analyse d’un fichier log » et «
Sprint2 : Gestion utilisateurs », étaient le cœur de notre travail. Ils se distribuent en 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 le revue du sprint
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.
Cependant, nous pouvons toujours y apporter quelques améliorations qui feront de cette
application. En ce qui concerne la côté ergonomique de l’application. En effet nous pourrons
58
Conclusion Générale
aussi 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.
Enfin, nous pouvons même développer une plateforme qui permet d’analyser les fichiers log
spécifiques à l’ESEN.
59
Références bibliographiques
Références bibliographiques
60

Langue

Soutenance 1

Transféré par

Informations du document

Titre original

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Soutenance 1

Transféré par

Droits d'auteur :

Université de la Manouba

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

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

Agha Mohamed Mehdi

Organisme d’accueil : VERMEG

Année universitaire : 2017-2018

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

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

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

A mon père parfait MUSTAPHA,

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,

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

A mes amis et mes collègues,

Qui ont contribué à mon épanouissement.Mercid’être toujours près de moi,

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

Le troisième chapitre est réservé à la conception et à l’architecture du projet ; nous

Chapitre 1 : Contexte Général

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

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

VERMEG a participé pleinement à la création de l’association TACT, qui regroupe des

Figure 1.1: Vermeg Logo

2.1. Produits de VERMEG

Figure 1.2 : Palmyra Logo

 MEGACUSTODY : C’est un logiciel de livraison, lui aussi récompensé par le label

2.2. Unité d’accueil

Figure 1.3:Organisation de VERMEG

VERMEG Groupe compte 4 principales unités à savoir :

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

3.4. Travail demandé

4.2. Analyseurs de log existants

4.3. Notion du fichier Log

5. Etude d’analyseurs de log existants

Figure 2.1 : Aperçu de l’interface Kibana

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

Figure 2.2 : Utilisation d’ELK

Ce logiciel offre plusieurs avantages comme :

 L’accès à l’interface web nécessite un login et un mot de passe.

Figure 2.3: Aperçu de l’interface Graylog

5.3. Log Surfer

Critères fonctionnels ELK Graylog Log Surfer

Complexité Oui Non Non

Tableau 1 : Etude Comparative

Graylog, elle est utilisable sauf sur le système d’exploitation Linux.

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

a. Les quatre valeurs fondamentales Agiles

Individus et interactions au lieu de processus et outils.

b. Les principales méthodes agiles

 Extreme Programming (XP)

 Adaptive Software Développement (ASD)

8.2. Méthodologie agile adoptée : Scrum

Figure1.5 Méthode Scrum

8.2.1. Justification du choix de la méthodologie

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

 Le Product Owner : Il s’agit du représentant officiel du client au sein d’un projet

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

 Product Owner : Equipe Palmyra

a. Les artéfacts dans Scrum

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

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

« Burndown charts » : (Graphique d’avancement)

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