ANNEE-ACADEMIQUE : 2014-2015
UNIVERSITE PROTESTANTE DE LUBUMBASHI
FACULTE DES SCIENCES INFORMATIQUES
DEVELOPPEMENT D'UNE APPLICATION WEB POUR
L'OPTIMISATION DU PROCESSUS D'ARCHIVAGE ET D'ACCES AUX DONNEES D'UNE
ENTREPRISE
(Cas de BELL EQUIPEMENT)
Par ILUNGA KADIATA Freddy
Travail Présenté en vue de L'obtention du titre de
gradué en sciences informatiques
Dirigé par Ass. Néhémie KAZIMOTO
Option : Ingénierie de système d'information
«Ce que l''on conçoit
bien s'énonce
clairement,
Et les mots pour le dire
arrivent aisément.»
Nicolas Boileau
EPIGRAPHE
II
DEDICACE
À vous nos parents, François KADIATA TA-MBUYI et
Clémentine MPEMBA MUTEBUA, qui nous ont inculqué un
esprit de
combativité, de persévérance et qui nous ont
toujours poussé et motivé
dans nos études. Sans vous, certainement nous n'en seront
pas à ce
niveau.
À vous oncle Jean-Pierre KALALA et votre épouse
Tante
Chantale MUSHIYA. Vous étiez pour nous oncle, un
père spirituel et un
modèle à suivre pour être au sommet des
échelons. Nous garderons
toujours un attachement profond pour vous. A vous et votre
famille,
nous serons toujours reconnaissants pour l'assistance que vous
avez
apportée dans nos études.
À tous ceux qui nous lirons, nous tenons
particulièrement à
dédier ce travail, Si nos voeux pouvaient avoir quelques
pouvoirs nous
en serons profondément heureux car nous voulons pour vous,
vos
familles toutes les réussites et satisfactions de ce
monde.
Freddy ILUNGA KADIATA
III
REMERCIEMENTS
La réalisation d'un tel ouvrage a été
rendue possible par le concours de plusieurs personnes que nous nous sentons
obligé de remercier.
A Jéhovah le créateur, le Dieu de toute
consolation, nous disons merci pour l'amour et la bonté
manifestés à notre égard.
Nous tenons à exprimer également nos
remerciements avec un grand plaisir à notre directeur Assistant
Néhémie KAZIMOTO, Ses conseils, Sa disponibilité et ses
encouragements nous ont permis de réaliser ce travail dans les
meilleures conditions. Nous exprimons de même notre gratitude à
monsieur Patient KAMBAJI qui a cru en nous et qui n'a cessé de nous
faire profiter de ses précieux conseils et soutiens.
Nous adressons aussi notre reconnaissance à tous les
professeurs et au corps administratif de l'université protestante de
Lubumbashi qui depuis quelques années leurs conseils et leurs
connaissances nous ont bien servis.
À Mireille KAMUANYA, Claudine MUJINGA, Mamichou MALEYA,
Yolande MIANDA, Laurenne KADIATA, Gemima KAMUANYA nos soeurs qui nous ont
toujours soutenu au prix des sacrifices inoubliables.
À nos frères Franck MUDIANGOMBE et Ken MUTEBUA,
à mes cousins Willy LUKOJI, Alain MUKEBA, Cédric MUTOMBO,
TIMOTHEE KAPUYA, PIERRE LUKOJI, LJ LUKOJI, Andi KALUBI pour vos encouragements
incessants et actes de bienveillances.
Nous tenons à dire combien le soutien quotidien de
notre famille a été important tout au long de ces quelques
années, nous leurs devons beaucoup.
Nous tenons à remercier nos collègues et
camarades de lutte, Donat TSHISWAKA, Rolly SAPEMBA, Sam KABEYA, Tendresse
FUAFUA, Clark NYOTA, Arlenne MBELU Gracia KABONDO, Concilie MUSHIYA, Francisco
KALONDA, Arlenne MBELU et Rodrick TSHIMANGA pour votre sincère
amitié, votre soutien permanent qui nous remonte le moral et vos
conseils qui nous incitent à relever les défis.
Nous ne pouvons nommer ici toutes les personnes qui de
près ou de loin n'ont ménagé aucun effort pour nous aider
et nous encourager. Nous tenons à les en remercier vivement.
IV
LISTE DES FIGURES
Figure 1:Processus d'archivage 10
Figure 2:Tableau de cycle vie des archives 13
Figure 3: Organigramme 20
Figure 4: Diagramme de contexte 22
Figure 5: Diagramme d'orchestration 23
Figure 6: Diagramme de collaboration 23
Figure 7 : Diagramme de cas d'utilisation 29
Figure 8: diagramme de séquence « Authentification
» 33
Figure 9:diagramme de séquence « Archiver document
» 33
Figure 10: diagramme de séquence « consulter
archive » 34
Figure 11: diagramme de séquence « gérer
archive » 35
Figure 12 : Modèle du domaine 37
Figure 13: diagramme de classe participante Consulter Archive
38
Figure 14 : diagramme de classe participante Archiver document
38
Figure 15: diagramme de classe participante Gérer
Archive 39
Figure 16 : Diagramme de séquence du scénario
nominale recherche rapide 40
Figure 17: diagramme de séquence scénario Erreur
de recherche 40
Figure 18:Diagramme de séquence de la suite du scenario
nominale de recherche rapide 41
Figure 19: Diagramme de séquence du scenario nominale
Archivage avec succès 41
Figure 20 : diagramme de classe de conception consulter
archive 42
Figure 21: diagramme de classe de conception Archiver nouveau
document 42
Figure 22: diagramme de classe de conception Gérer
Archive 43
Figure 23: Modèle physique des données 44
Figure 24: architecture 2 tiers 48
Figure 25: architecture 3 tiers 49
Figure 26: Architecture 3 tiers 50
Figure 27: Diagramme de déploiement 51
Figure 28: interface d'authentification 52
Figure 29: code PHP authentification 52
Figure 30: interface de création de compte utilisateur
53
Figure 31:interface d'archivage de documents 53
Figure 32: code PHP classe d'entité Archive 54
Figure 33: interface de consultation des documents 54
Cette nouvelle aire est également
caractérisée par l'expansion de l'archivage
électronique.
1
INTRODUCTION
PRESENTATION DU SUJET
Depuis la nuit des temps à nos jours, l'esprit
perfectionniste de l'homme n'a cessé de croitre et lui permet ainsi
d'améliore sa vie quotidienne. Le passage de la mécanique au
domaine d'électronique, d'automatique et d'informatique a
révolutionné la vie journalière de l'être humain.
Les nouvelles technologies de l'information et de communication illustrent ce
phénomène dans sa forme la plus pure et la plus
complète.
Vu l'intérêt croissant de gagner en temps, de
conserver les données, de limiter le nombre d'employés et
beaucoup d'autres raisons, ont poussé petites, moyennes et grandes
entreprises à chercher des solutions informatiques capables de
répondre à leur besoins.
Dans le même ordre d'idée, l'homme a pensé
délecter son cerveau de certaines taches par des outils technologique
qu'il ne cesse de perfectionner. Car comme jadis pour pouvoir
communiqué, s'échanger d'informations, conserver
d'informations..., l'homme recourait à des écorces d'arbres pour
pouvoir écrire et y conserver des informations jusqu'à ce qu'aux
environs des années 100, il fabrique le papier. Cette prouesse
technologique a considérablement changée la manière de
traiter, d'échanger, de conserver et de stocker les informations.
Aujourd'hui les entreprises et organisations tirent pleinement
partie de l'utilisation du papier car ils ont besoins de conserver des archives
d'informations pour des raisons utilitaire ou encore légale, en vue
d'une éventuelle consultation ultérieur. Or à cela
s'ajoute le fait que, plus l'entreprise prend de l'âge, la masse des
documents croit sensiblement et cela empêche l'entreprise de faire une
gestion optimale de ces documents.
Cette manipulation d'informations à travers des papiers
n'est pas toujours de tout repos et a montré ses limites de plusieurs
manière, c'est ce qui a fait qu'avec l'avènement des nouvelles
technologies, l'archivage d'informations prenne de l'importance et est
maintenant perçue d'une toute autre façons dans les
entreprises.
2
A cette fin, c'est dans ce cadre que s'inscrit notre projet de
fin de cycle qui consiste à réaliser une application d'archivage
de données au seins d'une entreprise et nous avons pris le cas
particulier de BELL EQUIPMENT.
CHOIX ET INTERET
Nous avons choisis de fixer notre étude sur ce
thème parce que nous avons constaté qu'un grand nombre
d'entreprise éprouve des sérieuses difficultés dans la
gestion des archives. Ce travail dégage plusieurs intérêts
:
Premièrement l'intérêt que nous portons
à ce sujet de recherche est, d'évaluer tout d'abord les
connaissances acquises tout au long de ce premier cycle d'étude
universitaire en informatique en proposant un système de gestion
assister par ordinateur pour la gestion du processus d'archivage et
d'accès aux données aux seins d'une entreprises.
Puis son intérêt se justifié aussi dans la
mesure ou si BELL EQUIPMENT (entreprise ou est basé notre sujet de
recherche) adopte cette solution il disposera d'un système
informatisé de gestion d'archives.
D'une autre part ce travail constituera un socle dans la
conduite et la réalisation des projets autour de l'archivage
électronique, les chercheurs, étudiants et professionnels
pourront s'appuyer déçu afin d'y mener d'autres projets
d'études et y approfondir les recherches.
ETAT DE LA QUESTION
Nous ne sommes pas les premiers ou même le seul à
parler de l'archivage électronique, d'autres auteurs bien avant nous en
ont aussi parlé, parmi ces travaux nous avons mis la main sur le travail
de LUDIVINE MAGREZ1 (master 2 Gestion de l'information et de la
documentation en entreprise), dans son mémoire il parle de comment
choisir une solution de gestion d'archives. Il montre les similitudes et les
différences entre l'archivage papier et l'archivage électronique,
Pour lui, après études et analyses, la solution logicielle
restait de loin la meilleur, il a fait une étude du marché des
logiciels et en a même propose quelques un après analyse et prise
en compte des contraintes budgétaire et fonctionnelles que
présentaient chacun
1 Ludivine Magrez. Comment choisir une solution de
gestion d'archives : le cas de la Communauté d'Agglomération de
la Porte du Hainaut. Université Charles de Gaulle Lille
3
domain shs.info.coll. 2010. <mem 00526158>
http://memsic.ccsd.cnrs.fr/mem
00526158
3
des logiciels qu'il avait sélectionné, mais
aussi après la prise en compte des besoin de la CAPH2. Il
finit son travail en présentant les avantages de la solution
logicielle.
En ce qui nous concerne, nous ne parlerons pas des logiciels
que nous propose déjà le marché, nous nous limiterons
à l'étude des problèmes d'archivages rencontré dans
les entreprises (cas particulier de BELL EQUIPMENT), nous proposerons une
solution et irons jusqu'à son implémentation.
PROBLEMATIQUE ET HYPOTHESE
PROBLEMATIQUE
BELL EQUIPMENT est une entreprise de location et vente
d'engins lourds bien implantée à Lubumbashi, et comporte
plusieurs représentations à travers le pays qui communiquent
entre elles. Dans chaque représentation nous y retrouvons un certain
nombre de départements et services qui produisent et reçoivent un
certain nombre des documents liés au fonctionnement de l'entreprise.
Tous ces documents, quelque soient leurs formes, date ou
même leurs support matériel, sont destinés à
être conservés. On remarque là que c'est une
quantité énorme d'informations acquise et produite par
l'entreprise. S'il faut enregistrer les archives ou les classer, les rechercher
dans des armoires ou rayons... Il va de soi que c'est un travail fastidieux. Or
ce sont là les opérations quotidiennes de l'archiviste qui doit
bien garder la super mémoire de BELL EQUIPMENT constitué
justement des archives capable de renseigner sur l'exercice des
activités.
La masse des documents qui ne cesse de croitre fait que
l'entreprise éprouve une grande difficulté de disponnibiliser un
document quand il est désiré par un autre service de
l'entreprise. La lenteur au service d'archivage constitue un véritable
disfonctionnement de l'entreprise. Lors d'un contrôle de la direction
générale de l'entreprise à ce service, il peut arriver
qu'il demande toutes les factures des fournisseurs pour une certaines
année. Et dans ce cas l'entreprise procède souvent à un
recrutement des ouvriers journalier pour effectuer cette recherche car la masse
des documents est considérable. Sans oublier aussi l'élaboration
du rapport qui devient un casse-tête pour l'archiviste.
Le constat que nous avons fait est que ce travail d'archivage
se fait de façon rudimentaire, ce mode de gestion des archives
occasionne la lenteur et la lourdeur des taches,
2 CAPH (communauté d'agglomération de la
porte du Hainaut) : domaine d'étude de LUDVINE MAGREZ
? La méthode agile dite de 80/20 situé à
mi-chemin entre UP (Unified Processing) et XP (eXtreme Programing) d'UML.
4
la perte de temps dans la recherche des documents, les
redondances avec risque
d'incohérence... Or quand une entreprise ne sait plus
maitriser ses flux d'informations, notamment ses archives qui constitue sa
mémoire, elle tombe dans l'inactivité.
C'est ainsi que nous nous sommes posé les questions
suivantes :
? Quelle serait la solution à mettre en place pour la
gestion optimale des archives de BELL EQUIPMENT ?
? Quelles seront les avantages du à la mise en place de
cette solution ?
HYPOTHESE
Pour répondre à ce problème, plusieurs
solution sont envisageables, pour notre part nous estimons que la meilleur
solution pour améliorer la gestion des archives de BELL EQUIPMENT, il
serait mieux de faire recours aux prouesses technologique et avantages que nous
offres l'outil informatique. D'une façon concrète et
précise, nous pensons qu'il faudrait mettre au point une application
informatique interagissant avec une base de données afin de permettre
:
- un accès rapide aux données archivées
- Une sécurité des informations
- Un stockage organisé des données
- Un gain de place physique
- Une réduction du cout dans la gestion d'archive
BELL EQUIPMENT pourrait ainsi avoir une meilleure perception
de l'archivage en ce sens que cette application pourrait permettre aux agents
de le voir sous un nouveau jour.
METHODE ET TECHNIQUE
Dans le but de bien appréhender le problème
posé et comme notre préoccupation est grande et que les
investigations doivent se poursuivre, il a été alors important de
définir une marche à suivre pour atteindre l'objectif.
METHODES
Pour mener à bien notre étude nous avons
utilisés deux méthodes.
5
? La méthode BPMN (Busness Process Modeling Notation)
de l'OMG (Object Management Group).
La méthode agile adoptée dans ce travail est une
démarche d'analyse et de conception des systèmes informatiques
centrée sur la notation UML et développé par Pascal Roques
dans son ouvrage intitulé : «UML pour le web»3.
Elle est basée sur le principe astucieux : «Modéliser 80% du
problème en utilisant 20% d'UML»4.
TECHNIQUES
Pour mieux recueillir et récolter un maximum
d'informations nécessaire à la réalisation de notre
travaille, nous avons fait recours aux techniques suivantes :
? L'entretien : L'entretien est une technique de recherche
scientifique qui consiste en une communication verbale entre l'enquêteur
et l'enquêté, cette technique nous a permis d'interroger les
différents acteurs du système qui nous ont donnés un
certain nombre d'informations lié à notre sujet de recherche.
? L'analyse de la documentation (Technique documentaire) :
Elle consiste à analyser, à étudier les documents porteurs
d'informations étant en relation avec notre objet d'étude. Cette
technique a été un objet utile pour la réalisation du
corps de notre travail suite à une lecture approfondie de certains
documents et ouvrage.
? L'observation : c'est une technique qui fait intervenir tous
les sens du chercheur, ici le chercheur observe les données utiles
à sa recherche, il identifie le cadre de travail et en tant que
scientifique, il devra aussi déterminer les instruments dont il va se
servir au cours des investigations. A cette technique nous avons fait parler
les yeux et les doit, grâce à notre propre analyse, nous avons pu
observer nous-mêmes la gestion des archives (classement, enregistrement,
recherche, etc.).
DELIMITATION DU TRAVAIL
Pour apporter une couche de précision à notre
travail, nous le délimitons de manière suivante : Notre recherche
se base sur le résultat de l'enquête effectuée aux seins de
l'entreprise BELL EQUIPMENT, nous partirons de l'analyse en passant par la
conception et nous terminerons par une implémentation de
l'application.
3 Pascal ROQUES, UML pour le web 4 ème Ed.
Eyrolles, Paris, 2008
4 Idem, P.14
6
SOMMAIRE
Pour atteindre notre objectif on a partagé le travail
comme suite :
? Le premier chapitre intitulé
«considération théorique et
conceptuelle», nous parlerons ici d'un aperçu
général sur l'archivage, sa place dans l'entreprise et son
importance, nous y parlerons également de certaines notions liés
à la conception des systèmes informatiques.
? Dans le second il s'agit d'une prise de connaissance
de l'existant pour savoir de ce que doit être capable de faire
et de quoi va servir notre futur application en d'autres termes il s'agit d'une
analyse et spécification des besoins.
? Le troisième chapitre sera consacré à
la conception de l'application il s'agit d'une phase de
modélisation théorique de l'application.
? Le quatrième chapitre on va présenter les
résultats obtenus et
l'implémentation, tous ceux-ci sans compter
l'introduction et la conclusion.
7
Chapitre I. CONSIDERATION THEORIQUE ET CONCEPTUELLE
INTRODUCTION
Dans ce chapitre nous faisons une définition des certains
concepts liés à notre sujet et un aperçu
général sur les concepts et méthodes liées au
processus d'archivage et à l'archivage électronique qui fait
l'objet de notre étude.
I.1. THEORIE SUR L'ARCHIVAGE
I.1.1. DEFINITION DES CONCEPTS
Optimisation : En informatique le terme
optimisation désigne souvent une amélioration des performances
(d'un logiciel, d'un système de gestion des bases des données,
d'un moteur de recherche, etc.).
Processus : Dans le dictionnaire de
français Larousse, le processus est définit comme un
enchaînement, une suite continue d'opérations aboutissant à
un résultat. C'est dans ce contexte que s'inscrit le processus
parlé dans ce sujet.
Donnée : une donnée est en fait
toute information élémentaire manipulée dans une
organisation ou dans une entreprise. Le dictionnaire français la
définie comme une information représentée sous une forme
conventionnelle, afin de pouvoir être traitée automatiquement.
Droit d'accès aux données : c'est
l'autorisation donné à un utilisateur d'accéder aux
informations dont il a besoin selon son habilité, selon les principes de
gestion établit dans l'entreprise et selon son pouvoir d'action.
I.1.2. PRESENTATION GENERALE
I.1.2.1 Archive
Etymologie : Le terme « Archive »
vient du bas latin archivum, signifiant « armoire », qui
lui-même vient du grecque ancien acheion signifiant « bâtiment
administratif, magistrature »5.
Dans le langage courant, « archives » signifie soit des
vieux papiers ou la paperasse plus ou moins inutile, soit des trésors
oubliés.
5
www.wikipedia.org/archive
consulté le 06 Mars 2015
8
Définition et rôle
En Archivistique6 francophone actuelle, le terme
« archives » a trois acceptions :
1. Tous les documents produits (crées et reçus)
par un organisme ou entreprise dans le cadre d'une activité, quel que
soient leur âge, leur types ou leurs supports.
2. Les services et institutions qui se chargent de leurs
gestions (plus particulièrement les archives définitives).
3. Les espaces de stockage de ces documents (les locaux ou
ils sont conservés, armoires, etc.).
I.1.2.2 ARCHIVAGE
L'archivage est un terme à la fois récent dans
la langue française, puisqu'il n'est utilisé que depuis quelque
décennies seulement, et complexe par le fait qu'il n'existe pas de
définition légale du terme «archivage» comme pour le
mot «archive».
Plusieurs ont prêtés à ce terme des
définitions différentes. Dans le dictionnaire de l'information,
l'archivage est défini comme «l'ensemble des méthodes,
processus et outils mis en oeuvre pour gérer et conserver les documents
qui ont cessés d'être d'utilité courante7
». Aujourd'hui cette définition est presque obsolète car
l'archivage touche l'ensemble des documents, les trois âges.
Marie-Anne CHABIN, archiviste française,
présente l'archivage comme étant «la démarche
d'organisation qui a pour objectif d'identifier, de mettre en
sécurité et de maintenir disponible l'ensemble de documents qui
engagent une entreprise ou un organisme vis-à-vis des tiers ou de son
activité future et dont le défaut représenterait un
risque8 ».
L'unité de base de l'archivage tourne autour de ce
qu'on appelle un document, qui est considéré comme une
entité physique constituée par un support individualisé
sur lequel sont fixées des informations. Ces documents, originaux ou
copiés, constitués ou non en dossiers, sont fixés sur des
supports, qui peuvent être physique ou électroniques, c'est ceux
dont nous parlerons dans une prochaine partie.
6 Science qui régit les principes et les
techniques relatifs à la gestion des archives. C'est une des disciplines
participant aux sciences de l'information.
7 CALCALY Serge, le COADIC Yves F, POMART
Paul-Dominique et al. ; Dictionnaire de l'information, Paris : Arnaud coli
[2è édition]. 2004, P.7
8 CHABIN Marie-Anne. Nouveau glossaire de
l'archivage [en ligne]. Archive 17, 2010 [consulté le 05 Mais 2015].
Disponible sur: <
www.archive17.fr/component/option.com_performs/itemid,55/>
9
De l'archivage au Records Management
Présentement dans les entreprises comme dans les
organismes, l'archivage des documents est perçu différemment, il
est devenu la démarche du contrôle du cycle de vie des documents
à risque dans l'entreprise. Cette nouvelle perception de l'archivage a
entrainé la création d'un système s'appuyant sur la
gestion des documents utiles à la fin de leur vie administrative et qui
assure leur fiabilité, leur intégrités et
accessibilité. Il s'agit du «Records Management»,
expression anglo-saxonne ayant pour signification approximative en
français «gestion de l'archivage», D'après la
norme ISO 15489 : 2001, le Records management désigne « le champ de
l'organisation et de la gestion en charge d'un contrôle efficace et
systématique de la création, de la réception, de la
conservation, de l'utilisation et du sort final des documents, y compris des
méthodes de fixation et de préservation de la preuve et de
l'information liées à la forme des documents ». Autrement
dit, c'est un système qui accompagne et gère les documents de
leur création à l'extinction de leur utilité par le
producteur en passant par leur réception et leur conservation. Sauf
qu'il ne prend en compte que la gestion des archives courantes et
intermédiaires, les archives définitives n'étant pas
prises en charge dans ce système. Nous verrons que les archives
numériques prennent de plus en plus d'importances dans cette
procédure.
L'archivage électronique est devenu un réel
défi pour le Records Management, le support numérique
ayant autant de valeur que le support papier dans la société
moderne et même au niveau des lois de certains pays. Le Records
Management symbolise d'une certaine façon l'évolution de
l'archivage, thème qui sera abordé plus bas mais d'abord parlons
un peu du processus d'archivage.
I.1.2.3 PROCESSUS D'ARCHIVAGE
Le projet d'archivage s'appuie sur le processus d'archivage,
selon les principes du Records Management. Articulé avec les
processus métiers, il se décompose en trois sous-processus
chronologiques, qui suivent le cycle de vie du document engageant : versement,
conservation et destruction, et un sous-processus transverse : la mise à
disposition ou l'accès aux utilisateurs. Le tableau ci -dessous illustre
les huit étapes du processus de gestion des documents :
10
Figure 1:Processus d'archivage 9
Les principales étapes de ce processus sont :
? Analyse et classement du document produit ou
reçu
Cette étape d'analyse permet d'identifier les types de
documents produits ainsi que les activités des différents
services. Le document est alors classé dans une rubrique du plan
9 Groupe Métiers AAF-ADBS « Records
Management ». Comprendre et pratiquer le records management : Analyse de
la norme ISO 15489 au regard des pratiques archivistiques françaises [en
ligne].
Documentaliste - Sciences de l'information, 2005 [consulté
le 15 Mars 2015], volume 42, n°2. p.106-116.
11
de classement des activités. Cette opération
indique si ce dernier sera ou non enregistré dans le système
d'archivage et précise les règles de conservation dans le cas
où il est archivé.
? Capture et enregistrement du document
Cette étape montre le rattachement d'un document
à un plan de classement. A ce document, sera ajouté des ajouts de
description, afin que celui-ci puisse être facilement retrouvé.
? Analyse et ajout de
métadonnées
Cette étape a pour but la description complète
du document. Celle-ci se fait par l'intégration de
métadonnées, qui sont « des données
structurées ou semi-structurées qui permettent de qualifier et de
gérer les documents archivés tout au long de leur cycle de
vie10». Trois types de métadonnées peuvent
être distingués :
- les métadonnées descriptives : description du
contenu intellectuel (ex.: titre, auteur, date, mots clés...),
- les métadonnées de gestion (ou de structure) :
elles aident à organiser, à valider puis à archiver les
ressources organisationnelles,
- les métadonnées de préservation (ou
administratives): métadonnées destinées à assurer
la conservation à long terme de ressources électroniques. Elles
incluent les données techniques telles que le contrôle
d'accès, les conditions d'utilisation...).
Les métadonnées permettent ainsi de :
- gérer le cycle de vie (savoir combien de temps on doit
conserver l'information,
à quelles autres informations elle est rattachée,
quand on peut la détruire),
- gérer les droits d'accès,
- gérer la recherche,
- gérer l'authenticité du document (valeur de
preuve),
- exploiter le document dans son contexte.
? Stockage sécurisés
10 CHABIN Marie-Anne. Nouveau glossaire de l'archivage [en
ligne]. Archive17, 2010 [consulté le 17 Mars 2015]. p. 26. Disponible
sur : <
http://www.archive17.fr/index.php?option=com_performs&Itemid=55
>.
12
La sécurité des documents doit être garantie.
Elle est synonyme d'identification, d'intégrité et de
confidentialité. Cette sécurité doit permettre à
garantir :
o l'identification,
o l'authentification,
o la sauvegarde,
o la lisibilité,
o la traçabilité, qui est « le fait de
créer, d'enregistrer et de préserver les données relatives
aux mouvements et à l'utilisation des documents».
? Prise en compte des évolutions des
documents
Cela signifie que tous les changements liés au document
concernant son statut, sa durée de conservation sont
mémorisés.
? Communication, mise à disposition,
accès
Cette étape a pour objectif la traçabilité
des actions de communication, de localisation, des utilisateurs et des motifs
d'utilisation du document.
? Application du sort final
Arrivé à la fin de la durée
d'utilité administrative, le sort final est appliqué : il est
décidé si le document doit être conservé pour
être transféré aux archives définitives ou
détruit.
I.1.2.4 PRINCIPES DE GESTION DES ARCHIVES
Les principes et les techniques relatifs à la gestion
des archives font l'objet d'une des disciplines participante des sciences de
l'information: l'archivistique. Les deux concepts de base de cette
discipline sont :
? Le principe du respect des fonds : qui
impose de traiter les documents en fonction de leur provenance et non de leur
sujet, ce qui implique de les classer et de les inventorier sans perdre de vue
leur lien organique avec l'entité qui les a produit.
? La théorie des trois âges :
cette théorie a déjà était signalé un peu
plus au déçu. En archivistique, on considère que le cycle
de vie du document est divisé en trois périodes : courantes
(Active), intermédiaire et définitive (1èr, 2èm,
3èm).
Les archives naissent dans les bureaux en vue d'une action
plus précise, puis conservent un intérêt plus ou moins
à long terme. Des bureaux aux Archives, les documents connaissent trois
étapes d'utilisation :
- Archives privées : sont celle qui ne
possède pas un caractère légal. On peut y rattacher ainsi
les papiers de famille, les documents personnels, les archives
d'entreprises,
13
? Les archives courantes (Dossiers vivants):
regroupent les documents qui sont nécessaire à l'activité
des services qui les ont produits. Les services les conservent à
proximité des utilisateurs et de leur bureau pour le traitement des
affaires courantes.
? Les archives intermédiaires: celle
qui ne sont plus d'usage courante mais doivent être conservées
temporairement, pour des besoins administratives et juridique. Ils sont
conservés à proximité des bureaux, souvent dans un local
dédié dit de pré archivage.
? Les archives définitives : celle
dont l'utilité administrative ou de gestion est éteinte et qui
ont vocation à être conservé pour des raisons historiques
ou patrimoniales. Elles sont versées dans les services d'archives
compétentes pour être conservés indéfiniment.
Tableau de cycle de vie des archives
Figure 2:Tableau de cycle vie des archives
A l'issu de la durée légale ou
règlementaire de conservation, les archives intermédiaires font
l'objet d'un tri et sont soit conservées définitivement soit
éliminées.
I.2. TYPES D'ARCHIVES
Les archives sont classées principalement en deux
grandes familles à savoir les archives privées et les archives
publiques.
11 ABBASI Rafiki, ABOMO AKONDO, BOUZIZI Sif Douala, et
al. Stage technique international des archives : l'archive électronique
[En ligne]. [Consulté 17 Mars 2015]. P.2. Disponible sur :
www.archivesdefrance.gouv.fr
14
d'associations politiques ou religieuses. Elles peuvent
être données, léguées ou même confiées
en dépôt à des services d'archives publiques ou
privés et leur communication peut obéir alors à des
règles particulières fixées par leurs
propriétaires. Elles restent propriétés de leurs
détenteurs originels, mais l'administration publique des archives doit
être avisée de tout ce qui pourrait affecter leur
intégrité (aliénation, restauration, etc.).
- Archives publique : sont celle produite par
les pouvoirs publiques et par les organisations chargés d'une mission de
service publique (parquet, organisme consulaire, organisme de droit
privé, officier ministériels). Elles désignent aussi dans
la langue courante les fonds d'archives conservés par les services
d'archives publiques. Leur délai de consultation est fixé par la
loi.
La distinction entre archives privées et archives
publiques est parfois difficile à
établir.
Les papiers d'un homme politique par exemple, peuvent
comporter des documents en rapport avec ses fonctions officielles qui sont donc
des archives publiques et des documents découlant de ses
activités de parlementaire et de responsable d'un parti politique qui
sont des archives privées.
I.3. ARCHIVAGE PAPIER vs ARCHIVAGE ELECTRONIQUE
I.3.1. PRESENTATION DE L'ARCHIVAGE ELECTRONIQUE
Avec l'introduction des nouvelles technologies dans les
collectivités et dans les administrations, beaucoup des documents
autrefois tenus sous format papier sont aujourd'hui gérés sous
format électronique.
A l'instar de l'archive papier, l'archivage
électronique est l'ensemble des procédures définies par
une collectivité pour assurer la conservation de son patrimoine
documentaire conformément à un référentiel
défini par l'autorité chargée du stockage et de la mise
à disposition future des documents effectivement versés. Il
représente, au sens général, « l'ensemble des
actions, outils et méthodes visant à identifier, recueillir,
classer et conserver des informations électroniques, qui sont mis en
oeuvre pour conserver à moyen et long terme ces informations dans le but
de les exploiter11». En comparaison avec l'archivage papier,
l'archivage électronique gère les documents numériques,
qui sont des « ensembles composés d'un contenu, d'une structure
logique, d'attributs de présentation
15
permettant leur représentation, dotés d'une
signification intelligible par l'homme ou lisible par une machine». Il
peut être crée à l'état natif ou obtenu par un
processus de transformation d'un document physique, par exemple par
numérisation (scannage). Les documents bureautiques, les bases de
données, les messages électroniques, les dossiers
numérisés sont considérés comme des documents
numériques.
I.3.2. EXIGENCE DE L'ARCHIVAGE ELECTRONIQUE
L'archivage électronique est un processus
(système) sensible, pour sa réalisation il doit répondre
à certaines exigences.
? L'intégrité des documents : cela consiste en
la protection du document garantir qu'il ne subisse aucun ajout, ni aucune
modification qui pourrait altérer ou entrainer sa destruction.
? La pérennité des données : elle
consiste à maintenir dans le temps l'intégrité des
données. En effet, un document doit être lisible à
n'importe quel moment. Un stockage sur de formats standards normalisés
et pérennes facilite les choses (PDF, etc.).
? La sécurité des documents : il s'agit ici
d'assurer la sécurité physique des locaux et des données.
Ça se fait par le biais des règles de sécurité pour
les bâtiments (l'anti-intrusion, lutte contre l'incendie, etc.), la
sauvegarde ou duplication des documents.
? L'authenticité des documents : le manuel de
spécifications Moreq2 explique qu'il s'agit de prouver qu'un document
est bien original. Pour cela, il faut prouver que le document est bien celui
qu'il prétend être, qu'il a été créé
ou envoyé, et qu'il a été créé ou
envoyé à la date prétendue.
C'est là en quelque sorte les exigences qu'il faudrait
observer sur l'archivage électronique.
Ces exigences permettent ainsi de faciliter l'accès
à l'information, de répondre aux exigences légales de
conservation et de communication et de relever le défi de l'obsolescence
technologique.
Il reste à signale que l'archivage électronique
est une fonction à ne pas confondre ni avec la « sauvegarde
informatique » ni avec la « gestion électronique des documents
(GED)». Effectivement, la sauvegarde informatique se contente uniquement
à stocké les données pour les restauré en cas de
pannes elle est conçue pour une conservation à court terme et son
support est inexploitable en dehors de son environnement technique. De plus, la
sauvegarde ne respecte pas les règles de classement, de mise à
disposition, de sécurité, de pérennité et de
traçabilité.
12 CHABIN Marie-Anne. Archiver, et après ?
Paris : Djakarta, 2007. p.66-69 [en ligne] [consulté le 17 Mars 2015]
16
La gestion électronique des documents appelé
aussi `'GED», contrairement à l'archivage
électronique, permet la modification de documents et la coexistence de
plusieurs versions d'un même document par leur propriétaires. Elle
peut même permettre la destruction des documents ce qui viole
l'intégrité des documents et trahit les exigences de l'archivage
électronique.
I.3.3. SIMILITUDES ET DIFFERENCES
Le plus grand enjeu de l'archivage électronique est de
traiter les archives électroniques selon les mêmes règles
que les archives papier. Les principes restent identiques à ceux des
archives papiers. Mais les moyens sont plus lourds et les risques plus grands
pour assurer l'intégrité et la sécurité. La plus
grande différence entre les deux qui peut être ressortie est due
en partie aux technologies informatiques.
? Concordances
L'archivage électronique intègre donc, tout
comme le papier, les notions de plan de classement, délais de
conservation, sort final des documents, identification, recherche, et
restitution. Il reprend en quelque sorte les étapes du processus du
Records Management.
? Différences
Une grande différence existe entre papier et
numérique. Marie-Anne CHABIN12 a clairement identifié
quartes caractéristiques fondamentales qui identifient le papier et le
numérique :
- L'unité de mesure : le papier se
compte en page, en maitres de rayonnages, tandis que le document
numérique se compte en octets.
- La sensorialité: les documents
numériques sont immatériels et ne réunissent aucun de cinq
sens. Contrairement au papier qui peut être touché,
feuilleté, etc.
- L'espérance de vie: pour les
documents papiers, le support et le contenu sont indissociables, le document
peut être conservé à long terme (30 ans et plus) sans
altérer son intégrité. Avec les documents
électroniques le problème de pérennité se pose
à cause des contraintes technologiques fortes. La plupart des fichiers
informatiques de plus de 10 ans sont aujourd'hui illisibles, ce qui a pour
conséquence plusieurs risques et contraintes inéluctables.
- L'accessibilité: Un problème
subsiste avec le papier, l'éloignement des archives, qui se trouve
parfois dans un lieu reculé et difficilement accessible. Pour consulter
au plus
13 CHABIN Marie-Anne. Nouveau glossaire de
l'archivage [en ligne]. Archive17, 2010 [consulté le 17 Mars 2015]. p.
8. Disponible sur :
www.archive17.fr.
17
rapide les archives papiers, il fallait penser à mettre
en place un magasin archives se trouvant au plus près des services
producteurs. Avec les archives numériques, les distances sont rompues.
Les services peuvent ainsi accéder rapidement aux informations, par le
biais d'une simple base de données, ou par l'accès à un
logiciel de gestion électronique de documents.
I.4. PLACE DE L'ARCHIVAGE DANS L'ENTREPRISE
Au cours de ces derniers années l'archivage a
considérablement évolué et s'est modernisé; sa
place au sein de l'entreprise a changé. La fonction archivage est
dès lors perçue différemment et ces enjeux n'en sont plus
que nombreux.
Sur ceux, Marie-Anne CHABIN13 indique que «
l'archivage relève de la responsabilité de toute personne morale,
comme conséquence logique de l'environnement réglementaire, des
risques de non disponibilité de l'information ou de sur-conservation,
avec les exigences afférentes d'authenticité,
d'intégrité et de fiabilité des documents dans le temps
».
En effet les enjeux induit par l'archivage, qu'il soit papier
ou électronique, sont multiples et font face à des nombreuses
exigences. Tels que des exigences (juridiques, règlementaire,
patrimoniaux et historiques, logistiques, sécuritaires, technologiques
et même financièrement).
L'archivage des documents d'une entreprise est une action
vitale, il aide à la préservation de la mémoire de
l'entreprise. Les nouvelles technologies appellent à repenser
l'archivage, c'est ainsi que du support papier englobant les textes, les
dessins, etc., nous sommes passés aux supports numériques.
CONCLUSION
Pour finir, nous pouvons dire que l'archivage a un bel avenir
devant lui, car malgré les outils perfectionnés mis à la
disposition des entreprises, la masse des documents demeure difficile à
maitriser et nécessite une gestion des archives vigoureuse. Il faut donc
se dire que malgré les préjugés portés à ce
service, l'archivage occupe désormais un rôle
prépondérant au sein de l'entreprise. Ce service doit avoir une
place centrale car sans l'archivage, les informations risqueraient de
disparaitre, de se disperser et d'être inutilisables.
Du point de vue juridique, Bell est une société
privée à responsabilité limité avec un objectif
social. Sous la dénomination BELL EQUIPMENT(DRC) Sarl.
18
Chapitre II. PRESENTATION DU CADRE D'ETUDE
ET MODELISATION DU METIER
INTRODUCTION
Dans l'élaboration de notre projet, nous
commençons par faire un aperçu de l'étude
préalable. Celle-ci consiste à recenser toutes les données
et tous les traitements du système en place avant de préconiser
une solution du système futur.
Il s'agit d'une étape cruciale dans la
réalisation d'une application donnée. Le futur d'une application
dépend beaucoup de cette phase, Elle permet d'éviter le
développement d'une application ne répondant pas à sa
spécification. Pour cela le client et le développeur doivent
être en étroite relations.
Pour arriver à nos fins il nous faut prendre
connaissance de :
? L'analyse et la définition des besoins : étape
qui permet de trouver un commun accord entre les spécialistes
(développeurs) et les utilisateurs.
? L'étude de faisabilité : le domaine
d'application, l'état actuel de l'environnement du futur
système.
? L'élaboration du cahier de charge.
Dans ce chapitre, nous présentons le système
existant en vue d'en dégager les faiblesses et proposer des solutions
informatiques appropriées.
II.1. PRESENTATION DU CADRE D'ETUDE
II.1.1. PRESENTATION DE BELL EQUIPEMENT
Bell Equipement est une société commerciale qui
s'occupe principalement de la vente des engins (des camions bennes, des
tracteurs etc.) ; des pièces de rechange (des boulons, des batteries
etc.) et des services après ventes (les réparations, la
maintenance, et la formation technique a l'utilisation du matériel).
De manière peu pragmatique Bell vend en état ses
engins et pièces de rechange c'est ce qui fait d'elle une entreprise
commerciale.
19
II.1.2. LOCALISATION GEOGRAPHIQUE
Le siège social de Bell Equipment est situé au
numéro 17 de l'avenue Munguzi au Quartier industriel dans la commune de
KAPEMBA. En République démocratique du Congo dans la province du
Katanga ville de Lubumbashi.
II.1.3. HISTORIQUE
La société Bell Equipment(DRC) Sarl a
été créée à Lubumbashi le 06 AOUT 2007
conformément aux lois congolaises par la société Bell
Equipment SA (9 .999parts sociales) et par la société Bell
Equipment Limited (1parts) avec un capital social d'USS 10.000. Elle avait
commencé avec un effectif de 11 personnes, A la fin du mois d'octobre
2011 le personnel atteignait environ 119 travailleurs dont 42
expatriés.
Au mois de février 2012, la société
comptait 204 travailleurs dont 60 expatriés. Le programme 2012
prévoyait la formation à l'étranger d'une quarantaine des
mécaniciens locaux.
A la fin de l'année 2012 la société
comptait près de 222 travailleurs dont 60 expatriés. Le programme
2013 prévoyait quant à lui la formation à
l'étranger d'une soixantaine des mécaniciens locaux.
A ce jour, la société compte 216 travailleurs
dont 58 expatriés. Le programme 2014 prévoyait la formation
à l'étranger d'une centaine de mécaniciens locaux.
II.1.4. BRANCHE OUVERTE DE BELL EQUIPMENT SUR LE
TERRITOIRE
NATIONAL
La société Bell Equipment a des branches ouvertes
:
? Au sud Kivu ou elle travaille avec la société
Twangiza Mining, qui exploite de
l'or.
? Dans la province orientale avec les sociétés
GPS et M&T à Doko (à watsa), qui travaille chez kibali gold
mining, qui exploite de l'or.
? Une branche a été ouverte à Kolwezi en
2013.
? Un autre est en voie d'ouverture à Kinshasa depuis
2013.
II.2. STRUCTURE FONCTIONNELLE
Pour son bon fonctionnement Bell Equipement possède une
structure fonctionnelle hiérarchique dont les postes sont agencés
de la manière suivante :
20
Figure 3: Organigramme
Source: service d'archivages
II.3. ANALYSE DE L'EXISTANT
Dans les lignes qui suivent, nous présentons le
processus d'archivage des documents chez Bell Equipment en vue de bien
circoncire notre domaine d'études.
II.3.1 DESCRIPTION TEXTUELLE DE L'EXISTANT
Le processus commence au niveau de l'administration et du
département des comptabilités. L'administration expédie et
reçoit toutes les correspondances et tous les documents de Bell
Equipement. Il peut s'agir des notes, des rapports, des procès-verbaux,
des lettres de décompte final, des lettres de licenciements, des lettres
de mutations et autres documents qui y sont produits.
Le département des comptabilités aussi
expédie et reçoit les factures fournisseurs et client, les
bordereaux et même bien d'autres documents traiter dans ses bureaux.
Après leurs traitements, la comptabilité comme
l'administration transfère auprès du bureau d'archivage tous ces
documents pour qu'ils y soient enregistrer et classer. L'archiviste les
reçoit et les vérifies d'abord avant leur classement. S'il
remarque quelque chose de bizarre ou toute autre anomalie, il retourne le
document à sa source pour analyse et correction avant de le recevoir
à nouveau. Le classement des documents se fait selon leurs natures (les
inputs et les outputs), selon leurs dates d'archivage ou un autre
critère afin de faciliter le rangement et la recherche. Après un
temps dont la périodicité est variable, l'archiviste se charge de
récupérer tous les documents classés. Il commence par
vérifier leurs états et leur nature pour qu'ils soient bien tenus
afin d'identifier la traçabilité du dossier, puis il les codifie
avant de les
21
consigner à son tour dans son registre. Il peut alors
les classer dans les armoires et rayons prévus à cette fin.
II.3.2. ANALYSE DES LOTS D'INFORMATIONS
Dans le but d'assurer un suivi de toutes ces opérations
liées à la gestion des archives, le bureau d'archives utilise les
documents ci-après :
? Registrer d'entrée : dans ce registre, on saisit sous
forme d'un tableau les informations relatives aux archives. Il s'agit de :
· Le Nom
· L'année
· Le type
· La provenance ou la Destination
? Les Classeurs : dans les classeurs on y range les documents
et on loge ensuite les classeurs dans les armoires et rayon. Sur les classeurs,
des étiquettes reprennent les informations suivantes pour faciliter le
classement et la recherche:
· L'intitulé
· L'année
· Le Type
II.3.3. DIAGRAMME DE CONTEXTE
Le Diagramme de contexte n'est pas un diagramme UML ou
même un diagramme BPMN, mais il nous permet d'avoir une vue global du
système étudié, des interactions entre ses
activités et le rapport avec l'environnement
extérieur14.
Le diagramme de contexte statique délimite le domaine
d'étude en précisant :
· ce qui est à la charge du système et
· en identifiant l'environnement extérieur au
système étudié avec lequel ce dernier communique.
Dans cette perspective, notre diagramme de contexte se
présente de la manière
suivante :
14UML, C. Johnen : IUT de Bordeaux,
V2consulté le 26 Mai 2015
22
Figure 4: Diagramme de contexte
II.3.4. MODELISATION DU METIER
II.3.4.1. PRESENTATION DU BPMN
BPMN (Business Process Modeling Notation) 2.0 de l'OMG (Object
Management Group) est une notation graphique standardisée portant sur la
modélisation des processus métiers. Elle vise à fournir
une notation facilement compréhensible par les utilisateurs
métiers (y compris les analystes métiers, les développeurs
et ceux qui devront gérer et surveiller les processus après leur
mise en oeuvre) mais aussi à créer une passerelle
standardisée pour combler le vide entre la modélisation de
processus métiers et les langages d'exécution métiers.
L'objectif du BPMN est de fournir un cadre permettant de
décrire un processus d'une manière commune à tous les
utilisateurs et ce, indépendamment de l'outil utilisé.
On retrouve, au sein de la notation BPMN2.0, quatre
catégories de diagrammes afin de représenter les
différentes perspectives d'un processus (Voir Annexe acce).
1. Les diagrammes d'orchestration (processus privé et
processus public)
2. Les diagrammes de collaboration
3. Le diagramme de chorégraphie
4. Le diagramme de conversation
Pour notre travail nous présenterons juste le diagramme
d'orchestration, et de collaboration, ils suffiront pour présenter le
processus métier.
23
II.3.4.2 DIAGRAMME D'ORCHESTRATION
Figure 5: Diagramme d'orchestration
II.3.4.3 DIAGRAMME DE COLLABORATION
Figure 6: Diagramme de collaboration
24
II.4. CRITIQUE DE L'EXISTANT
Le système actuellement utiliser chez Bell Equipment
permet une bonne organisation du travail, une bonne circulation de
l'information, un bon enregistrement des informations nécessaires sur
les archives et une bonne tenue des documents.
Mais hors mis les avantages du système actuelle, nous
avons constaté qu'il présente certaines lacunes tel que :
· la perte de temps dans la recherche des archives
· Possibilité d'avoir des redondances
d'information
· établissement laborieux des rapports
· Risque de mélanger les documents ce qui peut
être fatal
· Le suivie des clients et des fournisseurs peut rencontrer
beaucoup de problèmes.
· L'abondance des documents papier dans l'entreprise peut
ralentir les services.
· On peut avoir besoin de plus d'employés pour se
partager les taches en cas d'une recherche d'archive spécifique.
II.5. APPROCHE DE SOLUTION
En tenant compte des critiques et des besoins d'informatiser
les services cités ci-dessus, plusieurs solutions sont envisageables
mais nous pensons pour notre part que la solution est de concevoir et
développer une application permettant de satisfaire au maximum possible
le bureau d'archivage et Bell Equipment en particulier.
Pour cela l'application doit répondre aux besoins
suivants :
· Avoir un logiciel qui respecte les principes des
Interfaces Homme/Machine (IHM) tels que l'ergonomie et la fiabilité.
· Réduire les tâches manuelles qui nous
permettraient de gagner en spatiotemporel
· Archiver les informations en toute
confidentialité
· Restituer rapidement les données
recherchées
· Partager simultanément les informations
· Avoir un logiciel évolutif.
CONCLUSION
L'étude préalable appelée techniquement
ingénierie des exigences ou analyse et spécification des besoins,
constitue une phase capitale dans le cas où toute la suite du projet
25
dépend d'elle, elle doit être faite avec beaucoup
de rigueur et plus d'attention pour que le projet réussisse avec un
grand succès.
Dans ce chapitre, on a exposé les problèmes de
la société et de l'existant, puis nous avons fait les critiques
sur la façon actuelle d'archiver les données et enfin on a fait
une approche de solution qui consiste à concevoir et à
développer une application qui facilitera les services
énumérés précédemment.
Après avoir fixé nos objectifs, pour atteindre
notre but on doit suivre plusieurs étapes ces dernières
constituent une partie du cycle de vie de tout projet informatique. Ainsi dans
l'étape suivante on va se consacrer sur le choix des méthodes et
outils de la réalisation.
26
Chapitre III. CONCEPTION
INTRODUCTION
La plupart des nouveaux langages sont orientés objet.
Le passage de la programmation fonctionnelle à l'orienté objet
n'était pas facile. L'un des soucis était d'avoir une idée
globale en avance de ce qu'on doit programmer.
L'algorithmique qui était utilisé dans la
programmation fonctionnelle ne pourrait pas suffire à lui seul. Le
besoin d'avoir des méthodes ou langages pour la modélisation des
langages orientés objet se faisait sentir. Ainsi plusieurs
méthodes ou langages ont vu le jour. En occurrence UML qui nous a permis
de faire la conception de notre application.
UML (Unified Modeling language) se définit comme un
langage de modélisation graphique et textuel destiné à
comprendre et décrire des besoins, spécifier et documenter des
systèmes, esquisser des architectures logicielles, concevoir des
solutions et communiquer des points de vue15.
De nos jours UML2 possède treize diagrammes qui sont
classés en deux catégories: les diagrammes structurels
(dynamique) et les diagrammes comportementaux (statique). L'utilisation de ces
treize diagrammes est laissée à l'appréciation de tout un
chacun selon la méthode choisie, cela, même si le diagramme de
classe est souvent considéré comme le point central dans un
développement orienté objet16.
Nous avons appliqué les principes de la méthode
agile choisie en essayant de modéliser 80% du problème avec
seulement 20% d'UML.
III.1. PRESENTATION DE LA METHODE UTILISEE
Pour l'analyse et la conception du nouveau système,
nous avons fait recours à la démarche ou processus agile dite de
80/20, qui utilise la notation UML, c'est-à-dire modéliser 80% du
problème en utilisant 20% d'UML.
La notion de méthode agile est née à
travers un manifeste signé en 2001 par 17 personnalités du
développement logiciel17. Ce manifeste prône quatre
valeurs fondamentales :
? « Personnes et interactions plutôt que processus
et outils » : dans l'optique agile, l'équipe est bien plus
importante que les moyens matériels ou les procédures.
15 Pascal ROQUES, UML pour le web. P.4
16 Idem, P.5
17 Pascal Roque, op.cit., P.12
27
? « Logiciel fonctionnel plutôt que documentation
complète » : il est vital que l'application fonctionne. Le reste,
et notamment la documentation technique, est secondaire, même si une
documentation succincte et précise est utile comme moyen de
communication.
? « Collaboration avec le client plutôt que la
négociation du contrat » : le client doit être
impliqué dans le développement. On ne peut se contenter de
négocier un contrat au début du projet, puis de négliger
les demandes du client.
? « Réagir au changement plutôt que suivre
un plan » : la planification initiale et la structure du logiciel doivent
être flexibles afin de permettre l'évolution de la demande du
client tout au long du projet.
Cette méthode se situe à mi-chemin entre UP
(Unified Processus «processus unifié»), un cadre
générale très complet des processus de
développement, et XP (eXtreme Programming), une approche minimaliste
centrée sur le code.
Avec cette méthode, nous n'utilisons pas les treize
types de diagrammes proposés par UML 2, mais seulement un tiers, en
insistant particulièrement sur les diagrammes de classes et le diagramme
de séquence. Cette limitation volontaire ne diminue en rien la puissance
de la démarche, mais, elle nous permet une réduction
significative du temps d'apprentissage de la modélisation avec UML, tout
en restant largement suffisante pour une bonne modélisation de notre
système.
Pour ce faire, on va commencer par les diagrammes de cas
d'utilisation (Use Case) qui permet de donner une vue globale de l'application.
Pas seulement pour un client non avisé qui aura l'idée de sa
future application mais aussi le développeur s'en sert pour le
développement des interfaces.
En deuxième lieu on va présenter la chronologie
des opérations par les diagrammes de séquences.
Et finir par les diagrammes statiques, qui sont celles de
classe de conception, de classe participantes et le modèle physique.
III.2. CAPTURE DES BESOINS
Avant la modélisation de notre système, il est
important de capturer les besoins de l'utilisateur qui sont émis en
termes des fonctionnalités du futur système. Le futur
système devra permettre aux utilisateurs d'effectuer les actions
suivantes :
- enregistrer les archives
28
- rechercher des archives
- centraliser les archives
- consulter les archives
- générer des rapports périodiques
III.3. DIAGRAMME DE CAS D'UTILISATION
Le diagramme de cas d'utilisation fait partie des diagrammes
comportementaux d'UML. Les cas d'utilisations constituent un moyen de
recueillir et de décrire les spécifications et les exigences des
acteurs ou les besoins des acteurs du système.
La représentation d'un cas d'utilisation met en jeu
trois concepts : l'acteur, le cas d'utilisation et l'interaction entre l'acteur
et le cas d'utilisation.
Il convient pour nous d'expliquer d'abord ces concepts avant de
poursuivre :
? Acteur : Un acteur représente un rôle
joué par une entité externe (utilisateur humain, dispositif
matériel ou autre système) qui interagit directement avec le
système étudié18.
Un acteur peut consulter et/ou modifier directement
l'état du système, en émettant et/ou en recevant des
messages susceptibles d'être porteurs de données.
? Cas d'utilisation : Un cas d'utilisation (use case)
représente un ensemble de séquences d'actions qui sont
réalisées par le système et qui produisent un
résultat observable intéressant pour un acteur
particulier19.
Un cas d'utilisation modélise un service rendu par le
système. Il exprime les interactions acteurs/système.
? Interaction : une interaction permet de décrire les
échanges entre un acteur et un cas d'utilisation.
Elle signifie simplement «participe
à».
Dans cette partie nous verrons comment structurer, relier et
classer ces cas d'utilisation ainsi que les représentations graphiques
UML associées. Nous aborderons enfin l'impact de cette étude sur
la planification du système à mettre en place.
Suivant les besoins de notre système on peut
présenter deux acteurs. Il s'agit de l'archiviste, du département
de finance. La manière d'accéder aux services de l'application
pour
18 Pascal Roque, op.cit., P.41
19 19 Pascal Roque, op.cit., P.42
archivé.
29
les uns et les autres est la même. La différence
réside sur les droits d'accès et les limites de chacun.
Figure 7 : Diagramme de cas d'utilisation
Description textuelle
Archiver document
Acteur principale : Archiviste
? Objectifs : L'archiviste veut archiver un
document qu'il reçoit.
? Précondition
? L'archiviste doit recevoir un document venant de
l'administration
? L'archiviste doit s'authentifier avec succès
? Post conditions
? Nouveau document archivé
? Document classé
? Scénario nominal
1. L'archiviste vérifie le document reçu
2. L'archiviste codifie le document puis lance une requête
d'archivage au système.
3. Le système valide l'archivage du document et affiche
le message document
30
Alternative
1. a. L'archiviste constate le manque de certaines informations
sur le document :
1. L'archiviste fait un rapport sur l'erreur et le cas
d'utilisation se termine en échec.
2. a. le système détecte un disfonctionnement dans
le processus d'archivage :
1. le système signale le disfonctionnement à
l'archiviste
2. l'archiviste il prévient le service informatique pour
engager des a actions de maintenances. Le cas d'utilisation se termine en
échec.
3. a. L'archiviste détecte des erreurs ou des
incohérences sur les informations du nouveau document archiver :
1. l'archiviste modifie toutes les informations
erronées
2. l'archiviste valide la modification, le cas d'utilisation
reprend à l'étape trois du scénario nominal.
Gérer archive
Acteur principal : Archiviste
? Objectif : L'archiviste peut vouloir
générer des rapports, modifier certains droits
d'accès sur les archives, voir l'évolution du
trafic, modifier ou supprimer une archive.
? Précondition
? Au moins une archive doit être disponible
? L'archiviste doit s'authentifié avec succès
? Post condition
Le rapport a été généré/
l'archive a été modifié/ l'archive a été
supprimé/ les droits d'accès ont été
modifiés/ l'archiviste a vu l'évolution du trafic.
? Scénarios nominal
1. L'archiviste lance l'espace de gestion d'archives.
2. L'archiviste sélectionne l'option : a.
`'générer le rapport»
a.1. Le système affiche un formulaire
a.2. L'archiviste rempli le formulaire en fournissant la
période et lance la requête
a.3. Le système génère le rapport
télécharger.
31
b. «modifier archive»
b.1. Le système affiche un formulaire
b.2. l'archiviste sélectionne les informations qu'il
souhaite et les modifie
b.3. le système renvoi un message que la modification a
été effectuée avec succès.
c. «voir l'évolution ou modifier les droit
d'accès »
c.1. Le système affiche un formulaire
c.2. L'archiviste modifie les droits d'accès, supprime ou
regarde l'évolution
c.3. Le système renvoi un message de confirmation pout la
modification des droit d'accès ou de la suppression de l'archive.
Alternative
1. b. l'archiviste saisie des données erronées, le
système renvoi un message
d'échec.
2. c. l'archiviste modifie les droits d'accès d'un
archive utilisé, le système lui signifie que l'archive est ouvert
et qu'il est impossible de le modifie.
Consulter Archive
Acteur principal : Administration Acteur
secondaire : Archiviste
? Objectif : l'administration veulent
disposer d'un document qui a été archive.
? Précondition
? Au moins une archive disponible
? L'administration doit s'authentifier avec succès
? Post conditions
? Archive consulté
? Aucun Résultat
? Scénarios nominal
1. Le système affiche un formulaire de recherche
2. Le service de finance rempli la zone de recherche en
fournissant un mot clé et lance la requête
3. Le système affiche les archives trouvées
4. Il sélectionne l'archive qu'il veut consulter et
lance une requête pour le
32
5. Le service de finance ouvre l'archive
téléchargé
Alternative
3 .a. Le système n'a pas trouvé l'archive
correspondant à la recherche :
1. le affiche le message aucun archive trouver et lui propose
d'effectuer une
nouvelle recherche.
III.4. DIAGRAMMES DE SEQUENCE SYSTEME
Il s'agit d'une explication détaillée d'un cas
d'utilisation. Les principales informations contenues dans un diagramme de
séquence sont les messages échangés entre les lignes de
vie, présentés dans un ordre chronologique.
33
Authentification :
Figure 8: diagramme de séquence «
Authentification »
Archiver document :
Figure 9:diagramme de séquence « Archiver
document »
34
Consulter archive :
Figure 10: diagramme de séquence « consulter
archive »
35
Gérer archive :
Figure 11: diagramme de séquence « gérer
archive »
III.5. DIAGRAMMES DE CLASSES
Précédemment nous avons parlé de deux
grandes catégories de diagrammes UML (statique et dynamique), l'un des
diagrammes statique nous intéresse beaucoup pour pouvoir
implémenter le code, il s'agit du diagramme des classes.
Ce modèle nous permet d'avoir une vue statique de
l'application. Il nous montre les relations entre les différentes
entités (classes), composant de notre application. Il nous mène
vers la solution finale. À partir de ce diagramme on retrouve les corps
de différentes classes de notre application. Mieux encore en utilisant
la technique de la retro-ingénierie (voir Annexe 3) on obtient
une grande partie du code finale.
Le diagramme de classes est considéré comme le
plus important de la modélisation orientée objet, il est le seul
obligatoire lors d'une telle modélisation20.
20 Laurent AUDIBERT, op.cit., P.35
36
Alors que le diagramme de cas d'utilisation montre un
système du point de vue des acteurs, le diagramme de classes en montre
la structure interne. Il permet de fournir une représentation abstraite
des objets du système qui vont interagir ensemble pour réaliser
les cas d'utilisation.
Il s'agit d'une vue statique car on ne tient pas compte du
facteur temporel dans le comportement du système. Le diagramme de
classes modélise les concepts du domaine d'application ainsi que les
concepts internes créés de toutes pièces dans le cadre de
l'implémentation d'une application. Chaque langage de Programmation
Orienté Objets donne un moyen spécifique d'implémenter le
paradigme objet (pointeurs ou pas, héritage multiple ou pas, etc.), mais
le diagramme de classes permet de modéliser les classes du
système et leurs relations indépendamment d'un langage de
programmation particulier.
III.5.1. MODELE DU DOMAINE
C'est un diagramme de classes dépourvu de ses
méthodes. Il correspond à la sémantique des données
sur lesquelles reposent tous les traitements du domaine.
Il s'agit simplement de créer une représentation
visuelle des objets du monde réel dans un domaine donné.
Si l'on emploie la notation UML, il s'agit d'un ensemble de
diagrammes de classes dans lesquels on fait figurer les éléments
suivants :
· les classes conceptuelles ou les objets du domaine ;
· les associations entre classes conceptuelles ;
· les attributs des classes conceptuelles.
A partir des éléments décrits dans le
chapitre précédent, nous pouvons établir notre
modèle du domaine comme suite:
37
Figure 12 : Modèle du domaine
III.5.2. DIAGRAMME DE CLASSES PARTICIPANTES
Le diagramme de classes participantes est important puisqu'il
effectue la jonction entre, d'une part, les cas d'utilisation, le modèle
du domaine et la maquette IHM, et d'autre part, la jonction entre, les
diagrammes de conception logiciel que sont : les diagrammes d'interaction et
les diagrammes de classes de conception.
Il s'agit ici de diagrammes de classes UML qui
décrivent, cas d'utilisation par cas d'utilisation, les trois
principales classes d'analyse et leurs relations.
Le diagramme de classe participante modélise trois
types de classes d'analyse : les dialogues, les contrôles et les
entités.
? Les classes de dialogues : ces sont des classes qui
possèdent les attributs et les méthodes ; ou les attributs
représentent les champs de saisi ou les résultats et les
opérations représentent les actions de l'utilisateur sur
l'IHM.
? Les classes d'entités : elles ne
posséderont que les attributs, les attributs qui sont des informations
persistantes de l'application c'est-à-dire qu'elles survivent à
l'exécution d'un cas d'utilisation particulier et qu'elles permettent
à des données et des relations d'être stockées dans
des sources de données.
? Les classes de contrôles : celles qui vont
posséder des opérations, Ces opérations montrent la
logique de l'application, ou les comportements du système informatique.
Elles jouent le pont entre les classes de dialogues et les classe de
contrôles.
38
a. Cas d'utilisation Consulter Archive
Figure 13: Diagramme de classe participante Consulter
Archive
b. Cas d'utilisation Archiver document
Figure 14 : Diagramme de classe participante Archiver
document
39
c. Cas d'utilisation Gérer Archives
Figure 15: Diagramme de classe participante Gérer
Archive
III.6. CONCEPTION OBJET PRELIMINAIRE
Nous allons attribuer des responsabilités précises
de comportement aux classes d'analyse en construisant une vue statique
complétée sous forme de diagrammes de classes de conception
préliminaire, indépendamment des choix technologiques que nous
avons choisis.
La conception préliminaire nous a permis d'affiner et
compléter les diagrammes de classes participantes obtenus
précédemment pour :
· Ajouter ou préciser les opérations dans les
classes.
· Ajouter des types aux attributs et aux paramètres
et retours des opérations.
· Affiner les relations entre classes: associations
(avec indication de navigabilité), généralisations ou
dépendances.
III.6.1. DIAGRAMME D'INTERACTION
L'expression diagramme d'interactions englobe principalement deux
types de diagrammes UML spécialisés, qui peuvent servir tous les
deux à exprimer des interactions de messages similaires :
? les diagrammes de communication ? les diagrammes de
séquence.
40
Pour le cas de notre travail nous ne représenterons
qu'un certains nombres de diagramme d'interaction par acteur ou par scenario
nominale.
? Diagramme d'interaction des cas d'utilisations du
service de finance
Consulter archive
Figure 16 : Diagramme de séquence du scénario
nominale recherche rapide
Figure 17: Diagramme de séquence scénario
Erreur de recherche
41
Figure 18:Diagramme de séquence de la suite du
scenario nominale de recherche rapide
? Diagramme d'interaction des cas d'utilisations de
l'archiviste Archiver Document
Figure 19: Diagramme de séquence du scenario nominale
Archivage avec succès
42
III.6.2. DIAGRAMME DE CLASSE DE CONCEPTION PRELIMINAIRE
a. Cas d'utilisation consulter archive
Figure 20 : Diagramme de classe de conception consulter
archive
b. Cas d'utilisation Archiver document
Figure 21: Diagramme de classe de conception Archiver
nouveau document
43
c. Cas d'utilisation Gérer Archive
Figure 22: Diagramme de classe de conception Gérer
Archive
III.7. MODELE PHYSIQUE DES DONNEES
Ce modèle nous permet d'avoir une idée sur les
tables qui composent notre base. Evidemment il y'a des règles qui
permettent de passer d'un modèle à un autre (voir Annexe
2).
Le MPD (Modèle physique de données) est un autre
raffinement qui vise à produire un MLD pour un SGBD spécifique.
Nous avons utilisé l'outil MySQL Workbench pour produire ce
modèle.
44
Figure 23: Modèle physique des données
III.8. METHODES ET OUTILS POUR L'APPLICATION
Il est évident que les méthodes et les outils
choisis pour concevoir et développer une application doivent être
en fonction de l'environnement et du domaine d'application de celle-ci. Cela
est bien explique par le génie logiciel.
Comme nous l'avons dit tout au-dessus, nous allons mettre
l'accent sur les avantages de l'approche orienté objet, les
architectures n-tiers. Tous ces concepts nous ont guidés dans la
réalisation de notre travail et sur les méthodes et outils
appliqués.
III.8.1. DEFINITION ET AVANTAGE DE L'APPROCHE ORIENTEE
OBJET
Ce concept de programmation orienté objet (POO), est un
paradigme de la programmation élaborer par les Norvégiens
Ole-Johan et Kristen Nygaard au début des années 1960. Il
consiste en la définition et l'interaction de brique logicielles
appelées objets ; un objet représente un concept, une idée
ou toute entité du monde physique, comme une voiture, une
45
personne ou encore une page d'un livre. Il possède une
structure interne, et un comportement, et il sait interagir avec ses
pairs21.
Parmi les avantages de cette approche, on peut citer : la
possibilité de concevoir par objet une application informatique sans
pour autant utiliser des outils dédiés, il facilite beaucoup dans
la conception, la maintenance, la réutilisabilité des
éléments (objets), l'avantage d'utiliser un objet de base afin de
produire un autre qui peut être une amélioration de cet objet
(phénomène d'héritage), etc.
L'objet est le coeur de cette approche. Tout objet
donné possède deux caractéristiques :
- Son état courant (attributs)
- Son comportement (méthodes)
En approche orienté objet on utilise le concept de
classe, celle-ci permet de regrouper des objets de même nature.
Une classe est un module (prototype) qui permet de
définir les attributs (champs) et les méthodes (comportement)
à tous les objets de cette classe.
III.8.2. CHOIX DU PRINCIPE ET DU LOGICIEL DE
MODELISATION
Merise et UML sont deux grands principes de « traduction
» ou modélisation d'un système d'information.
Néanmoins, ils ne sont pas aussi proches qu'on pourrait le penser.
Le choix de l'un ou de l'autre se fait selon trois axes
à savoir l'accessibilité, la précision et
l'exploitabilité.
Pour le premier axe (accessibilité) MERISE
présente l'intérêt d'avoir des modèles logiques
moins détaillés facilement compréhensibles par un
utilisateur moins avisé.
Tandis qu'UML conçu pour s'adapter à n'importe
quel langage de programmation orientée objet (POO), présente
plusieurs modèles (diagrammes) dont leurs compréhensions
nécessitent une grande attention.
En ce qui concerne le deuxième critère
(précision), MERISE est décevant. Malgré sa clarté,
il manque une précision du fait qu'elle est éloignée du
langage, donc difficile à implémenter alors qu'UML intègre
les éléments communs des différents langages, sa
volonté
21 http//:ww.wikipedia.org/approche oriente
objet
46
est d'être fidèle à la réalisation
finale. Elle est beaucoup plus complète avec ses différents
diagrammes.
Pour en finir avec l'exploitabilité, MERISE est une
méthode plus généraliste. Elle donne une vue globale de la
solution sans autant rentrer dans les petits détails. Contrairement
à UML qui est conçu pour l'implémentation objet avec ses
différents détails et sa portabilité (s'adapte à
n'importe quelle plateforme) elle est donc plus exploitable.
L'une ou l'autre présente des avantages et des
inconvénients. Il est réservé au concepteur de choisir la
méthode la mieux adaptée pour son cas. Si on cherche la
précision et l'exploitabilité comme dans notre cas UML devance de
loin MERISE. Tandis que, si c'est la clarté et l'accessibilité
qui sont en question MERISE est préférable.
La conception de notre application mérite bien une
grande précision et une exploitabilité maximale. C'est la raison
pour laquelle on va retenir UML. Les différences entres les logiciels de
modélisation UML sont infimes. N'empêche de mentionner quelques
logiciels qui sont à notre connaissance : Modelio (open source), Visual
Paradigme, PACESTAR Software.
La facilité dotée au dernier (PACESTAR) de
pouvoir faire des diagrammes en UML 2.0, sa rapidité et sa
flexibilité sont des facteurs qui nous ont permis de l'utilisé
comme logiciel de modélisation.
III.8.3. CHOIX DES OUTILS DE DEVELOPPEMENT
Un parmi les avantages qui nous ont permis de choisir UML
comme méthode de modélisation est l'orienté objet. Cette
approche influe aussi sur le choix du langage à adopter on peut rajouter
quelques-uns à savoir la portabilité, la facilité, la
multidisciplinarité et pas mal d'autres comme la
sécurité.
III.8.3.1 CHOIX DU LANGAGE DE PROGRAMMATION
Dans le souci de concevoir une application web, nous avons choisi
PHP comme langage d'implémentation de notre application. Apparu en 1994,
PHP est un langage de programmation libre principalement utilisé pour
produire des pages Web dynamiques via un serveur http, mais pouvant fonctionner
comme n'importe quel langage interprété de façon
47
locale22. Le PHP propose plusieurs avantages, dont
nous pouvons en citer quelques qui nous ont poussés de porter le choix
sur lui:
? Le faite que c'est un langage orienté objet comme le
C++, le C# ou le Java
? C'est un langage peut typer et souple avec une grande
facilité d'apprentissage ? Il est multi plate-forme
? PHP est un langage Serveur
Pour concevoir notre application web, nous avons utilisé
le langage HTML pour la présentation des pages web, la CSS pour la mise
en forme des pages web et JavaScript qui est lui un langage de programmation de
scripts principalement employé dans les pages web interactives mais
aussi pour les serveurs.
III.8.3.2. CHOIX DE L'OUTIL DE DEVELOPPEMENT
Pour réaliser une application web, plusieurs outils sont
disponibles et la plus part d'entre elles sont gratuites. Nous avons choisis le
duo PHP MySQL, ce sont deux outils qui ont fait leurs preuves dans le domaine
de la conception d'application web.
Pour développer une application web, certains programmes
nous ont été indispensables :
? Un éditeur de texte : on a opté pour
l'éditeur Sublime Texte.
? Un navigateur web : qui nous permettait de tester l'application
et de le manipuler. Dans notre cas nous avons choisi Google Chrome comme
navigateur web.
Pour que notre ordinateur puisse lire du PHP et se comporter
comme un serveur, nous avons eu besoin d'autres programmes
supplémentaires comme Apache, PHP et MySQL.
? Apache : qui est un serveur web, son rôle est charger et
délivrer les pages web à l'utilisateur. Apache ne gère que
des pages web statiques (HTML), il faut donc le compléter aussi avec
d'autres programmes.
? PHP : qui est un plug-in pour Apache qui le rend capable de
traiter des pages web dynamiques en PHP. En claire la combinaison d'Apache et
PHP permet à un ordinateur de lire les pages web en PHP.
? MySQL : qui est un logiciel de gestion de base des
données, il permet d'enregistrer les données de manière
organisée. c'est un système de gestion de base des
22
www.wikipedia.org/langage
PHP/ en ligne, consulter le 10 Juillet 2015
48
données relationnelles (SGBDR) et il est disponible sur
une double licence GPL et propriétaire, il utilise le langage de
requête SQL pour l'accès aux données.
Il existe un «Packs» tous près qui contient ces
trois éléments tous réunis, c'est Wamp Server pour Windows
bien qu'il en existe plusieurs, nous avons choisi celui-ci car il offre
l'avantage d'être en français et a la possibilité
d'être régulièrement mis à jour.
III.8.4. ARCHITECTURE DE L'APPLICATION
Dans les phases préliminaires du développement
d'une application ou de la refonte d'un système d'information, la
définition de l'architecture technique consiste à faire les choix
de technologies et d'organisation de composants logiciels les plus
adaptés aux besoins et aux contraintes de l'organisation d'accueil.
Ces choix sont ensuite relayés au sein de notre projet,
guidant la conception et permettant la transformation d'un modèle
fonctionnel en application performante et robuste.
? Présentation de l'architecture à 2
niveaux
L'architecture à deux niveaux (aussi appelée
architecture 2-tiers, tiers signifiant étages en anglais)
caractérise les systèmes clients/serveurs 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
Figure 24: Architecture 2 tiers (Source :
www.google.com/images/deuxtiers.png)
49
? Présentation de l'architecture à 3
niveaux
Dans l'architecture à 3 niveaux (appelées
architecture 3-tiers), il existe un niveau intermédiaire,
c'est-à-dire que l'on a généralement une architecture
partagée entre:
1. Le client: le demandeur de ressources
2. Le serveur d'application (appelé aussi middleware): le
serveur chargé de fournir la ressource mais faisant appel à un
autre serveur
3. Le serveur secondaire (généralement un serveur
de base de données), fournissant un service au premier serveur.
Figure 25: Architecture 3 tiers (Source :
www.google.com/images/troistiers.png)
Tout système d'information nécessite la
réalisation de trois groupes de fonctions: le stockage des
données, la logique applicative et la présentation. Ces trois
parties sont indépendantes les unes des autres: on peut ainsi vouloir
modifier la présentation sans modifier la logique applicative. La
conception de chaque partie doit également être
indépendante, toutefois la conception de la couche la plus basse est
utilisée dans la couche d'au-dessus.
Ainsi la conception de la logique applicative se base sur le
modèle de données, alors que la conception de la
présentation dépend de la logique applicative.
? Architecture adoptée
Vis-à-vis de l'existant chez Bell Equipement:
organisation, compétences, architecture du système d'information,
nous avons choisi l'architecture 3 tiers car c'est une architecture:
50
· pérenne: applicable durant une
très longue période de temps et accepter des changements
technologiques ou fonctionnels tout en protégeant les investissements
réalisés.
· modulaire: un élément
peut être remplacé ou modifié sans devoir changer toute
l'architecture.
· ouverte: elle doit permettre de
construire ou de modifier une solution à partir de composants provenant
de différents constructeurs.
L'application web conçu sera déployée sur
une architecture 3-tiers. Cette architecture peut être décrite par
la figure ci-dessous :
Figure 26: Architecture 3 tiers (Source :
www.google.com/images/troisiers.png)
CONCLUSION
Dans ce chapitre nous avons fixé la structure globale de
l'application par quelque diagramme UML, nous avons présenté les
outils de travail que nous avons utilisé et nous avons enfin
présenté l'architecture de notre application.
51
Chapitre IV. REALISATION ET DEPLOIMENT
DE L'APPLICATION DEVELOPPE
INTRODUCTION
Arrivé à ce stade nous pouvons nous estimer
heureux, il ne reste qu'à commencer à écrire notre code en
se basant sur les résultats obtenus des chapitres
précédents. Mais cela se fait en suivant des critères. On
doit passer par plusieurs jalons pour avoir un produit de bonne
qualité.
Ainsi dans ce chapitre on va essayer de donner un bref
aperçu sur le code de l'application développée,
présenter les résultats de notre travail et finir par une petite
conclusion.
IV.1. DIAGRAMME DE DEPLOIEMENT
Le diagramme de déploiement est un diagramme UML qui
permet de représenté l'architecture physique l'architecture du
système. Dans ce diagramme UML nous décriront la disposition
physique des composants matérielle.
Figure 27: Diagramme de déploiement
52
IV.2 PRESENTATION DE L'APPLICATION DEVELOPPEE Page
d'accueil
Figure 28: interface d'authentification
Figure 29: code PHP authentification
53
Cree Compte
Figure 30: interface de création de compte
utilisateur
Archiver document
Figure 31:interface d'archivage de documents
54
Figure 32: code PHP classe d'entité Archive
Consulter archive
Figure 33: interface de consultation des documents
55
IV.3 ESTIMATION DU COUT GLOBALE
Libelle Quantité Explication Cout
Source
Scanneur et Imprimante
|
1
|
Pour la numérisation des documents et l'impression des
archives
|
350$
|
|
Serveur web
|
1
|
Pour faire tourner notre application
|
1130$
|
Internet
|
Câble UTP
|
|
10 mètre
|
5$
|
Best Buy
|
Connecteurs RJ45
|
10
|
|
2$
|
Best Buy
|
Système
d'exploitation
|
1
|
Debian ; libre donc aucune dépense
|
0$
|
|
PC de bureau
|
3
|
Aucune dépense
|
0$
|
|
Main d'ouvre
|
|
30% de dépenses
|
446,1$
|
|
Imprévu
|
|
5% de dépenses
|
96,655$
|
|
Total
|
|
|
2029,755
|
|
CONCLUSION
A travers ce chapitre, nous avons présenté la
réalisation de l'application en justifiant nos choix technologiques, en
représentant quelques interfaces graphiques que nous avons jugé
les plus importantes
56
CONCLUSION GENERALE
L'objectif de notre projet de fin de cycle était de
concevoir et implémenter une application de gestion du processus
d'archivage au sein de l'entreprise Bell Equipment.
Le point de départ de la réalisation de ce
projet était une récolte des informations nécessaires pour
dresser un état de l'existant, présenter un aperçu sur la
problématique ainsi qu'une étude documentaire sur l'archivage.
Par la suite, nous nous sommes intéressés
à l'analyse et la spécification des besoins qui nous a permis de
distinguer les différents acteurs interagissant avec l'application
visée. L'objectif de la partie suivante était la conception
détaillée, dans laquelle nous avons fixé la structure
globale de l'application et présenté les outils de travail que
nous avons utilisé.
Le dernier volet de notre projet était la partie
réalisation et déploiement de l'application qui a
été consacrée à la présentation des
interfaces les plus significatives de notre application.
L'apport de ce travail a été d'une importance
très considérable, en effet, il nous a permis d'une part: de
suivre une méthodologie de travail bien étudié,
d'approfondir nos connaissances dans le monde de développement des
applications et d'une autre part faciliter à l'entreprise en question,
d'améliorer la gestion du processus d'archivage.
La réalisation d'un tel projet, nous a permis
d'apprendre et de toucher du doigt une partie de divers aspects du
métier de développeur et de celui du concepteur.
57
BIBLIOGRAPHIE
[1] CHABIN Marie-Anne. Archiver, et après ? Paris :
Djakarta, 2007. 160p. ISBN 978-2-9528828-0-4.
[2] CHABIN Marie-Anne. Nouveau glossaire de l'archivage [en
ligne]. Archive17,
2010 [consulté le 27 mai 2010]. Disponible sur :
http://www.archive17.fr/index.php?option=com
performs&Itemid=55.
[3] CAYA Marcel. La théorie des trois âges en
archivistique. En avons-nous toujours besoin ? [En ligne]. Paris : L'Ecole des
chartes, 2004 [consulté le 22 juin 2010]. Disponible sur :
http://elec.enc.sorbonne.fr/document72.html.
[4] Pascal ROQUES, UML pour le web, Ed. Eyrolles,
Paris, 2008. 264p.
[5] Laurent AUDIBERT, Cours UML 2.0, IUT Paris, 2006,
inédit
[6] Martin LOBO, Tour sur les processus métier, Paris,
2011, inédit
NETOGRAPHIE:
[1]
http://fr.wikipedia.org
[2]
http://fr.google.org
[3]
http://code.google.cd/intl/fr-FR/webtoolkit/
[4] http://uml.free.fr/
58
ANNEXE
Annexe 1 : Aperçue du BPMN
Le BPMN permet une représentation standardisée
du déroulement des processus et ce, autant pour les analystes
d'affaires, qui produisent les premières ébauches, le personnel
technique, qui met en oeuvre la solution technologique exécutant le
processus et les utilisateurs d'affaires, qui gèrent et contrôlent
les processus. Nous l'utiliserons donc dans sa version 2.0 pour
présenter le processus métier dans notre travail.
V' Diagramme d'orchestration (processus
privé): Un processus privé est un type de
modélisation qui permet de représenter un processus
spécifique à une organisation, un département ou un
intervenant en précisant les sous-processus, les activités ou les
tâches, les Événements et les Objets échangés
et cela en adoptant le point de vue de celui qui les réalise.
V' Diagramme d'orchestration (processus
public): c'est un type de modélisation qui permet de
représenter les interactions qui relient un processus privé
à plusieurs participants externes (qui peuvent être un individu,
un département ou un autre processus) en définissant les flux de
messages, leur séquence et leur ordre.
V' Le diagramme de collaboration : c'est un
diagramme qui permet de représenter les échanges et les
interactions qui se nouent entre deux ou plusieurs unités d'affaire
représenté par des bassins. Les bassins sont définis comme
étant des participants de cette collaboration. Les messages
échangés entre les participants du diagramme de collaboration
sont représentés à l'aide du symbole flux de message
(symbole qui permet de connecter les bassins entre eux ou les objets qu'on
retrouve à l'intérieur de ces bassins).
Annexe 2 : Règles de passage du modèle
conceptuel au modèle physique (MCD MLD)
· Table et clé primaire : Toute
classe ou entité (=objet de gestion) est transformée en table.
Les attributs de l'entité deviennent les attributs de la table.
L'identifiant de la classe/entité devient la clé primaire de la
table
· Relation binaire (...,*) - (...,1) :
La clé primaire de l'entité reliée par (..., 1)
devient clé étrangère de l'entité reliée par
(...,*).
· Relation binaire (0.1) - (1.1) : La
clé primaire de l'entité reliée par (0, 1) devient
clé étrangère de l'entité reliée par (1,
1).
59
? Relation binaire et ternaire (...,*) - (...,*) :
On crée une table supplémentaire ayant comme clé
primaire une clé composée des clés primaires des deux
entités. Lorsque la relation contient elle-même des
propriétés, celles-ci deviennent attributs de la table
supplémentaire.
Annexe 3 : Ingénierie et
retro-ingénierie
Aujourd'hui les concepts ingénierie et
rétro-ingénierie, jouent un rôle important en informatique
plus particulièrement dans le domaine de génie logiciel. Les
développeurs de logiciels ne peuvent pas s'empêcher de profiter
d'un tel marché.
Les logiciels répondants à ces deux concepts
commencent à inonder le marché. Le principe de base est simple :
en ayant une conception on peut retrouver le corps du programme à
développer (ingénierie), et inversement on peut trouver la
conception (retro-ingénierie). En voici ce qu'on peut lire dans
Wikipédia :
La rétro-ingénierie (traduction littérale
de l'anglais Reverse engineering), également appelée
rétro-conception, est l'activité qui consiste à
étudier un objet pour en déterminer le fonctionnement. L'objectif
peut être par exemple de créer un objet différent avec des
fonctionnalités identiques à l'objet de départ sans
contrefaire de brevet. Ou encore de modifier le comportement d'un objet dont on
ne connaît pas explicitement le fonctionnement.
La démarche utilisée peut être celle de
l'étude d'une boîte noire : on isole l'objet à
étudier, on détermine les entrées et les sorties actives.
On essaie ensuite de déterminer la réponse du système en
fonction du signal d'entrée. Mais il est également possible de
démonter le système jusqu'à un certain point pour en
analyser les constituants.
60
Table des matières
EPIGRAPHE
DEDICACE II
REMERCIEMENTS III
LISTE DES FIGURES IV
INTRODUCTION 1
PRESENTATION DU SUJET 1
CHOIX ET INTERET 2
ETAT DE LA QUESTION 2
PROBLEMATIQUE ET HYPOTHESE 3
PROBLEMATIQUE 3
HYPOTHESE 4
METHODE ET TECHNIQUE 4
METHODES 4
TECHNIQUES 5
DELIMITATION DU TRAVAIL 5
SOMMAIRE 6
Chapitre I. CONSIDERATION THEORIQUE ET CONCEPTUELLE 7
INTRODUCTION 7
I.1. THEORIE SUR L'ARCHIVAGE 7
I.1.1. DEFINITION DES CONCEPTS 7
I.1.2. PRESENTATION GENERALE 7
I.1.2.2 ARCHIVAGE 8
I.1.2.3 PROCESSUS D'ARCHIVAGE 9
I.1.2.4 PRINCIPES DE GESTION DES ARCHIVES 12
I.2. TYPES D'ARCHIVES 13
I.3. ARCHIVAGE PAPIER vs ARCHIVAGE ELECTRONIQUE 14
I.4. PLACE DE L'ARCHIVAGE DANS L'ENTREPRISE 17
CONCLUSION 17
Chapitre II. PRESENTATION DU CADRE D'ETUDE ET MODELISATION DU
METIER 18
INTRODUCTION 18
II.1. PRESENTATION DU CADRE D'ETUDE 18
II.1.1. PRESENTATION DE BELL EQUIPEMENT 18
II.1.2. LOCALISATION GEOGRAPHIQUE 19
II.1.3. HISTORIQUE 19
II.1.4. BRANCHE OUVERTE DE BELL EQUIPMENT SUR LE TERRITOIRE
NATIONAL 19
II.2. STRUCTURE FONCTIONNELLE 19
II.3. ANALYSE DE L'EXISTANT 20
II.3.1 DESCRIPTION TEXTUELLE DE L'EXISTANT 20
61
II.3.2. ANALYSE DES LOTS D'INFORMATIONS 21
II.3.3. DIAGRAMME DE CONTEXTE 21
II.3.4. MODELISATION DU METIER 22
II.4. CRITIQUE DE L'EXISTANT 24
II.5. APPROCHE DE SOLUTION 24
CONCLUSION 24
Chapitre III. CONCEPTION 26
INTRODUCTION 26
III.1. PRESENTATION DE LA METHODE UTILISEE 26
III.2. CAPTURE DES BESOINS 27
III.3. DIAGRAMME DE CAS D'UTILISATION 28
III.4. DIAGRAMMES DE SEQUENCE SYSTEME 32
III.5. DIAGRAMMES DE CLASSES 35
III.5.1. MODELE DU DOMAINE 36
III.5.2. DIAGRAMME DE CLASSES PARTICIPANTES 37
III.6. CONCEPTION OBJET PRELIMINAIRE 39
III.6.1. DIAGRAMME D'INTERACTION 39
III.6.2. DIAGRAMME DE CLASSE DE CONCEPTION PRELIMINAIRE 42
III.7. MODELE PHYSIQUE DES DONNEES 43
III.8. METHODES ET OUTILS POUR L'APPLICATION 44
III.8.1. DEFINITION ET AVANTAGE DE L'APPROCHE ORIENTEE OBJET
44
III.8.2. CHOIX DU PRINCIPE ET DU LOGICIEL DE MODELISATION 45
III.8.3. CHOIX DES OUTILS DE DEVELOPPEMENT 46
III.8.4. ARCHITECTURE DE L'APPLICATION 48
CONCLUSION 50
Chapitre IV. REALISATION ET DEPLOIMENT DE L'APPLICATION DEVELOPPE
51
INTRODUCTION 51
IV.1. DIAGRAMME DE DEPLOIEMENT 51
IV.2 PRESENTATION DE L'APPLICATION DEVELOPPEE 52
IV.3 ESTIMATION DU COUT GLOBALE 55
CONCLUSION 55
CONCLUSION GENERALE 56
BIBLIOGRAPHIE : 57
NETOGRAPHIE: 57
ANNEXE 58
|