UNIVERSITE PROTESTANTE DE
LUBUMBASHI
FACULTE DES SCIENCES INFORMATIQUES
Vérité et liberté
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'obtentiondu titre de
gradué en sciences informatiques
Dirigé par Ass. NéhémieKAZIMOTO
Option : Ingénierie de système
d'information
ANNEE-ACADEMIQUE : 2014-2015
EPIGRAPHE
«Ce que l''on conçoit bien s'énonce
clairement,
Et les mots pour le dire arrivent aisément.»
Nicolas Boileau
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. Nousgarderons 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 enserons profondément heureux car
nousvoulons pour vous, vos familles toutes les réussites et
satisfactions de ce monde.
Freddy ILUNGA KADIATA
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
AssistantNé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 KAMUANYAnos 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, Josue Mbulayi 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.Noustenons à les en remercier vivement.
LISTE DES FIGURES
Figure 1:Processus d'archivage
2
Figure 2:Tableau de cycle vie des archives
14
Figure
3: Organigramme
21
Figure 4: Diagramme de contexte
23
Figure 5: Diagramme d'orchestration
24
Figure 6: Diagramme de collaboration
24
Figure 7 : Diagramme de cas d'utilisation
30
Figure 8: diagramme de séquence
« Authentification »
34
Figure 9:diagramme de séquence
« Archiver document »
34
Figure 10: diagramme de séquence
« consulter archive »
35
Figure 11: diagramme de séquence
« gérer archive »
36
Figure 12 : Modèle du domaine
38
Figure 13: diagramme de classe participante
Consulter Archive
39
Figure 14 : diagramme de classe participante
Archiver document
39
Figure 15: diagramme de classe participante
Gérer Archive
40
Figure 16 : Diagramme de séquence du
scénario nominale recherche rapide
41
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
42
Figure 19: Diagramme de séquence du scenario
nominale Archivage avec succès
42
Figure 20 : diagramme de classe de conception
consulter archive
43
Figure 21: diagramme de classe de conception
Archiver nouveau document
43
Figure 22: diagramme de classe de conception
Gérer Archive
44
Figure 23: Modèle physique des
données
45
Figure 24: architecture 2 tiers
50
Figure 25: architecture 3 tiers
50
Figure 26: Architecture 3 tiers
51
Figure 27: Diagramme de déploiement
53
Figure 28: interface d'authentification
54
Figure 29: code PHP authentification
54
Figure 30: interface de création de compte
utilisateur
55
Figure 31:interface d'archivage de documents
55
Figure 32: code PHP classe d'entité
Archive
56
Figure 33: interface de consultation des
documents
56
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.
Cette nouvelle aire est également
caractérisée par l'expansion de l'archivage
électronique.
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 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, 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.
Ø La méthode agile dite de 80/20 situé
à mi-chemin entre UP (Unified Processing) et XP (eXtreme Programing)
d'UML.
Ø 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.
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.
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.
· 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.
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 :
Figure 1:Processus d'archivage9(*)
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 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
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 :
Ø 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.
- 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, 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 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é. 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 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.
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.
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.
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évoyaitla 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 :
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 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 :
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.
II.3.4.2 DIAGRAMME D'ORCHESTRATION
Figure 5: Diagramme d'orchestration
II.3.4.3 DIAGRAMME DE COLLABORATION
Figure 6: Diagramme de collaboration
II.4. CRITIQUE DE
L'EXISTANT
Le système actuellement utiliser chez Bell
Equipmentpermet 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
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.
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.
· « 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
- 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 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 archivé.
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
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 télécharger.
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.
Authentification :
Figure 8: diagramme de séquence
« Authentification »
Archiver document :
Figure 9:diagramme de séquence
« Archiver document »
Consulter archive :
Figure 10: diagramme de séquence
« consulter archive »
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), composantde 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élisation21(*).
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:
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.
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
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.
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
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
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
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.
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
personne ou encore une page d'un livre. Il possède une structure
interne, et un comportement, et il sait interagir avec ses pairs22(*).
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é 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
locale23(*). 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
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)
Ø 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-à-visde 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:
· 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.
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
IV.2 PRESENTATION DE
L'APPLICATION DEVELOPPEE
Page d'accueil
Figure 28: interface d'authentification
Figure 29: code PHP authentification
Cree Compte
Figure 30: interface de création de compte
utilisateur
Archiver document
Figure 31:interface d'archivage de documents
Figure 32: code PHP classe d'entité
Archive
Consulter archive
Figure 33: interface de consultation des
documents
IV.3ESTIMATION 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
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.
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] PascalROQUES, 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/
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.
ü 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.
ü 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.
ü 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).
§ 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.
Table des matières
EPIGRAPHE
I
DEDICACE
II
REMERCIEMENTS
III
LISTE DES FIGURES
IV
INTRODUCTION
2
PRESENTATION DU SUJET
2
CHOIX ET INTERET
3
ETAT DE LA QUESTION
3
PROBLEMATIQUE ET HYPOTHESE
4
PROBLEMATIQUE
4
HYPOTHESE
5
METHODE ET TECHNIQUE
5
METHODES
5
TECHNIQUES
6
DELIMITATION DU TRAVAIL
6
SOMMAIRE
6
Chapitre I. CONSIDERATION THEORIQUE ET
CONCEPTUELLE
8
INTRODUCTION
8
I.1. THEORIE SUR L'ARCHIVAGE
8
I.1.1. DEFINITION DES CONCEPTS
8
I.1.2. PRESENTATION GENERALE
8
I.1.2.2 ARCHIVAGE
9
I.1.2.3 PROCESSUS D'ARCHIVAGE
10
I.1.2.4 PRINCIPES DE GESTION DES
ARCHIVES
13
I.2. TYPES D'ARCHIVES
14
I.3. ARCHIVAGE PAPIER vs ARCHIVAGE
ELECTRONIQUE
15
I.4. PLACE DE L'ARCHIVAGE DANS
L'ENTREPRISE
18
CONCLUSION
18
Chapitre II. PRESENTATION DU CADRE D'ETUDE ET
MODELISATION DU METIER
19
INTRODUCTION
19
II.1. PRESENTATION DU CADRE D'ETUDE
19
II.1.1. PRESENTATION DE BELL EQUIPEMENT
19
II.1.2. LOCALISATION GEOGRAPHIQUE
20
II.1.3. HISTORIQUE
20
II.1.4. BRANCHE OUVERTE DE BELL EQUIPMENT
SUR LE TERRITOIRE NATIONAL
20
II.2. STRUCTURE FONCTIONNELLE
20
II.3. ANALYSE DE L'EXISTANT
21
II.3.1 DESCRIPTION TEXTUELLE DE
L'EXISTANT
21
II.3.2. ANALYSE DES LOTS D'INFORMATIONS
22
II.3.3. DIAGRAMME DE CONTEXTE
22
II.3.4. MODELISATION DU METIER
23
II.4. CRITIQUE DE L'EXISTANT
25
II.5. APPROCHE DE SOLUTION
25
CONCLUSION
25
Chapitre III. CONCEPTION
27
INTRODUCTION
27
III.1. PRESENTATION DE LA METHODE
UTILISEE
27
III.2. CAPTURE DES BESOINS
28
III.3. DIAGRAMME DE CAS D'UTILISATION
29
III.4. DIAGRAMMES DE SEQUENCE SYSTEME
33
III.5. DIAGRAMMES DE CLASSES
36
III.5.1. MODELE DU DOMAINE
37
III.5.2. DIAGRAMME DE CLASSES PARTICIPANTES
38
III.6. CONCEPTION OBJET PRELIMINAIRE
40
III.6.1. DIAGRAMME D'INTERACTION
40
III.6.2. DIAGRAMME DE CLASSE DE CONCEPTION
PRELIMINAIRE
43
III.7. MODELE PHYSIQUE DES DONNEES
44
III.8. METHODES ET OUTILS POUR
L'APPLICATION
45
III.8.1. DEFINITION ET AVANTAGE DE
L'APPROCHE ORIENTEE OBJET
45
III.8.2. CHOIX DU PRINCIPE ET DU LOGICIEL DE
MODELISATION
46
III.8.3. CHOIX DES OUTILS DE
DEVELOPPEMENT
47
III.8.4. ARCHITECTURE DE L'APPLICATION
49
CONCLUSION
51
Chapitre IV. REALISATION ET DEPLOIMENT DE
L'APPLICATION DEVELOPPE
52
INTRODUCTION
52
IV.1. DIAGRAMME DE DEPLOIEMENT
52
IV.2 PRESENTATION DE L'APPLICATION DEVELOPPEE
53
IV.3 ESTIMATION DU COUT GLOBALE
56
CONCLUSION
56
CONCLUSION GENERALE
57
BIBLIOGRAPHIE :
58
NETOGRAPHIE:
58
ANNEXE
59
* 1Ludivine 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
* 2 CAPH (communauté
d'agglomération de la porte du Hainaut) : domaine d'étude
de LUDVINE MAGREZ
* 3 Pascal ROQUES, UML pour le
web 4 ème Ed. Eyrolles, Paris, 2008
* 4 Idem, P.14
* 5
www.wikipedia.org/archiveconsulté
le 06 Mars 2015
* 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/>
* 9Groupe 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 15Mars 2015], volume 42, n°2. p.106-116.
* 10CHABIN 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
>.
* 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
* 12CHABIN Marie-Anne.
Archiver, et après ? Paris : Djakarta, 2007. p.66-69[en ligne]
[consulté le 17 Mars 2015]
* 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.
* 14UML, C. Johnen : IUT
de Bordeaux, V2consulté le 26 Mai 2015
* 15 Pascal ROQUES, UML pour
le web. P.4
* 16 Idem, P.5
* 17 Pascal Roque, op.cit.,
P.12
* 18 Pascal Roque, op.cit.,
P.41
* 1920 Pascal Roque, op.cit.,
P.42
* 21 Laurent AUDIBERT, op.cit.,
P.35
* 22
http//:ww.wikipedia.org/approche oriente objet
* 23
www.wikipedia.org/langage
PHP/ en ligne, consulter le 10 Juillet 2015
|