1

INFORMATIQUE ET TÉLÉCOMMUNICATIONS

APPLICATION WEB D'ARCHIVAGE DES DONNÉES AU SEIN D'UNE

ENTREPRISE. CAS DE BELL EQUIPMENT

PAR FREDDY ILUNGA KADIATA

UNIVERSITÉ PROTESTANTE DE LUBUMBASHI

GRADUAT 2016
 2

LISTE DES FIGURES

Figure 1: Processus d'archivage 10

Figure 2: Tableau de cycle de 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 dewebmaster

 3

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
 4

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.

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
 5

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.
 6

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
risqué 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:
 7

- 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 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».

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

 8

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.
Pour atteindre notre objectif on a partagé le travail comme suit:
 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.
 9

CHAPITRE I. CONSIDERATION THEORIQUE ET CONCEPTUELLE

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 ». Dans le langage courant, « archives » signifie soit des vieux papiers ou
la paperasse plus ou moins inutile, soit des trésors oubliés.
 10

Définition et rôle

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
risque».
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.
 11

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.

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
 12

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'archivage

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:

o les métadonnées descriptives: description du contenu intellectuel (ex.: titre,

auteur, date, mots clés...),
o les métadonnées de gestion (ou de structure): elles aident à organiser, à
valider puis à archiver les ressources organisationnelles,
 13

o 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.
 14

 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
 15

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 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
 16

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 presentation 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

 17

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
 18

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
CHABIN a clairement identifié quatre 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.
 19

- 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 CHABIN 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.
 20

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.
 21

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, à 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.
 22

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:

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 circonscrire 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.
 23

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 context

 24

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

 25

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:

o La perte de temps dans la recherche des archives

o Possibilité d'avoir des redondances d'information
o établissement laborieux des rapports
o Risque de mélanger les documents ce qui peut être fatal
o Le suivie des clients et des fournisseurs peut rencontrer beaucoup de
problèmes.
o L'abondance des documents papier dans l'entreprise peut ralentir les services.
o 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.
 26

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.
 27

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 vue.

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é
objet.

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,
 28

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
 29

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:
 30

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é.

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

 31

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
4. 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 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

 32

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.

b. «modifier archive»
 33

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

 34

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

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:
 35

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élisation. 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.
 36

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:

o les classes conceptuelles ou les objets du domaine;

o les associations entre classes conceptuelles;
o 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.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 »
 37

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.

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.
 38

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:

o les classes conceptuelles ou les objets du domaine;

o les associations entre classes conceptuelles;
o 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
 39

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:

o Ajouter ou préciser les opérations dans les classes.

o Ajouter des types aux attributs et aux paramètres et retours des opérations.
o Affiner les relations entre classes: associations (avec indication de navigabilité),
généralisations ou dépendances.
 40

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

 41

c. Cas d'utilisation Gérer Archive

Figure 22: Diagramme de classe de conception Gérer Archive

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.
 42

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 pairs.

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.
 43

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
 44

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.

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
 45

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.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

 46

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:

o 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.
o Modulaire: un élément peut être remplacé ou modifié sans devoir changer
toute l'architecture.
o Ouverte: elle doit permettre de construire ou de modifier une solution à partir
de composants provenant de différents constructeurs.
 47

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.
 48

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

Figure 30: interface de création de compte utilisateur

Archiver document
 49

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.3 ESTIMATION DU COUT GLOBALE

Libelle Quantité Explication Cout Source

Scanneur et Imprimante

Pour la numérisation des documents et l'impression des archives 350$

Serveur web

Pour faire tourner notre application 1130$

Internet

Câble UTP 10 mètre 5$ Best Buy

Connecteurs RJ45 2$

Best Buy

Système d'exploitation Debian; libre donc aucune dépense 0$

PC de bureau Aucune dépense 0$

Main d'ouvre 30% de dépenses 446,1$

Imprévu 5% de dépenses 96,655$

Total 2029,755
 50

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.
 51

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,
3. 2010 [consulté le 27 mai 2010]. Disponible sur:
http://www.archive17.fr/index.php?option=com performs&Itemid=55.
4. 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.
5. Pascal ROQUES, UML pour le web, Ed. Eyrolles, Paris, 2008. 264p.
6. Laurent AUDIBERT, Cours UML 2.0, IUT Paris, 2006, inédit
7. Martin LOBO, Tour sur les processus métier, Paris, 2011, inédit

NETOGRAPHIE:

- http://fr.wikipedia.org
- http://fr.google.org
- http://code.google.cd/intl/fr-FR/webtoolkit/
- http://uml.free.fr/
 52

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
 53

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
 54

constituants.

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
 55

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

 56

NATIONAL 19

II.2. STRUCTURE FONCTIONNELLE 19

II.3. ANALYSE DE L'EXISTANT 20

II.3.1 DESCRIPTION TEXTUELLE DE L'EXISTANT 20

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

 57

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

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