PREMIERE PARTIE : PRESENTATION DE LA STRUCTURE

D’ACCUEIL, DEROULEMENT DU STAGE ET ETUDE

PREALABLE

Dans cette partie, nous allons au chapitre 1 procéder d’abord à une présentation brève mais
édifiante de la SOCIETE DES BRASSERIES DU CAMEROUN, ses activités, son organisation, sa
vision et par la suite dans le chapitre 2 le déroulement du stage consistera à expliquer l’accueil les
tâches effectuées ensuite une étude préalable du système
 CHAPITRE II : DEROULEMENT DU STAGE ET ETUDE
PREALABLE

SECTION 1 : DEROULEMENT DE STAGE

I. ACCUEIL ET INTEGRATION

Notre stage a débuté le 01 juillet 2019 à la SABC de l’usine de Koumassi à douala. À notre
Arrivé à 7h00 à la SABC, nous avons été reçus au standard après s’être enregistré avec nos cartes
d’identités à la guérite, nous avons patienté avant d’être accompagné par un employé aux ressources
humaines. A notre arrivée aux ressources humaines nous nous sommes faits identifiés par nos
différentes lettres de stage, munis d’un badge et d’un équipement de sécurité à porter sur le site
(casque et choisible). Par la suite nous avons reçu un cours sur les règles de sécurité à respecter sur le
site et enfin chacun a été dirigé vers le service dont son stage était tenu de se dérouler. L’accueil
chaleureux nous a laissé entrevoir le bon déroulement de l’ensemble du stage. Arrivé au Help Desk
nous avons été reçus par le chef de la section Mr EBONGOM Thierry Alex.

II. TACHES EFFECTUEES

Au sein du service Help Desk nous avons effectué, plusieurs taches ayant participées à son bon
fonctionnement parmi lesquelles :

 CONFIGURATION DES UTILISATEURS.

Nous avons eu à installer et paramétrer les logiciels tels que E. lions, Outlook qui permettait la
gestion du personnel et la communication des utilisateurs. Nous avons aussi connecté les utilisateurs
aux imprimantes pour faciliter les impressions depuis leur poste de travail.

 MAINTENANCE PREVENTIVE.
Ici nous avons nettoyé aussi bien intérieurement qu’extérieurement les équipements
informatiques (écrans, Unité Central, scanner etc.… ) et Tout ceci demandait l’utilisation d’une
souffleuse (pour l’intérieure), d’un produit chimique et d’un chiffon (pour la surface).

 DEPLOYER UNE MACHINE.

Nous avons déployé les machines c’est-à-dire transférer les données d’une ancienne machine
vers une nouvelle machine et cela consistait à :
 La sauvegarde des données également dans un disque externe pour éviter toutes pertes.
 Mettre en conformité le poste de travail, ce qui est spécifique au profil de l’utilisateur. Nous
soulignons que le choix du profil utilisateur, permet de lui restreindre ou non certains droits,
d’attribuer ou non certains logiciels.
SECTION 2 : ETUDE PREALABLE
La conception et la réalisation d’un système d’information informatisé fiable c'est-à-dire qui
vise à respecter la règle CQFD (Coût Qualité Fonctionnalité Délais) débute toujours nécessairement
par des études préalables. Ces dernières qui se font toujours par le biais des interviews auprès des
services concernés, jouent un rôle prépondérant pour la compréhension des besoins métiers. Ainsi
dans cette section, nous débuterons par une étude d’opportunité, ensuite nous ferons une étude de
faisabilité et enfin nous bâtirons le cahier de charges du projet.

I. ETUDE D’OPPORTUNITE

Cette étude nous permet de juger l’intérêt de l’informatisation du système. Vu les informations
reçues de ce système, il est opportun de changer le système car ce circuit d’information présente
beaucoup d’inconvénients. Ainsi avec la conception et réalisation d’une application de gestion des
incidents, L’entreprise pourra connaitre les incidents enregistrés et traités au cours d’une semaine
voir un mois, connaitre quel est le responsable ou l’intervenant qui a résolu l’incident.

II. ETUDE DE FAISABILITE

L’étude de faisabilité dans la gestion de projets est une étude qui tend à prouver que le Projet
est faisable et rentable. Elle permet à celui charger de l’analyse d’établir les coûts estimatifs du
système futur qui sera comparé aux coûts du système actuel. La question posée ici est de savoir si
l’entreprise est capable de supporter les coûts déchargés ? Y a-t-il un avantage vu les différents coûts
de changer de système ? Cependant, c’est pour permettre une bonne gestion dans ces affaires que
nous voulons monter ce projet de gestion informatisée des incidents. Ainsi l’on retrouvera sa
situation actuelle dans l’existant par la suite.

III. ELABORATION DU CAHIER DE CHARGES

1. Définition

Le cahier de charges est un document technique conçu et élaboré généralement par le MOA
(Maitre d’Ouvrage) et qui vise à comprendre clairement les objectifs de la solution informatique à
réaliser par le MOE (Maitre d’Œuvre).

Pour cette étude, il sera question pour nous de définir certains concepts qui nous permettrons de
mieux comprendre l’existant de l’entreprise.
 2. Recueil de l’existant

Le service informatique est chargé de gérer les incidents informatiques qui concourent aux
besoins des différents services et au développement de l’entreprise. On peut citer entre autres :
clavier endommagé, disfonctionnement du système d’exploitation, problème de mise à jour des
antivirus, problème de connexion au réseau, configuration de l’imprimante, machine défectueuse etc.

Lorsque l’incident survient dans un service, l’employé décrit son problème sur un bout de
papier et transmet au service informatique qui se chargera d’analyser le problème. Si le problème
est à la compétence des techniciens de l’entreprise, alors le chef service l’affecte à un technicien.
Sinon il fait appel à un intervenant externe. Lorsque le problème, est résolu, un rapport est fait au
chef service informatique qui se charge de clôturer l’incident.

3. Définition de la problématique

Présentement la déclaration des incidents informatiques se fait manuellement, autrement dit

elle se fait sur des bouts de papiers. Cette gestion manuelle pose de nombreuses difficultés à savoir:

 La difficulté d’avoir l’état de résolution d’un incident;

 La complexité dans l'établissement de l'état de l’incident;

 La lenteur dans le traitement, que ce soit dans la transmission des Informations ou pour une
recherche à cause d’excès de paperasses ;

 La difficulté dans l'analyse des incidents collectifs.

Malgré les insuffisances relevées, ce système possède certains points forts à savoir :

 La vérification des éventuels problèmes sur la machine des utilisateurs ;

 Le contrôle de la résolution des incidents causés sur les machines des utilisateurs.

4. Les résultats attendus

Nous devons concevoir et réaliser une application de gestion des incidents informatiques. Il
s’agira ici d’une application de bureau qui devra fonctionner dans un réseau local d’entreprise et qui
devra interagir avec une base de données centralisée afin de garantir le partage des données.

5. Responsabilités et rôles respectifs des parties engagées dans l'intervention

 Il sera question ici de déceler toutes les responsabilités des personnes intervenant dans ce
système. Ainsi ces intervenants sont :

*chef service informatique

Ici il joue le rôle d’administrateur et de ce fait il bénéficie de tous les droits d’accès de notre
application de gestion des incidents informatiques. Il doit être capable :

 De s’authentifier.

 De réinitialiser son mot de passe.

 De gérer son profil.

 De lister les différents incidents.

 D’éditer et consulter la liste des incidents.

 D’éditer et consulter la liste des utilisateurs.

 De gérer les incidents.

 De consulter la liste des incidents résolus.

 De vérifier si l’incident a été résolu.

 De Clôturer un incident.

* employé

Il doit être capable :

 De s’authentifier ;

 De se connecter ;

 Gérer son profil ;

 De modifier son mot de passe ;

 De décrire ces incidents ;

 De soumettre un incident.

6. Spécification fonctionnelle de l’application

 Pour commencer tous les services auront accès à l’application de gestion informatisée des
incidents, chacun disposera d’une session et ne pourra réaliser que les actions en rapport au droit
d’accès qui lui seront octroyé. L’ordinateur supporté par cette application favorisera la
communication et la gestion cohérente des incidents informatiques. Il sera constitué de quelques
stations interconnectées de type client-serveur local.

7. Mesure de succès

A l’issue de la mise en place de cette application interactive, l’outil permettant de mesurer si

l’atteinte des objectifs est effective, sera les tests d’acceptation et de validation. Après le déploiement
du système, une période d’un mois sera accordée à la SABC, leur permettant d’éprouver le système
afin de mesurer si les objectifs ont été atteints de façon efficace et efficiente. Un contrat de
maintenance sera dressé après la phase d’exploitation.

8. Contraintes du projet

Cette partie vise à savoir clairement les moyens qui seront dégagés pour la mise en place de
l’application. Dans le cadre de notre projet, on doit faire face à plusieurs contraintes :

a. Contrainte financière ou évaluation du coût de possession de l’informatique

Le coût est un paramètre très important à prendre en compte avant tout acquisition
et mise en place d’un outil de gestion des incidents.

Désignation Prix unitaire Quantité Montant

Coût de spécification fonctionnelle 150 000 FCFA 1 150 000 FCFA

Coût de conception détaillée 250 000 FCFA 1 250 000 FCFA

Coût d’implémentation ou codage 200 000 FCFA 1 200 000 FCFA

Coût de formation personnel 100 000FCFA 1 100 000 FCFA

Coût de maintenance manuelle 60 000 FCFA 1 60 000 FCFA

MONTANT TOTAL 760 000 FCFA

b. Contrainte temporelle
 Le déroulement du projet est planifié grâce aux réunions tenues avec les intervenants au sein de
la SABC .Nous avons pu définir plusieurs grandes phases : la première est consacrée à la
spécification fonctionnelle avec la recherche sur les éléments nécessaires pour aboutir à une solution.

Une phase parallèle a été faite, notamment la conception détaillée. Quant à la troisième étape,
elle traite l’implémentation (Codage, Design, installation. . .). Concernant l'élaboration du rapport.

Une période de formation est nécessaire pour pouvoir prendre en considération les notions de
base de l'architecture et de quelques notions techniques.

Le système informatique sera conçu et réalisé pour une période de Huit (08) mois dont voici ci-
dessous les détails de la feuille de route du projet inscrit dans le diagramme

N° des tâches Etape de réalisation Délais

A Spécification fonctionnelle 1 mois

B Conception détaillée 2 mois

C Implémentation 4 mois

D Formation 1 mois

Durée totale de la réalisation du projet Huit (8) mois

Le diagramme de GANTT est l’outil utilisé en ordonnancement et en gestion de projet et

permettant de visualiser dans le temps les diverses tâches composant un projet. Il a pour rôle de :
 Déterminer les dates de réalisation d’un projet,
 Identifier les marges existant sur certaines tâches,
 Visualiser d’un seul coup d’œil le retard ou l’avancement des travaux.

Diagramme de GANTT

c. Contraintes technologiques
 Les contraintes technologiques qui nous seront imposées sont :
MySQL : est un système de gestion de base de données (SGBD). Il est
distribué sous une double licence GPL (Général Public License) et
propriétaire. Il fait partie des logiciels de gestion de base de données les plus
utilisés au monde, autant par le grand public, que par des professionnels.

VISUAL STUDIO : est un environnement de développement intégré (IDE)

de Microsoft. Il est utilisé pour développer des programmes informatiques,
ainsi que des sites Web, des applications Web, des services Web et des
applications mobiles. Visual Studio utilise des plates-formes de
développement logiciel Microsoft telles que l’API (Application Programming
Interface Windows, Windows forms etc…

WINDESIGN est un outil de modélisation, offrant trois modules

autonomes et communicants (database, objet, business process
cartographie SI) ces modules vont vous permettre de concevoir, de
modéliser et de spécifier chaque angle de vues des systèmes
d’information.

XAMPP est un ensemble de logiciels permettant de mettre en place

facilement un serveur web et un serveur FTP. Il s’agit d’une distribution de
logiciels libres ( X apach mysql perl php) offrant une bonne souplesse d’
utilisation, réputée pour son installation simple et rapide.

APACHE est une description complète du serveur web apache.

Apache est un logiciel de serveur web gratuit et open-source qui alimente
environ 46% des sites web à travers le monde. Le nom officiel est serveur
apache http et il est maintenu et développé par apache software fondation.

PHPMYADMIN (PMA) est une application web de gestion de base

de données MYSQL réalisé principalement en PHP et distribuée sous
licence GNU GPL.

Ainsi, parvenu au terme de ce chapitre qui nous a permis de comprendre clairement les tenants
et les aboutissants de l’application de gestion des incidents informatiques que nous envisageons
développer. Nous allons maintenant nous appesantir sur la deuxième partie de notre rapport qui est
constituée de l’étude détaillée et de l’implémentation.
 PARTIE II ETUDE DETAILLEE ET IMPLEMENTATION

Cette partie de notre travail traite l’étude détaillée c’est -à-dire les besoins fonctionnels, le
langage de modélisation utilisé en chapitre 3, et l’implémentation de notre système c’est-à-dire les
captures de quelques interfaces de l’application en Chapitre 4.
 CHAPITRE III : ETUDE DÉTAILLÉE

La phase de conception permet de décrire de manière non ambiguë, le plus souvent en utilisant
un langage de modélisation, le fonctionnement futur du système, afin d'en faciliter la réalisation. Pour
faciliter notre tâche nous avons recours au langage de modélisation unifié (UML: Unified Modeling
Language) c'est une notation qui permet de modéliser un problème de façon standard. Ce langage qui
est né de la fusion de plusieurs méthodes existantes auparavant est devenu une référence en termes de
modélisation objet, UML est caractérisé par un support de communication performant mais aussi
c'est un langage formel et normalisé.

Il permet le gain de précision, encourage l'utilisation d'outils et constitue à cet effet un gage de
stabilité;

Il cadre l'analyse et facilite la compréhension des représentations abstraites complexes. Son

caractère polyvalent et sa souplesse en font un langage universel.

I. ANALYSE DES BESOINS FONCTIONNELS

Nous rappelons qu'un besoin fonctionnel est un besoin spécifiant une action qu'un système doit
être capable d'effectuer sans considérer aucune contrainte physique. C'est un besoin spécifiant un
comportement d'entrée/sortie d'un système.

1. Les acteurs du système

D’après les études que nous avons faites dans le chapitre précédent, nous avons identifié les
acteurs suivants pour notre système.

L’administrateur qui est responsable du service informatique peut :

 s’authentifier.

 réinitialiser son mot de passe.

 gérer son profil.

 lister les différents incidents.

 éditer ou consulter la liste des incidents.

 éditer ou consulter la liste des utilisateurs.

  gérer les incidents.

 Consulter la liste des incidents résolus.

 Vérifier si l’incident a été résolu ou non.

 Clôturer un incident.

* employé

Il doit être capable:

 De s’authentifier ;

 De décrire ses incidents ;

 Modifier son mot de passe ;

 De soumettre son incident ;

 Rejeter un incident non résolu ;

 Valider l’incident résolu.

2. Diagrammes des cas d’utilisation

Un cas d'utilisation (en anglais use case) permet de mettre en évidence les relations
fonctionnelles entre les acteurs et le système étudié. Le format de représentation d’un cas d’utilisation
est complètement libre mais UML propose un formalisme et des concepts issus de bonnes pratiques.
Le diagramme de cas d'utilisation permet de représenter visuellement une séquence d'actions
réalisées par un système, représenté par une boîte rectangulaire, produisant un résultat sur un acteur,
et ceci indépendamment de son fonctionnement interne.

Les cas d’utilisation : Les cas d'utilisation décrivent, sous la forme d'actions et de réactions, le
comportement, ou tout simplement ce que fait le système du point de vue de l'utilisateur, encore
appelé acteur. On recense, de la sorte, l'ensemble des fonctionnalités d'un système en examinant les
besoins fonctionnels de chaque acteur.

Les acteurs : Un acteur représente un ensemble cohérent de rôles joués par les utilisateurs des
cas d’utilisation en interaction avec ces cas d’utilisation. En règle générale, un acteur représente un
rôle qu’un homme, une machine ou même un autre système joue avec le système. Il existe 4 grandes
catégories d'acteurs :
 - les acteurs principaux. Cette catégorie regroupe les personnes qui utilisent les fonctions
principales du système.

- les acteurs secondaires. Cette catégorie regroupe les personnes qui effectuent des tâches
administratives ou de maintenance.

- le matériel externe. Cette catégorie regroupe les dispositifs matériels autres que les
ordinateurs comme les périphériques.

- les autres systèmes. Cette catégorie regroupe les systèmes avec lesquels le système interagit.

Les relations entre les cas d’utilisation: UML définit trois types de relations standardisées
entre cas d’utilisation, détaillées ci-après :

- La relation d’inclusion: formalisée par le mot clé « include », le cas d’utilisation de base en
Incorpore explicitement un autre de façon obligatoire.

- La relation d’extension : formalisée par le mot clé « extend », le cas d’utilisation de base en
incorpore explicitement un autre, de façon optionnelle.

- La relation de généralisation ou spécialisation : Les cas d’utilisation descendant hérite de la

description de leur parent commun. Chacun d’entre eux peut néanmoins comprendre des interactions
spécifiques supplémentaires.

Après l’identification des acteurs, nous avons élaboré le diagramme des cas d’utilisation. Les
figures montrent les diagrammes respectifs de l’administrateur et l’employé.

Diagramme de cas d’utilisation de l’administrateur

 Diagramme de cas 4d’utilisation de l’employé

3. Description détaillée des cas d’utilisation

 Après l’identification des cas d’utilisation du système et leur affection aux acteurs nous avons
développé les fiches techniques associées. Pour chaque cas d’utilisation nous avons donné une
description détaillée des scénarios. Pour chaque cas d’utilisation nous avons donné une description
détaillée des scénarios. Ainsi nous présenterons la description des cas d’utilisation les plus
importants.

Administrateur

Cas d’utilisation «Authentification»

Nom du cas d’utilisation S’authentifier

Description brève Ce cas d’utilisation permet à l’utilisateur d’accéder à

l’interface principale de l’application en saisissant le login et
le mot de passe.

Acteurs Employé

Pré condition

Post condition Accéder aux services de l’application

Scénario normal1 1. L’acteur saisie son login et son mot de passe et valide

2. Le système vérifie le couple login/mot de passe.

[Link] système affiche l’interface principale de l’application

Scénario alternatif 1 1) L’acteur saisie son login et son mot de passe et valide.

2) Le système vérifie le couple login/mot de passe.

3) Le système indique que le login et le mot de passe sont

Invalides.

4) Le système vide les zones de saisie et affiche un message

d’erreur.
 Cas d’utilisation <<gérer les incidents>>

Cette partie permet de lister l’ensemble des fonctionnalités de la gestion des incidents :

 Enregistrement d’un nouvel incident ;

 Recherche incident ;

 Modification d’un incident ;

 Suppression d’un incident ;

 Ajout d’un incident ;

 Lister les incidents.

 Description textuaire du cas d’utilisation<<gérer les incidents>>

nom de cas d’utilisation Gérer les incidents

Description brève L’employé saisie son login et son mot de passe pour
accéder au système. s’il fait une erreur il est renvoyé à la
page d’authentification, autrement il accède à son espace
et gère les incidents de l’entreprise.

Acteurs intervenant, responsable, administrateur

Précondition L’utilisateur n’est pas authentifié

Post condition Utilisateur désactivé

Scenario principale L’utilisateur consulte la liste de l’incident

L’utilisateur modifie l’incident

L’utilisateur supprime un incident

L’utilisateur ajoute une exigence

Le système vérifie le non duplication du nom de

l’incident

Si duplication, informer l’utilisateur et recommencer

Sinon enregistrer les données

Cas d’utilisation << gérer les intervenants>>

Cette partie permet de lister l’ensemble des fonctionnalités de gestion des techniciens.

 associer un incident à un intervenant ;

 associer une solution à un incident ;
 lister les intervenants ;
 créer un intervenant ;
 modifier un intervenant ;
 supprimer un intervenant ;
 ajouter un intervenant.
Description détaillée des cas d’utilisation<< gérer les intervenants>>

nom de cas d’utilisation Gérer les intervenants

Description brève Ce cas d’utilisation permet après le
traitement de l’incident d’associer à la
solution trouvé a l ‘incident et d’associer un
incident a un intervenant.

Acteurs administrateur

Précondition L’utilisateur doit être authentifié afin

de pouvoir accéder à l’application

Post condition Opération effectué avec succès.

Scenario principale associer un incident à intervenant

demander la liste des incidents

choisis un incident et cliquer sur détails

associer la solution a un incident

 EMPLOYE

Cas d’utilisation << enregistrer un incident>>

nom de cas d’utilisation Enregistrer un incident

Description brève Ce cas d’utilisation permet a l’utilisateur de

déclarer l’incident. et le soumettre.

Acteurs employé

Précondition L’utilisateur doit être authentifié afin de pouvoir

accéder à l’application

Post condition Opération effectué avec succès.

Scenario principal Décrire l’incident

Soumettre l’incident
Rejeter l’incident si ce n’est pas résolu
Valider l’incident si c’est résolu

Cette partie permet de lister l’ensemble des fonctionnalités pour un employé de créer un
incident.
- Décrire l’incident ;
- Soumettre l’incident ;
- Rejeter l’incident si ce n’est pas résolu ;
- Valider l’incident si c’est résolu.
 4. DIAGRAMME DES CLASSES

Le diagramme de classes est généralement considéré comme le plus important dans le

développement orienté objet. Il représente l’architecture conceptuelle du système interne : il décrit les
classes que le système utilise ainsi que leurs liens, un héritage au niveau des classes afin de
minimiser les interactions ou une agrégation entre deux classes. Elles permettent de modéliser un
programme et ainsi de découper une tâche complexe en plusieurs petits travaux simples.

Le diagramme de classes possède plusieurs caractéristiques principales à savoir : les classes

d’objets, les attributs, les identifiants, les opérations et les associations. Un objet est une entité qui a
un sens dans le contexte de l'application.

- Les classes d'objets décrivent un groupe d'objet ayant des propriétés similaires, un
comportement commun, des relations communes avec les autres objets.

- Les attributs sont des propriétés communes à tous les objets d’une classe.

- Une opération est associée à une classe ; c’est une fonction ou une transformation qui peut
être appliquée aux objets d'une classe. Une opération peut avoir des paramètres. (De la même
manière qu’une fonction ou procédure en possède en programmation classique).

- Un identifiant est une propriété particulière d’un objet telle qu’il n’existe pas deux
occurrences de cet objet pour lesquelles cette propriété pourrait prendre une même valeur.

- Une association (appelée aussi parfois relation) est un lien sémantique entre plusieurs classes.

Une association peut relier une, deux ou plusieurs classes. Dans le cas où elle relie n Classes
elle est dite n-aire et dans le cas où elle relie deux classes, elle est dite Binaire. Les classes de
relations sont représentées par des hexagones dont l’intitulé décrit le type de relation qui relie les
classes d’entités (généralement un verbe). On peut éventuellement ajouter des propriétés aux classes
de relations.

Ainsi le diagramme des classes de notre système est le suivant :

*Diagramme de classe
 5. DESCRIPTION DES CLASSES

ATTRIBUTS ET
TYPE SIGNIFICATION
OPERATIONS
INCIDENT
Codeincid string Code incident
Design string Désignation de l’incident
etatincid string Etat de l’incident
heurincid string Heure de l’incident
typeincid string Type de l’incident
dateincid date Date de l’incident
EMPLOYE
Codop string Code de l’employé
suspendu string Employé suspendu
Nomprenom Nom et prénom de l’employé
Tel integer Numéro de Téléphone de l’employé
Sexe string Sexe de l’employé
N°cni string Numéro de la carte nationale d’identité de
l’employé
datenais date Date de naissance de l’employé
Du string Date de délivrance de la carte nationale
d’identité
A string Lieu de délivrance de la carte nationale
d’identité
Suspendu string Employé suspendu
Pwd string Mot de passe de l’employé
SERVICE
Codesce string Code du service d’une agence
Design string Nom du service d’une agence
MENU
Codemenu string Code du menu

design string Désignation du menu

Père string Nom de l’onglet du menu

NATURE INCIDENT
 idnature string Identifiant de la nature de l’incident
libellenature string Libelle de la nature de l’incident
MACHINE
N°mach string Numéro de la machine
caracteristiquemach string Caractéristique de la machine
N°serie string Numéro de série de la machine
marquemach string Marque de la machine

INTERVENANT
Nomprenominter string Nom du technicien

Telinter integer Numéro de Téléphone du technicien

Sexeinter string Sexe du technicien

ncniinter string Numéro de la carte nationale d’identité du

technicien

datenaisinter date Date de naissance du technicien

codeinter string Code du technicien

PRIORITE
npriorite integer Numéro de priorité de l’incident

niveau string Niveau de priorité de l’incident

AGENCE
codeag string Code de l’agence

Design string Désignation de l’agence

Registrecom string Registre du commerce

N°ducontribuable string Numéro du contribuable

Tel string Numéro de téléphone de l’agence

Bp string Boite postal de l’agence

Fax Envoi des courriers électroniques de l’agence

 6. Diagramme de séquence système

Diagramme de séquence du scénario « S’authentifier »

Avant de pouvoir accéder aux fonctionnalités offertes par l'outil de gestion des incidents
informatiques, l’utilisateur doit s'identifier par un "login" et "un mot de passe". Cette phase
d'identification est indispensable pour la suite de l'utilisation de l'outil qui se déroule selon les
informations relatives à l'utilisateur notamment son Rôle (Employé ou Responsable). La figure ci-
dessous illustre en détail le scénario.
 Diagramme de séquence du scénario « Ajout incident»

Après authentification, l'employé accède à la rubrique de la gestion des incidents. Une liste des
incident sera affichée, il choisit le bouton ajouter incident, Le système affiche un formulaire à
remplir. Dans le cas où L'employé saisit les champs d'un incident correct le système affiche un
message de succès.

Diagramme de séquence du scénario « modifier incident»

Après authentification, l'employé accède à la rubrique de modification de l’incident. Une liste

des incidents sera affichée, il sélectionne l’incident, ensuite clic sur le bouton modifier, le système se
charge de modifier.
 CHAPITRE IV : IMPLEMENTATION

Dans tous projets informatiques, l’implémentation consiste à la phase de réalisation du projet.

Ainsi dans ce chapitre il sera question pour nous d’expliquer les techniques d’implémentation de
notre application de bureau. Dans un premier temps, nous nous appesantirons sur l’implémentation
de notre base de données, ensuite, nous expliquerons notre stratégie de codage et nos interfaces tout
en expliquant l’implémentation de notre politique de sécurité.

I- IMPLÉMENTATION DE LA BASE DE DONNEES

Étant donné que l’application de bureau de gestion des incidents informatique est une
application dynamique, c’est-à-dire une application interagissant avec une base de données déduit du
model logique de données de notre système, nous avons utilisé un serveur apache qui lui aussi
possède une application permettant de faciliter la gestion des bases de données MYSQL, qui est
PHPMYADMIN.

Ainsi nous obtenons quelques captures d’écran suivantes liées à la création des tables.

Sur la capture d’écran ci-dessus nous avons en définitive toutes les tables liées à la structure
complète de toute notre base de données.
 [Link] INTERFACES DE NOTRE APPLICATION

Pour commencer, nous allons présenter une interface de connexion de l’application ensuite le
menu principal et les interfaces de gestion.

Cette interface doit nous permettre de nous connecter au système, à cet effet l’utilisateur doit
spécifier son login et son mot de passe. Bien évidement l’utilisateur lors de la phase de connexion
peut ceci via l’interface changer son mot de passe suivante ;

2.a) INTERFACE DE SECURITE

La sécurité est une phase très importante dans un système d’information, raison pour laquelle
elle doit être prise au sérieux.
 Sécurité de données

Pour sécuriser nos données il faut :

-Instaurer le système de mot de passe aux différents utilisateurs du système,

-Installer des anti-virus pour protéger nos fichiers contre les virus informatiques,

-Instaurer des niveaux d’accès aux utilisateurs afin d’éviter des suppressions des fichiers,

Mettre sur pieds une politique de sauvegarde durable des informations qui consiste à
sauvegarder au jour le jour les données sur un support de mémoire auxiliaire.

Sécurité du matériel

La sécurité du matériel est une phase très importante et exige :

L’installation des onduleurs pour pouvoir maintenir les variations du courant électrique.

En outre lors du paramétrage, l’administrateur du système est chargé d’octroyer les

privilèges à chaque utilisateur, ceci pour limiter certaines actions dont il est capable d’effectuer sur le
système.

2.b) INTERFACE DU MENU PRINCIPAL

Cette interface permet à l’utilisateur de prendre connaissance de toutes les fonctionnalités de

notre application.
2.C) INTERFACE DE GESTION DES INCIDENTS

2 .d) INTERFACE PERMETTANT LA GESTION DES EMPLOYES

2.C) INTERFACE PERMETTANT LA GESTION DES AGENCES
CONCLUSION GENERALE
Bilan
Dans le cadre de notre stage académique, il était question pour nous de concevoir et réaliser
une application permettant de gérer les incidents informatiques de la SABC. Pour y parvenir nous
avons commencé par faire l’étude préalable qui nous a permis de cerner les contours et les
mécanismes du projet, par la suite nous sommes passés à la conception détaillée en nous appuyant sur
le langage UML qui nous a permis de réaliser les différents diagrammes ; quant à l’étude du système
futur nous avons pu ressortir les diagrammes tels que : le diagramme de cas d’utilisation, le
diagramme de classe et le diagramme de séquences. Ces différentes études ont permis de faire
l’implémentation qui a été réalisée dans un environnement de développement intégré Visual Studio
2010, PHPMYADMIN, MYSQL.
Durant la réalisation de ce travail, nous avons rencontré un certain nombre de difficultés parmi
lesquelles la plus importante est la difficulté à pouvoir analyser de fond en comble les contours de
notre système avec le langage UML pouvant nous faciliter l’implémentation.

Perspectives
Nous pouvons à présent dire que le challenge d’implémenter une application client-serveur
pour le cadre de notre stage académique est atteint ; car dans l’univers des logiciels, il n’existe
aucune sécurité à 100%. Il n’en demeure pas moins vrai que des améliorations soient possibles.
Confier la réalisation des tests à une équipe externe qui soit constituée des testeurs certifiés qui se
chargeront de mener à bien des tests fonctionnels automatisés. . Ce nouveau système qui est toujours
à sa phase de développement permettra à la SABC d’être plus efficace et surtout d’être plus rapide
dans le traitement des informations.
 RÉFÉRENCES

Quelques supports de cours utilisés :

Cours de méthode et système d’analyse d’information et programmation algorithme de M.
GUEMKAM SANDO et M YAKAM
Cours de programmation web et de base de données de M. GUEMKAM SANDO et M.
TCHOUPOU MELI Alex.
Des anciens rapports fournir par les encadreurs.

Pour les tutoriels nous nous sommes fait aider par des sites suivants:
OpenClassrooms ;
Dé[Link] ;

Quelques liens consultés:

[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
q=interface+de+connexion+du+glpi&client=opera&hs=I6b&source=lnms&tbm=isch&sa=X&ved=0ahUKEwi1

59PQkrnlAhVOQhUIHQqyC-QQ_AUIESgB&biw=1326&bih=658#imgrc=_
ANNEXES