Développement d'une application web pour l'optimisation du processus d'archivage et d'accès aux données d'une entreprise (cas de Bell equipement)

ANNEE-ACADEMIQUE : 2014-2015

UNIVERSITE PROTESTANTE DE LUBUMBASHI

FACULTE DES SCIENCES INFORMATIQUES

DEVELOPPEMENT D'UNE APPLICATION WEB
POUR L'OPTIMISATION DU PROCESSUS
D'ARCHIVAGE ET D'ACCES AUX DONNEES
D'UNE ENTREPRISE

(Cas de BELL EQUIPEMENT)

Par ILUNGA KADIATA Freddy

Travail Présenté en vue de L'obtention du titre de gradué en sciences informatiques

Dirigé par Ass. Néhémie KAZIMOTO

Option : Ingénierie de système d'information

«Ce que l''on conçoit

bien s'énonce

clairement,

Et les mots pour le dire

arrivent aisément.»

Nicolas Boileau

EPIGRAPHE

II

DEDICACE

À vous nos parents, François KADIATA TA-MBUYI et

Clémentine MPEMBA MUTEBUA, qui nous ont inculqué un esprit de

combativité, de persévérance et qui nous ont toujours poussé et motivé

dans nos études. Sans vous, certainement nous n'en seront pas à ce

niveau.

À vous oncle Jean-Pierre KALALA et votre épouse Tante

Chantale MUSHIYA. Vous étiez pour nous oncle, un père spirituel et un

modèle à suivre pour être au sommet des échelons. Nous garderons

toujours un attachement profond pour vous. A vous et votre famille,

nous serons toujours reconnaissants pour l'assistance que vous avez

apportée dans nos études.

À tous ceux qui nous lirons, nous tenons particulièrement à

dédier ce travail, Si nos voeux pouvaient avoir quelques pouvoirs nous

en serons profondément heureux car nous voulons pour vous, vos

familles toutes les réussites et satisfactions de ce monde.

Freddy ILUNGA KADIATA

III

REMERCIEMENTS

La réalisation d'un tel ouvrage a été rendue possible par le concours de plusieurs personnes que nous nous sentons obligé de remercier.

A Jéhovah le créateur, le Dieu de toute consolation, nous disons merci pour l'amour et la bonté manifestés à notre égard.

Nous tenons à exprimer également nos remerciements avec un grand plaisir à notre directeur Assistant Néhémie KAZIMOTO, Ses conseils, Sa disponibilité et ses encouragements nous ont permis de réaliser ce travail dans les meilleures conditions. Nous exprimons de même notre gratitude à monsieur Patient KAMBAJI qui a cru en nous et qui n'a cessé de nous faire profiter de ses précieux conseils et soutiens.

Nous adressons aussi notre reconnaissance à tous les professeurs et au corps administratif de l'université protestante de Lubumbashi qui depuis quelques années leurs conseils et leurs connaissances nous ont bien servis.

À Mireille KAMUANYA, Claudine MUJINGA, Mamichou MALEYA, Yolande MIANDA, Laurenne KADIATA, Gemima KAMUANYA nos soeurs qui nous ont toujours soutenu au prix des sacrifices inoubliables.

À nos frères Franck MUDIANGOMBE et Ken MUTEBUA, à mes cousins Willy LUKOJI, Alain MUKEBA, Cédric MUTOMBO, TIMOTHEE KAPUYA, PIERRE LUKOJI, LJ LUKOJI, Andi KALUBI pour vos encouragements incessants et actes de bienveillances.

Nous tenons à dire combien le soutien quotidien de notre famille a été important tout au long de ces quelques années, nous leurs devons beaucoup.

Nous tenons à remercier nos collègues et camarades de lutte, Donat TSHISWAKA, Rolly SAPEMBA, Sam KABEYA, Tendresse FUAFUA, Clark NYOTA, Arlenne MBELU Gracia KABONDO, Concilie MUSHIYA, Francisco KALONDA, 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. Nous tenons à les en remercier vivement.

IV

LISTE DES FIGURES

Figure 1:Processus d'archivage 10

Figure 2:Tableau de cycle vie des archives 13

Figure 3: Organigramme 20

Figure 4: Diagramme de contexte 22

Figure 5: Diagramme d'orchestration 23

Figure 6: Diagramme de collaboration 23

Figure 7 : Diagramme de cas d'utilisation 29

Figure 8: diagramme de séquence « Authentification » 33

Figure 9:diagramme de séquence « Archiver document » 33

Figure 10: diagramme de séquence « consulter archive » 34

Figure 11: diagramme de séquence « gérer archive » 35

Figure 12 : Modèle du domaine 37

Figure 13: diagramme de classe participante Consulter Archive 38

Figure 14 : diagramme de classe participante Archiver document 38

Figure 15: diagramme de classe participante Gérer Archive 39

Figure 16 : Diagramme de séquence du scénario nominale recherche rapide 40

Figure 17: diagramme de séquence scénario Erreur de recherche 40

Figure 18:Diagramme de séquence de la suite du scenario nominale de recherche rapide 41

Figure 19: Diagramme de séquence du scenario nominale Archivage avec succès 41

Figure 20 : diagramme de classe de conception consulter archive 42

Figure 21: diagramme de classe de conception Archiver nouveau document 42

Figure 22: diagramme de classe de conception Gérer Archive 43

Figure 23: Modèle physique des données 44

Figure 24: architecture 2 tiers 48

Figure 25: architecture 3 tiers 49

Figure 26: Architecture 3 tiers 50

Figure 27: Diagramme de déploiement 51

Figure 28: interface d'authentification 52

Figure 29: code PHP authentification 52

Figure 30: interface de création de compte utilisateur 53

Figure 31:interface d'archivage de documents 53

Figure 32: code PHP classe d'entité Archive 54

Figure 33: interface de consultation des documents 54

Cette nouvelle aire est également caractérisée par l'expansion de l'archivage électronique.

1

INTRODUCTION

PRESENTATION DU SUJET

Depuis la nuit des temps à nos jours, l'esprit perfectionniste de l'homme n'a cessé de croitre et lui permet ainsi d'améliore sa vie quotidienne. Le passage de la mécanique au domaine d'électronique, d'automatique et d'informatique a révolutionné la vie journalière de l'être humain. Les nouvelles technologies de l'information et de communication illustrent ce phénomène dans sa forme la plus pure et la plus complète.

Vu l'intérêt croissant de gagner en temps, de conserver les données, de limiter le nombre d'employés et beaucoup d'autres raisons, ont poussé petites, moyennes et grandes entreprises à chercher des solutions informatiques capables de répondre à leur besoins.

Dans le même ordre d'idée, l'homme a pensé délecter son cerveau de certaines taches par des outils technologique qu'il ne cesse de perfectionner. Car comme jadis pour pouvoir communiqué, s'échanger d'informations, conserver d'informations..., l'homme recourait à des écorces d'arbres pour pouvoir écrire et y conserver des informations jusqu'à ce qu'aux environs des années 100, il fabrique le papier. Cette prouesse technologique a considérablement changée la manière de traiter, d'échanger, de conserver et de stocker les informations.

Aujourd'hui les entreprises et organisations tirent pleinement partie de l'utilisation du papier car ils ont besoins de conserver des archives d'informations pour des raisons utilitaire ou encore légale, en vue d'une éventuelle consultation ultérieur. Or à cela s'ajoute le fait que, plus l'entreprise prend de l'âge, la masse des documents croit sensiblement et cela empêche l'entreprise de faire une gestion optimale de ces documents.

Cette manipulation d'informations à travers des papiers n'est pas toujours de tout repos et a montré ses limites de plusieurs manière, c'est ce qui a fait qu'avec l'avènement des nouvelles technologies, l'archivage d'informations prenne de l'importance et est maintenant perçue d'une toute autre façons dans les entreprises.

2

A cette fin, c'est dans ce cadre que s'inscrit notre projet de fin de cycle qui consiste à réaliser une application d'archivage de données au seins d'une entreprise et nous avons pris le cas particulier de BELL EQUIPMENT.

CHOIX ET INTERET

Nous avons choisis de fixer notre étude sur ce thème parce que nous avons constaté qu'un grand nombre d'entreprise éprouve des sérieuses difficultés dans la gestion des archives. Ce travail dégage plusieurs intérêts :

Premièrement l'intérêt que nous portons à ce sujet de recherche est, d'évaluer tout d'abord les connaissances acquises tout au long de ce premier cycle d'étude universitaire en informatique en proposant un système de gestion assister par ordinateur pour la gestion du processus d'archivage et d'accès aux données aux seins d'une entreprises.

Puis son intérêt se justifié aussi dans la mesure ou si BELL EQUIPMENT (entreprise ou est basé notre sujet de recherche) adopte cette solution il disposera d'un système informatisé de gestion d'archives.

D'une autre part ce travail constituera un socle dans la conduite et la réalisation des projets autour de l'archivage électronique, les chercheurs, étudiants et professionnels pourront s'appuyer déçu afin d'y mener d'autres projets d'études et y approfondir les recherches.

ETAT DE LA QUESTION

Nous ne sommes pas les premiers ou même le seul à parler de l'archivage électronique, d'autres auteurs bien avant nous en ont aussi parlé, parmi ces travaux nous avons mis la main sur le travail de LUDIVINE MAGREZ¹ (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

¹ Ludivine Magrez. Comment choisir une solution de gestion d'archives : le cas de la Communauté d'Agglomération de la Porte du Hainaut. Université Charles de Gaulle Lille 3

domain shs.info.coll. 2010. <mem 00526158>

http://memsic.ccsd.cnrs.fr/mem 00526158

3

des logiciels qu'il avait sélectionné, mais aussi après la prise en compte des besoin de la CAPH². 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,

² CAPH (communauté d'agglomération de la porte du Hainaut) : domaine d'étude de LUDVINE MAGREZ

? La méthode agile dite de 80/20 situé à mi-chemin entre UP (Unified Processing) et XP (eXtreme Programing) d'UML.

4

la perte de temps dans la recherche des documents, les redondances avec risque

d'incohérence... Or quand une entreprise ne sait plus maitriser ses flux d'informations,
notamment ses archives qui constitue sa mémoire, elle tombe dans l'inactivité.

C'est ainsi que nous nous sommes posé les questions suivantes :

? Quelle serait la solution à mettre en place pour la gestion optimale des archives de BELL EQUIPMENT ?

? Quelles seront les avantages du à la mise en place de cette solution ?

HYPOTHESE

Pour répondre à ce problème, plusieurs solution sont envisageables, pour notre part nous estimons que la meilleur solution pour améliorer la gestion des archives de BELL EQUIPMENT, il serait mieux de faire recours aux prouesses technologique et avantages que nous offres l'outil informatique. D'une façon concrète et précise, nous pensons qu'il faudrait mettre au point une application informatique interagissant avec une base de données afin de permettre :

- un accès rapide aux données archivées

- Une sécurité des informations

- Un stockage organisé des données

- Un gain de place physique

- Une réduction du cout dans la gestion d'archive

BELL EQUIPMENT pourrait ainsi avoir une meilleure perception de l'archivage en ce sens que cette application pourrait permettre aux agents de le voir sous un nouveau jour.

METHODE ET TECHNIQUE

Dans le but de bien appréhender le problème posé et comme notre préoccupation est grande et que les investigations doivent se poursuivre, il a été alors important de définir une marche à suivre pour atteindre l'objectif.

METHODES

Pour mener à bien notre étude nous avons utilisés deux méthodes.

5

? La méthode BPMN (Busness Process Modeling Notation) de l'OMG (Object Management Group).

La méthode agile adoptée dans ce travail est une démarche d'analyse et de conception des systèmes informatiques centrée sur la notation UML et développé par Pascal Roques dans son ouvrage intitulé : «UML pour le web»³. 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 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.

³ Pascal ROQUES, UML pour le web 4 ème Ed. Eyrolles, Paris, 2008

⁴ Idem, P.14

6

SOMMAIRE

Pour atteindre notre objectif on a partagé le travail comme suite :

? Le premier chapitre intitulé «considération théorique et conceptuelle», nous parlerons ici d'un aperçu général sur l'archivage, sa place dans l'entreprise et son importance, nous y parlerons également de certaines notions liés à la conception des systèmes informatiques.

? Dans le second il s'agit d'une prise de connaissance de l'existant pour savoir de ce que doit être capable de faire et de quoi va servir notre futur application en d'autres termes il s'agit d'une analyse et spécification des besoins.

? Le troisième chapitre sera consacré à la conception de l'application il s'agit d'une phase de modélisation théorique de l'application.

? Le quatrième chapitre on va présenter les résultats obtenus et l'implémentation, tous ceux-ci sans compter l'introduction et la conclusion.

7

Chapitre I. CONSIDERATION THEORIQUE ET CONCEPTUELLE

INTRODUCTION

Dans ce chapitre nous faisons une définition des certains concepts liés à notre sujet et un aperçu général sur les concepts et méthodes liées au processus d'archivage et à l'archivage électronique qui fait l'objet de notre étude.

I.1. THEORIE SUR L'ARCHIVAGE

I.1.1. DEFINITION DES CONCEPTS

Optimisation : En informatique le terme optimisation désigne souvent une amélioration des performances (d'un logiciel, d'un système de gestion des bases des données, d'un moteur de recherche, etc.).

Processus : Dans le dictionnaire de français Larousse, le processus est définit comme un enchaînement, une suite continue d'opérations aboutissant à un résultat. C'est dans ce contexte que s'inscrit le processus parlé dans ce sujet.

Donnée : une donnée est en fait toute information élémentaire manipulée dans une organisation ou dans une entreprise. Le dictionnaire français la définie comme une information représentée sous une forme conventionnelle, afin de pouvoir être traitée automatiquement.

Droit d'accès aux données : c'est l'autorisation donné à un utilisateur d'accéder aux informations dont il a besoin selon son habilité, selon les principes de gestion établit dans l'entreprise et selon son pouvoir d'action.

I.1.2. PRESENTATION GENERALE

I.1.2.1 Archive

Etymologie : Le terme « Archive » vient du bas latin archivum, signifiant « armoire », qui lui-même vient du grecque ancien acheion signifiant « bâtiment administratif, magistrature »⁵.

Dans le langage courant, « archives » signifie soit des vieux papiers ou la paperasse plus ou moins inutile, soit des trésors oubliés.

⁵ www.wikipedia.org/archive consulté le 06 Mars 2015

8

Définition et rôle

En Archivistique⁶ 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é courante⁷ ». 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.

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

⁷ CALCALY Serge, le COADIC Yves F, POMART Paul-Dominique et al. ; Dictionnaire de l'information, Paris : Arnaud coli [2è édition]. 2004, P.7

⁸ CHABIN Marie-Anne. Nouveau glossaire de l'archivage [en ligne]. Archive 17, 2010 [consulté le 05 Mais 2015]. Disponible sur: < www.archive17.fr/component/option.com_performs/itemid,55/>

9

De l'archivage au Records Management

Présentement dans les entreprises comme dans les organismes, l'archivage des documents est perçu différemment, il est devenu la démarche du contrôle du cycle de vie des documents à risque dans l'entreprise. Cette nouvelle perception de l'archivage a entrainé la création d'un système s'appuyant sur la gestion des documents utiles à la fin de leur vie administrative et qui assure leur fiabilité, leur intégrités et accessibilité. Il s'agit du «Records Management», expression anglo-saxonne ayant pour signification approximative en français «gestion de l'archivage», D'après la norme ISO 15489 : 2001, le Records management désigne « le champ de l'organisation et de la gestion en charge d'un contrôle efficace et systématique de la création, de la réception, de la conservation, de l'utilisation et du sort final des documents, y compris des méthodes de fixation et de préservation de la preuve et de l'information liées à la forme des documents ». Autrement dit, c'est un système qui accompagne et gère les documents de leur création à l'extinction de leur utilité par le producteur en passant par leur réception et leur conservation. Sauf qu'il ne prend en compte que la gestion des archives courantes et intermédiaires, les archives définitives n'étant pas prises en charge dans ce système. Nous verrons que les archives numériques prennent de plus en plus d'importances dans cette procédure.

L'archivage électronique est devenu un réel défi pour le Records Management, le support numérique ayant autant de valeur que le support papier dans la société moderne et même au niveau des lois de certains pays. Le Records Management symbolise d'une certaine façon l'évolution de l'archivage, thème qui sera abordé plus bas mais d'abord parlons un peu du processus d'archivage.

I.1.2.3 PROCESSUS D'ARCHIVAGE

Le projet d'archivage s'appuie sur le processus d'archivage, selon les principes du Records Management. Articulé avec les processus métiers, il se décompose en trois sous-processus chronologiques, qui suivent le cycle de vie du document engageant : versement, conservation et destruction, et un sous-processus transverse : la mise à disposition ou l'accès aux utilisateurs. Le tableau ci -dessous illustre les huit étapes du processus de gestion des documents :

10

Figure 1:Processus d'archivage ⁹

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

⁹ Groupe Métiers AAF-ADBS « Records Management ». Comprendre et pratiquer le records management : Analyse de la norme ISO 15489 au regard des pratiques archivistiques françaises [en ligne].

Documentaliste - Sciences de l'information, 2005 [consulté le 15 Mars 2015], volume 42, n°2. p.106-116.

11

de classement des activités. Cette opération indique si ce dernier sera ou non enregistré dans le système d'archivage et précise les règles de conservation dans le cas où il est archivé.

? Capture et enregistrement du document

Cette étape montre le rattachement d'un document à un plan de classement. A ce document, sera ajouté des ajouts de description, afin que celui-ci puisse être facilement retrouvé.

? Analyse et ajout de métadonnées

Cette étape a pour but la description complète du document. Celle-ci se fait par l'intégration de métadonnées, qui sont « des données structurées ou semi-structurées qui permettent de qualifier et de gérer les documents archivés tout au long de leur cycle de vie¹⁰». Trois types de métadonnées peuvent être distingués :

- les métadonnées descriptives : description du contenu intellectuel (ex.: titre, auteur, date, mots clés...),

- les métadonnées de gestion (ou de structure) : elles aident à organiser, à valider puis à archiver les ressources organisationnelles,

- les métadonnées de préservation (ou administratives): métadonnées destinées à assurer la conservation à long terme de ressources électroniques. Elles incluent les données techniques telles que le contrôle d'accès, les conditions d'utilisation...).

Les métadonnées permettent ainsi de :

- gérer le cycle de vie (savoir combien de temps on doit conserver l'information,

à quelles autres informations elle est rattachée, quand on peut la détruire),

- gérer les droits d'accès,

- gérer la recherche,

- gérer l'authenticité du document (valeur de preuve),

- exploiter le document dans son contexte.

? Stockage sécurisés

10 CHABIN Marie-Anne. Nouveau glossaire de l'archivage [en ligne]. Archive17, 2010 [consulté le 17 Mars 2015]. p. 26. Disponible sur : < http://www.archive17.fr/index.php?option=com_performs&Itemid=55 >.

12

La sécurité des documents doit être garantie. Elle est synonyme d'identification, d'intégrité et de confidentialité. Cette sécurité doit permettre à garantir :

o l'identification,

o l'authentification,

o la sauvegarde,

o la lisibilité,

o la traçabilité, qui est « le fait de créer, d'enregistrer et de préserver les données relatives aux mouvements et à l'utilisation des documents».

? Prise en compte des évolutions des documents

Cela signifie que tous les changements liés au document concernant son statut, sa durée de conservation sont mémorisés.

? Communication, mise à disposition, accès

Cette étape a pour objectif la traçabilité des actions de communication, de localisation, des utilisateurs et des motifs d'utilisation du document.

? Application du sort final

Arrivé à la fin de la durée d'utilité administrative, le sort final est appliqué : il est décidé si le document doit être conservé pour être transféré aux archives définitives ou détruit.

I.1.2.4 PRINCIPES DE GESTION DES ARCHIVES

Les principes et les techniques relatifs à la gestion des archives font l'objet d'une des disciplines participante des sciences de l'information: l'archivistique. Les deux concepts de base de cette discipline sont :

? Le principe du respect des fonds : qui impose de traiter les documents en fonction de leur provenance et non de leur sujet, ce qui implique de les classer et de les inventorier sans perdre de vue leur lien organique avec l'entité qui les a produit.

? La théorie des trois âges : cette théorie a déjà était signalé un peu plus au déçu. En archivistique, on considère que le cycle de vie du document est divisé en trois périodes : courantes (Active), intermédiaire et définitive (1èr, 2èm, 3èm).

Les archives naissent dans les bureaux en vue d'une action plus précise, puis conservent un intérêt plus ou moins à long terme. Des bureaux aux Archives, les documents connaissent trois étapes d'utilisation :

- Archives privées : sont celle qui ne possède pas un caractère légal. On peut y rattacher ainsi les papiers de famille, les documents personnels, les archives d'entreprises,

13

? Les archives courantes (Dossiers vivants): regroupent les documents qui sont nécessaire à l'activité des services qui les ont produits. Les services les conservent à proximité des utilisateurs et de leur bureau pour le traitement des affaires courantes.

? Les archives intermédiaires: celle qui ne sont plus d'usage courante mais doivent être conservées temporairement, pour des besoins administratives et juridique. Ils sont conservés à proximité des bureaux, souvent dans un local dédié dit de pré archivage.

? Les archives définitives : celle dont l'utilité administrative ou de gestion est éteinte et qui ont vocation à être conservé pour des raisons historiques ou patrimoniales. Elles sont versées dans les services d'archives compétentes pour être conservés indéfiniment.

Tableau de cycle de vie des archives

Figure 2:Tableau de cycle vie des archives

A l'issu de la durée légale ou règlementaire de conservation, les archives intermédiaires font l'objet d'un tri et sont soit conservées définitivement soit éliminées.

I.2. TYPES D'ARCHIVES

Les archives sont classées principalement en deux grandes familles à savoir les archives privées et les archives publiques.

¹¹ ABBASI Rafiki, ABOMO AKONDO, BOUZIZI Sif Douala, et al. Stage technique international des archives : l'archive électronique [En ligne]. [Consulté 17 Mars 2015]. P.2. Disponible sur : www.archivesdefrance.gouv.fr

14

d'associations politiques ou religieuses. Elles peuvent être données, léguées ou même confiées en dépôt à des services d'archives publiques ou privés et leur communication peut obéir alors à des règles particulières fixées par leurs propriétaires. Elles restent propriétés de leurs détenteurs originels, mais l'administration publique des archives doit être avisée de tout ce qui pourrait affecter leur intégrité (aliénation, restauration, etc.).

- Archives publique : sont celle produite par les pouvoirs publiques et par les organisations chargés d'une mission de service publique (parquet, organisme consulaire, organisme de droit privé, officier ministériels). Elles désignent aussi dans la langue courante les fonds d'archives conservés par les services d'archives publiques. Leur délai de consultation est fixé par la loi.

La distinction entre archives privées et archives publiques est parfois difficile à

établir.

Les papiers d'un homme politique par exemple, peuvent comporter des documents en rapport avec ses fonctions officielles qui sont donc des archives publiques et des documents découlant de ses activités de parlementaire et de responsable d'un parti politique qui sont des archives privées.

I.3. ARCHIVAGE PAPIER vs ARCHIVAGE ELECTRONIQUE

I.3.1. PRESENTATION DE L'ARCHIVAGE ELECTRONIQUE

Avec l'introduction des nouvelles technologies dans les collectivités et dans les administrations, beaucoup des documents autrefois tenus sous format papier sont aujourd'hui gérés sous format électronique.

A l'instar de l'archive papier, l'archivage électronique est l'ensemble des procédures définies par une collectivité pour assurer la conservation de son patrimoine documentaire conformément à un référentiel défini par l'autorité chargée du stockage et de la mise à disposition future des documents effectivement versés. Il représente, au sens général, « l'ensemble des actions, outils et méthodes visant à identifier, recueillir, classer et conserver des informations électroniques, qui sont mis en oeuvre pour conserver à moyen et long terme ces informations dans le but de les exploiter¹¹». En comparaison avec l'archivage papier, l'archivage électronique gère les documents numériques, qui sont des « ensembles composés d'un contenu, d'une structure logique, d'attributs de présentation

15

permettant leur représentation, dotés d'une signification intelligible par l'homme ou lisible par une machine». Il peut être crée à l'état natif ou obtenu par un processus de transformation d'un document physique, par exemple par numérisation (scannage). Les documents bureautiques, les bases de données, les messages électroniques, les dossiers numérisés sont considérés comme des documents numériques.

I.3.2. EXIGENCE DE L'ARCHIVAGE ELECTRONIQUE

L'archivage électronique est un processus (système) sensible, pour sa réalisation il doit répondre à certaines exigences.

? L'intégrité des documents : cela consiste en la protection du document garantir qu'il ne subisse aucun ajout, ni aucune modification qui pourrait altérer ou entrainer sa destruction.

? La pérennité des données : elle consiste à maintenir dans le temps l'intégrité des données. En effet, un document doit être lisible à n'importe quel moment. Un stockage sur de formats standards normalisés et pérennes facilite les choses (PDF, etc.).

? La sécurité des documents : il s'agit ici d'assurer la sécurité physique des locaux et des données. Ça se fait par le biais des règles de sécurité pour les bâtiments (l'anti-intrusion, lutte contre l'incendie, etc.), la sauvegarde ou duplication des documents.

? L'authenticité des documents : le manuel de spécifications Moreq2 explique qu'il s'agit de prouver qu'un document est bien original. Pour cela, il faut prouver que le document est bien celui qu'il prétend être, qu'il a été créé ou envoyé, et qu'il a été créé ou envoyé à la date prétendue.

C'est là en quelque sorte les exigences qu'il faudrait observer sur l'archivage électronique.

Ces exigences permettent ainsi de faciliter l'accès à l'information, de répondre aux exigences légales de conservation et de communication et de relever le défi de l'obsolescence technologique.

Il reste à signale que l'archivage électronique est une fonction à ne pas confondre ni avec la « sauvegarde informatique » ni avec la « gestion électronique des documents (GED)». Effectivement, la sauvegarde informatique se contente uniquement à stocké les données pour les restauré en cas de pannes elle est conçue pour une conservation à court terme et son support est inexploitable en dehors de son environnement technique. De plus, la sauvegarde ne respecte pas les règles de classement, de mise à disposition, de sécurité, de pérennité et de traçabilité.

¹² CHABIN Marie-Anne. Archiver, et après ? Paris : Djakarta, 2007. p.66-69 [en ligne] [consulté le 17 Mars 2015]

16

La gestion électronique des documents appelé aussi `'GED», contrairement à l'archivage électronique, permet la modification de documents et la coexistence de plusieurs versions d'un même document par leur propriétaires. Elle peut même permettre la destruction des documents ce qui viole l'intégrité des documents et trahit les exigences de l'archivage électronique.

I.3.3. SIMILITUDES ET DIFFERENCES

Le plus grand enjeu de l'archivage électronique est de traiter les archives électroniques selon les mêmes règles que les archives papier. Les principes restent identiques à ceux des archives papiers. Mais les moyens sont plus lourds et les risques plus grands pour assurer l'intégrité et la sécurité. La plus grande différence entre les deux qui peut être ressortie est due en partie aux technologies informatiques.

? Concordances

L'archivage électronique intègre donc, tout comme le papier, les notions de plan de classement, délais de conservation, sort final des documents, identification, recherche, et restitution. Il reprend en quelque sorte les étapes du processus du Records Management.

? Différences

Une grande différence existe entre papier et numérique. Marie-Anne CHABIN¹² 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

¹³ CHABIN Marie-Anne. Nouveau glossaire de l'archivage [en ligne]. Archive17, 2010 [consulté le 17 Mars 2015]. p. 8. Disponible sur : www.archive17.fr.

17

rapide les archives papiers, il fallait penser à mettre en place un magasin archives se trouvant au plus près des services producteurs. Avec les archives numériques, les distances sont rompues. Les services peuvent ainsi accéder rapidement aux informations, par le biais d'une simple base de données, ou par l'accès à un logiciel de gestion électronique de documents.

I.4. PLACE DE L'ARCHIVAGE DANS L'ENTREPRISE

Au cours de ces derniers années l'archivage a considérablement évolué et s'est modernisé; sa place au sein de l'entreprise a changé. La fonction archivage est dès lors perçue différemment et ces enjeux n'en sont plus que nombreux.

Sur ceux, Marie-Anne 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.

CONCLUSION

Pour finir, nous pouvons dire que l'archivage a un bel avenir devant lui, car malgré les outils perfectionnés mis à la disposition des entreprises, la masse des documents demeure difficile à maitriser et nécessite une gestion des archives vigoureuse. Il faut donc se dire que malgré les préjugés portés à ce service, l'archivage occupe désormais un rôle prépondérant au sein de l'entreprise. Ce service doit avoir une place centrale car sans l'archivage, les informations risqueraient de disparaitre, de se disperser et d'être inutilisables.

Du point de vue juridique, Bell est une société privée à responsabilité limité avec un objectif social. Sous la dénomination BELL EQUIPMENT(DRC) Sarl.

18

Chapitre II. PRESENTATION DU CADRE D'ETUDE ET
MODELISATION DU METIER

INTRODUCTION

Dans l'élaboration de notre projet, nous commençons par faire un aperçu de l'étude préalable. Celle-ci consiste à recenser toutes les données et tous les traitements du système en place avant de préconiser une solution du système futur.

Il s'agit d'une étape cruciale dans la réalisation d'une application donnée. Le futur d'une application dépend beaucoup de cette phase, Elle permet d'éviter le développement d'une application ne répondant pas à sa spécification. Pour cela le client et le développeur doivent être en étroite relations.

Pour arriver à nos fins il nous faut prendre connaissance de :

? L'analyse et la définition des besoins : étape qui permet de trouver un commun accord entre les spécialistes (développeurs) et les utilisateurs.

? L'étude de faisabilité : le domaine d'application, l'état actuel de
l'environnement du futur système.

? L'élaboration du cahier de charge.

Dans ce chapitre, nous présentons le système existant en vue d'en dégager les faiblesses et proposer des solutions informatiques appropriées.

II.1. PRESENTATION DU CADRE D'ETUDE

II.1.1. PRESENTATION DE BELL EQUIPEMENT

Bell Equipement est une société commerciale qui s'occupe principalement de la vente des engins (des camions bennes, des tracteurs etc.) ; des pièces de rechange (des boulons, des batteries etc.) et des services après ventes (les réparations, la maintenance, et la formation technique a l'utilisation du matériel).

De manière peu pragmatique Bell vend en état ses engins et pièces de rechange c'est ce qui fait d'elle une entreprise commerciale.

19

II.1.2. LOCALISATION GEOGRAPHIQUE

Le siège social de Bell Equipment est situé au numéro 17 de l'avenue Munguzi au Quartier industriel dans la commune de KAPEMBA. En République démocratique du Congo dans la province du Katanga ville de Lubumbashi.

II.1.3. HISTORIQUE

La société Bell Equipment(DRC) Sarl a été créée à Lubumbashi le 06 AOUT 2007 conformément aux lois congolaises par la société Bell Equipment SA (9 .999parts sociales) et par la société Bell Equipment Limited (1parts) avec un capital social d'USS 10.000. Elle avait commencé avec un effectif de 11 personnes, A la fin du mois d'octobre 2011 le personnel atteignait environ 119 travailleurs dont 42 expatriés.

Au mois de février 2012, la société comptait 204 travailleurs dont 60 expatriés. Le programme 2012 prévoyait la formation à l'étranger d'une quarantaine des mécaniciens locaux.

A la fin de l'année 2012 la société comptait près de 222 travailleurs dont 60 expatriés. Le programme 2013 prévoyait quant à lui la formation à l'étranger d'une soixantaine des mécaniciens locaux.

A ce jour, la société compte 216 travailleurs dont 58 expatriés. Le programme 2014 prévoyait la formation à l'étranger d'une centaine de mécaniciens locaux.

II.1.4. BRANCHE OUVERTE DE BELL EQUIPMENT SUR LE TERRITOIRE

NATIONAL

La société Bell Equipment a des branches ouvertes :

? Au sud Kivu ou elle travaille avec la société Twangiza Mining, qui exploite de

l'or.

? Dans la province orientale avec les sociétés GPS et M&T à Doko (à watsa), qui travaille chez kibali gold mining, qui exploite de l'or.

? Une branche a été ouverte à Kolwezi en 2013.

? Un autre est en voie d'ouverture à Kinshasa depuis 2013.

II.2. STRUCTURE FONCTIONNELLE

Pour son bon fonctionnement Bell Equipement possède une structure fonctionnelle hiérarchique dont les postes sont agencés de la manière suivante :

20

Figure 3: Organigramme

Source: service d'archivages

II.3. ANALYSE DE L'EXISTANT

Dans les lignes qui suivent, nous présentons le processus d'archivage des documents chez Bell Equipment en vue de bien circoncire notre domaine d'études.

II.3.1 DESCRIPTION TEXTUELLE DE L'EXISTANT

Le processus commence au niveau de l'administration et du département des comptabilités. L'administration expédie et reçoit toutes les correspondances et tous les documents de Bell Equipement. Il peut s'agir des notes, des rapports, des procès-verbaux, des lettres de décompte final, des lettres de licenciements, des lettres de mutations et autres documents qui y sont produits.

Le département des comptabilités aussi expédie et reçoit les factures fournisseurs et client, les bordereaux et même bien d'autres documents traiter dans ses bureaux.

Après leurs traitements, la comptabilité comme l'administration transfère auprès du bureau d'archivage tous ces documents pour qu'ils y soient enregistrer et classer. L'archiviste les reçoit et les vérifies d'abord avant leur classement. S'il remarque quelque chose de bizarre ou toute autre anomalie, il retourne le document à sa source pour analyse et correction avant de le recevoir à nouveau. Le classement des documents se fait selon leurs natures (les inputs et les outputs), selon leurs dates d'archivage ou un autre critère afin de faciliter le rangement et la recherche. Après un temps dont la périodicité est variable, l'archiviste se charge de récupérer tous les documents classés. Il commence par vérifier leurs états et leur nature pour qu'ils soient bien tenus afin d'identifier la traçabilité du dossier, puis il les codifie avant de les

21

consigner à son tour dans son registre. Il peut alors les classer dans les armoires et rayons prévus à cette fin.

II.3.2. ANALYSE DES LOTS D'INFORMATIONS

Dans le but d'assurer un suivi de toutes ces opérations liées à la gestion des archives, le bureau d'archives utilise les documents ci-après :

? Registrer d'entrée : dans ce registre, on saisit sous forme d'un tableau les informations relatives aux archives. Il s'agit de :

· Le Nom

· L'année

· Le type

· La provenance ou la Destination

? Les Classeurs : dans les classeurs on y range les documents et on loge ensuite les classeurs dans les armoires et rayon. Sur les classeurs, des étiquettes reprennent les informations suivantes pour faciliter le classement et la recherche:

· L'intitulé

· L'année

· Le Type

II.3.3. DIAGRAMME DE CONTEXTE

Le Diagramme de contexte n'est pas un diagramme UML ou même un diagramme BPMN, mais il nous permet d'avoir une vue global du système étudié, des interactions entre ses activités et le rapport avec l'environnement extérieur¹⁴.

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 :

¹⁴UML, C. Johnen : IUT de Bordeaux, V2consulté le 26 Mai 2015

22

Figure 4: Diagramme de contexte

II.3.4. MODELISATION DU METIER

II.3.4.1. PRESENTATION DU BPMN

BPMN (Business Process Modeling Notation) 2.0 de l'OMG (Object Management Group) est une notation graphique standardisée portant sur la modélisation des processus métiers. Elle vise à fournir une notation facilement compréhensible par les utilisateurs métiers (y compris les analystes métiers, les développeurs et ceux qui devront gérer et surveiller les processus après leur mise en oeuvre) mais aussi à créer une passerelle standardisée pour combler le vide entre la modélisation de processus métiers et les langages d'exécution métiers.

L'objectif du BPMN est de fournir un cadre permettant de décrire un processus d'une manière commune à tous les utilisateurs et ce, indépendamment de l'outil utilisé.

On retrouve, au sein de la notation BPMN2.0, quatre catégories de diagrammes afin de représenter les différentes perspectives d'un processus (Voir Annexe acce).

1. Les diagrammes d'orchestration (processus privé et processus public)

2. Les diagrammes de collaboration

3. Le diagramme de chorégraphie

4. Le diagramme de conversation

Pour notre travail nous présenterons juste le diagramme d'orchestration, et de collaboration, ils suffiront pour présenter le processus métier.

23

II.3.4.2 DIAGRAMME D'ORCHESTRATION

Figure 5: Diagramme d'orchestration

II.3.4.3 DIAGRAMME DE COLLABORATION

Figure 6: Diagramme de collaboration

24

II.4. CRITIQUE DE L'EXISTANT

Le système actuellement utiliser chez Bell Equipment permet une bonne organisation du travail, une bonne circulation de l'information, un bon enregistrement des informations nécessaires sur les archives et une bonne tenue des documents.

Mais hors mis les avantages du système actuelle, nous avons constaté qu'il présente certaines lacunes tel que :

· la perte de temps dans la recherche des archives

· Possibilité d'avoir des redondances d'information

· établissement laborieux des rapports

· Risque de mélanger les documents ce qui peut être fatal

· Le suivie des clients et des fournisseurs peut rencontrer beaucoup de problèmes.

· L'abondance des documents papier dans l'entreprise peut ralentir les services.

· On peut avoir besoin de plus d'employés pour se partager les taches en cas d'une recherche d'archive spécifique.

II.5. APPROCHE DE SOLUTION

En tenant compte des critiques et des besoins d'informatiser les services cités ci-dessus, plusieurs solutions sont envisageables mais nous pensons pour notre part que la solution est de concevoir et développer une application permettant de satisfaire au maximum possible le bureau d'archivage et Bell Equipment en particulier.

Pour cela l'application doit répondre aux besoins suivants :

· Avoir un logiciel qui respecte les principes des Interfaces Homme/Machine (IHM) tels que l'ergonomie et la fiabilité.

· Réduire les tâches manuelles qui nous permettraient de gagner en spatiotemporel

· Archiver les informations en toute confidentialité

· Restituer rapidement les données recherchées

· Partager simultanément les informations

· Avoir un logiciel évolutif.

CONCLUSION

L'étude préalable appelée techniquement ingénierie des exigences ou analyse et spécification des besoins, constitue une phase capitale dans le cas où toute la suite du projet

25

dépend d'elle, elle doit être faite avec beaucoup de rigueur et plus d'attention pour que le projet réussisse avec un grand succès.

Dans ce chapitre, on a exposé les problèmes de la société et de l'existant, puis nous avons fait les critiques sur la façon actuelle d'archiver les données et enfin on a fait une approche de solution qui consiste à concevoir et à développer une application qui facilitera les services énumérés précédemment.

Après avoir fixé nos objectifs, pour atteindre notre but on doit suivre plusieurs étapes ces dernières constituent une partie du cycle de vie de tout projet informatique. Ainsi dans l'étape suivante on va se consacrer sur le choix des méthodes et outils de la réalisation.

26

Chapitre III. CONCEPTION

INTRODUCTION

La plupart des nouveaux langages sont orientés objet. Le passage de la programmation fonctionnelle à l'orienté objet n'était pas facile. L'un des soucis était d'avoir une idée globale en avance de ce qu'on doit programmer.

L'algorithmique qui était utilisé dans la programmation fonctionnelle ne pourrait pas suffire à lui seul. Le besoin d'avoir des méthodes ou langages pour la modélisation des langages orientés objet se faisait sentir. Ainsi plusieurs méthodes ou langages ont vu le jour. En occurrence UML qui nous a permis de faire la conception de notre application.

UML (Unified Modeling language) se définit comme un langage de modélisation graphique et textuel destiné à comprendre et décrire des besoins, spécifier et documenter des systèmes, esquisser des architectures logicielles, concevoir des solutions et communiquer des points de 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, 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 logiciel¹⁷. 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.

¹⁵ Pascal ROQUES, UML pour le web. P.4

¹⁶ Idem, P.5

¹⁷ Pascal Roque, op.cit., P.12

27

? « Logiciel fonctionnel plutôt que documentation complète » : il est vital que l'application fonctionne. Le reste, et notamment la documentation technique, est secondaire, même si une documentation succincte et précise est utile comme moyen de communication.

? « Collaboration avec le client plutôt que la négociation du contrat » : le client doit être impliqué dans le développement. On ne peut se contenter de négocier un contrat au début du projet, puis de négliger les demandes du client.

? « Réagir au changement plutôt que suivre un plan » : la planification initiale et la structure du logiciel doivent être flexibles afin de permettre l'évolution de la demande du client tout au long du projet.

Cette méthode se situe à mi-chemin entre UP (Unified Processus «processus unifié»), un cadre générale très complet des processus de développement, et XP (eXtreme Programming), une approche minimaliste centrée sur le code.

Avec cette méthode, nous n'utilisons pas les treize types de diagrammes proposés par UML 2, mais seulement un tiers, en insistant particulièrement sur les diagrammes de classes et le diagramme de séquence. Cette limitation volontaire ne diminue en rien la puissance de la démarche, mais, elle nous permet une réduction significative du temps d'apprentissage de la modélisation avec UML, tout en restant largement suffisante pour une bonne modélisation de notre système.

Pour ce faire, on va commencer par les diagrammes de cas d'utilisation (Use Case) qui permet de donner une vue globale de l'application. Pas seulement pour un client non avisé qui aura l'idée de sa future application mais aussi le développeur s'en sert pour le développement des interfaces.

En deuxième lieu on va présenter la chronologie des opérations par les diagrammes de séquences.

Et finir par les diagrammes statiques, qui sont celles de classe de conception, de classe participantes et le modèle physique.

III.2. CAPTURE DES BESOINS

Avant la modélisation de notre système, il est important de capturer les besoins de l'utilisateur qui sont émis en termes des fonctionnalités du futur système. Le futur système devra permettre aux utilisateurs d'effectuer les actions suivantes :

- enregistrer les archives

28

- rechercher des archives

- centraliser les archives

- consulter les archives

- générer des rapports périodiques

III.3. DIAGRAMME DE CAS D'UTILISATION

Le diagramme de cas d'utilisation fait partie des diagrammes comportementaux d'UML. Les cas d'utilisations constituent un moyen de recueillir et de décrire les spécifications et les exigences des acteurs ou les besoins des acteurs du système.

La représentation d'un cas d'utilisation met en jeu trois concepts : l'acteur, le cas d'utilisation et l'interaction entre l'acteur et le cas d'utilisation.

Il convient pour nous d'expliquer d'abord ces concepts avant de poursuivre :

? Acteur : Un acteur représente un rôle joué par une entité externe (utilisateur humain, dispositif matériel ou autre système) qui interagit directement avec le système étudié¹⁸.

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 particulier¹⁹.

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

¹⁸ Pascal Roque, op.cit., P.41

19 19 Pascal Roque, op.cit., P.42

archivé.

29

les uns et les autres est la même. La différence réside sur les droits d'accès et les limites de chacun.

Figure 7 : Diagramme de cas d'utilisation

Description textuelle

Archiver document

Acteur principale : Archiviste

? Objectifs : L'archiviste veut archiver un document qu'il reçoit.

? Précondition

? L'archiviste doit recevoir un document venant de l'administration

? L'archiviste doit s'authentifier avec succès

? Post conditions

? Nouveau document archivé

? Document classé

? Scénario nominal

1. L'archiviste vérifie le document reçu

2. L'archiviste codifie le document puis lance une requête d'archivage au système.

3. Le système valide l'archivage du document et affiche le message document

30

Alternative

1. a. L'archiviste constate le manque de certaines informations sur le document :

1. L'archiviste fait un rapport sur l'erreur et le cas d'utilisation se termine en échec.

2. a. le système détecte un disfonctionnement dans le processus d'archivage :

1. le système signale le disfonctionnement à l'archiviste

2. l'archiviste il prévient le service informatique pour engager des a actions de maintenances. Le cas d'utilisation se termine en échec.

3. a. L'archiviste détecte des erreurs ou des incohérences sur les informations du nouveau document archiver :

1. l'archiviste modifie toutes les informations erronées

2. l'archiviste valide la modification, le cas d'utilisation reprend à l'étape trois du scénario nominal.

Gérer archive

Acteur principal : Archiviste

? Objectif : L'archiviste peut vouloir générer des rapports, modifier certains droits

d'accès sur les archives, voir l'évolution du trafic, modifier ou supprimer une archive.

? Précondition

? Au moins une archive doit être disponible

? L'archiviste doit s'authentifié avec succès

? Post condition

Le rapport a été généré/ l'archive a été modifié/ l'archive a été supprimé/ les droits d'accès ont été modifiés/ l'archiviste a vu l'évolution du trafic.

? Scénarios nominal

1. L'archiviste lance l'espace de gestion d'archives.

2. L'archiviste sélectionne l'option : a. `'générer le rapport»

a.1. Le système affiche un formulaire

a.2. L'archiviste rempli le formulaire en fournissant la période et lance la requête

a.3. Le système génère le rapport

télécharger.

31

b. «modifier archive»

b.1. Le système affiche un formulaire

b.2. l'archiviste sélectionne les informations qu'il souhaite et les modifie

b.3. le système renvoi un message que la modification a été effectuée avec succès.

c. «voir l'évolution ou modifier les droit d'accès »

c.1. Le système affiche un formulaire

c.2. L'archiviste modifie les droits d'accès, supprime ou regarde l'évolution

c.3. Le système renvoi un message de confirmation pout la modification des droit d'accès ou de la suppression de l'archive.

Alternative

1. b. l'archiviste saisie des données erronées, le système renvoi un message

d'échec.

2. c. l'archiviste modifie les droits d'accès d'un archive utilisé, le système lui signifie que l'archive est ouvert et qu'il est impossible de le modifie.

Consulter Archive

Acteur principal : Administration Acteur secondaire : Archiviste

? Objectif : l'administration veulent disposer d'un document qui a été archive.

? Précondition

? Au moins une archive disponible

? L'administration doit s'authentifier avec succès

? Post conditions

? Archive consulté

? Aucun Résultat

? Scénarios nominal

1. Le système affiche un formulaire de recherche

2. Le service de finance rempli la zone de recherche en fournissant un mot clé et lance la requête

3. Le système affiche les archives trouvées

4. Il sélectionne l'archive qu'il veut consulter et lance une requête pour le

32

5. Le service de finance ouvre l'archive téléchargé

Alternative

3 .a. Le système n'a pas trouvé l'archive correspondant à la recherche :

1. le affiche le message aucun archive trouver et lui propose d'effectuer une

nouvelle recherche.

III.4. DIAGRAMMES DE SEQUENCE SYSTEME

Il s'agit d'une explication détaillée d'un cas d'utilisation. Les principales informations contenues dans un diagramme de séquence sont les messages échangés entre les lignes de vie, présentés dans un ordre chronologique.

33

Authentification :

Figure 8: diagramme de séquence « Authentification »

Archiver document :

Figure 9:diagramme de séquence « Archiver document »

34

Consulter archive :

Figure 10: diagramme de séquence « consulter archive »

35

Gérer archive :

Figure 11: diagramme de séquence « gérer archive »

III.5. DIAGRAMMES DE CLASSES

Précédemment nous avons parlé de deux grandes catégories de diagrammes UML (statique et dynamique), l'un des diagrammes statique nous intéresse beaucoup pour pouvoir implémenter le code, il s'agit du diagramme des classes.

Ce modèle nous permet d'avoir une vue statique de l'application. Il nous montre les relations entre les différentes entités (classes), composant de notre application. Il nous mène vers la solution finale. À partir de ce diagramme on retrouve les corps de différentes classes de notre application. Mieux encore en utilisant la technique de la retro-ingénierie (voir Annexe 3) on obtient une grande partie du code finale.

Le diagramme de classes est considéré comme le plus important de la modélisation orientée objet, il est le seul obligatoire lors d'une telle modélisation²⁰.

²⁰ Laurent AUDIBERT, op.cit., P.35

36

Alors que le diagramme de cas d'utilisation montre un système du point de vue des acteurs, le diagramme de classes en montre la structure interne. Il permet de fournir une représentation abstraite des objets du système qui vont interagir ensemble pour réaliser les cas d'utilisation.

Il s'agit d'une vue statique car on ne tient pas compte du facteur temporel dans le comportement du système. Le diagramme de classes modélise les concepts du domaine d'application ainsi que les concepts internes créés de toutes pièces dans le cadre de l'implémentation d'une application. Chaque langage de Programmation Orienté Objets donne un moyen spécifique d'implémenter le paradigme objet (pointeurs ou pas, héritage multiple ou pas, etc.), mais le diagramme de classes permet de modéliser les classes du système et leurs relations indépendamment d'un langage de programmation particulier.

III.5.1. MODELE DU DOMAINE

C'est un diagramme de classes dépourvu de ses méthodes. Il correspond à la sémantique des données sur lesquelles reposent tous les traitements du domaine.

Il s'agit simplement de créer une représentation visuelle des objets du monde réel dans un domaine donné.

Si l'on emploie la notation UML, il s'agit d'un ensemble de diagrammes de classes dans lesquels on fait figurer les éléments suivants :

· les classes conceptuelles ou les objets du domaine ;

· les associations entre classes conceptuelles ;

· les attributs des classes conceptuelles.

A partir des éléments décrits dans le chapitre précédent, nous pouvons établir notre modèle du domaine comme suite:

37

Figure 12 : Modèle du domaine

III.5.2. DIAGRAMME DE CLASSES PARTICIPANTES

Le diagramme de classes participantes est important puisqu'il effectue la jonction entre, d'une part, les cas d'utilisation, le modèle du domaine et la maquette IHM, et d'autre part, la jonction entre, les diagrammes de conception logiciel que sont : les diagrammes d'interaction et les diagrammes de classes de conception.

Il s'agit ici de diagrammes de classes UML qui décrivent, cas d'utilisation par cas d'utilisation, les trois principales classes d'analyse et leurs relations.

Le diagramme de classe participante modélise trois types de classes d'analyse : les dialogues, les contrôles et les entités.

? Les classes de dialogues : ces sont des classes qui possèdent les attributs et les méthodes ; ou les attributs représentent les champs de saisi ou les résultats et les opérations représentent les actions de l'utilisateur sur l'IHM.

? Les classes d'entités : elles ne posséderont que les attributs, les attributs qui sont des informations persistantes de l'application c'est-à-dire qu'elles survivent à l'exécution d'un cas d'utilisation particulier et qu'elles permettent à des données et des relations d'être stockées dans des sources de données.

? Les classes de contrôles : celles qui vont posséder des opérations, Ces opérations montrent la logique de l'application, ou les comportements du système informatique. Elles jouent le pont entre les classes de dialogues et les classe de contrôles.

38

a. Cas d'utilisation Consulter Archive

Figure 13: Diagramme de classe participante Consulter Archive

b. Cas d'utilisation Archiver document

Figure 14 : Diagramme de classe participante Archiver document

39

c. Cas d'utilisation Gérer Archives

Figure 15: Diagramme de classe participante Gérer Archive

III.6. CONCEPTION OBJET PRELIMINAIRE

Nous allons attribuer des responsabilités précises de comportement aux classes d'analyse en construisant une vue statique complétée sous forme de diagrammes de classes de conception préliminaire, indépendamment des choix technologiques que nous avons choisis.

La conception préliminaire nous a permis d'affiner et compléter les diagrammes de classes participantes obtenus précédemment pour :

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

· Ajouter des types aux attributs et aux paramètres et retours des opérations.

· Affiner les relations entre classes: associations (avec indication de navigabilité), généralisations ou dépendances.

III.6.1. DIAGRAMME D'INTERACTION

L'expression diagramme d'interactions englobe principalement deux types de diagrammes UML spécialisés, qui peuvent servir tous les deux à exprimer des interactions de messages similaires :

? les diagrammes de communication ? les diagrammes de séquence.

40

Pour le cas de notre travail nous ne représenterons qu'un certains nombres de diagramme d'interaction par acteur ou par scenario nominale.

? Diagramme d'interaction des cas d'utilisations du service de finance

Consulter archive

Figure 16 : Diagramme de séquence du scénario nominale recherche rapide

Figure 17: Diagramme de séquence scénario Erreur de recherche

41

Figure 18:Diagramme de séquence de la suite du scenario nominale de recherche rapide

? Diagramme d'interaction des cas d'utilisations de l'archiviste Archiver Document

Figure 19: Diagramme de séquence du scenario nominale Archivage avec succès

42

III.6.2. DIAGRAMME DE CLASSE DE CONCEPTION PRELIMINAIRE

a. Cas d'utilisation consulter archive

Figure 20 : Diagramme de classe de conception consulter archive

b. Cas d'utilisation Archiver document

Figure 21: Diagramme de classe de conception Archiver nouveau document

43

c. Cas d'utilisation Gérer Archive

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

III.7. MODELE PHYSIQUE DES DONNEES

Ce modèle nous permet d'avoir une idée sur les tables qui composent notre base. Evidemment il y'a des règles qui permettent de passer d'un modèle à un autre (voir Annexe 2).

Le MPD (Modèle physique de données) est un autre raffinement qui vise à produire un MLD pour un SGBD spécifique. Nous avons utilisé l'outil MySQL Workbench pour produire ce modèle.

44

Figure 23: Modèle physique des données

III.8. METHODES ET OUTILS POUR L'APPLICATION

Il est évident que les méthodes et les outils choisis pour concevoir et développer une application doivent être en fonction de l'environnement et du domaine d'application de celle-ci. Cela est bien explique par le génie logiciel.

Comme nous l'avons dit tout au-dessus, nous allons mettre l'accent sur les avantages de l'approche orienté objet, les architectures n-tiers. Tous ces concepts nous ont guidés dans la réalisation de notre travail et sur les méthodes et outils appliqués.

III.8.1. DEFINITION ET AVANTAGE DE L'APPROCHE ORIENTEE OBJET

Ce concept de programmation orienté objet (POO), est un paradigme de la programmation élaborer par les Norvégiens Ole-Johan et Kristen Nygaard au début des années 1960. Il consiste en la définition et l'interaction de brique logicielles appelées objets ; un objet représente un concept, une idée ou toute entité du monde physique, comme une voiture, une

45

personne ou encore une page d'un livre. Il possède une structure interne, et un comportement, et il sait interagir avec ses 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.

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é

²¹ http//:ww.wikipedia.org/approche oriente objet

46

est d'être fidèle à la réalisation finale. Elle est beaucoup plus complète avec ses différents diagrammes.

Pour en finir avec l'exploitabilité, MERISE est une méthode plus généraliste. Elle donne une vue globale de la solution sans autant rentrer dans les petits détails. Contrairement à UML qui est conçu pour l'implémentation objet avec ses différents détails et sa portabilité (s'adapte à n'importe quelle plateforme) elle est donc plus exploitable.

L'une ou l'autre présente des avantages et des inconvénients. Il est réservé au concepteur de choisir la méthode la mieux adaptée pour son cas. Si on cherche la précision et l'exploitabilité comme dans notre cas UML devance de loin MERISE. Tandis que, si c'est la clarté et l'accessibilité qui sont en question MERISE est préférable.

La conception de notre application mérite bien une grande précision et une exploitabilité maximale. C'est la raison pour laquelle on va retenir UML. Les différences entres les logiciels de modélisation UML sont infimes. N'empêche de mentionner quelques logiciels qui sont à notre connaissance : Modelio (open source), Visual Paradigme, PACESTAR Software.

La facilité dotée au dernier (PACESTAR) de pouvoir faire des diagrammes en UML 2.0, sa rapidité et sa flexibilité sont des facteurs qui nous ont permis de l'utilisé comme logiciel de modélisation.

III.8.3. CHOIX DES OUTILS DE DEVELOPPEMENT

Un parmi les avantages qui nous ont permis de choisir UML comme méthode de modélisation est l'orienté objet. Cette approche influe aussi sur le choix du langage à adopter on peut rajouter quelques-uns à savoir la portabilité, la facilité, la multidisciplinarité et pas mal d'autres comme la sécurité.

III.8.3.1 CHOIX DU LANGAGE DE PROGRAMMATION

Dans le souci de concevoir une application web, nous avons choisi PHP comme langage d'implémentation de notre application. Apparu en 1994, PHP est un langage de programmation libre principalement utilisé pour produire des pages Web dynamiques via un serveur http, mais pouvant fonctionner comme n'importe quel langage interprété de façon

47

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

²² www.wikipedia.org/langage PHP/ en ligne, consulter le 10 Juillet 2015

48

données relationnelles (SGBDR) et il est disponible sur une double licence GPL et propriétaire, il utilise le langage de requête SQL pour l'accès aux données.

Il existe un «Packs» tous près qui contient ces trois éléments tous réunis, c'est Wamp Server pour Windows bien qu'il en existe plusieurs, nous avons choisi celui-ci car il offre l'avantage d'être en français et a la possibilité d'être régulièrement mis à jour.

III.8.4. ARCHITECTURE DE L'APPLICATION

Dans les phases préliminaires du développement d'une application ou de la refonte d'un système d'information, la définition de l'architecture technique consiste à faire les choix de technologies et d'organisation de composants logiciels les plus adaptés aux besoins et aux contraintes de l'organisation d'accueil.

Ces choix sont ensuite relayés au sein de notre projet, guidant la conception et permettant la transformation d'un modèle fonctionnel en application performante et robuste.

? Présentation de l'architecture à 2 niveaux

L'architecture à deux niveaux (aussi appelée architecture 2-tiers, tiers signifiant étages en anglais) caractérise les systèmes clients/serveurs dans lesquels le client demande une ressource et le serveur la lui fournit directement. Cela signifie que le serveur ne fait pas appel à une autre application afin de fournir le service

Figure 24: Architecture 2 tiers (Source : www.google.com/images/deuxtiers.png)

49

? Présentation de l'architecture à 3 niveaux

Dans l'architecture à 3 niveaux (appelées architecture 3-tiers), il existe un niveau intermédiaire, c'est-à-dire que l'on a généralement une architecture partagée entre:

1. Le client: le demandeur de ressources

2. Le serveur d'application (appelé aussi middleware): le serveur chargé de fournir la ressource mais faisant appel à un autre serveur

3. Le serveur secondaire (généralement un serveur de base de données), fournissant un service au premier serveur.

Figure 25: Architecture 3 tiers (Source : www.google.com/images/troistiers.png)

Tout système d'information nécessite la réalisation de trois groupes de fonctions: le stockage des données, la logique applicative et la présentation. Ces trois parties sont indépendantes les unes des autres: on peut ainsi vouloir modifier la présentation sans modifier la logique applicative. La conception de chaque partie doit également être indépendante, toutefois la conception de la couche la plus basse est utilisée dans la couche d'au-dessus.

Ainsi la conception de la logique applicative se base sur le modèle de données, alors que la conception de la présentation dépend de la logique applicative.

? Architecture adoptée

Vis-à-vis de l'existant chez Bell Equipement: organisation, compétences, architecture du système d'information, nous avons choisi l'architecture 3 tiers car c'est une architecture:

50

· pérenne: applicable durant une très longue période de temps et accepter des changements technologiques ou fonctionnels tout en protégeant les investissements réalisés.

· modulaire: un élément peut être remplacé ou modifié sans devoir changer toute l'architecture.

· ouverte: elle doit permettre de construire ou de modifier une solution à partir de composants provenant de différents constructeurs.

L'application web conçu sera déployée sur une architecture 3-tiers. Cette architecture peut être décrite par la figure ci-dessous :

Figure 26: Architecture 3 tiers (Source : www.google.com/images/troisiers.png)

CONCLUSION

Dans ce chapitre nous avons fixé la structure globale de l'application par quelque diagramme UML, nous avons présenté les outils de travail que nous avons utilisé et nous avons enfin présenté l'architecture de notre application.

51

Chapitre IV. REALISATION ET DEPLOIMENT DE
L'APPLICATION DEVELOPPE

INTRODUCTION

Arrivé à ce stade nous pouvons nous estimer heureux, il ne reste qu'à commencer à écrire notre code en se basant sur les résultats obtenus des chapitres précédents. Mais cela se fait en suivant des critères. On doit passer par plusieurs jalons pour avoir un produit de bonne qualité.

Ainsi dans ce chapitre on va essayer de donner un bref aperçu sur le code de l'application développée, présenter les résultats de notre travail et finir par une petite conclusion.

IV.1. DIAGRAMME DE DEPLOIEMENT

Le diagramme de déploiement est un diagramme UML qui permet de représenté l'architecture physique l'architecture du système. Dans ce diagramme UML nous décriront la disposition physique des composants matérielle.

Figure 27: Diagramme de déploiement

52

IV.2 PRESENTATION DE L'APPLICATION DEVELOPPEE Page d'accueil

Figure 28: interface d'authentification

Figure 29: code PHP authentification

53

Cree Compte

Figure 30: interface de création de compte utilisateur

Archiver document

Figure 31:interface d'archivage de documents

54

Figure 32: code PHP classe d'entité Archive

Consulter archive

Figure 33: interface de consultation des documents

55

IV.3 ESTIMATION DU COUT GLOBALE

Libelle Quantité Explication Cout Source

Scanneur et Imprimante	1	Pour la numérisation des documents et l'impression des archives	350$
Serveur web	1	Pour faire tourner notre application	1130$	Internet
Câble UTP		10 mètre	5$	Best Buy
Connecteurs RJ45	10		2$	Best Buy
Système d'exploitation	1	Debian ; libre donc aucune dépense	0$
PC de bureau	3	Aucune dépense	0$
Main d'ouvre		30% de dépenses	446,1$
Imprévu		5% de dépenses	96,655$
Total			2029,755

CONCLUSION

A travers ce chapitre, nous avons présenté la réalisation de l'application en justifiant nos choix technologiques, en représentant quelques interfaces graphiques que nous avons jugé les plus importantes

56

CONCLUSION GENERALE

L'objectif de notre projet de fin de cycle était de concevoir et implémenter une application de gestion du processus d'archivage au sein de l'entreprise Bell Equipment.

Le point de départ de la réalisation de ce projet était une récolte des informations nécessaires pour dresser un état de l'existant, présenter un aperçu sur la problématique ainsi qu'une étude documentaire sur l'archivage.

Par la suite, nous nous sommes intéressés à l'analyse et la spécification des besoins qui nous a permis de distinguer les différents acteurs interagissant avec l'application visée. L'objectif de la partie suivante était la conception détaillée, dans laquelle nous avons fixé la structure globale de l'application et présenté les outils de travail que nous avons utilisé.

Le dernier volet de notre projet était la partie réalisation et déploiement de l'application qui a été consacrée à la présentation des interfaces les plus significatives de notre application.

L'apport de ce travail a été d'une importance très considérable, en effet, il nous a permis d'une part: de suivre une méthodologie de travail bien étudié, d'approfondir nos connaissances dans le monde de développement des applications et d'une autre part faciliter à l'entreprise en question, d'améliorer la gestion du processus d'archivage.

La réalisation d'un tel projet, nous a permis d'apprendre et de toucher du doigt une partie de divers aspects du métier de développeur et de celui du concepteur.

57

BIBLIOGRAPHIE

[1] CHABIN Marie-Anne. Archiver, et après ? Paris : Djakarta, 2007. 160p. ISBN 978-2-9528828-0-4.

[2] CHABIN Marie-Anne. Nouveau glossaire de l'archivage [en ligne]. Archive17,

2010 [consulté le 27 mai 2010]. Disponible sur :
http://www.archive17.fr/index.php?option=com performs&Itemid=55.

[3] CAYA Marcel. La théorie des trois âges en archivistique. En avons-nous toujours besoin ? [En ligne]. Paris : L'Ecole des chartes, 2004 [consulté le 22 juin 2010]. Disponible sur : http://elec.enc.sorbonne.fr/document72.html.

[4] Pascal ROQUES, UML pour le web, Ed. Eyrolles, Paris, 2008. 264p.

[5] Laurent AUDIBERT, Cours UML 2.0, IUT Paris, 2006, inédit

[6] Martin LOBO, Tour sur les processus métier, Paris, 2011, inédit

NETOGRAPHIE:

[1] http://fr.wikipedia.org

[2] http://fr.google.org

[3] http://code.google.cd/intl/fr-FR/webtoolkit/

[4] http://uml.free.fr/

58

ANNEXE

Annexe 1 : Aperçue du BPMN

Le BPMN permet une représentation standardisée du déroulement des processus et ce, autant pour les analystes d'affaires, qui produisent les premières ébauches, le personnel technique, qui met en oeuvre la solution technologique exécutant le processus et les utilisateurs d'affaires, qui gèrent et contrôlent les processus. Nous l'utiliserons donc dans sa version 2.0 pour présenter le processus métier dans notre travail.

V' Diagramme d'orchestration (processus privé): Un processus privé est un type de modélisation qui permet de représenter un processus spécifique à une organisation, un département ou un intervenant en précisant les sous-processus, les activités ou les tâches, les Événements et les Objets échangés et cela en adoptant le point de vue de celui qui les réalise.

V' Diagramme d'orchestration (processus public): c'est un type de modélisation qui permet de représenter les interactions qui relient un processus privé à plusieurs participants externes (qui peuvent être un individu, un département ou un autre processus) en définissant les flux de messages, leur séquence et leur ordre.

V' Le diagramme de collaboration : c'est un diagramme qui permet de représenter les échanges et les interactions qui se nouent entre deux ou plusieurs unités d'affaire représenté par des bassins. Les bassins sont définis comme étant des participants de cette collaboration. Les messages échangés entre les participants du diagramme de collaboration sont représentés à l'aide du symbole flux de message (symbole qui permet de connecter les bassins entre eux ou les objets qu'on retrouve à l'intérieur de ces bassins).

Annexe 2 : Règles de passage du modèle conceptuel au modèle physique (MCD MLD)

· Table et clé primaire : Toute classe ou entité (=objet de gestion) est transformée en table. Les attributs de l'entité deviennent les attributs de la table. L'identifiant de la classe/entité devient la clé primaire de la table

· Relation binaire (...,*) - (...,1) : La clé primaire de l'entité reliée par (..., 1) devient clé étrangère de l'entité reliée par (...,*).

· Relation binaire (0.1) - (1.1) : La clé primaire de l'entité reliée par (0, 1) devient clé étrangère de l'entité reliée par (1, 1).

59

? Relation binaire et ternaire (...,*) - (...,*) : On crée une table supplémentaire ayant comme clé primaire une clé composée des clés primaires des deux entités. Lorsque la relation contient elle-même des propriétés, celles-ci deviennent attributs de la table supplémentaire.

Annexe 3 : Ingénierie et retro-ingénierie

Aujourd'hui les concepts ingénierie et rétro-ingénierie, jouent un rôle important en informatique plus particulièrement dans le domaine de génie logiciel. Les développeurs de logiciels ne peuvent pas s'empêcher de profiter d'un tel marché.

Les logiciels répondants à ces deux concepts commencent à inonder le marché. Le principe de base est simple : en ayant une conception on peut retrouver le corps du programme à développer (ingénierie), et inversement on peut trouver la conception (retro-ingénierie). En voici ce qu'on peut lire dans Wikipédia :

La rétro-ingénierie (traduction littérale de l'anglais Reverse engineering), également appelée rétro-conception, est l'activité qui consiste à étudier un objet pour en déterminer le fonctionnement. L'objectif peut être par exemple de créer un objet différent avec des fonctionnalités identiques à l'objet de départ sans contrefaire de brevet. Ou encore de modifier le comportement d'un objet dont on ne connaît pas explicitement le fonctionnement.

La démarche utilisée peut être celle de l'étude d'une boîte noire : on isole l'objet à étudier, on détermine les entrées et les sorties actives. On essaie ensuite de déterminer la réponse du système en fonction du signal d'entrée. Mais il est également possible de démonter le système jusqu'à un certain point pour en analyser les constituants.

60

Table des matières

EPIGRAPHE

DEDICACE II

REMERCIEMENTS III

LISTE DES FIGURES IV

INTRODUCTION 1

PRESENTATION DU SUJET 1

CHOIX ET INTERET 2

ETAT DE LA QUESTION 2

PROBLEMATIQUE ET HYPOTHESE 3

PROBLEMATIQUE 3

HYPOTHESE 4

METHODE ET TECHNIQUE 4

METHODES 4

TECHNIQUES 5

DELIMITATION DU TRAVAIL 5

SOMMAIRE 6

Chapitre I. CONSIDERATION THEORIQUE ET CONCEPTUELLE 7

INTRODUCTION 7

I.1. THEORIE SUR L'ARCHIVAGE 7

I.1.1. DEFINITION DES CONCEPTS 7

I.1.2. PRESENTATION GENERALE 7

I.1.2.2 ARCHIVAGE 8

I.1.2.3 PROCESSUS D'ARCHIVAGE 9

I.1.2.4 PRINCIPES DE GESTION DES ARCHIVES 12

I.2. TYPES D'ARCHIVES 13

I.3. ARCHIVAGE PAPIER vs ARCHIVAGE ELECTRONIQUE 14

I.4. PLACE DE L'ARCHIVAGE DANS L'ENTREPRISE 17

CONCLUSION 17

Chapitre II. PRESENTATION DU CADRE D'ETUDE ET MODELISATION DU METIER 18

INTRODUCTION 18

II.1. PRESENTATION DU CADRE D'ETUDE 18

II.1.1. PRESENTATION DE BELL EQUIPEMENT 18

II.1.2. LOCALISATION GEOGRAPHIQUE 19

II.1.3. HISTORIQUE 19

II.1.4. BRANCHE OUVERTE DE BELL EQUIPMENT SUR LE TERRITOIRE NATIONAL 19

II.2. STRUCTURE FONCTIONNELLE 19

II.3. ANALYSE DE L'EXISTANT 20

II.3.1 DESCRIPTION TEXTUELLE DE L'EXISTANT 20

61

II.3.2. ANALYSE DES LOTS D'INFORMATIONS 21

II.3.3. DIAGRAMME DE CONTEXTE 21

II.3.4. MODELISATION DU METIER 22

II.4. CRITIQUE DE L'EXISTANT 24

II.5. APPROCHE DE SOLUTION 24

CONCLUSION 24

Chapitre III. CONCEPTION 26

INTRODUCTION 26

III.1. PRESENTATION DE LA METHODE UTILISEE 26

III.2. CAPTURE DES BESOINS 27

III.3. DIAGRAMME DE CAS D'UTILISATION 28

III.4. DIAGRAMMES DE SEQUENCE SYSTEME 32

III.5. DIAGRAMMES DE CLASSES 35

III.5.1. MODELE DU DOMAINE 36

III.5.2. DIAGRAMME DE CLASSES PARTICIPANTES 37

III.6. CONCEPTION OBJET PRELIMINAIRE 39

III.6.1. DIAGRAMME D'INTERACTION 39

III.6.2. DIAGRAMME DE CLASSE DE CONCEPTION PRELIMINAIRE 42

III.7. MODELE PHYSIQUE DES DONNEES 43

III.8. METHODES ET OUTILS POUR L'APPLICATION 44

III.8.1. DEFINITION ET AVANTAGE DE L'APPROCHE ORIENTEE OBJET 44

III.8.2. CHOIX DU PRINCIPE ET DU LOGICIEL DE MODELISATION 45

III.8.3. CHOIX DES OUTILS DE DEVELOPPEMENT 46

III.8.4. ARCHITECTURE DE L'APPLICATION 48

CONCLUSION 50

Chapitre IV. REALISATION ET DEPLOIMENT DE L'APPLICATION DEVELOPPE 51

INTRODUCTION 51

IV.1. DIAGRAMME DE DEPLOIEMENT 51

IV.2 PRESENTATION DE L'APPLICATION DEVELOPPEE 52

IV.3 ESTIMATION DU COUT GLOBALE 55

CONCLUSION 55

CONCLUSION GENERALE 56

BIBLIOGRAPHIE : 57

NETOGRAPHIE: 57

ANNEXE 58