Rapport de Stage d’Immersion en Entreprise

4.4 Consulter Document

. . . . . . . . . . . . 37

4.5 Saisie/Mise `a jour Document . . . . . . . . 38

. . . . . . . . . . . 39

4.6 Enregistrer Document

4.7 Echanger Document

. . . . . . . . . . . . 41

4.8 Supprimer Document . . . . . . . . . . . . 42

. . . . . . . . . 42

4.9 Chronogramme du travail

v

Introduction Générale

Une organisation est un ensemble d’´el´ements en inter-

action ayant pour objectif l’atteinte des buts bien pr´ecis

tout en facilitant la circulation des flux.

Pour ce faire, elle doit mettre en oeuvre toutes les syner-

gies existantes et elle doit avoir un Syst`eme d’Informa-

tion qui est l’ensemble des moyens humains, mat´eriels et

logiciels capables de produire, de traiter ,de g´erer et de

faire communiquer l’information de mani`ere efficace.

Devant ce grand flux d’information `a g´erer, l’organisa-

tion rencontre plusieurs probl`emes qui peuvent obstruer

son fonctionnement.

Afin de palier a ces problemes, maitriser la Gestion des

Documents devrait ˆetre le point de d´epart de la construc-

tion d’un Syst`eme d’Informations bien structur´e.

Actuellement, l’automatisation de la Gestion des Do-

cuments est devenue indispensable pour toute organisa-

tion. Elle permet non seulement l’am´elioration du d´erou-

lement des services mais aussi une meilleure interaction

entre eux.

1

Parmi les proc´ed´es d’automatisation d’un Syst`eme d’In-

formations, nous citons la Gestion Electronique des Do-

cuments qui vise la num´erisation des documents en com-

primant le volume papier.

Dans ce cadre que se d´eroule notre projet de stage

d’immersion dans une entreprise qui consiste `a conce-

voir et impl´ementer une application de gestion de docu-

ments qui doit g´erer les processus m´etier de l’entreprise

NeoTech-SARL.

Le pr´esent rapport r´esume notre travail. Il est compos´e

de quatre chapitres divis´es comme suit :

Dans le premier chapitre, nous allons pr´esenter le cadre

du projet et nous allons faire une ´etude de l’existant.

Le deuxi`eme chapitre englobera les besoins fonctionnels

et non fonctionnels des utilisateurs du futur syst`eme.

Le troisi`eme chapitre sera consacr´e pour la description

de la conception globale ainsi que la conception d´etaill´ee

du futur syst`eme.

Finalement, dans le dernier chapitre nous allons pr´esen-

ter la r´ealisation a laquelle nous avons aboutit a travers

des imprim´es ´ecran.

2

Cadre du stage

Ce m´emoire s’inscrit dans le cadre du stage d’immer-

sion dans une entreprise pour les ´el`eves ing´enieurs de

l’Ecole Nationale des Sciences de l’Informatique. Le tra-

vail est r´ealis´e au sein de la soci´et´e NeoTech durant la

p´eriode de 01 Juillet 2010 au 12 Aoˆut 2010. Le projet a

´et´e encadr´e par Mr M’Hamed Essersi.

Pr´esentation de l’organisme d’acceuil

NeoTech est une entreprise jeune et dynamique qui

op`ere dans le secteur des nouvelles technologies. Elle est

fond´ee en 2007 et son local se situe `a 10 rue El Banafsej

La Corniche Bizerte.

Pr´esentation du sujet

Notre sujet consiste `a concevoir et d´evelopper une ap-

plication qui automatise la gestion des diff´erents docu-

ments circulant au sein de l’entreprise NeoTech comme

elle doit g´erer ses processus m´etiers.

3

Etat de l’Art

1

Avant d’entamer l’´etude approfondie du projet, nous

nous proposons de pr´esenter l’´etat actuel de la gestion

des documents au sein de NeoTech. Ensuite, nous allons

´evaluer ce syst`eme.

Ce pr´esent chapitre renfermera aussi une vue d’ensemble

sur la Gestion Electronique des Documents ainsi que ses

apports pour les organisations.

1.1 Etude Pr´ealable

La soci´et´e NeoTech est une soci´et´e commerciale dont

l’activit´e est informatique. Elle est sp´ecialis´ee dans la

vente et la location des mat´eriels informatiques et de t´e-

l´ecommunication.

Dans cette section, nous allons d´ecrire l’´etat actuel du

traitement documentaire au sein de NeoTech et nous al-

lons ´enoncer les problemes qui ont incit´e a la r´ealisation

de ce projet.

4

1.1.1 Etude de l’existant

Un document est un ´el´ement vivant de l’entreprise. Il

doit pouvoir ˆetre enrichi, diffus´e et partag´e afin de per-

mettre une meilleure communication entre les diff´erents

services de l’entreprise.

Actuellement, les traitements documentaires existants

sont principalement ” Tout papier ” entrainant un volume

papier en croissance exponentielle.

Au sein de l’entreprise NeoTech-SARL, la gestion des

documents demeure manuelle. En effet, cette soci´et´e ac-

quiert toutes formes de documentation sous forme de pa-

pier.

Ensuite, ils sont tri´es et trait´es manuellement. Pour l’´etape

de classification, elle passe par l’indexation qui consiste `a

l’attribution manuelle par les employ´es des marques dis-

tinctives `a chaque document.

Ces marques renseignent avec pertinence sur la nature

des documents et facilitent ainsi leurs recherches.

Comme la communication entre les services s’av`ere

fondamentale afin de bien mener les tˆaches, ces docu-

ments doivent ˆetre diffus´es. Au sein d’un mˆeme service,

les documents sont transmis de main en main alors qu’entre

les services, un duplicata est envoy´e.

Finalement, pour le stockage, les documents sont archi-

v´es selon des crit`eres bien pr´ecis facilitant toute consulta-

tion ult´erieure. C’est-`a-dire, il reste possible de les consul-

5

ter par type, par nature, par date de modification...

1.1.2 Critique de l’existant

Etant donn´e que NeoTech-SARL est une entreprise qui

envoie et re¸coit beaucoup de documents. Les conditions

actuelles de leurs gestion causent alors des probl`emes qui

se r´esument en :

– Lenteur de la communication de l’information entre

les services : les agents de chaque service ex´ecutent

leurs tˆaches de maniere d´ependante, c’est-a-dire les

tˆaches sont r´ealis´ees les unes apr`es les autres. Entre

les services, il y a une lenteur de diffusion des docu-

ments qui engendre une lenteur dans la r´ealisation

des traitements.

– Difficult´e de la recherche des documents : mˆeme si

les documents sont index´es, une recherche manuelle

dans l’archive reste encore non agr´eable et fatigante.

– Perte de temps et par la suite d’argent qui est due

`a la difficult´e de la recherche des documents.

– Perte des documents qui sont parfois importants :

un grand volume papier augmente la probabilit´e de

la perte des documents.

– La ressaisie des montants pour calculer les d´ecla-

rations et le TVA, en se r´ef´erant `a plusieurs docu-

ments, augmente les risques d’erreurs et engendre la

perte du temps.

6

1.2 Solution Propos´ee

A la suite de ces constatations, il parait clair qu’il faut

se pencher des a pr´esent sur le sujet et de commencer

a r´ealiser un systeme qui permet l’automatisation de la

gestion des documents.

Dans cette section, nous allons d´etailler la solution que

nous allons concevoir.

1.2.1 La Gestion Electronique des Documents

La Gestion Electronique des Documents est une solu-

tion qui s’impose a toute organisation ou entreprise des

lors que se posent des probl´ematiques d’optimisation des

informations.

La mise en place de la Gestion Electronique des Docu-

ments, qui recouvre l’ensemble des outils, des techniques

et des logiciels permettant le traitement et l’organisation

des documents qui p´enetrent, sortent et circulent a l’in-

t´erieur d’une organisation d’une mani`ere informatis´ee,

am´eliore les processus organisationnels existants.

Les techniques utilis´ees visent la d´emat´erialisation, le

classement, la gestion et le stockage des documents `a tra-

vers leurs num´erisations visant la r´eduction du ” Volume

papier ”.

Elles assurent aussi l’int´egration des documents, leurs

7

identifications, leurs archivages, leurs restitutions, leurs

administrations et leurs s´ecurit´es et facilitent par suite

leurs recherches, leurs consultations et leurs ´echanges.

La Gestion Electronique des Documents est cat´egori-

s´ee en diff´erents domaines. Ainsi ce concept est subdivis´e

en :

– GED Administrative : d´edi´ee au classement des do-

cuments ´electroniques administratifs.

– GED Bureautique : d´edi´ee `a la production et au par-

tage de documents dans un groupe de travail.

– GED Documentaire : d´edi´ee `a l’indexation des res-

sources documentaires.

– GED Technique : d´edi´ee `a la gestion des documents

techniques, propre `a un m´etier.

Il existe quatre ´etapes majeures dans la Gestion Elec-

tronique des Documents :[N 4]

– Acquisition des documents : qui est l’int´egration des

documents papiers et ´electroniques existants.

– Classement des documents : qui passe par l’indexa-

tion selon des crit`eres bien d´etermin´es en vue de fa-

ciliter leurs exploitations.

– Stockage des documents : c’est la sauvegarde et l’ar-

8

chivage des documents d’une mani`ere hi´erarchique

en fonction du contenu.

– Diffusion des documents : c’est l’´echange et le par-

tage des documents entre les diff´erents agents de

l’entreprise.

1.2.2 Les Apports de la GED

La Gestion Electronique des Documents est devenue

une tendance des organisations pour ses apports ind´e-

niables sur le plan organisationnel ainsi que sur le plan

du profit. En effet, elle assure a l’entreprise un Systeme

d’Informations plus performant et plus efficace en par-

venant `a constituer un r´ef´erentiel de l’ensemble de ses

documents et en accordant la possibilit´e de gestion de

leurs cycles de vie, de leurs cr´eations `a leurs destruc-

tions.

Les avantages induits par un syst`eme GED se r´esument

en :

– L’organisation de l’information

La GED permet de limiter la masse de ” papiers”,

tout en garantissant l’homog´en´eit´e du support et en

standardisant les documents internes. En outre, les

informations sont class´ees dans un plan de classe-

ment adapt´e aux besoins sp´ecifiques de l’organisa-

tion.

– Gestion du cycle de vie des documents

Depuis la cr´eation jusqu’`a l’archivage, la GED prend

en charge l’ensemble des processus documentaire, en

garantissant au passage, la tra¸cabilit´e, le contrˆole et

9

les relations entre documents, ce qui optimise la re-

cherche et la mise `a jour des informations.

– Centralisation et partage des documents

Grˆace `a la GED, il est possible de centraliser et

de partager les documents, les informations et les

connaissances, a partir d’une interface d’acces, of-

frant des moyens de recherche garantissant une ac-

quisition rapide et pertinente de l’information.

– S´ecurisation de l’information

En int´egrant une gestion pointue des diff´erents ni-

veaux d’habilitation sur la consultation et la diffu-

sion des informations, la GED permet de s´ecuriser

l’acc`es aux documents. Ainsi, une information ne de-

vient consultable que par les ” ayant droit ”.

Conclusion

Dans ce chapitre, nous avons men´e une ´etude pr´ealable

qui nous a permis de comprendre le travail demand´e.

Nous avons aussi pr´esent´e la solution dont nous sp´ecifie-

rons les objectifs et nous ´eclaircissons les diff´erents be-

soins dans le chapitre suivant.

10

Spécification et Analyse

des besoins

2

Ce chapitre consiste en une ´etape analytique dans la-

quelle nous allons recenser et factoriser les besoins des

utilisateurs de l’application. Ceci est fortement li´e `a l’´etude

pr´ealable men´ee au cours du premier chapitre.

Pour ce faire, cette phase doit r´epondre aux questions

suivantes :

– Que doit offrir le syst`eme pour les utilisateurs ?

– Quels sont les besoins fonctionnels du syst`eme ?

– Quelles sont les contraintes qui doivent ˆetre prises

en consid´eration ?

2.1 Sp´ecification

La solution `a d´evelopper doit prendre en consid´eration

des besoins fonctionnels et non fonctionnels. Dans ce qui

suit, nous allons recenser ces diff´erents besoins.

2.1.1 Sp´ecification des besoins fonctionnels

Notre application doit fournir aux diff´erents utilisa-

teurs tels que le personnel et le g´erant de NeoTech les

11

fonctionnalit´es que nous allons sp´ecifier dans cette sec-

tion.

Le syst`eme de Gestion des Documents doit :

– Permettre `a l’utilisateur de cr´eer des documents, de

les consulter et de les mettre `a jour.

– Stocker et archiver toutes formes de documentation

de tailles connues de mani`ere persistante ou tempo-

raire.

– Echanger les documents entre les diff´erents agents

d’un mˆeme service et entre les services.

– Automatiser le calcul de la TVA tout en respectant

les pourcentages et les lois fiscales.

2.1.2 Sp´ecification des besoins non fonctionnels

Cette application doit satisfaire une s´erie des besoins

non fonctionnels tels que :

– Interface Homme Machine conviviale et agr´eable.

– L’application peut tourner sur r´eseau local de l’en-

treprise ou via l’internet.

– L’application peut ˆetre ´etendue `a d’autres fonction-

nalit´es.

– Optimiser le temps de r´eponse.

12

2.2 Analyse des Besoins

Pour sp´ecifier de fa¸con formelle les besoins requis par

l’application, nous avons opt´e pour la r´ealisation du dia-

gramme des cas d’utilisation pour avoir une meilleure

compr´ehension des besoins.

2.2.1 Identification des acteurs

Un acteur est un ´el´ement externe, qui peut ˆetre un

homme, une machine, ou un autre syst`eme, qui interagit

avec le syst`eme pour avoir un r´esultat. Il prend des d´e-

cisions et des initiatives.

Dans le cas de notre application, les acteurs que nous

identifions sont : l’administrateur(le gestionnaire ou le

g´erant) qui a des tˆaches de contrˆole, l’employ´e qui a des

tˆaches d’ajout, de saisie, d’impression et d’envoie des do-

cuments. Finalement, le comptable qui v´erifie les calculs

des d´eclarations.

2.2.2 Mod`ele de cas d’utilisation

Le mod`ele des cas d’utilisation d´efinit les activit´es at-

tendues des diff´erents utilisateurs par rapport `a l’appli-

cation. Il doit r´epondre aux questions suivantes :

– Quels sont les tˆaches principales r´ealis´ees par les ac-

teurs ?

– Quels sont les informations manipul´ees par les ac-

teurs ?

13

Le diagramme des cas d’utilisation contient les acteurs,

les cas d’utilisation c’est-`a-dire les services offertes par le

syst`eme et les applications.

Un cas d’utilisation est l’ensemble des actions logique-

ment ordonn´ees repr´esentant les ´echanges entre les ac-

teurs et le syst`eme.

La figure ci-dessous FIGURE 2.1 illustre le diagramme

de cas d’utilisation de notre application.

Figure 2.1 – Diagramme de cas d’utilisation

2.2.3 Les Sc´enarios

Dans cette section nous allons d´etailler quelques cas

d’utilisation par des diagrammes de s´equence.

Pour tous les sc´enarios de cas d’utilisation, tout utilisa-

teur doit s’authentifier en indiquant un nom d’utilisateur

14

et un mot de passe.

Figure 2.2 – Phase d’Authentification

2.2.3.1 Ajout Document

Lors de la phase de cr´eation, l’utilisateur remplit les

champs propres `a un document et des listes de choix de

type, de destination lui seront fournies pour lui faciliter

cette tˆache.

Le diagramme ci dessous FIGURE 2.3 pr´esente les

´etapes n´ecessaires pour la cr´eation d’un nouveau docu-

ment.

15

Figure 2.3 – Diagramme de s´equence ”Ajout document”

2.2.3.2 Mise `a jour Document

La mise `a jour des documents est une fonctionnalit´e

restreinte `a l’administrateur. Il est le seul qui peut mo-

difier les champs d’un document valid´e.

16

Figure 2.4 – Diagramme de s´equence ”Mise `a Jour document”

2.2.3.3 Consultation Document

Le diagramme de s´equence ci dessous FIGURE 2.5

pr´esente les ´etapes n´ecessaires pour un utilisateur pour

consulter un document.

Pour r´eussir cette tˆache, le document doit ˆetre existant.

17

Figure 2.5 – Diagramme de s´equence ”Consulter document”

2.2.3.4 Echanger Document

Le succ`es de cette tˆache exige que l’utilisateur soit

connect´e sur le serveur local de l’entreprise. Pour cela,

il doit avoir un compte valide ainsi que son destinataire.

Les causes d’´echec sont, soit le nom d’utilisateur ou

le mot de passe indiqu´e sont erron´es, soit le compte du

destinataire est invalide.

Le diagramme ci-dessous FIGURE 2.6 repr´esente le cas

de succ`es.

18

Figure 2.6 – Diagramme de s´equence ”Echanger document”

2.2.3.5 Suppression Document

Pour la phase de suppression, la pr´eexistence du do-

cument s’av`ere fondamentale. En outre, l’utilisateur doit

ˆetre un administrateur.

Si l’utilisateur souhaitant faire la suppression n’est pas

l’administrateur, le syst`eme affichera un message d’er-

reur.

Le diagramme ci-dessous FIGURE 2.7 repr´esente le cas

de r´eussite de cette tˆache.

19

Figure 2.7 – Diagramme de s´equence ”Supprimer Document”

2.2.3.6 Calcul TVA

Cette fonctionnalit´e prend en compte plusieurs contraintes :

les factures s´electionn´ees doivent ˆetre non d´eclar´ees au-

paravant ainsi que les certificats de retenu impˆot. Le cal-

cul doit ˆetre conforme aux pourcentages exig´es par la

finance.

Le diagramme ci-dessous FIGURE 2.8 repr´esente le cas

de r´eussite de calcul de TVA.

20

Figure 2.8 – Diagramme de s´equence ”Calculer TVA”

2.3 Diagramme d’Activit´e

Pour d´ecrire le comportement g´en´erique d’un cas d’uti-

lisation ou d´etailler une op´eration complexe on utilise le

diagramme d’activit´e. Ce dernier permet aussi de mod´e-

liser la dynamique d’une tˆache[4].

La figure ci-dessous repr´esente le diagramme d’activit´e

propre `a notre application.

21

Figure 2.9 – Diagramme d’Activit´e

Conclusion

Dans ce chapitre, nous avons essay´e de sp´ecifier les

besoins de notre application afin de d´elimiter le cadre de

notre travail et de pr´eparer un terrain favorable pour la

prochaine phase qui est la phase de conception.

Cette ´etape aura pour but global de concevoir clairement

l’architecture de notre solution.

22

Conception

3

La phase d’analyse et de conception a pour objectif de

permettre la formalisation des ´etapes pr´eliminaires du

d´eveloppement d’un syst`eme. Ainsi, ce dernier devient

plus fid`ele aux besoins du client.

La phase de conception permet de d´ecrire la mani`ere

du fonctionnement d´esir´e du syst`eme afin d’en faciliter

la r´ealisation et la maintenance.

Pour ce faire, nous pr´esentons dans une premi`ere partie

une conception globale de notre application ensuite dans

la deuxi`eme partie nous d´etaillerons la conception.

3.1 Conception Globale

Notre application consiste `a concevoir et d´evelopper

un systeme qui r´ealise la gestion des documents des leurs

arriv´ee jusqu’`a leurs archivage. Afin de mieux r´ealiser la

gestion des documents, nous devons concevoir toutes les

´etapes par lesquelles ils passent.

Ci-dessous une figure r´esumant la vue globale de notre

23

application.

Figure 3.1 – Vue globale de la solution

Le syst`eme de gestion des documents doit r´ealiser toutes

les ´etapes pr´esent´ees par la figure ci-dessus.

Un document entrant doit ˆetre enregistr´e dans la base

des documents re¸cus, l’enregistrement se fait par identi-

fication du document c’est-`a-dire l’attribution automa-

tique d’un identifiant unique et la saisie des champs n´e-

cessaires ensuite le scanne du document est n´ecessaire

pour avoir toujours un duplicata du document r´eel.

24

Apr`es l’enregistrement, le document peut ˆetre imprim´e,

distribu´e entre les services concern´es ou bien il servira

pour effectuer les d´eclarations mensuelles de l’entreprise

s’il s’agit d’une facture ou d’un certificat de retenu im-

pˆots.

Pour envoyer un document `a un destinataire ext´erieur

`a l’entreprise NeoTech-SARL, l’employ´e doit cr´eer un

nouveau document selon les besoins c’est-`a-dire choisir

le type d´esir´e, ensuite il fait la saisie des champs n´eces-

saires avec l’identification du document. Une fois la saisie

est termin´ee, le document est enregistr´e dans la base des

documents ´emis, il est ensuite imprim´e pour ˆetre finale-

ment envoy´ee au destinataire.

Notre application doit, alors, prendre en consid´eration

ces diff´erentes ´etapes. Elle doit aussi d´etailler les diff´e-

rents types des documents que l’entreprise utilise afin de

faciliter le travail des employ´es.

Dans ce qui suit, nous allons entamer la conception

d´etaill´ee.

3.2 Conception D´etaill´ee

Dans cette section, nous d´ecrirons plus en d´etails notre

application. Nous allons pr´esenter le diagramme de classes

qui r´esume la structure g´en´erale du syst`eme.

25

3.2.1 Les Contraintes

Lors de la saisie des champs d’un nouveau document,

il existe plusieurs contraintes qui doivent ˆetre v´erifi´ees.

Afin d’en tenir compte, lors de l’impl´ementation, nous

devons ajouter des contrˆoles qui se r´esument en :

– L’ID de tout type de documents doit ˆetre unique.

– Lorsqu’il s’agit d’un document re¸cu, le champ Desti-

nation est automatiquement rempli par NeoTech et

en cas inverse c’est-`a-dire le document est ´emis, le

champ Source est automatiquement rempli par Neo-

Tech.

– Comme les types des documents circulant au sein de

NeoTech sont bien d´etermin´es, le champ Type dans

un document est rempli `a partir d’une liste fournie

et qui est mise `a jour en cas de saisie d’un nouveau

type.

– Pour les champs Source et Destination d’un docu-

ment, leur remplissage ob´eit aux mˆemes conditions

que celle du champ Type.

– Les deux dates, date de remise au comptable et date

de d´eclaration, doivent ˆetre post´erieures `a celle du

document.

– Il y a aussi des champs qui sont r´ecup´er´es `a partir

d’autres champs `a noter les champs Jour, Mois et

Ann´ee qui seront d´eduis automatiquement `a partir

du champ Date.

26

– Il existe des champs dont le remplissage est condi-

tionn´e par une certaine valeur des champs pr´ec´e-

dents. Pour s’assurer que l’utilisateur saisie ces champs

lorsque la condition est satisfaite, nous allons utiliser

des boites de dialogues jouant le rˆole de rappel.

Toutes ces contraintes visent `a r´eduire la saisie afin de

minimiser les erreurs.

3.2.2 Diagramme de Classes

La figure ci-dessous FIGURE 3.2 repr´esente le dia-

gramme de classes qui traduit les relations entre les dif-

f´erentes classes.

27

Figure 3.2 – Diagramme de classes

Remarque : Dans Domino Designer, chaque classe de-

vient un document.

La classe G´en´eral est une classe m`ere qui regroupe

tous les attributs communs a tous les documents a par-

tir de laquelle h´eritent deux classes Objet r`eglement et

Moyen r`eglement.

28

La classe Objet r`eglement repr´esente les redevances et les

recettes de l’entreprise qui sont r´egl´ees par les Moyen r`eglement.

En effet, les classes Facture, Note honoraire et Quittance

sont des sous classes de Objet r`eglement mais seule la

classe Facture qui contient la TVA.

La classe Facture contient plusieurs ligne de facture dont

chacune fait r´ef´erence `a un article.

Il existe aussi une forme particuli`ere de quittance qui h´e-

rite de Facture qui est Quittance douane car elle contient

le champ TVA.

La classe D´eclaration douane qui fait r´ef´erence `a plu-

sieurs ligne de facture en incluant des param`etres comme

le taux et le droit de douane.

Pour les classes Ch`eque, Traite et Virement, elles sont

des Moyen reglement, mais la classe Traite possede une

date d’´ech´eance.

La classe Bulletin versement ch`eque traduit les op´era-

tions de versement des diff´erents cheques a la banque.

La classe Relev´e compte regroupe toutes les op´erations

effectu´ees dans le compte de l’entreprise pendant un mois.

Elle comporte les r´ef´erences des Ch`eque.

La classe D´eclaration comporte les deux m´ethodes cal-

culer TVA() et Calculer impots() qui traduit les d´ecla-

rations mensuelles de l’entreprise sur ses b´en´efices et sur

son personnel. Les d´eclarations effectu´ees se basent sur

les classes Certificat retenu impot qui calcule les impˆots

sur les soci´et´es et Facture qui fournit le montant de TVA

`a d´eclarer.

La classe Domiciliation contient les paiements des frais

de douane pour une exp´edition.

Dans un document domiciliation, le montant doit ˆetre

en devise, le fournisseur et le taux de change doivent

ˆetre les mˆeme c’est pour cela que nous avons utilis´e les

29

op´erations Verif meme frns(), Verif mt devise() et Ve-

rif mem tx chg().

Conclusion

A travers ce chapitre, nous avons pr´esent´e notre concep-

tion de l’application. Nous avons fourni, dans un premier

lieu, une conception globale `a travers un sch´ema g´en´e-

ral d´ecrivant le parcours d’un document. Ensuite, nous

avons pr´esent´e la conception d´etaill´ee de l’application `a

travers le diagramme de classes. A pr´esent, nous sommes

capables d’entamer la partie r´ealisation.

30

Réalisation

4

La phase de r´ealisation consiste a construire le systeme

en se r´ef´erant aux autres phases et principalement `a la

phase de conception d´etaill´ee auparavant.

Cette phase met l’accent sur la gestion des ressources et

le contrˆole des op´erations pour optimiser les coˆuts, les

d´elais et la qualit´e.

En tenant compte des besoins fix´es et des choix concep-

tuels effectu´es, nous consacrons ce chapitre `a la descrip-

tion du travail r´ealis´e.

Nous commen¸cons par d´ecrire l’environnement mat´eriel

et logiciel sur lequel notre application est r´ealis´ee. En-

suite, nous pr´esenterons quelques captures d’´ecran de

l’Interface Homme/Machine traduisant l’utilisation de notre

application.

4.1 Environnement et outils de travail

Cette partie est consacr´ee `a la pr´esentation de l’envi-

ronnement mat´eriel et logiciel utilis´e pour la r´ealisation

de notre application.

31

4.1.1 Environnement mat´eriel

Le tableau ci-dessous illustre la configuration mat´e-

rielle utilis´ee dans notre projet.

4.1.2 Environnement logiciel

Du point de vue logiciel, nous avons travaill´e sur une

plateforme Windows XP sur laquelle sont install´es les

outils n´ecessaires `a la r´ealisation de notre travail :

– Syst`eme d’exploitation : Microsoft Windows XP pro-

fessionnel Version 2002

– Environnement de d´eveloppement : Domino Desi-

gner 8.5, Lotus Notes 8.5

– Outils de mod´elisation UML : ArgoUML

– L’outil de traitement de textes : Latex Comme lan-

gage de programmation et TeXnicCenter comme Edi-

teur latex pour la r´edaction du rapport.

Comme nous utilisons le logiciel Lotus Notes pour la

premi`ere fois, nous allons consacrer une section dans la-

quelle nous allons le pr´esenter et nous d´etaillerons les

32

principes de base du langage utilis´e Lotus Script.

4.1.2.1 Lotus Notes

Lotus Notes est un logiciel de travail collaboratif, uti-

lis´e dans des entreprises et des administrations pour de

nombreuses applications y compris les e-mails, calendrier,

messagerie instantan´ee, navigation sur le Web ainsi que

pour une vari´et´e d’applications riches en fonctionnalit´es

personnalis´ee.

Il peut ˆetre utilis´e pour acc´eder `a la fois en local et aussi

aux applications bas´ees sur serveur.

Il permet de g´erer les projets et les ´echanges d’informa-

tions autour d’une base commune.

Ce logiciel permet aussi aux utilisateurs de rationaliser

leur fa¸con de travailler. Il est facile a utiliser et il aide a

faire le travail plus rapidement.

33

Figure 4.1 – Interface de Lotus Notes

Il supporte plusieurs langages : Java, Java Script, Lo-

tus Script, Lotus Formula language

Mais le langage le plus utilis´e dans la programmation des

bases Notes de domino est : Lotus Script.

4.1.2.2 Lotus Script

Lotus Script est un dialecte du langage de program-

mation BASIC utilis´e par Lotus Notes.

Il est accessible via l’outil Designer. Ce langage est in-

terpr´et´e `a l’ex´ecution mais il est avant tout un langage

objet. Il peut ˆetre ex´ecut´e cot´e client s’il est mis dans des

actions de masques ainsi que du cot´e serveur s’il est mis

dans des agents de base.

D’un point de vue syntaxique, il s’apparente `a Visual

Basic mais il contient des objets-classes propres `a Do-

mino, parmi lesquelles :

– NotesItem : champ d’un document.

34

– NotesUiDocument : document ”actif”.

– NotesView : repr´esente une vue.

Comme ce langage est destin´e aux bases Lotus Notes,

le d´eveloppement en Lotus Script se fait avec le client

Domino Designer. Il s’agit de la mˆeme interface de d´eve-

loppement utilis´ee pour la cr´eation de bases Notes.

Figure 4.2 – Interface de D´eveloppement

4.2 Interface Homme/Machine

Dans cette section, nous allons pr´esenter les vues les

plus importantes de notre application. Ces vues servent

`a donner une id´ee plus claire sur l’avancement de notre

travail. En effet, elles sont le r´esultat des trois phases :

analyse, conception et impl´ementation.

Ces vues seront pr´esent´ees `a l’aide des imprim´es ´ecran

que nous avons r´ealis´e.

35

4.2.1 Cr´eation Document

La figure ci-dessous FIGURE 4.3 montre l’interface de

cr´eation d’un document.

Lorsqu’un utilisateur souhaite cr´eer un document, il doit

aller au workspace, cliquer sur ”Create” et choisir le type

du document qu’il souhaite cr´eer.

Figure 4.3 – Cr´eation Document

4.2.2 Ouvrir/Consulter Document

L’ouverture d’un document se fait `a partir des vues,

qui sont des s´elections ou des cat´egories de documents

d’une base Notes.

La figure ci-dessous FIGURE 4.4 montre comment ou-

vrir un document.

36

Figure 4.4 – Consulter Document

Les documents dans notre application sont cat´egoris´es

selon les besoins fondamentaux et quotidiens de l’entre-

prise.

Tous les documents sont class´es par nature : Emis ou

Re¸cus pour all´eger et faciliter leurs recherches.

– Factures : sont divis´ees selon la d´eclaration de TVA

(TVA d´eclar´ee, TVA non d´eclar´ee, TVA non d´educ-

tible) ou par critere de reglement et remboursement.

– Certificats Retenues Impˆots : sont cat´egoris´es en se

basant sur l’indice d´eclaration.