Rapport Hamdoun - Bouthelja Ssice

République Tunisienne
Ministère de l’Enseignement Supérieur,

de la Recherche Scientifique et de la Technologie
--
Université Tunis El Manar
Code : SSICE18
Mémoire de Mastère
Pour l’obtention d’un Mastère Professionnel en informatique
Option: Sécurité des Systèmes Informatiques communicants et Embarqués
(SSICE)
Intitulé :
CONCEPTION ET DÉVELOPPEMENT D’UNE
APPLICATION DE GESTION DU SUIVI DE MISSION
D’AUDIT
Réalisé par :
HAMDOUN Emir BOUTHELJA Safa
Organisme d’accueil :
Keystone Consulting
Encadré par :
Encadrant de l’entreprise : Monsieur ELMIR Haythem
Encadrant à l’ISI : Monsieur KHALFALLAH Adel

Mémoire de fin d’études 2012/2013
Dédicaces
Du plus profond de mon cœur et avec le plus grand plaisir de ce monde, je dédie ce travail :
A mes très chers parents Abdessatar et Lamia pour tous les sacrifices qu’ils ont consentis pour
mon éducation et pour tout ce qu’ils ont enduré pour satisfaire toutes mes sollicitations.
Que le dieu les préserve en bonne santé et longue vie
A Mon cher Frère et ma chère sœur Wassim et Marwa.

A qui je souhaite un avenir radieux Plein de bonheur et de succès.
Que dieu vous bénisse et vous accorde joie, santé et longue vie.
A Ma grand-mère Wissal celle qui m’a fait l’honneur d’être ma grand-mère.

En témoignage de mon amour et mon grand attachement J’espère que tu seras toujours en pleine
santé. Que Dieu vous bénisse et vous accorde joie, santé et longue vie.
A toutes la famille HAMDOUN et CHERIF

Celles que je suis fier d’être un d’entre eux.
Que dieu vous bénisse et vous accorde joie, santé et longue vie.
A Mes très chers cousins Ismail et Ahmed

Avec mes meilleurs sentiments et mon profond respect.
Que Dieu vous bénisse et vous accorde joie, santé et longue vie.
Emir HAMDOUN
Dédicaces
En signe de reconnaissance, je dédie ce mémoire à :
A Mes chers parents Salah et Hayet
A mes adorables sœurs Soumaya, Yosra, Kawther,
Dhouha et Hajer
Pour leur amour, leur affectation, leur soutien et tous leurs sacrifices
Pour que je puisse achever mes études.

Que dieu les gardes
A mon binôme Emir

Pour toutes ses aides et ses encouragements.
A Mes chers frères Ahmed et Taieb

Pour leurs soutiens moraux.
A mes chères cousines

Pour leurs soutiens.
A Toute la famille Bouthelja et Mensi
A Tous mes amis sans exception
Et a tous ceux qui m’ont aidé de prés ou de loin à la réalisation de ce travail.
Safa BOUTHELJA
Remerciements
Tout d’abord nous tenons à remercier le bon Dieu pour la bonne foi, la force et la
patience qu’il nous a accordées pour pouvoir accomplir ce travail.
De même, nous présentons nos remerciements les plus sincères à nos encadreurs Mr
ELMIR Haythem et Mr KHALFALLAH Adel pour leurs aides, leurs patiences, leurs conseils et
pour l’intérêt dont ils ont fait preuve tout au long de la réalisation de ce travail.
Nos vifs remerciements s’adressent aussi aux membres de jury qui nous ont fait
l’honneur de bien accepter d’évaluer ce projet.
Finalement, nous remercions toutes les personnes qui ont contribué directement ou
indirectement à la réalisation de ce travail, et nous tenons à leur exprimer toute notre gratitude.
Abstract
This report is part of our graduation project entitled "Auditor Manager Dashboard". This project
aims to design and implementation of an application to monitor the mission of an auditor, the
analysis of vulnerability reports and the automatic generation of customized audit reports in
order to manage security aspect of the enterprise. This project was conducted within “Keystone
Consulting” over a period of four months.
To achieve the project, we used UML for application design, and we used the programming
language Java, JavaEE platform, the JAXB API, the JSF framework, MySQL database and the
Hibernate framework for Object/Relational Mapping.
Keywords: Audit, Vulnerability, Report of audit, spring, JavaEE, JSF, Hibernate, JAXB.
Résumé
Ce rapport s'inscrit dans le cadre de notre mémoire de fin d'études qui consiste en la
conception et le développement d'un système de gestion d’une mission d’audit « Audit Managing
Dashboard » permettant de faire le suivi d’une mission d’audit technique au sein d’une
entreprise ainsi qu’une analyse des rapports de vulnérabilités et faire le suivi de sa sécurité par la
génération des rapports personnalisés. Ce projet a été effectué au sein de « Keystone
Consulting » sur une période de quatre mois.
Pour la réalisation du projet, nous avons utilisé UML pour la conception de l'application, et nous
avons utilisé le langage de programmation Java, la plateforme JavaEE, le Framework JSF, le
SGBD MySQL et le framework JAXB pour le parsing XML et le framework Spring intégrant le
framework de mappage Objet/Relationnel Hibernate.
Mots clés : Audit technique, vulnérabilités, rapports d’audit, Spring, JavaEE, JSF, Hibernate,
JAXB.
Table des matières
Chapitre 1 : Etat de l’art ...................................................................................... 3

Introduction ................................................................................................................. 3
1- Présentation de l’organisme d’accueil........................................................................ 3
2-L’audit technique ....................................................................................................... 4
2.1-Définition général .......................................................................................................... 4
2.2-Processus d’audit technique ........................................................................................... 4
2.3-Critique de l’existant....................................................................................................... 5
2.4-Contributions ................................................................................................................. 5
Conclusion ................................................................................................................... 6
Chapitre 2 : Spécification des besoins ............................................................... 7
Introduction ................................................................................................................. 7
1-Besoins fonctionnels ................................................................................................. 7
1.1-Les cas d’utilisation : ...................................................................................................... 8
2-Diagramme des cas d’utilisation générale : ................................................................. 9
2.1-Raffinement des cas d’utilisation : ................................................................................ 10
3-Besoins non fonctionnels : ...................................................................................... 18
4-Dictionnaire de donnée : ............................................................................... 18
Conclusion ................................................................................................................. 22
Chapitre 3 : Conception .................................................................................... 23
Introduction ............................................................................................................... 23
1-Architecture technique : .......................................................................................... 23
1.1-Architectures possibles................................................................................................. 23
1.2-Architecture 2-tiers ...................................................................................................... 23
1.3-Architecture adoptée .................................................................................................... 24
1.4-Architecture applicative : .............................................................................................. 25
2-Architecture générale de l’application ...................................................................... 26
2.1-Diagramme de paquetages :.......................................................................................... 26

3-Vue statique :........................................................................................................... 27
3.1-Diagrammes de classe .................................................................................................. 27
4-La vue dynamique ................................................................................................... 30
4.1-Diagramme de séquence de la CU «s’authentifier » ....................................................... 31
4.2-Diagramme de séquence de la CU «add auditor » ......................................................... 32
4.3-Diagramme de séquence de la CU « Delete auditor»................................................. 33
4.4-Diagramme de séquence de la CU «update auditor » ................................................ 34
4.5-Diagramme de la séquence de la CU « Ajouter ressource» ....................................... 35
4.6-Diagramme de la séquence de CU «Editer planning»................................................ 36
Conclusion ................................................................................................................. 37
Chapitre 4 : Réalisation ..................................................................................... 38
Introduction ............................................................................................................... 38
1-Environnement et outils de travail ........................................................................... 38
1.1-Plateforme matérielle ................................................................................................... 38
1.2-Plateforme logicielle ..................................................................................................... 38
2-Réalisation : ............................................................................................................. 41
2.1-Déploiement du système : ............................................................................................ 41
2.2-Interfaces Homme-Machine :....................................................................................... 42
Conclusion ................................................................................................................. 47
Chapitre 5 : Gestion de projet ........................................................................... 48
Introduction ............................................................................................................... 48
1-Modèle de cycle de vie adopté: ................................................................................ 48
2-Planification du projet : ........................................................................................... 50
Conclusion ................................................................................................................. 51
Conclusion et perspectives ............................................................................... 52
Glossaire ............................................................................................................. 54
Bibliographie...................................................................................................... 56
Nétographie ....................................................................................................... 57
AnnexeA ............................................................................................................. 58
Table des figures

Figure 1 : Service d'information fournies par Keystone ......................................................................... 3
Figure 2:Diagramme des Cas d’utilisation générale ............................................................................... 9
Figure 3: Architecture 3 tiers ................................................................................................................ 24
Figure 4 : Architecture MVC2 ................................................................................................................ 25
Figure 5 : Diagramme de paquetages ................................................................................................... 26
Figure 6 : Diagramme de classe modèle ............................................................................................... 28
Figure 7 : Diagramme de classe DAO .................................................................................................... 30
Figure 8 : Diagramme de séquence de la CU « s’authentifier» ............................................................ 31
Figure 9 : Diagramme de séquence de la CU « add auditor » .............................................................. 32
Figure 10 : Diagramme de séquence de la CU« Delete auditor» .......................................................... 33
Figure 11 : Diagramme de séquence de la CU« Update auditor »........................................................ 34
Figure 12 : Diagramme de séquence de la CU «Ajouter ressource » ................................................... 35
Figure 13 : Diagramme de séquence de la CU « Editer planning » ....................................................... 36
Figure 14 : Diagramme de déploiement ............................................................................................... 42
Figure 15 : Interfaces d’ajout d’un chef de projet ................................................................................ 43
Figure 16 : Interfaces d’ajout d’un auditeur ......................................................................................... 43
Figure 17 : Interface de suppression et de mise à jour des utilisateurs .............................................. 44
Figure 18 : Interface d’ajout d’une organisation .................................................................................. 45
Figure 19 : Interface de consultation du planning ................................................................................ 45
Figure 20 : Interface d’édition de planning........................................................................................... 46
Figure 21 : Modèle en spirale ................................................................................................................. 49
Figure 22 : Architecture de Spring 3.0 .................................................................................................. 58
Introduction générale
De nos jours, l’informatique a envahi tous les domaines de la pensée et de l’action de l’humanité.
Elle est devenue une nécessité pour l’homme spécialement pour les entreprises vue qu’elle leur a
permis une gestion facile des données. Bien qu’il soit bénéfique l’informatique peut pousser
l’entreprise vers à une situation d’insécurité informatique menant à des pertes financières très
importantes ou à la divulgation de données stratégiques de l’entreprise.
Dans cette optique, lancer périodiquement un projet d’audit technique au sein d’une
organisation, devient une activité primordiale pour garantir la confidentialité, l’intégrité des
données, la disponibilité des services, l’authenticité et la non répudiation. En effet, la mission
d’audit technique occupe une importance majeure dans le plan de sécurisation d’une
organisation. Elle permet une analyse précise du système d’information de l’organisation pour
mener enfin à des recommandations concrètes.
Dans cette perspective, « keystone consulting » nous a chargés à développer une application
permettant la gestion des projets d’audit technique afin d’automatiser le déroulement et le suivi
de ces derniers, la génération des rapports et la centralisation des informations et des traitements.
Notre projet de fin d’étude a pour but d’étudier, concevoir et développer une application
permettant de faire le suivi d’une mission d’audit.
1
Organisation du rapport
Nous commençons notre rapport par un chapitre d’état d’art contenant une description de
l’organisme d’accueil et une introduction au concept de l’audit technique : les problèmes
rencontrés et les mesures prises pour y remédier. Pour le deuxième chapitre, nous proposons
une spécification des besoins et une conception en se basant sur le langage de modélisation
Unified Modelling Language UML. Le troisième chapitre comportera une présentation de
l’application selon deux vues divergentes : Une conception statique présentée par le diagramme
de classes et une autre, plutôt, dynamique argumentée par les diagrammes de séquence. Le
quatrième chapitre sera consacré à la description de la phase de l’implémentation de notre
système. Avant de décrire quelques captures d’écran de notre application, nous allons dans un
premier temps définir une liste de tous les outils et logiciels utilisés au cours de cette phase. Puis
dans un deuxième temps, nous allons décrire en détail les différents modules et sous modules
composant notre application. Un cinquième chapitre sera normalement consacré à la gestion du
projet où nous comptons présenter le modèle de cycle de vie ainsi que la durée de chaque tâche
du projet. Nous couronnons notre mémoire par une conclusion portant sur tout le projet et des
perspectives ouvrant un horizon sur l’apport de notre application au futur.
2
Chapitre 1 : Etat de l’art
Introduction
Dans ce premier chapitre, nous proposons de mettre le projet dans son contexte général en
l’entamant par une présentation de l'entreprise d'accueil. Ensuite, nous donnerons une brève
définition sur l’audit technique pour mieux l’expliciter ; puis, nous envisageons poser la
problématique et la solution proposée par ce projet. Finalement, nous synthétisons par une
conclusion afin de tout récapituler.
1- Présentation de l’organisme d’accueil

Keystone Consulting est une société spécialisée en sécurité de l'information, assistant les
entreprises à comprendre leurs menaces et à définir les méthodes de prévention des attaques, en
offrant une variété de services à valeurs ajoutées pour les accompagner dans le développement
de leur savoir-faire.
Notre savoir à Keystone est basé sur de nombreux experts hautement qualifiés en sécurité de
l'information, avec une expérience de plus de 10 ans et disposant de certifications internationales
des plus prestigieuses et valorisantes (CISSP, CEH, CHI, ISO27001LA, PSP, CISA, etc.)
Les services de sécurité de l'information fournis par Keystone Consulting sont divisés en 4
catégories :
Services
Technologiques
Développement Sécurité
de compétences Managée
Services
organisationnels
Figure 1.1 Service d'information fournies
par Keystone
Figure 1 Services d’information fournies par Keystone
3
Service technologique : Keystone aide les entreprises à déployer la technologie appropriée dans le
bon environnement avec un coût raisonnable, tout en assistant les entreprises à acheter et à
intégrer de nouvelles technologies tels que les solutions antivirales, les firewalls, les détecteurs
d'intrusion, les firewalls applicatifs, SIEM…
Services organisationnels : Keystone aide les entreprises à définir l'organisation adéquate

conformément aux standards internationaux et aux standards de bonnes pratiques en matière de
sécurité de l'information. Définir un processus de vérification, afin d'évaluer la sécurité de
l'entreprise et de proposer des recommandations pour éliminer les failles de sécurité
Développement de compétence : Keystone considère que le savoir est la première barrière de

sécurité pour faire face aux cyber-attaques. Dans cette perspective, elle fournit une liste des
formations sur des thèmes relatifs à la sécurité de base et sur des thématiques assez avancées est
fournie pour les experts en sécurité
Sécurité managée : Keystone fournit une liste complète de services de sécurité managée :
- Monitoring de la sécurité
- Monitoring des sites Web
- Le traitement des incidents et l'investigation judiciaire:
- Alerte et d'avertissement
- Les tests de pénétration
- Audit de vulnérabilité
2-L’audit technique
2.1-Définition général
Un audit technique consiste à valider les moyens de protection mis en œuvre sur le plan
technique, au regard de la politique de sécurité, en faisant appel à un tiers de confiance expert en
audit de sécurité informatique.
2.2-Processus d’audit technique

Le lancement d’une mission d’audit technique est initié après l’expression d’un besoin par une
entreprise afin qu’elle vérifie son Système d’Information en évaluant les risques auxquelles elle
peut y faire face et en cherchant des parades adaptées.
4
L’activité d’audit technique commence, dans un premier temps par le lancement d’un nouveau
projet d’audit technique correspondant à l’organisation en question. Dans un second temps, un
chef de projet sera affecté au projet déjà créé. Ce dernier commence par la définition du
périmètre de la mission d’audit (identification des ressources matérielles et logicielles à auditer),
ensuite, il divise le projet en plusieurs phases et tâches selon : les objectifs de la mission, les
ressources et les besoins de l’entreprise. Il estime la durée de chaque tâche, prépare le planning
du projet et affecte chacune d’elles à un auditeur. Ce dernier fait les tests et les scans convenables
et donne un rapport sur les résultats de la tâche réalisée.
2.3-Critique de l’existant
- Difficulté de la consultation des informations sur les projets : Les données propres à
l’entreprise sont éparpillées : ce qui influence sur le suivi du projet puisqu'il aura une
possibilité d’oubli d’un détail important.
- L’édition des rapports des projets se fait manuellement : L’auditeur est ramené à
rédiger le rapport d’audit manuellement.
- Pas de forme précise des rapports : Chaque auditeur rédige un rapport personnalisé
sans avoir recours à un modèle de rapport standard ce qui rend difficile sa lecture et
sa synthèse pour les autres auditeurs et pour l’entreprise en question.
- Chaque auditeur décrit les vulnérabilités trouvées de sa manière.
- Les informations sur les auditeurs, les projets et les vulnérabilités sont dispersées ;
d’ailleurs, une fois les données ne sont pas centralisées, cela engendrait une mauvaise
gestion de la mission d’audit.
- Difficulté de planification : disponibilité des auditeurs, estimation des durées des
tâches, estimation des coûts nécessaires pour achever le travail demandé.
- Difficulté de suivie du déroulement de projet : en effet, une mission d’audit technique
demande une supervision globale qui permettra de fournir à chaque phase un compte
rendu informant sur son bon déroulement.
- Perdre du temps et refaire le même travail pour chaque projet d’audit, dans ce sens,
chaque fois qu’il y aura un nouveau projet les auditeurs sont amenés à refaire les
étapes de rédaction des rapports.
2.4-Contributions
Pour faciliter l’activité d’audit technique et le travail des auditeurs et des intervenants, nous avons
opté à implémenter une application accessible via le web intitulé «Audit Managing Dashboard».
5
Dans cette perspective, notre application va permettre d’automatiser la tâche des auditeurs et
l’optimiser de façon qu’ils bénéficient d’un coût et une durée de l’audit réduits.
Ainsi, puisque les projets d’audit souffrent d’une décentralisation des informations, et vu
l’absence d’une base de données, nous avons opté en premier lieu pour créer une base qui
s’intitule «AuditDashbase» optimisant le contrôle et le stockage des données relatives aux
auditeurs, à l’entreprise à auditer, à ses ressources et à la mission d’audit en entier.
En deuxième lieu, nous avons essayé de créer un module de génération de plan de charges qui
comportera la liste des tâches de la mission d’audit bornées par leurs dates de début et de fin
ainsi que les auditeurs qui vont les effectuer sous forme d’un planning. Ce dernier permettra
d’organiser la mission et ses différentes phases et de donner une vue globale sur tout le projet.
Nous avons tout de même créé un module permettant la génération d’un plan d’action. En fait,
un plan d’action est un ensemble de recommandations dépendant des vulnérabilités détectées sur
les ressources. Ces recommandations seront utiles pour le rapport d’audit à fournir à l’entreprise.
Etant donné que la génération des rapports d’audit est manuelle et qu’on a l’intention de
satisfaire la contrainte du temps, nous avons créé un module permettant d’automatiser cette
tâche et par conséquent faciliter l’évaluation du système audité. Ainsi, il aidera les auditeurs à
faire la synthèse du rapport d’audit pour dégager les recommandations pertinentes.
Conclusion
Dans ce chapitre nous avons illustré la problématique qui nous a poussés à réaliser une
application qui aura comme objectif d’améliorer la mission d’audit technique.
Dans le chapitre suivant, nous allons faire la capture des besoins pour limiter le travail actuel et
proposer les grandes lignes de la solution retenue.
6
Chapitre 2 : Spécification des besoins
Introduction
Dans tout système, les fonctionnalités doivent être mises en relation avec un ensemble de
besoins utilisateurs. Ces besoins définissent les services que le système doit fournir aux
utilisateurs. Dans ce chapitre, nous définissons les besoins fonctionnels et non fonctionnels de
l’application. Puis, à partir de cette spécification, nous identifions les cas d’utilisation de notre
application.
1-Besoins fonctionnels
- Gérer les équipes de travail : gérer la liste des utilisateurs ayant accès à l’application (leurs
informations, les tâches qu’ils effectuent).
- Réalisation d’une base de vulnérabilités: Une base de données stockant la liste des
vulnérabilités est requise.
- Gestion du plan de charges : L’application doit fournir aux utilisateurs la possibilité de
générer un plan de charges qui contiendra les différentes tâches avec une estimation de
la durée de chacune d’elle.
- Gestion du plan d’action : L’application doit fournir aux utilisateurs la possibilité de
générer un plan d’action qui comportera une liste de recommandations recueillis à partir
de l’analyse des rapports d’outils de scan.
- Suivi de l’avancement de la mission : l’application doit fournir aux différents utilisateurs
un tableau de bord décrivant les tâches et leurs taux de finalité ainsi que les auditeurs
auxquels elles sont affectées.
- Génération de rapports : L’application apportera la possibilité de générer le rapport
d’audit automatiquement.
- Analyse des rapports : L’application doit donner la possibilité d’extraire les méta-
informations à partir des rapports générés par les différents outils de scan servant comme
support pour la création du plan d’action.
- Saisie des résultats d’audit : En plus des rapports qui sont générés par les outils,
l’application doit donner la main aux auditeurs d’ajouter des détails qu’ils jugent utiles.
7
- Agrégation des résultats et des rapports : La possibilité de réunir les résultats d’audit
générés à partir des outils et les rassembler dans un rapport d’audit complet.
1.1-Les cas d’utilisation :

1.1.1-Identification des acteurs :
Administrateur : C’est un acteur humain. Son rôle consiste à l’administration du système et à la

supervision des différents projets d’audit. Une identification est nécessaire afin de pouvoir
utiliser le système.
Chef de projet : C’est un acteur humain utilisant le système. Il réalise la gestion des différentes
tâches du projet d’audit et les affecte aux auditeurs. Une identification préalable est requise.
Auditeur : C’est un acteur humain utilisant le système avec une restriction de rôles par rapport
au chef de projet. Il assure une mission d’audit .Une identification préalable est nécessaire pour
pouvoir utiliser le système.
1.1.2-Identification des cas d’utilisations :
- S’authentifier.
- Crud projet d’audit.
- Crud liste entreprise
- Crud base de vulnérabilités.
- Crud auditeurs.
- Affecter chef de projet.
- Consulter planning
- Editer résultats d’audit.
- Crud tâches de projet.
- Crud liste ressources.
- Editer rapport d’audit.
- Editer planning.
- Affecter auditeur.
- Faire suivi projet.
8
2-Diagramme des cas d’utilisation générale :
Figure 2:Diagramme des Cas d’utilisation générale
9
2.1-Raffinement des cas d’utilisation :

Cas d’utilisation d’une authentification « s’authentifier » :
Acteur : Administrateur, Chef de projet et auditeur.
Pré-condition : Utilisateur désirant utiliser le système.
Résumé : Un utilisateur ne peut pas exploiter l’application sans passer par la phase de
l’authentification.
Séquences nominales :
1. Le système affiche l’interface d’authentification.
2. L’utilisateur introduit son login et mot de passe.
3. Le système vérifie les données introduites ainsi que le rôle de l’utilisateur qui vient de
se connecter.
4. Le système affiche le profil de l’utilisateur dépendant de son rôle.
Séquences alternatives :
a. Si l’utilisateur laisse les champs vides le système affiche le message suivant :
”User Name or Password incorrect”.
b. Si l’utilisateur introduit des valeurs fausses le système affiche le message suivant:
” User Name or Password incorrect”.
c. A chaque erreur commise le système réaffiche l’interface d’authentification
Post-conditions : Utilisateur authentifié avec succès.
Cas d’utilisation de la gestion de projets « Crud projet d’audit » :

Acteur : Administrateur.
Pré-condition : Utilisateur authentifié avec succès.
Résumé : L’administrateur choisit de Créer, supprimer, modifier ou consulter les
informations d’un projet.
1. Le système affiche l’interface contenant une liste contenant les opérations suivantes :
Créer, supprimer modifier ou consulter les informations d’un projet.
2. L’administrateur choisit l’opération à effectuer.
3. Dans le cas d’une création d’un nouveau projet, un formulaire s’affiche donnant la
possibilité de saisir les informations : Entité « Project » :[DD2]
4. A la création d’un nouveau projet le CU « Affecter chef de projet » est invoqué.
10
5. Dans le cas d’une modification, une interface contenant la liste des projets est
affichée donnant la possibilité d’édition des données.
6. Après avoir effectué les modifications appropriées l’utilisateur confirme les données
qui seront stockées dans la base de données.
7. En cas de suppression, toutes les données concernant le projet seront supprimées de
la base de données.
a. Si le projet existe déjà le système mentionne l’erreur et réaffiche l’interface de la
gestion de projet.
b. Si l’administrateur introduit une valeur erronée dans les champs réservés à la
saisie le système affiche un message d’erreur demandant la ressaisie et réaffiche
l’interface d’ajout.
Post-conditions : Projet crée, supprimé, modifié et/ou informations consultées avec
succès.
Cas d’utilisation de la gestion de la base « Crud base de vulnérabilités» :
Résumé : L’administrateur choisit d’ajouter, mettre à jour, supprimer ou consulter une
vulnérabilité.
1. Le système affiche l’interface contenant l’ensemble des opérations: ajouter, mettre à
jour, supprimer et consulter une vulnérabilité.
2. L’administrateur choisit l’opération qu’il désire effectuer.
3. Dans le cas de l’ajout d’une nouvelle vulnérabilité le système affiche un formulaire à
remplir.
4. L’administrateur saisit les données suivantes : Entité « Vulnerability ».[DD9]
5. Après avoir remplit les champs du formulaire l’utilisateur valide les informations.
a. Si la vulnérabilité existe déjà le système demande à l’utilisateur de la mettre à jour
et affiche l’interface de mise à jour correspondante.
11
b. Si l’administrateur introduit une valeur erronée dans les champs réservés à la

saisie le système affiche un message d’erreur demandant la ressaisie et réaffiche
l’interface concernée.
Post-conditions : Base de données mise à jour avec succès.
Cas d’utilisation de la gestion des auditeurs «Crud auditeurs» :
Résumé : L’administrateur choisit d’ajouter, mettre à jour, supprimer ou consulter les
informations d’un auditeur.
1. Le système permet à l’utilisateur d’ajouter, mettre à jour, supprimer et ou consulter
les informations concernant l’auditeur.
2. L’administrateur choisit l’opération adéquate.
3. Dans le cas d’ajout d’un nouvel auditeur un formulaire s’affiche.
4. L’administrateur entre les informations : Entité « Users »[DD1].
5. Après avoir remplit le formulaire, l’utilisateur valide les informations saisies.
6. Dans le cas d’une mise à jour ou d’une lecture des informations d’un auditeur le
système fournit une liste de tous les auditeurs avec leurs affectations aux différents
projets.
a. Si l’auditeur existe le système affiche un message d’erreur indiquant son
existence, demande la ressaisie et réaffiche l’interface d’ajout.
b. Si l’administrateur laisse des champs vides ou tape des valeurs erronées, le
système l’avertit et réaffiche l’interface d’ajout.
Post-conditions : Auditeur ajouté, supprimé et/ou informations auditeur consultées,
mises à jour.
Cas d’utilisation d’une gestion des entreprises à auditer «Crud liste entreprise» :
Acteur : Administrateur
Pré-condition : Administrateur authentifié avec succès.
12
Résumé : L’administrateur est amené à chaque nouvelle mission d’audit, à saisir les
informations de l’entreprise concernée et au fur et à mesure à les modifier, à les supprimer
et à les consulter.
1. Le système affiche l’interface de la gestion des entreprises.
2. L’administrateur choisit l’opération à effectuer : Ajout, suppression, mise à jour ou
consultation d’une entreprise.
3. Si l’administrateur a choisi d’ajouter une nouvelle organisation, un formulaire
s’affiche. L’administrateur le remplira par les données suivantes : Entité
« Entreprise »[DD5].
4. En cas d’une consultation des informations d’une entreprise une liste est fournie par
le système contenant toutes les organisations avec les informations qui les
concernent.
5. Dans le cas d’une suppression, toutes les informations relatives à l’entreprise seront
détruites.
a. Un message d'erreur s'affiche s'Il ya des champs obligatoires vides ou des erreurs
de saisie.
b. En cas d’existence de l’organisation le système affiche un message d’erreur.
Post-conditions : Une entreprise crée, supprimée, mise à jour ou consultée.
Cas d’utilisation d’une édition des ressources à auditer «Crud liste ressources» :
Acteur : Chef de projet

Résumé : Après avoir réalisé un inventaire de l’entreprise à auditer le chef de projet est
amené à stocker la liste des ressources dans la base de données pour pouvoir les consulter
ou les mettre à jour si nécessaire.
1. Le système affiche l’interface d’édition des ressources avec la possibilité d’ajouter,
supprimer ou éditer la liste des ressources.
2. En cas d’ajout d’une ressource, le système affiche l’interface d’ajout contenant un
formulaire à remplir.
13
3. Le chef de projet remplit le formulaire par les informations adéquates : Entité

« Resources ».[DD6]
4. Le chef de projet valide les informations à la fin de la saisie.
5. Si l’utilisateur a choisi de consulter les ressources une liste sera fournie contenant les
détails de tous les équipements.
a. Si l’utilisateur a commis une erreur de saisie ou a laissé des champs obligatoires
vides le système affiche un message d’erreur et réaffiche l’interface d’ajout.
Post-conditions : Ressources éditées avec succès.
Cas d’utilisation d’une édition d’un rapport d’audit «Editer rapport d’audit» :
Acteur : Chef de projet.

Pré-condition : utilisateur authentifié avec succès.
Résumé : A la fin du projet, un rapport d’audit est généré automatiquement par le
système cette étape est précédée par une édition des informations se basant sur les
rapports d’audit des équipements automatiquement générés par les outils tels que les
scanners de vulnérabilité.
1. Le système affiche la liste des projets en cours.
2. Le chef de projet vérifie le taux de finalité d’un projet.
3. Le système affiche le résultat.
4. Le chef de projet saisie les informations appropriées au rapport d’audit entité
« AuditReport ».[DD10]
5. valide l’édition du rapport.
6. Le système génère automatiquement le rapport d’audit.
a. Si le projet concerné n’est pas encore fini, un message de notification sera affiché
parle système.
Post-conditions : Rapport d’audit généré avec succès.
Cas d’utilisation de la gestion des tâches de projet «Crud tâches de projet» :
14
Pré-condition : Chef de projet authentifié avec succès.

Résumé : Le CU ‘’Gérer tâches de projet’’ consiste en l’ajout, la suppression, la
modification ou la consultation d’une tâche de projet. Le CU ‘’ajouter tâche de projet’’
invoque le CU ‘’Affecter auditeur’’.
1. Le système affiche l’interface de gestion des tâches.
2. Le chef de projet choisit une opération entre ajouter, supprimer, modifier ou
consulter tâche de projet.
3. En cas d’ajout d’une tâche, un formulaire à remplir est affiché.
4. L’administrateur remplit le formulaire par les données suivantes : Entité
« Task »[DD10] .
5. Après son ajout, la tâche sera affectée à un auditeur.
6. Après la modification d’une tâche les informations seront validées par le chef de
projet.
a. En cas d’existence de la tâche de projet le système affiche un message d’erreur.
b. Dans le cas d’une modification ou d’un ajout d’une tâche, un message d'erreur
s'affiche s'Il ya des champs obligatoires vides ou des erreurs de saisie.
c. Si une tâche est supprimée, ses informations seront détruites de la base de
données.
Post-conditions : Tâches de projet gérées avec succès.
Cas d’utilisation de l’affectation d’un auditeur «Affecter auditeur» :

Résumé : Le CU ‘’Affecter auditeur’’ est invoqué à chaque fois qu’une tâche est crée. Un
auditeur peut être affecté à plusieurs tâches simultanément.
1. Le système affiche la liste des auditeurs.
2. L’administrateur choisit l’auditeur à affecter à une tâche qui sera à son tour averti par
mail.
3. L’auditeur valide son affectation.
15
a. Si l’auditeur n’a pas validé l’affectation, l’administrateur est averti.
b. A chaque fois, la liste des auditeurs est réaffichée.
Post-conditions : auditeur affecté avec succès.
Cas d’utilisation de l’édition du planning « Editer le planning» :
Acteur : Chef de projet, auditeur

Résumé : Ce CU aura effet après l’édition des ressources à auditer et après une génération
automatique d’un planning de réalisation du projet.
1. L’utilisateur demande de consulter le planning.
2. Le système affiche le planning généré.
3. L’utilisateur saisit des informations supplémentaires si nécessaire (Par exemple :
prolongement de tâche, report d’une tâche).
4. L’utilisateur valide le nouveau planning.
a. En cas de saisie d’informations inappropriées le système génère une erreur et
réaffiche l’interface d’édition.
Post-conditions : Planning édité avec succès.
Cas d’utilisation du suivi de l’avancement du projet «Faire suivi projet »
Acteur : Chef de projet

Résumé : Ce cas d’utilisation permet de faciliter le suivi de l’avancement du projet et la
réalisation des tâches dans les délais prévus.
1. Le chef de projet choisit la tâche ou le projet à suivre.
2. Le système fournit un chronogramme généré automatiquement comportant la liste
des tâches ainsi que leurs taux de finalité.
a. Si un projet comportant des tâches finies le système notifie le chef de projet.
16
Post-conditions : Projet et/ou tâches consultées avec succès.
Cas d’utilisation d’une édition des résultats d’audit «Editer résultats d’audit» :
Acteur : Auditeur, chef de projet

Résumé : Ce CU aura effet quand l’auditeur juge nécessaire ajouter des informations en
plus de celles fournies par les outils.
1. L’utilisateur doit sélectionner la tâche du projet à effectuer.
2. Après avoir effectué les tests et les scans nécessaires, il sélectionne les vulnérabilités
trouvées à partir de la base des vulnérabilités.
3. L’utilisateur ajoute des informations supplémentaires sous forme de
recommandations si nécessaire.
4. Il valide l’édition des résultats d’audit.
5. Le système enregistre les informations dans la base de connaissances.
a. Si l’utilisateur saisit des valeurs erronées un message d’erreur sera affiché.
Post-conditions : Résultats d’audit édités avec succès.
Cas d’utilisation d’une affectation d’un chef de projet « Affecter chef de projet » :
Acteur : Administrateur
Pré-condition : Utilisateur authentifié correctement et projet crée avec succès.
Résumé : A la création d’un nouveau projet, un chef de projet est y affecté pour le gérer.
1. 1. L’administrateur choisit le chef de projet à affecter.
2. 2. Une notification par mail est envoyée au chef de projet l’avertissant.
3. 3. Le chef de projet valide l’affectation.
a. Si le chef de projet est affecté à un autre projet un message d’erreur est affiché.
b. A chaque fois qu’une erreur s’est produite l’administrateur doit rechoisir un chef
de projet.
Post-condition : Chef de projet affecté avec succès.
17
3-Besoins non fonctionnels :

La réalisation d’une interface homme machine :
Les interfaces de l’application doivent être conviviales et présentent un certain niveau

d’ergonomie. La réalisation des interfaces homme-machines conviviales n’a été possible que par
le développement de la technologie objet. La vulgarisation des interfaces graphiques a conduit à
imaginer l’application de plus en plus selon les besoins de l’utilisateur et non selon les contraintes
des interfaces, d’où vient le choix des couleurs et de fenêtres standards.
Robustesse :
Concevoir une application avec un taux d’erreur assez rétréci pour assurer l’efficacité de
l’application et la continuation du service.
Sécurité :
La gestion des utilisateurs est une mesure de sécurité puisqu’elle restreint l’accès à l’application
et l’ordonne dans un contexte de privilèges
4-Dictionnaire de donnée :
Users :[DD1]
1 IdUser Numéro de l'utililisateur Numérique 6 Attribut identifiant l'utilisateur de l'application.
2 UName Nom de l'utilisateur Chaine de caractères 20 Nom de l'utilisateur de l'application.

L'utlisateur peut étre soit administrateur,auditeur ou
3 USubName Prénom de l'utilisateur Chaine de caractères 20 bien chef de projet
Attribut permettant de stocker le mot de passe de
4 Password mot de passe utisateur Chaine de caractères 20 l'utilisateur
5 Login Login de l'utilisateur Chaine de caractères 30 Attribut stockant le login de l'utilisateur.

Le numéro de téléphone de Attribut correspondant au numéro de télélphone de
6 UTel l'utilisateur Numérique 12 l'utilisateur
7 UAdress Adresse de l'utilisateur Chaine de caractères 50 Attribut stockant l'adresse de l'utilisateur.

8 UEmail Adresse électronique de l'utilisateur Chaine de caractères 30 Adresse éléctronique de l'utilisateur
Méthode permettant d'ajouter un utilisateur à la base
9 CreateUser Ajouter un utilisateur Méthode de données.
Méthode permettant de supprimer un utilisateur de la
10 RemoveUser Suprimer un utilisateur Méthode base de données.
18
Project :[DD2]
11 IdProject Numéro du projet Numérique 6 Attribut Identifiant le projet.

12 ProjName Nom du projet Chaine de caractères 20 Attribut renvoyant le nom d'un nouveau projet.
13 PCreationDate Date de création Date Date du lancement du projet.
14 PEndDate Date de fin Date Date du clôture du projet.

Méthode permettant d'ajouter un nouveau projet à la
15 CreateProject Création d'un projet Méthode base de données
Méthode de suppression d'un projet ainsi que tous
16 RemoveProject Suppression d'un projet Méthode ses paramètres de la base de données.
Task :[DD3]
17 IdTask Numéro de la tâche Numérique 6 Attribut dentifiant une tâche.

18 TaskName Nom de la tâche Chaine de caractére 50 Nom de la tâche
19 TBeginDate Date de début Date Date du lancement de la tâche
20 TEndDate Date de fin Date Date de fin de la tâche
21 State Etat de la tâche Chaine de 20 caractères Attribut correspondant à l'état de la tâche,,
22 Number Numéro de la tâche Numérique 6 Numéro de la tâche,
23 Priority Priorité de la tâche Chaine de caractére 20 Attribut renvoyant la priorité de la tâche,
24 CreateTask Création d'une nouvelle tâche Méthode Méthode d'jout d'une tâche à la base de données.
25 RemoveTask Suppression d'une tâche Méthode Supprression d'une tâche de la base de données.
26 GenerateReport Génération de rapport Méthode Généreation de rapport sous format PDF
InfosTreatment : [DD4]
27 IdInfo Identifiant d'une Numérique 6 Identifiant d'une statiqtique
La valuer à introduire pour informer sur la durée de
28 ValueTreat Durée de taritement d'une ressource Chaine de caractères 50 traitement d'une ressource
Méthode permettant d'ajouter des valeurs
29 AddInfo Ajouter des valeurs manuellement Méthode mauellement à la base de données.
19
Entreprise : [DD5]
30 IdEntreprise Numéro de l'entreprise Numérique 6 Identifiant de l'entreprise à auditer.
31 EName Nom de l'entreprise Chaine de caractères 20 Nom de l'entreprise à auditer
32 EAdress Adresse de l'entreprise Chaine de caractères 20 Adresse de l'entreprise à auditer
33 ETel Numéro de téléphone de l'entreprise Numérique 5 Numéro de téléphone de l'entreprise à auditer.

Adresse électronique du responsable chez
34 EEmail Adresse électronique de l'entreprise Chaine de caractères 20 l'entreprise à auditer.
35 RespName Nom du responsable de l'entreprise. Chaine de caractères 50 Le nom du responsable de l'entreprise.
36 RespTel Numéro de téléphone du responsable Chaine de caractères 12 Le numéro de téléphone du responsable
37 RespMail Adresse électronique du responsable Chaine de caractères 30 L'adresse électronique du responsable
38 CreateEntr Ajouter une entreprise Méthode Méthode permettant d'ajouter une entreprise.
39 RemoveEntr Supprimer un entreprise Méthode Méthode permettant de supprimer une entreprise
Resources : [DD6]
40 IdRsrc Identifiant d'une ressource Numérique 6 Attribut identifiant d'une ressource à saisir.
Attribut représentant le nom d'une
41 RName Nom de la ressource Chaine de caractères 20 ressource(ordinateur,routeur,switcher,.. )
Nombre d'exemplaires d'une Attribut représentatnt le nombre d'exemplaires
42 NbrOfRsrc ressource Numérique 5 disponibles correspondant à une ressource.
La catégorie à laquelle appartienne la Attribut représentatnt la catégorie à laquelle
43 Category ressource. Chaine de caractères 30 appartienne de la ressource
Attribut représentatnt la criticité de la ressource à
44 Criticality Niveau de criticité de la ressource. Chaine de caractères 20 auditer
Méthode responsable de l'ajout d'une ressource à la
45 CreateResource Ajout d'une ressource Méthode base de données.
Méthode permettant de supprimer une ressource de
46 RemoveResource Suppression d'une ressource Méthode la base.
Tools : [DD7]
Attribut identifiant chaque outil utilisé durant une tâche

47 IdTool Identifiant d'un outil. Numérique 6 (Exemple :Scanner de vulnérabilité..).
48 ToolName Le nom d'un outil Chaine de caractères 40 Attribut correspondant au nom de l'outil utilisé.
Attribut définisant le système d'exploitation compatible
49 TOS Le système d'exploitation de l'outil. Chaine de caractères 20 avec l'outil.
50 TVersion La version de l'outil Chaine de caractères 20 Attribut informant sur la version de l'outil.
51 Target La catégorie de la cible à auditer Chaine de caractères 40 Attribut renvoyant la catégorie de la cible à auditer
Trouver la vulnérabilité de la
52 FindVulnerability ressource auditée Méthode Méthode permettant de chercher une vulnérabilité
20
Inventory :[DD8]
53 IdInventory Identifiant d'un inventaire Numérique 6 Identifiant d'un inventaire

Attribut correpondant à la date de l'achèvement d'un
54 InvDate La date de l'inventaire Date inventaire
55 GenerateInv Création d'un inventaire Méthode Méthode de création d'un inventaire.
Vulnerability :[DD9]
56 IdVuln Identifiant d'une vulnérabilité Numérique 6 Identifiant d'une vulnérabilité
57 IdCVE Identifiant CVE d'une vulnérabilité Chaine de caractères 40 Identifiant CVE d'une vulnérabilité
58 VName Nom d'une vulnérabilité Chaine de caractères 20 Attribut correpondant à une vulnérabilité
59 V_Type Type d'une vulnérabilité Chaine de caractères 20 Attribut correspondant au type d'une vulnérabilité
60 Description Decription d'une vulnérabilité Chaine de caractères 50 Attribut décrivant la vulnérabilité
Niveau de dangérosité de la Attribut décrivant le niveau de dangérosité de la
61 CVSS vulnérabilité Chaine de caractères 50 vulnérabilité
62 Link Lien vers les détails de la vulnérabilité Chaine de caractères 40 Lien vers les détails de la vulnérabilité
Méthode d'ajout d'une vulnérabilité dans la base de
63 AddVulnerability Ajout d'une vulnérabilité Méthode données.
AuditReport : [DD10]
64 IdAuditRep Identifiant d'un rapport d'audit Numérique 6 Attribut identifiant un rapport d'audit
Date de de génération du rapport Attribut renvoyant sur la date de génération du rapport
65 RADate d'audit Date d'audit.
Recommandations à appliquer par Attribut donnant la liste de recommandations à
66 Recommandations l'entreprise Chaine de caractères 200 appliquer par l'entreprise.
67 GenAuditRep Générer un rapport d'audit Méthode Méthode permettant de générer le rapport d'audit final
Report : [DD11]
68 IdReport Identifiant du rapport généré par l'outil. Numérique 6 Attribut identifiant un rapport généré par l'outil utilisé.
Attribut correspondant à la date de début d'une
Date de commencement d'une opération de l'outil.Une opération peut être un scan de
69 OpBegin l'opération de l'outil.. Date vulnérabilités.
Attribut correspondant à la date de fin d'une opération
70 OpEnd Date de fin d'une opération de l'outil. Date de l'outil.
Attribut du rapport généré présentant le résultat de
71 Result Résultat de l'opération de scan. Chaine de caractères 50 l'outil utilisé
72 GenerateReport Génération de rapport Méthode Méthode de génération de rapport d'outil.

Méthode permettant de parser un rapport généré par
73 ParseReport Parser un rapport généré par un outil Méthode l'outil choisi.
21
ActionPlan : [DD12]
Attribut identifiant un plan d'action.Ce plan est généré
74 IdActPlan identifiant du plan d'action Numérique 6 à partir d'une liste de vulnérabilités
75 ActDescription Description du plan d'action Chaine de caractères 200 Attribut stockant la description du plan d'action
Génération d'un plan d'action après Génération d'un plan d'action dépendant du type et de
76 GenerateActionPlan avoir trouvé une vulnérabilité Méthode l'impact de la vulnérabilité
ChargePlan : [DD13]
Attribut identifiant un plan de charges.Ce plan est
77 IdChPlan Identifiant du plan de charges Numérique 6 généré à partir des valeurs de traitemant saisies.
78 ChDescription Description de plan de charge Chaine de caractères 200 Attribut stockant la description du plan de charge
Génération d'un plan de charge après Génération d'un plan de charge à partir des valeurs de
79 GenerateChargePlan Méthode
le calcul des statistiques traitemant saisies.
Role : [DD14]
80 Id_Role Identifiant du rôle de l'utilisateur Numérique 5 Attribut rôle identifiant l'utilisateur
81 RoleName Le rôle de l'utilisateur Chaine de caractères Attribut donnant le rôle de l'utilisateur
82 AddRole Ajouter rôle Méthode Méthode d'ajout d'un rôle
83 RemoveRole Supprimer rôle Méthode Méthode de suppression d'un rôle
Planning : [DD15]
84 IdPlanning Identifiant d'un planning Numérique 6 Attribut identifiant un planning
85 CreatePlanning Méthode de création d'un planning Méthode Méthode d'ajout d'un nouveau planning
Conclusion
Tout au long de ce chapitre, nous avons identifié les exigences et les contraintes prescrites pour
chaque module de notre système qui nous ont aidés à former une idée générale sur les
fonctionnalités requises par notre système.
22
Chapitre 3 : Conception
Introduction
Compte tenu de l’analyse fonctionnelle mentionnée au niveau de la problématique et de l’analyse
des besoins et vu l’intérêt que cela présente pour le système, nous nous sommes investis à
implémenter une application qui prend en charge la gestion de suivi d’une mission d’audit. Ainsi,
nous nous sommes aidés du langage UML pour représenter les différents diagrammes de ce
système, en utilisant l’outil de conception Visual Paradigm for UML.
Outil de conception Visual Paradigm for UML:
Visual Paradigm for UML (VP-UML) est un outil de conception UML conçu pour l'aide au
développement de logiciels. VP-UML supporte les normes clés de l'industrie telle qu’Unified
Modeling Language (UML), SysML, BPMN, XMI, etc. Il offre une gamme complète d'outils
logiciels pour le développement, le logiciel de planification, la planification des tests, la
modélisation de classe, la modélisation des données, etc.
1-Architecture technique :
Les choix architecturaux d'une application sont décisifs dès qu'ils interviennent sur les
performances, l'évolutivité, les temps de développement, et sur les couts.
1.1-Architectures possibles
Une application peut être subdivisée en un ensemble de couches et on parle ainsi de multi
niveaux (ou n-tiers).
1.2-Architecture 2-tiers
Un système client/serveur fait référence à au moins deux types de composants, qui sont les
systèmes de base de données en serveur, et les applications qui en exploitent les données en
client. Cette architecture caractérise les systèmes dans lesquels le client demande une ressource et
le serveur la lui fournit directement. Cela signifie que le serveur ne fait pas appel à une autre
application afin de fournir le service. Ce type d'architecture possède toutefois des inconvénients
majeurs. En effet, d'une part, ce type d'architecture alourdit le client, puisque les applications
23
sont logées à ce niveau, d'autre part, chaque mise à jour du logiciel nécessite un nouveau
déploiement très couteux.
1.3-Architecture adoptée
L’architecture 3 tiers :
Afin d'atteindre les différents objectifs, l'architecture 3-tiers est indispensable. Les principales
fonctionnalités que doit assurer chaque tiers sont les suivantes :
Un serveur de données : Ce serveur sera responsable de la collecte des données manipulées tels
que les informations sur les auditeurs, l’entreprise à auditer.
Un serveur Web : Ce serveur est chargé de la présentation et l'affichage des données des
utilisateurs à travers les interfaces qu'il offre. Il offre, également, la possibilité aux clients
d'interagir avec le système.
Un serveur d'application : Ce serveur est chargé de contenir les objets manipulés lors de
l'exécution des fonctions et services des clients.
Un modèle de spécification logicielle consiste à recenser les besoins des différents exploitants du
système, ce modèle est organisé en couches de responsabilités techniques de manière à affiner les
exigences.
Ci-dessous la figure représente l’architecture 3 tiers
Figure 3: Architecture 3 tiers
24
1.4-Architecture applicative :
Une couche logicielle représente un ensemble de spécifications ou de réalisations, qui
respectivement expriment ou mettent en œuvre un ensemble de responsabilités techniques et
homogènes pour un système logiciel.
Le but maintenant est de trouver un modèle de décomposition logicielle qui correspond à notre
architecture en 3-tiers précédemment établie.
Le MVC2 est un modèle de conception qui repose sur la volonté de séparer les données les
traitements et la présentation ; ceci répond parfaitement à nos exigences.
Le Modèle-View-Contrôleur 2 (MVC2) hérite des propriétés du modèle MVC. La seule

différence entre ces deux modèles se situe au niveau de la couche applicative (Contrôleur) : dans
le modèle MVC2, le contrôleur est une classe unique, garantissant ainsi l’unicité du point d’entrée
de l’application.
Partant de cette définition, la présentation du modèle MVC2, revient à celle du modèle MVC.
Le modèle MVC a été initialement développé pour le langage Smaltalk dans le but de mieux
structurer une application avec une interface graphique : séparation des couches présentation
(Vue), traitement (Contrôleur) et accès aux donnés (Modèle).
Cette séparation permet, lors du développement d’une application s’appuyant sur ce modèle, de
simplifier la tâche des développeurs. En effet, suivant ce modèle, chaque partie peut être confiée
à un développeur sans pour autant, le plus souvent, qu’il soit dépendant des autres parties.
Ci-dessous la figure décrivant l’architecture de l’MVC2
Figure 4 : Architecture MVC2
25
2-Architecture générale de l’application

2.1-Diagramme de paquetages :
Dans ce qui suit, nous présentons le diagramme de packages de notre système. Ce diagramme
nous donne une vue générale sur la répartition des différents objets et tables ainsi que leurs
interactions.
Figure 5 : Diagramme de paquetages
Notre application est donc décomposée en trois parties : une partie présentation, une partie
métier et une partie accès aux données.
 Partie Présentation :
Le package org.auditor.bean : Ce package assure la gestion des évènements de l'application. Il

analyse, ainsi, chaque événement de l'utilisateur et enclenche une action à effectuer. Ce sont des
classes java qui permettent : l'affichage des données provenant de la couche service, le stockage
des valeurs d'un formulaire, la validation des valeurs et l'émission de messages (ou d'actions)
pour la navigation.
 Partie métier :
Le package org.auditor.Service : Package pour les interfaces de nos classes services.
Le package org.auditor.ImplService : Package pour les implémentations de notre service.
26
 Partie accès aux données :
Le package org.auditor.Dao : Package pour les interfaces de nos classes d'accès aux données.
Le package org.auditor.ImplDao : Package pour l’implémentation de notre couche d'accès aux

données.
Le package org.auditor.Model : Package pour les classes de notre modèle de données.
3-Vue statique :
Les diagrammes de classes expriment de manière générale la structure statique d’un système en
termes de classes et de relations entre ces classes. Une classe permet de décrire un ensemble
d’objets (attributs et comportement), tandis qu’une relation permet de faire apparaître des liens
entre ces objets.
Le diagramme de classes est un modèle permettant de décrire de manière abstraite et générale les
liens entre objets.
3.1-Diagrammes de classe
Ce diagramme qui contient les différentes classes décrivant le système à réaliser, permet de
donner une vue orientée objet du système.
27
3.1.1-Diagramme de classe couche modèle
Figure 6 : Diagramme de classe modèle
 La classe ” Users ” : Représente tout tiers ayant accès à l’application identifié par un numéro
unique « idUser ».
 La classe ” Role ” : Cette classe représente la liste des rôles correspondant à chaque
utilisateur du système. Soit un administrateur, un chef de projet et un auditeur. Un chef de
projet peut être un auditeur.
 La classe ”Project ” : Cette classe représente l’objet projet identifié par un numéro et référé
par un nom. Un projet correspond à une mission d’audit et est découpé en plusieurs tâches.
 La classe ”Task ” : Représente une tâche du projet. Elle est identifiée par un numéro et
bornée par une date de début et une date de fin.
28
 La classe ”Tools ” : Cette classe représente la liste des outils utilisés lors d’une tâche de l’audit
leurs versions et les systèmes d’exploitation sur lesquels peuvent tourner avec le type de la
cible à auditer.
 La classe ”Entreprise ” : Représente l’objet ‘entreprise’ qui contient les informations
spécifiques à l’entreprise à auditer (son adresse, son numéro de téléphone et fax) ainsi que le
nom du responsable et ses contacts.
 La classe ”Resources ” : Cette classe représente la liste des différentes ressources faisant
partie du patrimoine de l’entreprise qui seront introduites dans la base de données après
avoir effectué un inventaire. Une ressource peut être : un poste de travail, un serveur, un
Routeur, un Switcher, une application …
 La classe ”Report ” : Représente l’objet rapport généré à partir d’un outil tel qu’un scanner
de vulnérabilités qui sera par la suite parsé pour en dégager les informations importantes à
introduire dans le rapport d’audit ainsi que pour générer un plan d’action.
 La classe InfosTreatment ” : Cette classe représente les durées de traitement calculées ou
saisies manuellement. Ces valeurs correspondent aux différentes ressources, à auditer ils
informent sur les bonnes pratiques pour optimiser la durée d’audit et donnent une estimation
sur la durée de chaque tâche du projet.
 La classe ”Inventory ” : Cette classe représente l’inventaire réalisé par l’administrateur afin
d’introduire toutes les ressources propres à l’entreprise.
 La classe ”Vulnerability ” : Représente les vulnérabilités dégagées après une phase d’audit
d’une ressource. Une vulnérabilité est identifiée par un Identificateur internationale appelé
CVE et référée par un nom.
 La classe ”ChargePlan ” : C’est la classe représentant le plan de charge généré selon les
statistiques fournies à partir de l’inventaire de l’ensemble des ressources.
 La classe ”ActionPlan ” : C’est la classe représentant le plan d’action généré dépendant de la
vulnérabilité détectée au niveau d’une ressource.
 La classe ”Planning ” : Cette classe représente la planification générée correspondant au
projet et ses différentes tâches. Un planning peut être édité par l’auditeur ou le chef de projet.
 La classe ”AuditReport ” :C’est la classe qui représente le rapport d’audit final à fournir à
l’entreprise. Il englobe tout le projet ainsi que ses différentes phases argumentées par une
liste de recommandations pour chaque vulnérabilité détectée.
29
3.1.2-Diagramme de classe couche DAO :
Après avoir détaillé notre modèle, nous allons passer à la couche DAO dont la figure ci-dessous
présente un exemple. L'interface générique illustrée dans cette figure présente un contrat de
communication avec les autres couches de manière qu’elle est considérée comme boite noire ne
publiant que les méthodes, leurs paramètres et leurs types de retours .Cette interface sera
implémentée n fois (par n classe) selon le nombre de classes modèle que nous avons, dont
chacune possède les mêmes services (service du contrat InterfaceDao) mais avec des
implémentations plus ou moins différentes.
Figure 7 : Diagramme de classe DAO
4-La vue dynamique

La vue dynamique est assurée dans la méthodologie UML par quatre diagrammes :
Diagramme de collaboration, diagramme de séquence, diagramme état/transition et diagramme

d’activité. Nous avons opté dans la conception dynamique de notre projet à utiliser les
30
diagrammes de séquences puisqu’ils forment une représentation temporelle des objets et de leurs
interactions.
4.1-Diagramme de séquence de la CU «s’authentifier »
Figure 8 : Diagramme de séquence de la CU « s’authentifier»

Description : Ce diagramme décrit l’enchainement du processus d’authentification et
l’ordonnancement des opérations réalisées par chaque acteur tentant de s’authentifier.
Ainsi les objets évoqués et les informations communiquées au système de gestion
d’authentification.
L’acteur concerné par le Cu est tout utilisateur ayant recours à exploiter le système puisqu’il doit
s’authentifier au préalable afin de vérifier son identité et son rôle.
31
4.2-Diagramme de séquence de la CU «add auditor »
Figure 9 : Diagramme de séquence de la CU « add auditor »
Description : Ce diagramme concerne le cas d’utilisation d’ajout d’un nouvel auditeur à la base
de données « AuditDashbase ». L’administrateur, entre les informations relatives à l’auditeur tels
que son nom, son login son mot de passe puis il y aura une comparaison des données saisies
avec celles qui sont stockées dans la base de données : Si l’auditeur existe, déjà un message
d’erreur s’affiche ; sinon, un message notifiant la réussite de l’ajout.
32
4.3-Diagramme de séquence de la CU « Delete auditor»
Figure 10 : Diagramme de séquence de la CU« Delete auditor»
Description : Ce diagramme décrit l’enchainement de la suppression d’un auditeur. Une liste

s’affiche contenant la liste des auditeurs, l’administrateur sélectionne l’auditeur à supprimer puis
valide la suppression.
33
4.4-Diagramme de séquence de la CU «update auditor »
Figure 11 : Diagramme de séquence de la CU« Update auditor »
Description : Le diagramme ci-dessus représente la séquence de mise à jour des auditeurs. Pour
les éditer, l’administrateur doit, ainsi, saisir un formulaire dont les données seront vérifiées au
niveau du système « Audit Managing Dashboard » et en cas de succès les informations seront
stockées dans la base de données « AuditDashbase ».
34
4.5-Diagramme de la séquence de la CU « Ajouter ressource»
Figure 12 : Diagramme de séquence de la CU «Ajouter ressource »
Description : Ce diagramme permet de décrire l’ajout d’une ressource à la base de données.

L’administrateur doit remplir le formulaire d’ajout avec le nom de la ressource, le nombre
d’exemplaires, la catégorie de la ressource ainsi que sa criticité. Si les données saisies sont
correctes, la ressource sera stockée, alors, dans la base de données
35
4.6-Diagramme de la séquence de CU «Editer planning»
Figure 13 : Diagramme de séquence de la CU « Editer planning »
Description : Ce diagramme de séquence représente le cas d’utilisation de l’édition du planning.

En effet, un planning est un plan de charge qui est crée dépendamment du nombre de
ressources susceptibles d’être auditées ainsi que le nombre des tâches et d’auditeurs disponibles.
Le plan de charge déjà crée s’affiche, l’administrateur choisit le champ à éditer (Exemple : la date
de la fin d’une tâche), puis, insère la valeur désirée .Enfin, il valide les changements et régénère
un nouveau plan de charges.
36
Conclusion
Tout au long de ce chapitre, nous avons circonscrit notre problème et nous nous sommes
focalisés sur l'aspect architectural du système accompagné des principaux diagrammes UML.
En effet, dans cette partie, nous avons rassemblé les différents éléments de modélisation de
notre solution et donc nous entamerons dans le chapitre qui suit la réalisation de sa maquette
approximative.
37
Chapitre 4 : Réalisation
Introduction
Dans ce chapitre, nous allons décrire la phase d’implémentation de notre système.
Nous allons donc commencer par donner une spécification des différents outils utilisés dans la
réalisation du système. Ensuite, nous présenterons le diagramme de déploiement de notre
système sur les dispositifs physiques. Enfin, nous décrirons les différents modules qui
composent notre application, en se basant sur la conception évoluée dans le chapitre précédent.
1-Environnement et outils de travail
Dans cette partie, nous décrivons brièvement l'environnement matériel et logiciel ainsi que les
choix technologiques faits pour réaliser le projet.
1.1-Plateforme matérielle
Le long de notre projet, nous avons utilisé une machine ayant la configuration suivante :
- Un processeur Intel core i5 de fréquence 2.5 GHZ.
- Une mémoire vivre 4GO.
- Un disque dur de capacité 200GO.
1.2-Plateforme logicielle
Tout au long de la phase de développement, nous nous sommes servis de l'environnement
logiciel suivant :
Logiciel de traitement d’image : Adobe Photoshop CS6
Outil pour la conception : Visual Paradigm for UML 10.0.
Serveur d'application : Apache Tomcat 7.0
Apache Tomcat est une implémentation Open Source d'un conteneur Web JEE. Il
permet de déployer des applications Web dynamiques. Les principales caractéristiques de
ce serveur sont : Ecrit entièrement en java, il peut être utilisé sur n'importe quel système
disposant d'une machine virtuelle. Disponible gratuitement sous forme d'une licence
Open Source.
Système de Gestion de Base de Données : MySQL 5.5.4
38
Choix de SGBD :
De nombreux SGBD sont disponibles sur le marché, partant des SGBD gratuits jusqu'aux
SGBD destinés spécialement aux professionnels. Le choix d'un SGBD ou de l'autre dépend
entièrement des besoins du système. En effet, le SGBD à choisir, doit supporter principalement
les contraintes de voluminosité des données et de sécurité des accès. Parmi les SGBDs les plus
utilisés dans le monde nous citons : Access, MySQL, et Oracle.
 Access : C’est une solution Microsoft simple à utiliser. Il est développé pour répondre
aux besoins des simples utilisateurs des bases de données. Le problème majeur d'Access
est la dégradation de performance pour un grand nombre d'utilisateurs et sa limitation en
quantité des données stockées. En plus la sécurité pour une base de données Access n'est
pas assez performante.
 Oracle : C’est le SGBD choisi par plusieurs entreprises grâce à son habilité et sa richesse
fonctionnelle. Mais oracle présente une complexité d'administration liée à la richesse
fonctionnelle. De plus il est un fort demandeur de ressources. Oracle est bien plus
gourmand en ressource mémoire que ses concurrents, ce qui implique un investissement
matériel non négligeable, La connexion utilisateur nécessite par exemple prés de 700
Ko/utilisateur, contre une petite centaine sur des serveurs
 MySQL : C’est le SGBD le plus utilisé dans le monde. Le succès de MySQL marqué
principalement par le fait qu'il est un logiciel libre. Il présente, de plus, une très bonne
intégration dans l'environnement Apache et une facilité de déploiement et de prise en
main. Le point fort de MySQL est son classent en premier, pour répondre aux besoins
du système.
Editeurs pour le développement : Eclipse Juno
Eclipse est un projet de la Fondation Eclipse visant à développer un environnement de
développement intégré libre, extensible, universel et polyvalent. Son objectif est de produire et
fournir des outils pour la réalisation de logiciels, englobant les activités de programmation
(notamment au moyen d’un environnement de développement intégré) mais aussi de
modélisation, de conception, de test et de reporting. Son environnement de développement
intégré vise à supporter tout langage de programmation. Le marketplace d’Eclipse fournit des
extensions pour but de guider et faciliter le développement, parmi ces extensions, nous allons
utiliser les suivantes :
 JBossTools : C’est une extension composé d’un ensemble de modules et de fonctionnalités
conçus pour aider les développeurs JavaEE, parmi ces modules, je citerai :
39
- SpringSource Tool Suite : C’est une extension fournit par la communauté

SpringSource, qui permet le support de Spring dans Eclipse. Il se base sur le plugin
Spring IDE. Il nous assiste également dans l'édition des fichiers XML en
apportant l'auto-complétion au niveau des noms des classes Java, des propriétés et
des beans Spring référencés. [1]
1.2.1-Langages et Technologies de développement
Dans cette partie, nous donnons un aperçu sur les outils de développement qui ont servi pour la
réalisation de l'application.
La plateforme JavaEE :
Pour le codage des fonctionnalités du tableau de bord, nous avons choisi l'architecture JavaEE
(Java Entreprise Edition) pour une multitude de raisons que nous décrivons brièvement.
La plateforme JavaEE a été retenue pour le développement de notre système grâce à ces
avantages. En effet, elle s'appuie entièrement sur le langage Java ce qui lui permet de bénéficier
des avantages de ce dernier, en particulier la sécurité, une bonne portabilité et une facilité de
maintenance du code. De plus, JavaEE simplifie l'extensibilité de l'architecture et garantit une
bonne qualité de service, ainsi que la facilité de prise en main des API de cette plate-forme. En
effet, celle-ci cache très souvent la complexité d'accès aux ressources et permet un gain de temps
énorme pour le développeur qui a donc plus de temps pour se préoccuper du fonctionnement
réel de son application. Par ailleurs, la plateforme JavaEE est basée sur un standard ouvert ce qui
lui assure une pérennité et rend le déploiement des applications plus rapide et plus simple sur la
majorité des serveurs.[4]
Java Server Faces (JSF) :
Java Server Faces (JSF) est une technologie dont le but est de proposer un framework qui facilite
et standardise le développement d'applications web avec Java.
Son développement a tenu compte des différentes expériences acquises lors de l'utilisation des
technologies standards pour le développement d'applications web (servlet, JSP, JSTL) et de
différents frameworks (Struts, ...).
Ainsi, de par sa complexité et sa puissance, JSF s'adapte parfaitement au développement
d'applications web complexes en facilitant leur écriture.[6]
PrimeFaces :
PrimeFaces est une bibliothèque développée par la société « Prime Technologie ». Il fonctionne
uniquement sous JSF 2.X. L’intérêt principal de PrimeFaces réside dans la diversité et la qualité
des composants proposés. Ils sont nombreux, et répondent le plus souvent en standard aux
40
besoins des applications. Ce sont des composants graphiques avancés qui possèdent des
fonctionnalités prêtes à l’emploi, aidant ainsi à créer aisément des RIA (Rich Internet
Application).[3]
Hibernate :
Un framework de mapping objet/relationnel. Il permet de faire le mapping entre les objets Java
et les objets stockés dans la base de données relationnelle. Hibernate apporte une solution aux
problèmes d'adaptation entre le paradigme objet et les SGBD en remplaçant les accès à la base
de données par des appels à des méthodes objet de haut niveau.[2]
Jasper Report:
C’est l’outil le plus populaire au monde pour la création de rapports, écrit en JAVA et peut
prendre en charge n’importe quel type de données Il peut être utilisé dans les applications Java, y
compris JavaEE ou des applications Web, pour générer du contenu dynamique. Il lit ses
instructions à partir d’un fichier XML ou JRXML.[1]
JAXB :
Java Architecture for XML Binding est un API ayant pour but de faciliter la manipulation d'un
document XML en générant un ensemble de classes qui fournissent un niveau d'abstraction plus
élevé que l'utilisation de JAXP (SAX ou DOM). Avec ces deux API, toute la logique de
traitements des données contenues dans le document est à écrire. JAXB au contraire fournit un
outil qui analyse un schéma XML et génère à partir de ce dernier un ensemble de classes qui vont
encapsuler les traitements de manipulation du document. Le grand avantage est de fournir au
développeur un moyen de manipuler un document XML sans connaître XML ou les
technologies d'analyse. Toutes les manipulations se font au travers d'objets java. [1][2]
2-Réalisation :
2.1-Déploiement du système :
Le diagramme de déploiement est un diagramme Uml qui permet de donner une vue physique
sur le déploiement de notre système sur les dispositifs physiques. La figure ci-dessous présente le
diagramme de déploiement relatif au système.
41
Figure 14 : Diagramme de déploiement
Description :
A partir de ce diagramme, nous pouvons dégager les différents modules de notre système. En
effet, le composant AuditDashboard correspond aux informations consultées et manipulées de
l’application reliées au serveur d’application Apache Tomcat via le protocole Transfer Control
Protocol/Internet Protocol TCP/IP. Ainsi il est relié au serveur de base de données via le
connecteur Java DataBase Connector (JDBC).
L’application est exploitée par les utilisateurs via un navigateur web invoquant le serveur web
Apache Tomcat via le protocole Hyper Text Transfer Protocol (http).
A partir de ce diagramme de déploiement, nous pouvons dégager d’une manière plus claire et
précise les différentes fonctionnalités du système à l’aide des différentes interfaces réalisées.
2.2-Interfaces Homme-Machine :
Dans cette partie nous envisageons présenter les modules de l’application avec les interfaces qui
leur correspondent
42
Figure 15 : Interfaces d’ajout d’un chef de projet
Figure 16 : Interfaces d’ajout d’un auditeur
Ces deux interfaces correspondent à la fonctionnalité d’ajout des utilisateurs à la base de

données. La première interface concerne l’ajout d’un utilisateur ayant comme rôle : « Chef de
projet » et la deuxième interface correspond à l’ajout d’un utilisateur avec le rôle
« Auditeur ».L’ajout des utilisateurs à la base de données est une fonctionnalité propre à
l’administrateur. L’administrateur ne peut pas exploiter l’application sans passer par la phase
d’authentification.
43
Figure 17 : Interface de suppression et de mise à jour des utilisateurs
Cette interface correspond à la mise à jour de la liste des auditeurs. Cette fonctionnalité est
réalisée par l’administrateur pour modifier ou supprimer un utilisateur si nécessaire.
44
Figure 18 : Interface d’ajout d’une organisation
Cette interface illustre la fonctionnalité d’ajout des informations concernant l’entreprise. Elle
consiste en le remplissage du formulaire
Figure 19 : Interface de consultation du planning
45
Cette interface correspond à la fonctionnalité de consultation de planning. Le planning est

représenté sous forme d’un calendrier contenant la liste des tâches qui peuvent être consultées par
tous les auditeurs affectés au projet d’audit technique ainsi que leur chef de projet. A partir de cette
interface l’édition du planning est possible si un utilisateur juge nécessaire un changement dans le
planning.
Figure 20 : Interface d’édition de planning
Cette interface décrit l’édition du planning. L’auditeur ou le chef de projet peuvent estimer des
durées antérieures ou ultérieures à celles fournies par le plan de charges et peuvent par conséquent
modifier le planning. L’auditeur choisit la tâche à éditer, puis modifie sa date de début et sa date de
fin et valide la modification.
46
Conclusion
Ce chapitre est une récapitulation de l'environnement utilisé pour mettre en œuvre notre travail
ainsi que la présentation de quelques fonctionnalités de l'application réalisées pendant ce projet.
Le système que nous avons développé facilitera les processus de génération automatique de
rapport d’audit, la génération du plan de charge et du plan d’action.
47
Chapitre 5 : Gestion de projet
Introduction
Dans ce chapitre nous présenterons le modèle de cycle de vie que nous avons suivi pour le
développement de notre application. Puis nous illustrerons le découpage de notre projet en
tâches ainsi que leurs déroulements.
1-Modèle de cycle de vie adopté:

Modèle en spirale peut être défini comme un modèle basé sur SDLC (Systems Development Life
Cycle). Il intègre des caractéristiques de modèle de cascade et le modèle de prototypage. SDLC
est tout simplement un modèle qui fournit des lignes directrices pour la procédure et les
différentes phases de développement de logiciels, comme requis, de l'architecture, de
l'application et de test suivie par un entretien. Modèle en cascade est définie comme une
méthode de l'avancement séquentiel et linéaire d'un logiciel. Modèle de prototypage est la
construction et l'essai d'un prototype de développement requis.
Procédure pour le développement du modèle en spirale :
48
Figure 21 : Modèle en spirale
Étape 1: Les conditions requises du nouveau système sont décrites en détail, en consultant tous
les utilisateurs du modèle existant et conception d'un système d'introduction est préparé pour
nouveau modèle ou du système.
Étape 2: Première archétype est construit avec des caractéristiques proches du système final,
suivie par la création du second type.
Étape 3: Création second prototype consiste à évaluer la performance de la première et de

décrire les conditions requises par le second prototype, suivie par la construction et l'essai la
seconde architecture.
Étape 4: Les écarts dans le coût estimatif en cours d'exécution sont évalués et l'efficacité du
nouveau prototype est testée pour savoir si le nouveau modèle répond aux attentes du client.
Étape 5: Les étapes de la création d'un nouveau prototype sont répétées jusqu'à ce que le
nouveau prototype remplisse toutes les exigences du client.
Étape 6: Entretien du nouveau modèle est fait pour éviter briser, jusqu'à ce qu'il soit assuré que
le nouveau système fonctionne sans heurts.
Tout comme n'importe quel autre système ou modèle, un client doit évaluer les avantages et les
inconvénients du modèle en spirale. Passons en revue ces rapidement.
49
Analyse des risques :

La mise en œuvre demande des compétences managériales et devrait être limitée aux projets
innovant à cause de l'importance que ce modèle accorde à l'analyse des risques.
Citons, par exemple :
 Risques humains:
− Défaillance du personnel ; surestimation des compétences
− Travailleur solitaire, héroïsme, manque de motivation
 Risques processus
− Pas de gestion de projet
− Calendrier et budget irréalistes
− Calendrier abandonné sous la pression des clients
− Composants externes manquants
− Tâches externes défaillantes
− Insuffisance de données
− Validité des besoins
2-Planification du projet :
La planification consiste à définir l’enchainement des tâches les unes par rapport aux autres et à
placer celles-ci en fonction du calendrier pour définir les instants où ces tâches pourront être
réalisées.
Étape 1 : Recherche bibliographique et découverte des technologies à utiliser.

Étape 2 : Rédaction du cahier des charges
Étape 3 : Analyse et spécification des besoins du projet.
Étape 4 : Conception du projet
Étape 5 : Développement et mise en place de l'application.
Étape 6 : Tests et validation
Étape 7:Rédaction du rapport
Le projet réalisé a duré quatre mois avec une décomposition de temps selon le chronogramme de
la figure ci-dessous :
50
Figure 5.1 Chronogramme de réalisation de projet
Conclusion
Le découpage du projet en étapes nous a été bénéfique puisqu’il nous a permis de bien organiser
et ordonner les différentes tâches.
51
Conclusion et perspectives
Notre travail s’inscrit dans le cadre d’un stage de fin d’´etudes, effectué au sein du Keystone
Consulting, en vue de l’obtention du mastère professionnel en Sécurité des Systèmes
Informatiques Communicants et Embarqués de l’Institut Supérieur d’Informatique.
Le fruit de ce mémoire de fin d’études est un système intitulé « Audit Managing Dashboard »
permettant de faire une automatisation entière des tâches des auditeurs avec une mise en place
d’une politique de sécurité permettant de restreindre l’accès à l’application aux personnes
autorisées. Ce travail qui a duré dans les environs de quatre mois, a nécessité la mise en œuvre
des différentes connaissances que nous avons apprises à l’ISI pendant les cinq dernières années,
les plus importantes étant la programmation Orientée Objet, la conception des Interfaces
Homme-Machine et la programmation web.
Ce projet nous a été bénéfique tant au niveau de l’expérience professionnelle qu’au niveau de
l’amélioration de notre savoir faire en matière de développement des applications, au niveau de la
programmation orientée objet et surtout dans le langage de programmation Java.
Pour conclure, ce projet nous a été constructif aussi bien au niveau scientifique qu’intellectuel et
même personnel puisqu’il nous a aidés à s’intégrer dans le domaine professionnel. Nous avons
constaté tout au long de la réalisation de ce projet de fin d’étude, que nous avons beaucoup
appris et qu’il nous reste beaucoup à apprendre.
Nous proposons dans ce qui suit la liste des perspectives de notre système: autrement dit, nous
allons présenter les améliorations qui peuvent y être apportées ainsi que les nouveaux horizons
que peut ouvrir ce projet de fin d’´etude.
Vu la tendance de la mobilité et puisque la technologie progresse pour s’orienter vers une

technologie mobile, il faudrait rendre notre application accessible via les terminaux mobiles.
Ainsi, nous proposons d’introduire une fonctionnalité de génération d’alarme à l’aide d’envoi
d’un SMS pour notifier les utilisateurs à chaque production d’un événement important
concernant la mission d’audit technique.
52
En guise de conclusion, nous souhaitons intégrer un moteur de workflow qui servirait à

orchestrer et ordonner les différentes tâches des auditeurs .Il servirait à automatiser le passage
entre les différentes étapes d’une mission d’audit tout en prenant en considération la notion de
temps de session affectée à chaque étape au préalable par le chef de projet.
53
Glossaire
A
Audit : C’est l'examen professionnel qui consiste en une expertise par un agent compétent et
impartial et un jugement sur l'organisation, la procédure, ou une opération quelconque
d'une entité.
F
Framework : Bibliothèque définissant une méthode de travail.
H
HTML : (En anglais : HyperText Markup Language) : Langage de document hypertext pour
l'internet.
J
JavaEE : Version entreprise des spécifications de la plateforme java
JDBC : (Java Data Base Connectivity) : API normalisée permettant l'accès au système de base
des données (SGBD).
JSF : (Java Server Faces) : Un Framework JavaEE suivant le Design Pattern MVC2.
M
MVC: (Modèle-vue-contrôleur) : Design Pattern qui propose de séparer les composants en trois
parties : un modèle, représentation interne des objets une vue, présentation des données un
contrôleur, gestion des actions sur le modèle.
54
S
SGBD : (En français : Système de Gestion de Base de Données) : Logiciel permettant de stocker
les données, de les mettre à jour et de les consulter.
SQL : (Structured Query Language) : langage permettant d'effectuer des requêtes sur une base
des données.
T
Tomcat : Projet Jakarta relatif à un conteneur de servlets utilisé comme une implémentation
logicielle des techniques JSP et servlets java. Il est développé dans un environnement ouvert et
participatif. Il est distribué sous Licence Apache.
U
UML : (En anglais : Unified Modeling Language) : concept de modélisation orientée objet.
X
XML : (En anglais : eXtensible Markup Language) : Langage de description de données a base de
balise.
55
Bibliographie
MuIler P.A., Modélisation objet avec UML, Paris : Eyrolles, l997
Rick Cattell, Jim Inscore, J2EE Conception d’applications d’entreprises
Gary Mak, Spring par l'exemple
56
Nétographie
[1] : http://www.mkyong.com
[2] : http://javabrains.koushik.org
[3] : http://www.primefaces.org
[4] : http://stackoverflow.com/
[5] : http://tahe.developpez.com/
[6] : http://www.coreservlets.com/
57
AnnexeA
SPRING :
Spring est un framework complet d’application Java/JavaEE hébergé par la communauté

SpringSource, connu précédemment sous le nom Interface21. Spring prend en charge de
nombreux aspects du développement d’une application Java/Java EE et aide à produire plus
rapidement des applications de qualité et de performances élevées.
Spring s’intègre avec :Hibernate ou toplink

JSF ou Struts
Les standards de JavaEE
Spring s’appuis sur : La programmation orientée aspect

L’inversion de contrôle
Architecture de Spring 3.0
Figure 22 : Architecture de Spring 3.0
58
L’inversion de contrôle : IOC
L’idée de ce principe est d’inverser le sens de recherche des ressources. Dans une recherche
traditionnelle, les composants extraire les ressources en consultant un conteneur délivre lui-
même des ressources aux composants qu’il géré. Avec Spring IoC ce n'est plus l'application
qui appelle les ressources de l’application , mais un framework qui, à l'aide d'une couche
abstraite mettant en œuvre un comportement propre, va appeler les ressources en
l'implémentant, cette comportement est assurée de deux façons différentes :
- La recherche de dépendances : consiste pour un objet à interroger le conteneur, afin de

trouver ses dépendances avec les autres objets
- L’injection de dépendances : permet de déléguer la gestion du cycle de vie des

dépendances et leur injection à une application au lieu de laisser celle-ci créer
directement les instances des objets dont elle a besoin
59

Rapport Hamdoun - Bouthelja Ssice

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

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 :

Formats disponibles

Rapport Hamdoun - Bouthelja Ssice

Transféré par

Droits d'auteur :

Formats disponibles

République Tunisienne

Ministère de l’Enseignement Supérieur,

HAMDOUN Emir BOUTHELJA Safa

Encadrant de l’entreprise : Monsieur ELMIR Haythem

Encadrant à l’ISI : Monsieur KHALFALLAH Adel

A Mon cher Frère et ma chère sœur Wassim et Marwa.

A Ma grand-mère Wissal celle qui m’a fait l’honneur d’être ma grand-mère.

A toutes la famille HAMDOUN et CHERIF

A Mes très chers cousins Ismail et Ahmed

En signe de reconnaissance, je dédie ce mémoire à :

A Mes chers parents Salah et Hayet

A mes adorables sœurs Soumaya, Yosra, Kawther,

Pour que je puisse achever mes études.

A mon binôme Emir

A Mes chers frères Ahmed et Taieb

A mes chères cousines

A Toute la famille Bouthelja et Mensi

A Tous mes amis sans exception

Et a tous ceux qui m’ont aidé de prés ou de loin à la réalisation de ce travail.

patience qu’il nous a accordées pour pouvoir accomplir ce travail.

l’honneur de bien accepter d’évaluer ce projet.

Table des matières

Chapitre 1 : Etat de l’art ...................................................................................... 3

2.1-Diagramme de paquetages :.......................................................................................... 26

Table des figures

Chapitre 1 : Etat de l’art

1- Présentation de l’organisme d’accueil

Services organisationnels : Keystone aide les entreprises à définir l'organisation adéquate

Développement de compétence : Keystone considère que le savoir est la première barrière de

- Monitoring des sites Web

- Le traitement des incidents et l'investigation judiciaire:

- Les tests de pénétration

2.2-Processus d’audit technique

Chapitre 2 : Spécification des besoins

1.1-Les cas d’utilisation :

Administrateur : C’est un acteur humain. Son rôle consiste à l’administration du système et à la

1.1.2-Identification des cas d’utilisations :

2-Diagramme des cas d’utilisation générale :

Figure 2:Diagramme des Cas d’utilisation générale

2.1-Raffinement des cas d’utilisation :

Cas d’utilisation de la gestion de projets « Crud projet d’audit » :

Cas d’utilisation de la gestion de la base « Crud base de vulnérabilités» :

b. Si l’administrateur introduit une valeur erronée dans les champs réservés à la

Cas d’utilisation de la gestion des auditeurs «Crud auditeurs» :

Acteur : Chef de projet

3. Le chef de projet remplit le formulaire par les informations adéquates : Entité

Acteur : Chef de projet.

Cas d’utilisation de la gestion des tâches de projet «Crud tâches de projet» :

Acteur : Chef de projet.

Pré-condition : Chef de projet authentifié avec succès.

Cas d’utilisation de l’affectation d’un auditeur «Affecter auditeur» :

Acteur : Chef de projet.

Cas d’utilisation de l’édition du planning « Editer le planning» :

Acteur : Chef de projet, auditeur

Cas d’utilisation du suivi de l’avancement du projet «Faire suivi projet »

Acteur : Chef de projet

Post-conditions : Projet et/ou tâches consultées avec succès.

Acteur : Auditeur, chef de projet

3-Besoins non fonctionnels :

Les interfaces de l’application doivent être conviviales et présentent un certain niveau

2 UName Nom de l'utilisateur Chaine de caractères 20 Nom de l'utilisateur de l'application.

5 Login Login de l'utilisateur Chaine de caractères 30 Attribut stockant le login de l'utilisateur.

7 UAdress Adresse de l'utilisateur Chaine de caractères 50 Attribut stockant l'adresse de l'utilisateur.