XDEMAT

Département GED & ARCHIVAGE Electronique

13 septembre 2010 Créé par : Zahir MOUHOUBI

Nous présentons dans ce mémoire, le travail accompli durant le stage de fin d'étude, réalisé au sein de la société Reactis,

en partenariat avec la société XDemat, dans le domaine de la dématérialisation et l'archivage électronique. Nous avons

travaillé sur le développement d'une interface qui respecte la norme EAD (Encoded Archival Description) et qui puisse

assurer l'interopérabilité entre progiciels et SAE en suivant le Standard d'Echange de Données Archivistiques (SEDA).

Interface généralisée

EAD - SEDA

Mémoire de fin d'étude

Conseil en Dématérialisation & Archivage électronique

Faculté des Sciences de Luminy

Département Informatique

Master 2 Informatique Avancée et Applications (I2A)

Option Algorithmique et Recherche Opérationnelle (ARO)

XDEMAT

Remerciements

Je souhaite présenter un grand merci à ma famille pour leur soutien qui n'a jamais

fléchi.

Je tiens à remercier M. MASSAT et le corps enseignant de m'avoir accepté au sein de

la formation I2A, qui m'a permis de pratiquer ma passion pour l'informatique.

Mes sincères remerciements à tous les enseignants de la formation I2A, pour le savoir et les

connaissances qu'ils m'ont apportées.

Je remercie mes tuteurs de stage, M. GIMENEZ et Mme BOUTIER de m'avoir

accepté au sein de l'entreprise XDEMAT pour mon stage de fin d'études, et tiens à leur

exprimer mon respect et ma gratitude pour tout ce qu'ils m'ont appris grâce à leur

professionnalisme et leurs valeurs humaines, et sans qui ce travail n'aurait pas pu se faire.

Je remercie également mes amis et toutes les personnes qui ont contribué de près ou de

loin à la réalisation de ce rapport.

À Kahina.

XDEMAT

XDEMAT

i

Sommaire

INTRODUCTION GENERALE .......................................................................................................................... 1

CHAPITRE 1 PRESENTATION DE LA SOCIETE XDEMAT. .............................................................................. 2

I. INTRODUCTION ............................................................................................................................ 2

II. XDEMAT : DEMATERIALISATION ET ARCHIVAGE ELECTRONIQUE .................................................................. 3

A. Présentation de la Société ......................................................................................................................... 3

B. Savoir faire et domaines de compétence ......................................................................................................... 4

C. Effectif : ............................................................................................................................................. 5

D. Références en GED & Archivage électronique .................................................................................................. 5

III. PRESENTATION DES TUTEURS DU STAGE : .............................................................................................. 7

A. GIMENEZ Roger : directeur technique REACTIS et PDG XDemat ........................................................................ 7

B. BOUTIER Claude : Consultante en dématérialisation & archivage électronique XDemat.............................................. 7

CHAPITRE 2 .................................................................................................................................................... 8

DEMATERIALISATION ET ARCHIVAGE ELECTRONIQUE : ETAT DE L'ART. ................................................ 8

I. INTRODUCTION ............................................................................................................................ 8

II. QUELQUES DEFINITIONS DE BASE (1) .................................................................................................... 8

A. Définition du mot archive ......................................................................................................................... 8

B. Autres sens du mot « archive » ................................................................................................................... 9

C. Archives Informatiques ............................................................................................................................10

D. Document électronique ...........................................................................................................................10

E. Fonds (d'archives) .................................................................................................................................10

F. Instrument de recherche ..........................................................................................................................11

III. CYCLE DE VIE DES ARCHIVES ........................................................................................................... 12

A. Archives courantes .................................................................................................................................12

B. Archives intermédiaires ...........................................................................................................................12

C. Archives définitives ................................................................................................................................12

IV. DEMATERIALISATION .................................................................................................................... 13

D. Avantage de la dématérialisation ...............................................................................................................14

V. GESTION ELECTRONIQUE DE DOCUMENTS (GED) ................................................................................. 15

A. Domaines fonctionnels ............................................................................................................................15

VI. DE LA GED AU RECORDS MANAGEMENT ............................................................................................ 16

A. Qu'est ce que le Record Management ? .........................................................................................................16

B. Intérêt du Records management .................................................................................................................17

C. GED et records Management ....................................................................................................................17

VII. ARCHIVAGE ELECTRONIQUE DES DOCUMENTS A VALEUR PROBANTE ........................................................ 18

A. Les enjeux de la conservation sur le très long terme : l’obsolescence technologique (3) ................................................18

B. XML et l'archivage électronique (4) ............................................................................................................21

C. La valeur probante d'un document : ............................................................................................................21

D. Archivage électronique : définitions et objectifs ...............................................................................................21

E. Objectifs.............................................................................................................................................22

F. L’organisation type d’un système d’archivage électronique .................................................................................23

VIII. CADRE NORMATIF ................................................................................................................... 26

A. MOREQ2 ...........................................................................................................................................26

B. Dublin Core (4) ....................................................................................................................................26

C. NFZ 42013 (5) ...................................................................................................................................27

D. OAIS (Open Archival Information System) ....................................................................................................27

E. ISAD(G) ............................................................................................................................................30

F. EAD (Encoded Archival Description) ...........................................................................................................31

G. ISAAR (CPF), (International Standard Archival Authority Record for Corporate Bodies, Persons and Families) ..................33

XDEMAT

ii

H. EAC (Encoded Archival Context) ................................................................................................................34

I. SEDA (Standard d'Echange de Données pour l'Archivage) .................................................................................34

J. Synthèse sur les normes (6): ......................................................................................................................41

CHAPITRE 3 : GESTION DE PROJET ET OUTIL COLLABORATIF. .................................................................42

I. METHODOLOGIE DE GESTION DE PROJET. ........................................................................................... 42

II. L'OUTIL COLLABORATIF : MICROSOFT ONLINE SERVICES ......................................................................... 43

A. SharePoint : ........................................................................................................................................43

B. Live Meeting : ......................................................................................................................................44

CHAPITRE 4 : RAPPORT TECHNIQUE ET CONTRIBUTIONS. .......................................................................46

I. PRESENTATION DU SUJET DE STAGE : ................................................................................................. 46

A. Applications métiers ...............................................................................................................................46

B. Interface généralisée...............................................................................................................................47

C. Les systèmes d’archivage électronique ..........................................................................................................47

II. ANALYSE DES BESOINS : ................................................................................................................. 48

A. Mission de l'interface généralisée ...............................................................................................................48

III. SPECIFICATIONS FONCTIONNELLES .................................................................................................... 49

A. Identification des acteurs de l’interface généralisée ..........................................................................................49

B. Identification des cas d’utilisations .............................................................................................................49

C. Diagramme des cas d’utilisation ................................................................................................................50

D. Description textuelle des cas d’utilisation (8) .................................................................................................50

E. Description graphique des cas d’utilisation ...................................................................................................53

F. Evolution du cahier des charges : ...............................................................................................................55

IV. SPECIFICATIONS TECHNIQUES : ........................................................................................................ 56

A. Outils utilisés : ....................................................................................................................................56

B. Choix des outils et technologies : ................................................................................................................56

C. Architecture de l'application : ...................................................................................................................59

D. Diagramme des classes : ..........................................................................................................................61

E. Présentation de l'application développée ......................................................................................................65

V. PLEADE : PUBLICATION, RECHERCHE ET CONSULTATION DE DOCUMENTS D'ARCHIVES .................................... 70

A. Présentation : ......................................................................................................................................70

B. Les principales fonctionnalités : .................................................................................................................71

C. Quelques références : ..............................................................................................................................73

D. Automatiser la publication avec PLEADE .....................................................................................................73

E. Les avantages : .....................................................................................................................................76

VI. DIFFICULTES RENCONTREES ............................................................................................................ 77

A. Génération de fichier XML sous MAC OS X ..................................................................................................77

B. Compatibilité des rapports et des comptes rendu ..............................................................................................77

C. Manque de documentation sur PLEADE .......................................................................................................77

D. Réutilisation des feuilles de style XSL de PLEADE : .........................................................................................77

E. Récupération du statut de publication de PLEADE ..........................................................................................78

VII. CONCLUSION ET PERSPECTIVES .................................................................................................... 78

CONCLUSION GENERALE ..............................................................................................................................79

BIBLIOGRAPHIE ............................................................................................................................................80

VIII. ANNEXE A : QUELQUES TERMINOLOGIES ARCHIVISTIQUES .................................................................... 81

IX. ANNEXE B : LES ELEMENTS DE LA NORME DUBLIN CORE .......................................................................... 83

X. ANNEXE C : EXEMPLE D'INSTRUMENT DE RECHERCHE AVEC SON ENCODAGE EN EAD ....................................... 84

XI. ANNEXE D : EXEMPLE DE FICHIER XMLEAD GENERE AVEC L'APPLICATION EAD_WEB, LE FICHIER XSL DEVELOPPE ET LE

RESULTAT EN PDF ............................................................................................................................... 90

XDEMAT

1

Rap

port

de

stag

e| 1

3/09

/20

10

Introduction générale

Avec l’évolution de l’informatique et le développement des nouvelles technologies, la prolifération des

échanges numériques ne cesse de s’accroitre. Les administrations publiques et les organismes privés se sont rendu

compte du gain de temps et d’espace que l’on pouvait avoir dans la création, gestion et stockage des archives en

utilisant les outils informatiques.

Le monde de l’archivage a durant des années, travaillé avec des documents papier, mais avec l’informatique, sa

présence dans les administrations, les entreprises et l’équipement des foyers en micro informatique, il s’est

éveloppé une nouvelle forme d’échanges de données numériques, qui a induit le développement d’un nouveau

type d’archivage : l’archivage électronique.

La loi sortie en mars 2000, donne le même pouvoir de preuve au document numérique que celui du document

papier.

Cependant, réussir une opération d'archivage numériques dépend de divers paramètres : l'échange des données,

les formats des données, assurer leurs intégrité et leurs intelligibilité…etc.

L'état français s'est investit considérablement pour développer ce domaine, c'est d'ailleurs l'une des missions de la

DGME (Direction générale pour la Modernisation de l'Etat)1 et des Archives de France2.

Que ça soit au niveau des collectivités publiques ou privés, les différents acteurs se devaient de travailler avec le

même langage, c'est pourquoi des normes et standards ont été établis pour structurer et faciliter l'échange et la

manipulation des données informatiques. Parmi ces normes, nous pouvons citer OAIS, ISAD(G), ISAAR(CPF),

SEDA, EAD…etc.

L'objet de notre travail se portera essentiellement sur la norme EAD et le SEDA. Globalement, L'EAD est utilisé

pour la description archivistique en langage XML, et le SEDA est utilisé pour l'échange des données entre

systèmes informatique. Nous y reviendront plus en détail au cours de ce rapport.

Ce rapport de stage est composé de quatre chapitres :

- Le premier chapitre va présenter les deux entreprises et les tuteurs de stage qui m'ont accueilli pour

réaliser ce travail.

- Le deuxième chapitre est consacré à la découverte du domaine des archives et du cadre normatif qui s'est

développé pour assurer un archivage électronique pérenne.

- Le troisième chapitre contient la méthodologie suivi pour la réalisation du travail, ainsi qu'un bref aperçu

d'un outil collaboratif.

- Le quatrième chapitre présente le travail réalisé, les outils utilisé et la contribution apporté durant ce

stage.

1 www.modernisation.gouv.fr

2 www.archivesdefrance.culture.gouv.fr

XDEMAT

2

Rap

port

de

stag

e| 1

3/09

/20

10

Chapitre 1 Présentation de la société

XDEMAT.

I. Introduction

Je vais vous présenter dans ce chapitre l'entreprise, REACTIS, qui m'a accueillit dans le cadre de mon

stage de six mois que j'ai entamé le 01 avril 2010. REACTIS travaille en étroite collaboration avec une jeune

entreprise, XDemat cabinet de consultants spécialisé dans le domaine de la GED3, de la dématérialisation et de

l'archivage électronique.

Ce partenariat, présente l'avantage d'élargir l'offre de services aux clients potentiels tout en enrichissant les

compétences de chacune des sociétés.

Pourquoi deux entreprise ?

Depuis 2007, le domaine de l'archivage électronique ne cesse de se développer. Consciente de cette évolution,

REACTIS a dû développer son département GED & archivage et acquérir les compétences adéquates pour

satisfaire les besoins du marché.

En janvier 2010, XDemat arrive en tant que cabinet de conseil spécialisé dans la dématérialisation et l'archivage

électronique. Elle apporte la partie étude et conseil et devient complémentaire avec les offres de REACTIS en

tant qu'intégrateur

Ce rapprochement s'est fait logiquement car le P.D.G. d'XDemat, M. GIMENEZ, est également le directeur

technique de la société REACTIS.

Là ou REACTIS se présente comme intégrateur, XDemat apporte la partie conseil et étude.

C'est dans cette optique que je vais vous présenter les deux sociétés, leur savoir-faire, le service qui m'a accueillit

et les personnes qui m'ont encadré tout au long de ce travail.

3 GED : Gestion Électronique de Documents

XDEMAT

3

Rap

port

de

stag

e| 1

3/09

/20

10

II. XDemat : Dématérialisation et Archivage électronique

A. Présentation de la Société

XDEMAT est une société de conseil dans le domaine des systèmes d'information. Créée en janvier 2010

par M. GIMENEZ Roger, elle s'est spécialisée dans la GED, l’archivage électronique et la dématérialisation.

Par ce qu’un projet d’archivage électronique ne peut réussir que s‘il prend en compte toutes les composantes

(archivistique, métier, informatique, juridique et normative), XDEMAT s'est entourée de spécialistes de chaque

domaine.

Le réseau de consultant d’XDEMAT, une équipe pluridisciplinaire. :

XDemat participe à des commissions d’audit de validation sur les normes en vigueur (ex : Z42-013 travaux

AFNOR/ISO nouvelle version R 2.2.1 en cours d’étude ou encore sur la définition d’un SAE).

Un suivi est effectué et certains des consultants interviennent directement sur les projets en cours dans le secteur

des collectivités et plus particulièrement ceux pilotés par la DGME4 et la DAF5.

De même, XDemat est membre actif d’associations sur la GED, l’archivage et de façon générale sur le domaine

documentaire comme la FedISA6 et est en relation dans le cadre de ses travaux avec les associations d’archivistes

l’AAF7.

XDEMAT mène une veille technologique et normative en participant activement aux commissions de

normalisation (AFNOR et ISO) ainsi qu’aux projets d’expérimentation sur l’Archivage Electronique (DGME /

ADELE8).

4 Direction Générale de la Modernisation de l'État

5 Direction des Archives de France

6 Fedisa - Fédération de l'ILM (Information Lifecycle Management), du Stockage et de l'Archivage.

7 AAF – Association des Archives de France

XDEMAT

4

Rap

port

de

stag

e| 1

3/09

/20

10

B. Savoir faire et domaines de compétence

CONSEIL

- Conseil et audit,

- expertise dans le domaine des systèmes

d'information au service des Directions

générales,

- opérationnelles ou informatiques

ASSISTANCE A MAITRISE D'OUVRAGE

(AMOA)

Conseil et assistance à la définition des besoins

du client,

cadrage de projet,

rédaction de cahier des charges,

pilotage de projet,

coordination des différents intervenants et sous-

traitants,

assistance à la recette,

conduite du changement

ÉTUDES

- Etude d'opportunité,

- Etude préalable,

- Spécifications générales et détaillées de

systèmes ou de logiciels

QUALITE, TESTS ET VALIDATION

Management : AMOA, Industrialisation de

Processus Logiciel,

Assurance Qualité : Produit, Projet, CMMI9/ITIL

10,

Support : Gestion des exigences, d11

e

Configuration, des Tests,

Formation certifiante Tests & Qualification :

externalisation de TRA, centre NearShore et

Offshore.

8 Projet gouvernementale "ADministration ELEctronique"

9 CMMI (Capability Maturity Model + Integration) : c'est un modèle de référence, un ensemble structuré

de bonnes pratiques, destiné à appréhender, évaluer et améliorer les activités des entreprises d'ingénierie. 10

ITIL (Information Technology Infrastructure Library pour "Bibliothèque pour l'infrastructure des technologies de l'information") est un ensemble d'ouvrages recensant les bonnes pratiques ("best practices") pour la gestion des services informatiques (ITSM), édictées par l'Office public britannique du Commerce (OGC).

11 TRA (Tierce Recette Applicative) : correspond à la mise en place d'une méthodologie de tests aux

différentes étapes d'un projet afin d’en optimiser la recette finale.

XDEMAT

5

Rap

port

de

stag

e| 1

3/09

/20

10

GED / WORKFLOW

- Gestion électronique de documents et

workflow.

- Processus de dématérialisation

ARCHIVAGE A VALEUR PROBANTE Conseil et proposition de solutions packagées

pour l'archivage légal à valeur probante.

DÉCISIONNEL

- Expertise dans le domaine décisionnel.

Conception de datawarehouse12

, de

datamart13

.

- ETL14

, reporting et tableaux de bord

FORMATION Formation technique et méthodologique en intra

et interentreprises

C. Effectif :

Pour l’heure le fonctionnement de XDEMAT se base à la fois sur des consultants salariés et par des

missions confiées à des consultants indépendants spécialistes et experts en archivage électronique et

dématérialisation.

A ce jour, XDEMAT dispose de deux consultants experts, les autres consultants interviennent selon les

spécificités des études :

D. Références en GED & Archivage électronique

Voici les références sur lesquelles XDEMAT est intervenu directement en tant que TITULAIRE

de marché ou de sous-traitance sur des projets de GED & ARCHIVAGE.

12 DataWareHouse: désigne une base de données utilisée pour collecter, ordonner, journaliser et stocker

des informations provenant de base de données opérationnelles et fournir une aide à la décision en entreprise. 13

DataMart: sous-ensemble d’une base de données relationnelle utilisé en informatique décisionnelle ; 14

ETL : Extract-Transform-Load, technologie informatique intergicielle permettant d'effectuer des synchronisations massives d'information d'une base de données vers une autre.

Source: Wikipedia

Normatif

Juridique

Archivage légal

GED

Technique

Fonctionnel

SAE

…

Si tout va bien, j’intègrerai la société XDemat mi-octobre.

XDEMAT

6

Rap

port

de

stag

e| 1

3/09

/20

10

PSA a commandé une étude comparative de 7 progiciels d’archivage électronique au CXP qui à fait appel à XDEMAT pour réaliser l’étude. Cette étude est basée sur des questionnaires très précis, des entretiens et des démonstrations de produits. Pour chaque produit, une fiche descriptive à été fournies. Une synthèse générale et des notations ont été produites.

Avril 2010

Le Syndicat mixte MEGALIS souhaite faire appel à une prestation d’Assistance à Maîtrise d’Ouvrage afin de disposer des éléments nécessaires au lancement d’une consultation visant au choix et la mise en œuvre d'une solution mutualisée d’archivage électronique à valeur probatoire. Le Syndicat mixte a souhaité être accompagné dans sa démarche préalable de définition des besoins, de connaissance du marché et de rédaction du cahier des charges

Mai 2010 à Décembre 2010

Mise en place du Système d'information des Archives du MAEE.

Fin 2009 - 2010

Définition d’une Stratégie d’Archivage 2009

Mise en place d’une GED au niveau de la Ville avec un 1° projet sur la GED Immobilière 2009 – début 2010

Mise en œuvre d’un socle commun au SIH – GED & ARCHIVAGE 2009

Archivage documents DCE pour plate formes de dématérialisation 2010

XDEMAT

7

Rap

port

de

stag

e| 1

3/09

/20

10

III. Présentation des tuteurs du stage :

Durant mon stage, 'ai été encadré par deux personnes compétentes et avec des valeurs humaines remarquables.

A. GIMENEZ Roger : directeur technique REACTIS et PDG XDemat

Directeur, en charge pendant plus de 10 ans jusqu’en 2003 de prés d’une centaine d’informaticiens

(Développement, Système et Réseau), M. GIMENEZ a été notamment en charge de la mise en place de stratégies

de Gestion Documentaire et d’archivage.

Depuis 2003, en tant que directeur technique chez REACTIS, il est en charge de développer les prestations

d’accompagnement dans le cadre de la GED (Gestion Electronique de Document) et d’archivage. Les premières

années avec une responsabilité opérationnelle (forfait et pénalité sur SLA), il a mis en place une Tierce

Maintenance Applicative sur des processus Gestion de Documents Technique (Avionique) accompagnée d’une

démarche de veille afin d’optimiser les processus.

Depuis 2006, M. GIMENEZ s’est spécialisé dans les aspects archivage notamment à valeur probante. Il a

accompagné des administrations et Groupement d’Intérêt Public dans la définition et mise en place de solutions

d’archivage. Il participe activement à des commissions d’audit et validation de normes en tant que membre de la

FédISA15 et anime des hubs sur l’archivage à valeur "probante".

En 2008-2009, Roger GIMENEZ a mené l’étude de définition de la stratégie d’archivage électronique aux CG13

et AD13.

B. BOUTIER Claude : Consultante en dématérialisation & archivage électronique XDemat

Consultante spécialisée dans l’archivage électronique et la dématérialisation, elle connaît très bien le

métier des archivistes et les offres progicielles permettant de mettre en place des outils de gestion des archives

papier et numériques.

Elle a travaillé plusieurs mois avec les archives départementales des bouches du Rhône afin d’analyser les

différents processus de gestion des archives et d’auditer le système existant. Claude connaît le contexte législatif

et normatif lié à la dématérialisation des processus et l’archivage électronique. Elle a pu étudier comment un

système peut assurer la valeur probante de ses archives, expertiser les différents standards (OAIS, EAD,

SEDA …).

Elle a mené une étude comparative des progiciels d’archivage électronique lors de laquelle elle a pu mettre en

évidence les différents types d’offres existants et apprécier les contextes dans lesquels ils sont le mieux adaptés.

Elle a travaillé en tant qu’assistance à maitrise d’ouvrage pour la définition des besoins, la mise en place de

scénarios, la rédaction de spécifications fonctionnelles et techniques, la réalisation de maquettes visant à aboutir à

la rédaction de cahier des charges dans des projets de mise en place de SAE.

15 Fédération de l'ILM (Information Lifecycle Management), du Stockage et de l'Archivage

XDEMAT

8

Rap

port

de

stag

e| 1

3/09

/20

10

Chapitre 2

Dématérialisation et archivage

électronique : Etat de l'art.

I. Introduction

Nous présentons dans ce chapitre, les domaines passionnants que j'ai côtoyés tout au long de mon stage:

la dématérialisation, l'archivage électronique, la gestion électronique de document (GED), etc.

Ces domaines sont vraiment d'actualité, avec la popularisation de l'outil informatique, le besoin d'optimiser les

méthodes archivistique et la volonté de se moderniser.

Durant des années, le document papier a été le principal support d'information utilisé. Que ça soit un acte

notariale, un contrat de location, des fiches de payes, ou des documents scientifiques, leurs valeur n'était

sauvegardé à moyen ou long terme que si on gardé l'original papier.

Avec le développement de la technologie, depuis l'an 2000 le document numérique peut être certifié et signé

électroniquement, juridiquement, il devient ainsi une preuve officielle au même titre que le document papier.

Ces domaines commencent à s'intégrer à plus grande échelle au niveau des collectivités et des entreprises privés.

II. Quelques définitions de base (1)

Dans le cadre du stage, j'ai du assimiler les connaissances métier du monde archivistique, car l'archivage

électronique s'inspire de ces connaissances pour trouver des solutions adaptées qui facilite le travail de l'archiviste.

Commençons par découvrir les définitions de base et les terminologies archivistiques utilisées.

A. Définition du mot archive

Nous avons adopté la définition officielle du Conseil international des Archives (CIA) :

"Les archives sont l'ensemble des documents quels que soient leur date, leur forme et leur support matériel,

produits ou reçus par toute personne physique ou morale, et par tout organisme public ou privé, dans l'exercice

de leur activité, documents soit conservés par leur créateur ou leur successeurs pour leurs besoins propres, soit

transmis à l'institution d'archives compétente en raison de leur valeur archivistique." XDEMAT

9

Rap

port

de

stag

e| 1

3/09

/20

10

Figure 1 schématisation d'une archives

B. Autres sens du mot « archive »

a) Service Administratif

Le mot archives désigne aussi des institutions ou des services administratifs (publics ou privés) qui

ont pour mission de conserver les fonds d’archives d’une institution ou d’un groupe d’institutions (publiques ou

privées).

Dans ce cas, on ajoute au mot archives l’adjectif qualificatif qui définit le statut du service d’archives, qui identifie

habituellement la juridiction ou le type d’organisme de qui dépend le service.

EXEMPLE

Les expressions : «Archives nationales» pour l'institution qui conserve les archives de l'État, «Archives régionales» pour

le service qui conserve les archives des institutions régionales, «Archives municipales» pour le service responsable

des archives des municipalités et des communes, «Archives hospitalières» pour celui des archives des hôpitaux etc.

Comme il s'agit de services ou d'institutions, le mot archives est dans le cas de ces expressions employé avec une

majuscule.

b) Les bâtiments

Le mot archives peut également désigner les bâtiments ou les locaux affectés à la conservation, au traitement et

à la communication de ces documents, dits «bâtiments d'archives».

XDEMAT

10

Rap

port

de

stag

e| 1

3/09

/20

10

C. Archives Informatiques

Définition "Documents produits ou reçus par un organisme dans l'exercice de ses activités et conservés sous forme

d'enregistrements électroniques sur des supports tels que les bandes magnétiques, les disques magnétiques, les

disques optiques etc., et qui ne peuvent être lus que par l’intermédiaire d’une machine."

D. Document électronique

La notion de document, si elle ne pose guère de problème dans un univers matériel, est largement remise en

question par la dématérialisation et la reprographie.

Notre approche de la gestion documentaire prend l'acception suivante du terme « document » :

Définition « Ensemble constitué par un support et par l'information qu'il porte ».

a) Le support

Le support est un fichier. Le document-fichier est créé, modifié et rendu lisible par une application.

Typiquement, un document Word est créé, modifié et rendu lisible par l’application Microsoft Word, et de la

même manière pour les documents ODF (Open Office), Autocad, ou Adobe Première.

Cette association document / application est omniprésente dans la GED. Ceci d’autant plus que beaucoup des

documents manipulés utilisent des formats fermés, c’est à dire qu’ils ne peuvent être créés, modifiés et même lus

que par leur application associée. De sorte que l’application de GED gère finalement des objets qui lui sont le plus

souvent opaques, impénétrables.

Un document électronique est avant tout un fichier, mais n’importe quel fichier n’est pas un document.

Typiquement, un fichier exécutable n’est pas un document. Un document est un fichier porteur d’une

information, une information produite par l’homme et destinée à l’homme.

Les applications de GED introduisent la notion de document objet, qui réunit conceptuellement le document

fichier et l’ensemble des métadonnées qui lui sont attachées.

E. Fonds (d'archives)

Tous les documents, pièces et dossiers, réunis et conservés par une personne ou une institution au cours de ses

activités forment un tout que l’on appelle un fonds.

Aussi lorsque l’on veut désigner un fonds d’archives, on le fait toujours par référence à la personne (physique ou

morale) qui a constitué le fonds, au producteur du fonds.

XDEMAT

11

Rap

port

de

stag

e| 1

3/09

/20

10

EXEMPLE

La lettre d’un maire à l’un de ses administrés à propos de questions d’urbanisme est intéressante en soi.

Mais elle ne prend sa pleine valeur qu’au milieu de tous les autres dossiers d’urbanisme de la mairie.

C’est pourquoi, c’est surtout dans leur ensemble, comme fonds, que les documents d’archives intéressent

l’archiviste.

Un fonds d’archives est la conséquence et le résultat nécessaires et naturels de l’activité d’une personne, mais

n’est pas l’objet de cette activité.

Remarque Le fonds d'archives est différent de la collection. Une collection est la réunion de documents déterminée

selon l'intérêt et le choix du collectionneur. Pensons aux collections d'autographes, réunies selon les goûts du

collectionneur, le hasard de ses découvertes et de ses moyens financiers, mais il n'a créé lui-même aucun de ces

documents et ils n'ont pas servi à ses actions.

EXEMPLE

Le "fonds Robert-Doisneau" est le fonds d’archives du photographe Robert Doisneau. Il est formé de

l’ensemble des photographies et des papiers administratifs produits dans le cadre des activités de ce célèbre

photographe ;

Une "collection Robert-Doisneau" peut être une collection de lettres, de photographies réunissant des clichés de

ce même photographe, mais constitue un assemblage très différent de documents qu’un collectionneur peut avoir

créé parce qu’il s’intéresse à l’œuvre de ce photographe.

F. Instrument de recherche

La première fois que j'ai entedu ce mot, j'ai directement fait allusion à un outil permettant de retrouver

de l'information rapidement. Pour être honnête, j'ai directement pensé au moteur de recherche Google.

Dans la pratique, cela est totalement faux puisque les archivistes désignent d'instrument de recherche tout outil

décrivant un ensemble de documents d'archives.

Voici la définition exacte :

Définition "Outil papier ou informatisé énumérant ou décrivant un ensemble de documents d'archives de manière à les

faire connaître aux lecteurs. Les instruments de recherche fondamentaux sont, en allant du général au particulier,

les états des fonds et les guides, les états sommaires et états des versements, les répertoires méthodiques ou numériques et les

bordereaux de versement, les inventaires sommaires ou analytiques, les catalogues, les inventaires-index."

Remarque : Pour avoir un aperçu concret de ce qu'est un instrument de recherche, je vous propose de consulter l'Annexe C.

L'instrument de recherche qui y est décrit, définit un Fonds du centre hospitalier de Versailles.

XDEMAT

12

Rap

port

de

stag

e| 1

3/09

/20

10

III. Cycle de vie des archives

La gestion des documents d’archives consiste à assurer leur traitement selon un cycle de vie des documents.

Ce cycle de vie a été formalisé sous le nom de théorie des trois âges des archives par l’archiviste français Yves

Pérotin pour mieux sensibiliser les producteurs d’archives et les archivistes à leurs rôles respectifs. Cette théorie

distingue trois âges successifs dans la continuité de la vie de tout document et de tout dossier composant les fonds

d’archives.

Ces trois âges sont ceux des :

A. Archives courantes

L’âge des archives courantes correspond au moment de la

création des documents et des dossiers. Il dure tant que ces

documents sont immédiatement et quotidiennement utiles aux affaires qui ont nécessité leur création.

B. Archives intermédiaires

L’âge des archives intermédiaires est celui où ces documents et ces dossiers cessent d'être d'un usage, sinon quotidien, du moins

régulier, parce que les affaires sont terminées. Les documents ne sont plus couramment utiles au traitement des affaires, les dossiers sont clos. Mais, ils doivent être conservés pour d’autres usages, indirects, pour diverses raisons, notamment fiscales, juridiques ou d’information. Leur valeur administrative directe subsiste encore pour quelque temps et une conservation de précaution à assurer détermine leur durée d’utilité administrative. Lorsque toutes les obligations de conservation des documents pour utilisations temporaires sont arrivées à échéance et s’il ne reste plus aucune valeur ni directe, ni indirecte en particulier administratives, juridiques ou d’information, les documents peuvent être détruits.

C. Archives définitives

Les documents qui doivent être conservés indéfiniment sont appelés archives définitives. À partir de ce moment là, les documents sont conservés sans limitation de durée pour tous les usages à venir, prévisibles et imprévisibles, pour toutes les valeurs, directes (notamment juridiques) et indirectes (notamment d’information historique).

XDEMAT

13

Rap

port

de

stag

e| 1

3/09

/20

10

La figure ci-dessous décrit le cycle de vie des archives.

Figure 2 Théorie des trois âges

IV. Dématérialisation

On entend par dématérialisation le fait de transformer un document ou des données en format

électronique.

Elle consiste à prendre en charge l’ensemble des données et/ou des documents physiques d’une entreprise ou

d’un service pour les convertir, les numériser et permettre une gestion plus efficace en mode électronique.

Définition de la Dématérialisation La dématérialisation a pour objet de gérer de façon totalement électronique des données ou des

documents métier (correspondances, contrats, factures, brochures, contenus techniques, supports

administratifs,…) qui transitent au sein des entreprises et/ou dans le cadre d’échanges avec des partenaires

(administrations, clients, fournisseurs…).

La dématérialisation, c’est le remplacement des documents papier par des fichiers informatiques, entraînant la

mise en œuvre du fameux "bureau sans papier ".

L’indexation va apporter la souplesse et la précision dans les recherches en ciblant par des critères de sélection le

dossier ou le document à retrouver

La dématérialisation s'articule autour de cinq étapes formant un processus de dématérialisation type :

- La numérisation du document qui fait typiquement intervenir des scanners professionnels de

production avec des résolutions graphiques et couleurs.

La capture de l’image en format TIFF ou PDF va permettre la restitution et l’affichage (noir, niveau de gris

ou couleur) sur support numérique pour un accès plus rapide.

- Le traitement de fichiers informatiques par programme pour la capture, l’indexation, la restitution

et l’affichage sur support numérique pour un accès plus rapide.

Sort final

DUA

Temps

Archives intermédiaire

Archives

Archives Courantes

Gestio

Diffusion

Conservation

Création

XDEMAT

14

Rap

port

de

stag

e| 1

3/09

/20

10

- L’indexation des documents est une étape qui va permettre de capturer des informations du

document pour les retrouver une fois transférées vers une base de données ou un support de consultation.

L’indexation du document s’effectue au moyen d’outils logiciels de reconnaissance optique de caractères

ou par saisie manuelle. La consultation ciblée par l’indexation effectuée donne toute la force à ce mode de

traitement.

- La restitution des documents peut être en visualisation à l’écran, en impression papier, en diffusion

ou transfert par messagerie.

- Le support d’enregistrement sera choisi en fonction de la gestion des documents selon le nombre

d’utilisateurs, le taux de consultation, ou la diffusion ou la distance des utilisateurs : le cdrom autonome, le

serveur web ou la microfiche argentique sont les supports les plus fréquents qui ont chacun leur particularité et

leur force.

D. Avantage de la dématérialisation

Une fois dématérialisé, le document électronique peut facilement et rapidement être retrouvé par des recherches

directes ou croisées, par des mots clés.

Affiché à l’écran du poste de travail, le document peut être restitué et réimprimé dans sa forme originale sur

papier, mais il peut également être copié sur CDROM ou diffusé par messagerie à différents destinataires et à un

coût très faible.

Pour la conservation, la consultation ou la diffusion, c’est toute la souplesse et la force du document électronique

face au papier

Figure 3 Dématérialisation du courrier

Après avoir dématérialisé les documents papiers, les documents électroniques résultant devront être stocké,

conservé et restitué si besoin est. C'est dans cette démarche que la gestion électronique de document intervient.

XDEMAT

15

Rap

port

de

stag

e| 1

3/09

/20

10

V. Gestion Electronique de Documents (GED)

Si vous utilisez un ordinateur pour manipuler des documents électroniques, alors vous vous êtes

certainement posé des questions sur l'efficacité de votre gestion. Ai-je la bonne version? Est-ce une copie du

fichier original? Où est-ce-que j'ai enregistré ce fichier? Est-ce le bon fichier que mon collègue m'a envoyé?

La GED à pour objectif d'apporter la solution à ces problèmes.

Voyons voir sa définition :

Définition (2) : "Ensemble de techniques et de logiciels qui permettent de traiter les éléments disparates d'un même

document comme un tout, de façon dynamique. La gestion électronique de documents assure l'intégration de

documents issus de sources diverses, leur identification, leur archivage, leur restitution, leur administration et

leur sécurité (physique et niveaux de confidentialité)."

La GED (Gestion électronique de documents ou, en anglais, Electronic Content Management, noté ECM)

représente l'utilisation de moyens informatisés pour l'ensemble de la gestion d'un document électronique (fichier

texte, fichier tableur, image, vidéo, fichier audio etc.).

L'objectif de la GED est de Prendre en charge le stockage, le partage et la restitution de documents électroniques

et parvenir à constituer un référentiel de l'ensemble des documents, qu'ils soient structurés (bases de données,

XML, etc.) ou non (HTML, etc.) afin d'être en mesure de gérer leur cycle de vie, de leur création à leur sort final.

A. Domaines fonctionnels

Nous nous efforçons ici de positionner la gestion documentaire vis-à-vis d’un certain nombre de domaines

connexes. Ces domaines ont des intersections avec la gestion documentaire, et peuvent parfois être

complémentaires. Il est donc utile de bien les situer.

a) Gestion documentaire

Objectif : Prendre en charge le stockage, le partage et la restitution de documents électroniques. Il s'agit

majoritairement de systèmes gérant des fichiers incluant un fond et une forme.

Priorité : Gestion de documents électroniques, donc de fichiers.

Orientation : Stockage, partage, recherche

Termes rencontrés : GED - Gestion Electronique de Document, EDM - Electronic Document Management,

DMS – Document Management System

b) Gestion de contenu Web

Objectif : prendre en charge la rédaction, la validation et la mise en ligne de contenus à destination de sites web

Priorité : Mise en ligne d’information

Orientation : Diffusion, restitution de contenus structurés et/ou éditoriaux, contribution au second plan.

XDEMAT

16

Rap

port

de

stag

e| 1

3/09

/20

10

Termes rencontrés : WCM - Web Content Management, CMS – souvent employé pour désigner la gestion de

contenu Web

c) Workflow (flux de travail)

Objectif : permettre de fluidifier des processus, via l’enchaînement de tâches unitaires entre différents acteurs

Priorité : Gestion des processus

Orientation : gestion de tâches attachées à des profils d’utilisateur (« Taskflow », par exemple Organisation

d’un séminaire) ou à des documents (« Docflow », typiquement la validation d’un document)

Termes rencontrés : BPM – Business Process Management

d) Collaboratif

Objectif : Faciliter le travail de groupes de personnes au moyen d’outils dédiés, souvent de communication ou

d’interaction en temps réel ou différé (par exemple : email, agenda partagé…)

Priorité : Facilitation du travail en équipe

Orientation : Partage d’information opérationnelle

Termes rencontrés : Groupware – travail en équipe (outil ou méthode), Chat – messagerie instantanée, Blog –

Mode de communication personnel via des billets thématiques, auxquels il est possible de réagir, Wiki – Mode de

partage d’information via la coédition de pages, avec traçabilité des modifications, Agenda partagé – possibilité de

consulter, voire d’interagir avec des plannings.

VI. De la GED au Records Management

Le concept de Records management n’est pas nouveau, mais sa mise en œuvre au sein des organismes

publics ou privés est encore rare.

Pourtant, il est intéressant de penser son records management, en particulier lorsque l’on dispose d’une GED ou

que l’on souhaite en mettre une en place

A. Qu'est ce que le Record Management ?

Le terme « Records » n’est à traduire ni par « Enregistrements» ni par « Documents » (car cela inclut les

documents non finalisés, des documents de travail ou des documents qui n’ont pas vocation à être conservés).

Ce terme est issu du milieu archivistique anglo-saxon.

Un « Record » est un document validé et figé, destiné à être conservé pour sa dimension de preuve et d’utilité

dans le cadre de la conduite des activités d’un organisme.

Le « records management » vise à rationaliser la production, le tri, la conservation et l’utilisation des

documents d’archives, qu’ils soient sur support papier comme électronique, dans un souci de traçabilité,

intégrité, sécurité et pérennité des informations

XDEMAT

17

Rap

port

de

stag

e| 1

3/09

/20

10

Il existe différentes natures d’archives en relation avec les contraintes auxquelles est confronté tout organisme :

la loi (archives légales ou auditables)

le risque de contentieux (archives à valeur probante)

le risque de sinistres (archives vitales nécessaires pour redémarrer l’activité)

la conduite de l’action et de la stratégie (archives internes)

la nécessité de conserver une mémoire (archives historiques)

Le records management permet à un organisme de disposer à tout instant des documents et des données dont il a

besoin pour conduire ses activités, assurer la traçabilité de celles-ci, les poursuivre en cas de sinistre, défendre ses

intérêts en cas de litige, réduire les risques et répondre aux exigences légales et réglementaires en matière de

conservation de document.

B. Intérêt du Records management

Alors que les pratiques archivistiques, notamment européennes, concernent les archives intermédiaires et

définitives (à l’image des fameuses boites que l’on fait en fin d’année ou quand on n’a plus de place, pour les

stocker en salle d’archives …), le records management s’attache à gérer les archives courantes et intermédiaires.

Les bénéfices sont doubles :

Faciliter la gestion du cycle de vie du document en l’anticipant dès la création du document

Etre au plus près de la source pour disposer des informations sur le document et sur son

contexte de création et d’utilisation

Ces bénéfices sont d’autant plus réels et faciles à obtenir si la démarche de records management est implantée

dans l’outil que les utilisateurs utilisent au quotidien pour leur gestion.

C. GED et records Management

Lors du référencement ou du versement d’un document dans la GED, il suffirait que l’utilisateur ou un

traitement automatique :

le rattache à un dossier

le lie à une activité (ex : Activité Informatique \ Passation de marché)

qualifie le type du document (ex : Cahier des charges)

renseigne les éléments de description du contexte et du contenu du document

indique sa location si le document n’existe que sous une forme papier

Le système saurait alors, grâce au référentiel de conservation, combien de temps un document ou un dossier doit

être conservé. Par exemple, un document identifié comme facture doit être conservé 10 ans minimum. Les

éléments à épurer sont automatiquement identifiables

La nature de l’archive aux différentes étapes du cycle de vie pourra également avoir des impacts, notamment sur

l’optimisation du stockage. Pour des raisons économiques comme de confort, il est préférable des stocker sur

des disques à accès rapides les documents couramment utilisés. Alors que l’on pourra choisir de conserver des

documents rarement consultés sur des supports plus lents, mais moins onéreux. Ou encore s’assurer que les

archives vitales bénéficient des meilleures conditions de conservation.

XDEMAT

18

Rap

port

de

stag

e| 1

3/09

/20

10

Il n’est pas de la vocation d’une GED de conserver des documents sur de longues périodes (10 ans, 30

ans, voire 50 ou 90 ans). Par contre, la GED peut les transmettre à un Système d’archivage électronique (SAE).

L’idéal est que ces deux applications partagent les mêmes référentiels d’activité, de conservation, etc. pour ne pas

avoir à requalifier les documents lors du passage d’un système dans l’autre, ou pour que d’éventuelles

modifications des règles de conservation soient répercutées sur les deux systèmes.

Figure 4 GED et record management

VII. Archivage électronique des documents à valeur probante

La dématérialisation des processus métiers et le développement de l’administration électronique ont

accéléré la production de documents numériques à valeur probante. Au-delà de la simplification administrative

opérée à l’occasion de cette mutation, la nature même des documents ne change pas.

C’est bien la substitution progressive du support papier au profit des disques durs, dvd et cd-rom et les

contraintes de la signature électronique qui valent aujourd’hui aux collectivités d’adapter les processus à ces

nouvelles exigences. C’est aussi l’occasion de mettre à profit les avantages du numérique pour proposer des

services supplémentaires : suivi des versements et communication/consultation.

La conservation et l’indexation de ces documents requiert la création de processus et de référentiels spécifiques

pour assurer la protection des données, la traçabilité et la communication pour l’ensemble des utilisateurs.

A. Les enjeux de la conservation sur le très long terme : l’obsolescence technologique (3)

Dressons un petit inventaire des difficultés auxquelles nous aurions à faire face pour relire, par exemple après 10

ans, un fichier informatique pour lequel aucune précaution de conservation n’aurait été prise.

XDEMAT

19

Rap

port

de

stag

e| 1

3/09

/20

10

Votre fichier a 10 ans :

A travers cet exemple, se dessinent les 4 principaux risques qui menacent inéluctablement un fichier :

l’obsolescence matérielle,

l’obsolescence logicielle,

l’obsolescence du format de fichier,

la perte de la signification du contenu.

Faire de l’archivage numérique pérenne, c’est mettre en œuvre les moyens nécessaires pour lutter contre ces

menaces.

XDEMAT

20

Rap

port

de

stag

e| 1

3/09

/20

10

a) Contre la dégradation et le vieillissement des médias

Il faudra prévoir de conserver des copies multiples des documents archivés, tout en diversifiant les

technologies de stockage. Dans l’idéal, on peut par exemple souhaiter conserver sur site une copie disque et une

copie bande, et une seconde copie bande sur un site distant. Ces seules précautions ne suffiront pas. Il faudra en

outre rafraîchir (i.e. renouveler) régulièrement les supports en remplaçant les supports anciens par des supports

neufs. Ici également, on veillera à appliquer le principe de précaution. Si tel fabricant réputé sérieux garantit la

lisibilité de tel support sur 10 ans, c’est sans doute qu’il le sait fiable sur une durée de 20 ans. En vertu de quoi,

on procédera par précaution au rafraîchissement régulier de tous les supports vieux de... 5 ans, soit la moitié de la

durée de vie garantie par le fournisseur.

b) Contre la disparition soudaine de matériels ou de logiciels

On mettra en place des dispositifs d’alertes de type veille technologique et économique. En l’occurrence,

et contrairement à la veille classique qui s’intéresse aux phénomènes émergents, on s’intéressera ici surtout aux

technologies éprouvées en vue d’anticiper leur obsolescence. D’une manière générale, dans ce domaine comme

ailleurs, on cherchera à privilégier systématiquement les normes pour éviter les dépendances vis-à-vis de solutions

propriétaires.

Lorsque l’obsolescence d’un logiciel est avérée, l’émulation peut être une solution, bien que très coûteuse. Elle

consiste à recréer l’environnement d’un logiciel pour pouvoir l’exécuter à nouveau. Cette technique est

majoritairement utilisée aujourd’hui pour faire revivre les premiers jeux-vidéo, comme Pacman.

c) Pour éviter l’impasse de la disparition des formats de fichier

On optera pour des formats pérennes (durables). Qu’est-ce qu’un format durable ?

C’est avant tout un format publié. C’est-à-dire un format dont les spécifications internes sont librement

accessibles. Seul un format publié peut en effet permettre, dans le plus extrême des cas, à un développeur

d’écrire un programme spécifique de relecture du fichier. Un format durable est aussi un format très utilisé, ou

appelé à le devenir. Un format durable, c’est enfin et si possible un standard voire une norme.

Au regard de ces critères, voici une liste des principaux formats actuellement considérés comme pérennes :

Nom complet Nom court

Advanced Audio Coding AAC

Audio Interchange File Format AIFF

Free Lossless Audio Codec FLAC

Graphics Interchange Format GIF

Hypertext Markup Language HTML

Joint Photographic ExpertsGroup JPEG

Moving Picture Experts Group MPEG-4

Portable Document File PDF, PDF/A

Portable Network Graphics PNG

Scalable Vector Graphics SVG

Tagged Image File Format TIFF

TeXTe TXT

WAVEform audio file format WAVE

Extensible Markup Language XML

XDEMAT

21

Rap

port

de

stag

e| 1

3/09

/20

10

Par ailleurs, choisir un format durable pour l’archivage n’enlève pas le fait qu’un jour ce format deviendra

obsolète : il ne fait que retarder ce moment. Face à cela, une des solutions pour garantir la lisibilité d’un fichier

est la conversion de format, c’est-à-dire, migrer le document dans un format différent de celui dans lequel il était

précédemment encodé, tout en en préservant la fidélité.

d) Pour surmonter le dernier obstacle - le manque de documentation

La solution tient en un mot : les métadonnées. Les métadonnées, étymologiquement « les données sur les

données », représentent toute l’information sur le document, information qu’il va falloir conserver avec le

document pour en assurer l’intelligibilité dans le futur.

B. XML et l'archivage électronique (4)

Dans le domaine de l'archivage électronique, le langage XML s'est avéré être le langage idéal pour répondre aux

besoins établies par les contraintes du domaine archivistique. Pour l'archivage à long terme, il fallait utiliser un

format non propriétaire pour assurer la réutilisation des données à long terme, ce qui est le cas du langage XML.

Voici les principaux avantages apporté par le langage XML :

L'interopérabilité : les systèmes informatiques arrivent à utiliser XML pour échanger des données

informatiques.

Format libre, non propriétaire : pratique pour l'archivage à long terme et pour l'accès à la

majorité des utilisateurs.

Liberté pour le choix des balises : Contrairement au langage HTML, on peut utiliser les données

que l'on souhaite dans les balises.

Facilité d'indexation : l'indexation est importante dans le domaine archivistique pour retrouver des

informations rapidement, XML permet cela.

C. La valeur probante d'un document :

Définition " La valeur probante ou de preuve d’un document désigne la faculté d’un document à être utilisé par

celui qui réclame l’exécution d’une obligation ou qui se prévaut d’un fait qui a produit l’extinction de son

obligation. Pour un document électronique, cette valeur est acquise depuis la loi du 13 mars 2000 qui en a fixé les

modalités (Art. 1316-1 CC)."

D. Archivage électronique : définitions et objectifs

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

La nature des archives produites par une collectivité reste identique quelque soit le support utilisé.

Différence entre stockage et archivage

Il faut différencier stockage et archivage. Alors que le premier n’est que la conservation de données

brutes, le second consiste non seulement en stockage mais aussi en indexation, mutation du support pour assurer

une consultation durable et une certification du contenu pour garantir la conformité d’un document/flux au

regard d’une réglementation pour en conserver sa valeur probante.

XDEMAT

22

Rap

port

de

stag

e| 1

3/09

/20

10

Une fois échue leur Durée d'Utilité Administrative (DUA) ou juridique, les archives sont soit éliminées, soit

considérées comme ayant une valeur historique, et donc conservées définitivement.

E. Objectifs

L’archivage électronique des documents/flux à valeur probante doit poursuivre 4 objectifs :

a) Pérennité/réversibilité

Les documents créés par la collectivité et conservés soit par elle-même soit par un tiers sont déposés sur des

supports garantissant une consultation à minima égale à leurs DUA, voire pour une période plus longue si ce sont

des archives définitives. Les formats ouverts acceptés pour tous les types de documents (textes, plans, images,

etc.…) et la périodicité de la procédure de conversion sont des composantes essentielles à définir en début de

projet.

b) Communication

L’indexation du document par le système choisi doit permettre une consultation partielle ou totale du document.

Ainsi le document/flux est décrit dans un index hébergé sur un serveur distinct du serveur de stockage. Il

comporte outre la nature du document (délibération, arrêté, fiche de paye, dossier de travaux, déclaration fiscale

ou sociale, notation, etc.) et la date de création, les éléments suivants :

description libre,

les dates de début et de fin d’archivage,

la langue du contenu d'information (obligatoire),

la taille (nombre d'octets, nombre d'enregistrements, nombre de boîtes, etc.),

l'historique de la conservation (interventions pratiquées sur le contenu depuis sa création jusqu'à

son transfert dans un service d'archives),

la position du contenu d'information dans le plan de classement du service producteur,

des informations de format,

des références à des objets liés,

d'autres données descriptives,

le service producteur du contenu d'information et le service d'archives qui en est responsable,

des règles d'accès et de conservation,

des mots-clés.

Le contenu du document est stocké dans une base de données distincte et redondante.

Il est consultable dans l’index selon les droits d’accès définis dans la convention d’archivage par le service

d’archives ou par le demandeur d’archives.

XDEMAT

23

Rap

port

de

stag

e| 1

3/09

/20

10

c) Traçabilité

Pour un document à valeur probante comme pour des documents placés en archive définitive, il est

important de pouvoir suivre les étapes de conservation. L’index propose : l'historique de la conservation

(interventions pratiquées sur le contenu depuis sa création jusqu'à son transfert dans un service d'archives) et les

références de l’horodatage générés lors de la transmission.

d) Protection des données et archivage légal

Pour les documents/flux dont la valeur probante doit être certifiée en raison de leur exigence de conformité à

une réglementation pour être exécutoire, le système d’archivage électronique doit garantir la protection des

données et l’archivage légal des documents versés (garantie d’intégrité, force probatoire et copies certifiées

conformes).

F. L’organisation type d’un système d’archivage électronique

a) Les acteurs du processus

La production d’une archive par une collectivité et son versement vers un service idoine s’organise autour d’une

chaine d’acteurs dont les caractéristiques sont décrites ci-après.

- Service producteur : Les agents des collectivités produisent des documents qui sont soit imprimés,

signés et numérisés soit entièrement dématérialisés au travers des applications métiers. Ce service

transmet le document via un tiers de confiance au service de l’Etat concerné. L’horodatage de la

transmission et l’épuisement des délais légaux de recours confère la force probante.

- Service versant : chaque service producteur transfère les archives courantes périodiquement et selon

une procédure définie préalablement vers la plate-forme d’archivage électronique soit vers la direction

des systèmes d’information, la direction générale des services ou le service Archives de la collectivité.

- Service de contrôle : il vérifie l’intégrité des paquets de documents transmis vers la plateforme.

- Service d’Archives : il peut effectuer le versement des archives. Ses missions principales sont

l’indexation et la conversion des documents. Ce service est responsable du traitement des requêtes de

consultation et des éditions.

- Demandeur d’Archives (professionnels et grand public) : il consulte les documents archivés,

effectue des requêtes et demande le cas échéant des copies conformes.

b) Le contrat

Un engagement entre la collectivité et le service ou le tiers chargé de l’archivage définit les modalités de transfert

d’archives et d’élimination, les modalités de communication entre un système producteur, un système versant et

un système d’archivage. Sur le plan technique, il définit les formats de documents acceptés, le type et la structure

des archives versées et la périodicité des versements. Le contrat permet à la plate-forme de gérer les versements

et au service de contrôle de réaliser des audits du système.

XDEMAT

24

Rap

port

de

stag

e| 1

3/09

/20

10

c) La protection des données

Dans le cas de documents à valeur probante ou de documents signés électroniquement, la règlementation liée au

protocole standard d’échange impose la génération de fichiers d’identification et de vérification :

l’empreinte : associée à un fichier ou à une partie de fichier pour en contrôler l’intégrité

la signature : le standard permet d’insérer une signature électronique. Les signatures apposées à

l’origine sur les données versées, demeurent avec les données dans leur format d’origine

d) Le processus type d’Archivage électronique

La figure suivante décrit le processus type d'archivage électronique du versement à la communication.

Figure 5 Processus type d'archivage électronique

XDEMAT

25

Rap

port

de

stag

e| 1

3/09

/20

10

e) L’indexation et les métadonnées

Le document/flux est décrit dans un index hébergé sur un serveur distinct, la base descriptive. Celle-ci contient

les métadonnées destinées à identifier et référencer le document.

Les renseignements contenus dans cet index sont constitutives de la base de méta données qui serviront, dans

l’espace de communication, à rechercher des documents à partir d’un moteur de recherche.

f) La conversion

Assurer la réversibilité des documents consiste à anticiper les détériorations des supports de stockage dans le

temps, l’évolution des formats de documents tout en valorisant le patrimoine documentaire de la collectivité.

Selon les termes du contrat propre à chaque collectivité, les formats de fichiers acceptés par les plates-formes

d’archivage électronique diffèrent.

Pour les logiciels de conversion, il apparaît préférable de privilégier des logiciels libres, rapides, compatibles avec

la plateforme d’archivage électronique, facilement compréhensible et bénéficiant d’un support technique de

bonne qualité.

g) Les facettes d'un projet d'archivage numérique

Un projet portant sur un Système d’Archivage Electronique est complexe et doit obligatoirement aborder toutes

les facettes du projet :

Organisationnel : Missions et responsabilité de la collectivité, des directions et Services versant en

prenant en compte les Archives Départementales. Prise en compte d’objectifs et de cultures

différentes, Archivistique et Informatique, appelées à converger pour la mise en œuvre d’un SAE

commun et sur l’ensemble du cycle de vie des archives (record management).

Métiers et Réglementation Sectoriels : Activités prenant en compte les bonnes pratiques et les

contraintes du secteur (métiers).

Fonctionnel : Les échanges (Flux documents) entre les entités et les processus, les accès à

l’information.

Veille et contexte Normalisation : Les projets analogues, projets pilotes, notamment avec la

Direction des Archives de France et le contexte normatif pour guider et conseiller sur les modalités

et les moyens à mettre en œuvre. La mise en conformité des applications versantes ainsi que du

système d’archivage électronique s’il est déjà installé.

Juridique : Ce que dit la loi et ce qu’elle ne dit pas dans le cadre de la dématérialisation des

documents (valeur "probante" du document électronique)

Infrastructure : Stockage et Gestion "hiérarchique" des supports, Compromis

Usage/Performances / Coûts, contraintes Réseaux

XDEMAT

26

Rap

port

de

stag

e| 1

3/09

/20

10

VIII. Cadre normatif

A. MOREQ2

MoReq216 propose des spécifications génériques pour un système d’archivage électronique [SAE ou

ERMS (Electronic Records Management System)]. Il s’agit d’une version mise à jour et enrichie du premier

Modèle d’exigences pour l’organisation de l’archivage électronique, publié en 2001.

MoReq2 est destiné à être employé par un large éventail d’organisations des secteurs public et privé qui

souhaitent développer un système d’archivage électronique. Il peut être utilisé pour la rédaction des cahiers des

charges, l’évaluation des systèmes existants, la préparation de supports de formation à la gestion documentaire,

etc.

Forum DLM

MoReq2 a été développé par la Commission européenne à la demande du forum DLM17 (Document Lifecycle

Management), une organisation européenne indépendante regroupant des services d’archives et d’autres

organisations publiques et privées intéressées par l’archivage électronique, le records management et la gestion de

l’information.

B. Dublin Core (4)

La norme de métadonnées du Dublin Core est un ensemble d'éléments simples mais efficaces pour

décrire une grande variété de ressources en réseau. La norme du Dublin Core comprend 15 éléments dont la

sémantique a été établie par un consensus international de professionnels provenant de diverses disciplines telles

que la bibliothéconomie, l'informatique, le balisage de textes, la communauté muséologique et d'autres domaines

connexes.

Chaque élément est optionnel et peut être répété. Chaque élément possède également un ensemble limité de

qualificatifs, des attributs qui peuvent être utilisés afin de raffiner davantage (et non pas étendre) la signification de

l'élément. L'Initiative de métadonnées du Dublin Core (IMDC) a défini, en juillet 2000, des façons normalisées de

"qualifier" les éléments au moyen de différents types de qualificatifs.

Bien que le Dublin Core favorise la description d'objets ressemblant à des documents (car la description des

ressources textuelles traditionnelles est une activité bien maîtrisée), son usage pour la description des ressources

ne ressemblant pas à des documents traditionnels va dépendre, jusqu'à un certain point, des similitudes entre les

métadonnées de ces nouveaux documents par rapport aux métadonnées habituelles d'un document. Il va aussi

dépendre des objectifs visés par les métadonnées de ces nouveaux documents. (4)

Vous pouvez trouver la liste des éléments composant le Dublin Core en Annexe B.

16http://www.dlmforum.eu/index.php?option=com_content&view=category&layout=blog&id=901&Itemi

d=20&lang=en 17

http://www.dlmforum.eu/

XDEMAT

27

Rap

port

de

stag

e| 1

3/09

/20

10

C. NFZ 42013 (5)

La norme NF Z 42-013 énonce un ensemble de spécifications de l'AFNOR18 concernant les mesures

techniques et organisationnelles à mettre en œuvre pour l'enregistrement, le stockage et la restitution de

documents électroniques afin d'en assurer la conservation et l'intégrité.

Le titre de la norme révisée en mars 2009 a évolué : "Spécifications relatives à la conception et à l'exploitation de

systèmes informatiques en vue d'assurer la conservation et l'intégrité des documents stockés dans ces systèmes"

La norme révisée est destinée :

aux organismes ou entreprises qui souhaitent mettre en œuvre des systèmes informatiques dans lesquels

ils pourront stocker des images des documents électroniques de telle façon que leur fidélité et leur

intégrité par rapport aux documents d'origine soient assurées ;

aux éditeurs de systèmes d'archivages électroniques;

aux sociétés de services informatiques qui désirent concevoir ces systèmes ;

aux entreprises de services assurant le stockage de documents électroniques.

Positionnement de la norme vis à vis de MOREQ

La norme révisée en 2009 mentionne dans son introduction qu'elle permet de préciser de manières

différentes ou complémentaires des sujets qui ont été abordés dans d'autres normes ou spécifications. Elle fait

référence en particulier à la norme ISO 15489, au Moreq et à la norme ISO 14721 (OAIS).

La norme NF Z 42-013 s'attache à l'essentiel pour la préservation des documents électroniques. Elle précise les

exigences pour répondre au besoin de pérennité, d'intégrité et de sécurité. Dans le MoReq2, les mêmes points

sont abordés mais de nombreuses exigences complémentaires sur des périmètres fonctionnels complémentaires

sont également abordées. L'exemple des plans de classement abordé par MorReq2 illustre la différence

d'approche entre la norme et le MoReq.

La norme n'a aucune exigence sur la manière dont il faut classer des documents puisqu'elle estime que le fait de

classer des documents n'apporte rien de plus quant à l'intégrité, la sécurité et à la pérennité des documents. A

l'inverse, le MoReq2 estime que sans plan de classement, il n'est pas possible de mettre en place un SAE et

mentionne 91 exigences rien que sur ce point.

D. OAIS (Open Archival Information System)

Le modèle de référence OAIS - Reference Model for an Open Archival Information System - est le résultat d’un

travail du CCSDS - Consultative Committee for Space Data Systems (organisme international de normalisation

des agences spatiales) - réalisé à la demande de l’ISO.

18 AFNOR : groupe international de services organisé autour de 4 grands domaines de compétences :

la normalisation, la certification, l’édition spécialisée et la formation.

XDEMAT

28

Rap

port

de

stag

e| 1

3/09

/20

10

OAIS est un modèle abstrait. Il définit une terminologie et des concepts. Il identifie les acteurs, décrit les

fonctions et les flux d’information, et propose un modèle d’information particulièrement adapté à la

problématique de l’archivage numérique, même s’il ne préjuge pas de la nature des objets à archiver.

OAIS n’est pas un recueil de spécifications techniques destinées à être directement implémentées. C’est un guide

qui cerne la problématique dans son ensemble et qui contraint à se poser toutes les bonnes questions.

En tant que modèle conceptuel de référence, OAIS s’est aujourd’hui largement imposé, au niveau international,

auprès de tous les acteurs institutionnels de l’archivage numérique.

a) Les acteurs de l’archivage

Le modèle OAIS identifie quatre rôles principaux dans un système d’archivage :

Un acteur interne, l’ « archive », c’est-à-dire l’opérateur du système d’archivage, trois acteurs externes : le «

management », les « producteurs » et les « utilisateurs ».

Le « management » assure la fonction de décideur politique. Pour le management, le système

d’archivage s’insère dans un plan stratégique global dont il n’est qu’un élément parmi d’autres.

C’est évidemment au management qu’il revient de soutenir le dispositif, politiquement,

financièrement, et sur le très long terme.

Les « producteurs » sont les personnes, ou plus vraisemblablement les organismes, qui

fournissent les objets à archiver. Les objets numériques sur lesquels travaillent les producteurs avant

archivage sont les SIP (submission information package). Une fois archivés, ils deviennent les AIP

(archival information package), objets internes à l’Archive.

Les « utilisateurs », quant à eux, sont les organismes et les personnes qui ont accès aux copies de

ces objets archivés. Les objets numériques mis à la disposition d’utilisateurs sont les DIP

(dissemination information package). OAIS identifie une classe particulière d’utilisateurs - la «

communauté d’utilisateurs cible » - comme étant la population prioritairement bénéficiaire du

service d’archivage. Les services à fournir seront distincts selon que la communauté d’utilisateurs

cible est nombreuse ou non, experte ou « grand public », etc.

XDEMAT

29

Rap

port

de

stag

e| 1

3/09

/20

10

b) Les fonctions de l’archivage

Le modèle OAIS cartographie un système d’archivage selon 6 grands domaines fonctionnels.

Figure 6 Les six fonction du modèle OAIS

L’entité « entrées » reçoit, contrôle et valide les objets à archiver. Les objets eux-mêmes sont transmis

à l’entité « stockage », tandis que les informations nécessaires à leur description et à leur gestion dans le

temps sont transmises à l’entité « gestion des données ».

L’entité « stockage » assure la conservation physique des objets archivés. Elle tient les objets archivés à

la disposition de l’entité « accès ». Conformément aux règles établies par l’entité « administration », elle

prend en charge la réalisation des copies multiples et le renouvellement des supports anciens.

L’entité « gestion des données » prend en charge la tenue à jour de toutes les informations internes -

base de données - nécessaires au système d’archivage. Elle fournit aux autres entités du système les

informations descriptives des objets archivés (notamment à l’entité « accès ») et toutes les informations

de gestion techniques et archivistiques nécessaires.

L’entité « administration » assure la coordination générale du système. Elle en établit les règles

internes. Elle veille à la qualité globale du service rendu et à son amélioration. Elle rend compte au

management.

L’entité « planification de la pérennisation » est la cellule de veille et de planification du système.

Elle « écoute » l’environnement extérieur et émet des recommandations en vue de procéder aux

évolutions nécessaires, notamment aux évolutions de type technologiques. Elle prépare et planifie ces

évolutions. Elle est également responsable du suivi des changements qui peuvent s’opérer dans la «

communauté d’utilisateurs cible » cible en vue de garantir que le service d’accès reste conforme aux

attentes nouvelles des utilisateurs.

L’entité « accès » regroupe tous les services qui sont en interface directe avec les utilisateurs. Outre les

fonctions de contrôle d’accès, il s’agit principalement de permettre aux utilisateurs de rechercher dans le

« catalogue » des objets archivés, et de leur fournir les objets dont ils passent commande.

XDEMAT

30

Rap

port

de

stag

e| 1

3/09

/20

10

Remarque Le terme « Open » de OAIS signifie simplement que le modèle, c’est-à-dire le contenu du document de

référence, n’est pas sous « copyright » et qu’il est donc librement diffusable et utilisable.

E. ISAD(G)

La norme générale et internationale de description archivistique (en anglais General International Standard

Archival Description), communément désigné sous le sigle ISAD(G), a été publiée officiellement par le conseil

international des archives en 1994. La dernière version date de 1999.

Son objectif est de permettre la diffusion d'informations sur le contenu et l'intérêt des fonds d'archive tant entre

services d'archives qu'à destination des chercheurs, grâce à des descriptions homogènes, des fichiers d'autorité

communs et des accords sur les formats d'échange.

Elle repose sur trois principes :

- Validité du concept de fonds et donc du principe de respect des fonds,

- Correspondance entre les niveaux de classement et les niveaux de description,

- Liaison hiérarchique des descriptions d'un niveau à l'autre.

Elle comporte 26 éléments descriptifs dont la combinaison permet de décrire n'importe quelle unité archivistique.

Ces éléments sont répartis en 6 zones : identification, contexte, contenu, conditions d'accès, sources

complémentaires et notes.

La première zone qui est la plus importante comprend la cote de l'unité décrite, l'intitulé qui en résume le

contenu, les dates extrêmes, le niveau de description choisi et des indications sur le volume de l'unité décrite

(métrage linéaire, nombre de pièces, etc.).

ISAD(G) ne traite pas de la gestion matérielle, de l'indexation et des règles d'écriture et de vocabulaire.

Voici la liste des descripteurs ISAD(G)

1- Zone d'identification 1.1 Référence 1.2 Intitulé/analyse 1.3 Dates 1.4 Niveau de description 1.5 Importance matérielle et support de l'unité de description

2- Zone du contexte 2.1 Nom du producteur 2.2 Histoire administrative/Notice biographique 2.3 Historique de la conservation 2.4 Modalités d'entrée

3- Zone du contenu 3.1 Présentation du contenu 3.2 Evaluation, tris et éliminations, sort final 3.3 Accroissements 3.4 Mode de classement

4- Zone des conditions d'accès et d'utilisation

4.1 Conditions d'accès 4.2 Conditions de reproduction 4.3 Langue et écriture des documents 4.4 Caractéristiques matérielles 4.5 Instruments de recherche

5- Zone des sources complémentaires 5.1 Existence et lieu de conservation des originaux 5.2 Existence et lieu de conservation des copies 5.3 Sources complémentaires

6- Zone des notes 6.1 Notes

XDEMAT

31

Rap

port

de

stag

e| 1

3/09

/20

10

5.4 Bibliographie

7- Zone du contrôle de la description 7.1 Notes de l'archiviste 7.2 Règles ou convention 7.3 Date(s) de la description

F. EAD (Encoded Archival Description)

L'EAD (Description d'archive en français) est un format basé sur le langage XML qui permet de

structurer des descriptions de manuscrits ou de documents d'archives19.

Destiné à la description d'une production documentaire (métadonnées descriptives), L'EAD permet de structurer

les instruments de recherche de type archivistique : inventaire, répertoire, catalogue de collection…

L'EAD est utilisé en particulier par les services d’archives, bibliothèques et musées pour décrire des fonds

d’archives, des collections de manuscrit et des collections hiérarchisées de documents ou d’objets (photographies,

microfilms, pièces de musée).

Ce format a été initialement conçu pour permettre le traitement rétrospectif des instruments de recherche

existants, documents imprimés ou produits avec des outils de traitement de texte dans la perspective d'une

édition papier. Ceci explique que :

- la structure générale du modèle reste proche de celle des documents imprimés ;

- les règles d'utilisation sont peu contraignantes, afin de pouvoir être adaptées à des contextes

divers ;

- le modèle combine des éléments de description structurée et des éléments d'encodage de texte.

L'EAD est également et de plus en plus utilisé pour produire les instruments de recherche en XML.

Les utilisateurs de l'EAD ont à leur disposition une DTD (solution majoritairement utilisée en France) et un

schéma XML, dans une version qui date de 2002.

Ce format respecte les principes définis par la norme internationale éditée par le Conseil international des archives

en 2000 : ISAD (G).

a) La structure de base d'un fichier XML/EAD

L'EAD est une DTD utilisée pour décrire des fonds d’archives, des collections de manuscrits et plus généralement

tout ensemble hiérarchisé de documents.

Un schéma XML a été élaboré pour l’EAD (version 1.0, mars 2007), pour mieux suivre les évolutions techniques

du XML :

- pour permettre une saisie plus cohérente des données ;

- pour être en mesure d’inclure le schéma EAD dans d’autres schémas ou d’inclure d’autres DTD ou d’autres

schémas dans l’EAD ;

- pour gérer la Tag Library et les règles de gestion dans un document unique.

19 http://www.bnf.fr/fr/professionnels/formats_catalogage/a.f_ead.html

XDEMAT

32

Rap

port

de

stag

e| 1

3/09

/20

10

La DTD EAD contient 146 éléments dont 8 seuls sont obligatoires. Nous allons présenter les balises principales

d'un fichier XmlEad.

La racine d'un XmlEad est la balise <ead>, puis viennent trois balises, dont deux sont obligatoires, les voici :

L'élément <eadheader> (Obligatoire)

Les informations bibliographiques et descriptives qui définissent l'instrument de recherche sont diverses (titre,

date, auteur, etc.). Ces informations sont intégrées dans la balise <eadheader>, et sont indexées avec les balises

correspondantes. L'élément <eadheader> ne prend pas en considération les informations sur les documents

d'archives que contient l'instrument de recherche.

L'élément <frontmatter>

Elément préliminaire, il sert à créer une page de titre ou une première de couverture (il permet d’intégrer

des logos, des photographies) ; on peut aussi y intégrer une préface, une note technique pour le public ou les

professionnels (projet scientifique…), un mode d’emploi de l’instrument de recherche. Dans notre travail sur les

instruments de recherche des archives municipale de Versailles, nous n’avons pas utilisé cet élément.

L'élément <archdesc> (Obligatoire)

La description des documents d'archives contenus dans l'instrument de recherche est encodée à l'intérieur de

la balise <archdesc>. Il englobe toutes les informations décrivant un corpus documentaire dans son ensemble et

recouvrant les différents niveaux hiérarchiques de cette description.

L’élément <archdesc> comprend des informations de haut niveau : identification du fonds (élément <did>),

biographie/histoire institutionnelle (élément <bioghist>) ; puis on décrit les parties du fonds dans l’élément

<dsc> Description des sous-composants, en commençant par le niveau hiérarchique le plus élevé et en allant si on

le souhaite jusqu’au niveau de la pièce, et ce via l'élément <c>. Les différents niveaux de l'arborescence sont

marqué via l'attribut "LEVEL" de la balise <c>.

b) Objectifs de l'EAD

Ce format a été développé dans les années 1990 à l'initiative de la bibliothèque de l'Université Berkeley avec pour

objectifs :

de développer un modèle permettant de traiter les instruments de recherche existants, dans leur

diversité de forme et de structure ;

de restituer l'organisation hiérarchisée des instruments de recherche (reflet de la structure des fonds

décrits) et les interrelations entre les composants ;

de conserver le principe d'héritage des informations entre les niveaux (sauf mention contraire, une

information relative à un niveau supérieur s'applique également aux niveaux qui lui sont

subordonnés).

Remarque : Nous avons découvert au cours de ce travail, une source d'instruments de recherche normé EAD qui nous a bien

servi pour appréhender cette norme. Cette source fourni également des exemples sur la norme EAC et leur

équivalent en format PDF.

Cette source est le site des archives de la ville de Genève : http://www.ville-ge.ch/geneve/archives/

XDEMAT

33

Rap

port

de

stag

e| 1

3/09

/20

10

G. ISAAR (CPF), (International Standard Archival Authority Record for Corporate Bodies, Persons and Families)

La traduction française d'ISAAR est Norme Internationale sur les notices d'autorités archivistiques relatives aux

collectivités, aux personnes et aux familles.

Elle permet de décrire les producteurs d'archives et le contexte des documents. Elle prolonge ISAD(G) qui traite

du contenu des documents.

La présente norme fournit les lignes directrices pour la préparation de notices d'autorité qui offre la description

d'entité (collectivités, personnes ou familles) associées à la production et à la gestion des archives.

a) Notice d'autorité

Notice associant une forme autorisée du nom d'une entité à des éléments d'information qui permettent d'identifier

et de décrire cette entité, et qui peuvent la mettre en relation avec d'autres notices d'autorité (Authority record).

Les notices d'autorité peuvent être utilisées :

Pour décrire une collectivité, une personne ou une famille, en tant qu'unité à l'intérieur d'un

système d'information archivistique,

Pour contrôler la création et l'utilisation de points d'accès dans les descriptions archivistiques,

Pour apporter des informations sur les relations entre différents producteurs d'archives, entre

ces entités et les archives ou d'autres ressources qu'elles produisent ou qui les concernent.

La production des producteurs d'archives est une activité essentielle des archivistes, que ceux-ci travaillent dans

un environnement manuel ou informatisé. Cette activité requiert une documentation complète et régulièrement

mise à jour, sur le contexte de production et d'utilisation des documents, en particulier sur leur provenance.

Les éléments de description d'une notice d'autorité archivistique sont regroupés en quatre zones :

- La zone d'identification : on y trouve les informations qui identifient de manière unique le

producteur, et qui définissent un point d'accès standardisé.

- La zone de description : on y trouve les informations sur la nature, le contexte et les activités du

producteur

- La zone des relations : on y trouve mentionnées et décrites les relations avec les autres

collectivités, personnes ou familles.

- La zone du contrôle de la description : on y trouve le numéro international d'identification de

la notice d'autorité, et les informations qui précisent comment, quand et par quel service cette notice

a été créée et mise à jour.

XDEMAT

34

Rap

port

de

stag

e| 1

3/09

/20

10

H. EAC (Encoded Archival Context)

Décrire les archives implique aussi de fournir des informations sur les circonstances entourant leur

production et leur utilisation. Les archives sont en effet des documents provenant d’un producteur avant d’être

des documents portant sur des sujets particuliers.

Connaître le contexte de production des archives est essentiel pour comprendre l’organisation et le contenu

informationnel de ces documents. L’historique de la conservation des documents d’archives, de leur mode de

classement et des circonstances entourant leur production et leur utilisation contribue à établir leur authenticité.

EAC est une implémentation de la norme ISAAR (CPF), c'est pourquoi, le schéma EAC-CPF se limite à la

description des collectivités, des personnes et des familles. D’autres spécialisations de l’EAC seront élaborées

pour la description des autres entités composant le contexte de la description archivistique.

Atouts de l'EAC-CPF

L’EAC-CPF permet de gérer la description des collectivités, des personnes et des familles de manière

autonome, en la séparant de la description des documents d’archives en EAD.

Les collectivités, personnes et familles peuvent jouer des rôles directs dans la création, dans la conservation et

dans l’utilisation des documents d’archives, mais aussi en être des sujets ou entretenir d’autres types de relations

avec ces documents. L’EAC-CPF permet de mettre en relation ces entités avec les descriptions archivistiques en

EAD.

Ce schéma s'efforce également d’expliciter la nature de ces relations. L’EAC-CPF crée ainsi les conditions pour le

partage et la réutilisation de l’information sur les collectivités, les personnes et les familles. Dans un souci

d’interopérabilité avec d’autres schémas de métadonnées exprimés en XML, il s'appuie sur l'état de l'art en la

matière.

I. SEDA (Standard d'Echange de Données pour l'Archivage)

a) Présentation du SEDA

Le SEDA est un standard mis en place par la direction des archives de France afin de faciliter le transfert de

données pour l’archivage en France. Ce standard s'appuie sur l'utilisation du langage XML.

Ce standard se base sur différentes normes déjà établies : OAIS, ISAD(G), Moreq 2 et PREMIS

Bref présentation de PREMIS (Preservation Metadata : Implementation Strategies)

La version 2.0 a été publiée en 2008, elle décrit la liste des métadonnées de préservation des données. Le SEDA

étant Utilisée pour l’échange de données, PREMIS a été utilisé pour vérifier qu’aucune information de

pérennisation, à fournir par le service versant, n’avait été oubliée.

En plus des normes citées, SEDA s’est inspiré des notions suivantes :

le langage XML, recommandation du W3C ;

la DTD EAD (Encoded Archival Description) ;

le format d’encodage base64 ;

les travaux de l’UN/CEFACT, organisme des Nations Unies qui promeut le développement et

la simplification des échanges électroniques professionnels, du commerce électronique et des

procédures administratives.

XDEMAT

35

Rap

port

de

stag

e| 1

3/09

/20

10

b) Les acteurs

Le service d’archive (Archival Agency)

Entité destinataire du transfert et assure la gestion des archives transférés par les services versants.

Le service versant (Transferring Agency)

Entité qui transfert un ensemble de données vers un service d’archive.

Le service producteur (Originating Agency)

Entité qui a produit les archives.

Le service de contrôle (Control Authority)

Certain messages ne sont émis qu’après validation par un service de contrôle. Dans le secteur public en France, ce

service de exerce le contrôle scientifique et technique sur les archives.

Demandeur d’archive (Access Requester)

Toute personne physique ou morale qui souhaite consulter les archives conservées par le service d’archive.

c) Les objets échangés

On a parlé d’échange d’archives entre deux acteurs, mais qu’est ce qu’une archive exactement? Un ensemble de

documents, numériques ou papiers ? Comment gère t on l’intégrité ? L’authenticité ?

Archive (Archive)

Ensemble d’information associant :

un contenu de données, c.-à-d. le ou les objets numériques ou physiques qui sont l’objet principal

de la pérennisation ;

des informations de représentation qui traduisent le contenu de données en des concepts plus

explicites (par exemple, la définition du code ASCII décrit comment une séquence de bits (un

contenu de données) est convertie en caractères) ;

des informations de pérennisation qui sont les informations nécessaires à une bonne conservation

du contenu d’information (information de provenance, d’identification, d’intégrité, de contexte).

Le contenu de données et les informations de représentation correspondantes forment le contenu d’information.

Remarques : Les informations de représentation sont particulièrement importantes dans le cas où il s’agit de conserver des

objets numériques.

Une archive comporte obligatoirement une description de contenu, et peut comporter des documents joints. Elle

peut également être subdivisée en Objets d’archives, dotés de propriétés similaires.

XDEMAT

36

Rap

port

de

stag

e| 1

3/09

/20

10

L’Archive possède un identifiant, un intitulé (Obligatoire), une indication du niveau de description (Obligatoire),

ainsi que les attributs suivants :

Accord d’archivage (Archival Agreement) : accord (convention, contrat) ou texte

réglementaire servant de cadre aux relations entre le service versant et le service d’archives ;

Type d’archive (Archival Profile) : règles de constitution de l’archive en fonction du type de

documents ou d’application concernée ;

Langue de la description (Description Language) - obligatoire ;

Niveau de service (Service Level) : niveau de service demandé (disponibilité, sécurité...), en

référence aux différents niveaux prévus par le contrat ou la convention passée entre le service versant et

le service d'archives.

Objet d’archives (Archive object)

Définit comme une subdivision intellectuelle de l’archive. Les objets d’archives peuvent être eux-mêmes

subdivisés en objets. Il existe ainsi différents niveaux de description qui indiquent le type de regroupement

effectué : fonds, série, dossier, pièce…etc.

Description du contenu (Content Description)

La description du contenu est obligatoire pour l’archive, facultative pour l’objet d’archive.

La description permet d'indiquer :

- une description libre, dont la confidentialité éventuelle doit être obligatoirement précisée (par

exemple si des noms de personnes figurent dans cette description) ;

- les dates de début et de fin ;

- la langue du contenu d'information (obligatoire) ;

- la taille (nombre d'octets, nombre d'enregistrements, nombre de boîtes, etc.) ;

- l'historique de la conservation (interventions pratiquées sur le contenu depuis sa création jusqu'à

son transfert dans un service d'archives) ;

- position du contenu d'information dans le plan de classement du service producteur ;

- des informations de format ;

- des références à des objets liés ;

- d'autres données descriptives.

Elle peut mentionner par ailleurs :

le service producteur du contenu d'information et le service d'archives qui en est responsable ;

des règles d'accès et de conservation ;

des mots-clés.

XDEMAT

37

Rap

port

de

stag

e| 1

3/09

/20

10

Document (Document)

Document joint à l’archive ou à l’objet d’archive comportant une ou plusieurs pièces jointes.

Les documents joints servent essentiellement à transporter

le contenu de données ;

des informations de représentation.

Remarque : Les informations de pérennisation (origine des données, description, dates, mots-clés, etc.) doivent

obligatoirement être saisies dans les attributs prévus a cet effet chaque fois que cela est possible. Si ce n’est pas

possible, elles peuvent êtres fournies en document joint.

Les descriptions de données constituées selon une structuration particulière propre au métier du producteur

peuvent également est fournies en document joint.

Une pièce jointe peut correspondre à :

un fichier informatique (file), c’est-à-dire une séquence de bits nommée et ordonnée

connue par un système d’exploitation

un train de bits (bitstream), c’est-à-dire un ensemble de données, contiguës ou non, à

l’intérieur d’un fichier, qui a des propriétés de conservation particulières (exemple : une image à

l’intérieur d’un fichier TIFF qui en contient plusieurs) – pour être transformé en fichier

autonome, un train de bits doit au minimum être augmenté d’une structure de fichier (en-tête

etc.) et/ou reformaté pour être conforme à un certain format ;

un fichier encapsulé (filestream), c’est-à-dire un train de bits encapsulé qui peut être

transformé en un fichier autonome sans qu’il soit nécessaire de lui ajouter aucune information

(exemple : un fichier TIFF à l’intérieur d’un fichier TAR, un fichier PDF encodé en base 64 et

encapsulé dans un fichier XML, etc.).

un objet physique (un dossier, une boîte, un CD-Rom...).

Une pièce jointe est caractérisé par :

- son URI;

- son type MIME (exemple : application/pdf) ;

- son format, indiqué de manière plus précise que le simple type MIME (par exemple : PDF 1.4) ;

- son encodage, s’il s’agit d’un fichier binaire converti en caractères au moyen d’un système

d’encodage (exemple : base 64) ;

- son jeu de caractères (exemple : ISO-8859-1) ;

- son nom de fichier, lorsqu’il s’agit d’un fichier en tant que tel ;

- son contenu, dans le cas où les données sont encapsulées dans le message.

XDEMAT

38

Rap

port

de

stag

e| 1

3/09

/20

10

Plusieurs pièces jointes formant une même unité intellectuelle et possédant les mêmes propriétés pour l’archivage

(durée de conservation, règles d’accès, producteur...) peuvent être groupées dans un même document. Par

exemple : un fichier HTML et ses images liées formant une page Web ; les images PNG des pages d’un même

dossier.

Le document joint peut comporter une description sommaire. Il est notamment indispensable d’indiquer son

type : contenu de données, information de représentation, information de pérennisation.

Empreinte (Hash Code)

Empreinte associée à un fichier ou une partie de fichier aux fins d'en contrôler l'intégrité.

Signature (Signature)

Information garantissant l'intégrité ou l'authentification ou l'approbation d'un fichier ou d'une partie de fichier. Le

standard d'échange permet d’insérer soit une signature XMLDsig2, soit une signature PKCS73, moins complète

mais plus courante à ce jour.

NB : Afin d’avoir une meilleure vision d’une archive et des liens avec les autres composants, je vous recommande

de vous référer aux diagrammes de classes fourni dans la version 2.0 du standard de données des échanges.

d) Diagramme de classe d'une archive Complète :

XDEMAT

39

Rap

port

de

stag

e| 1

3/09

/20

10

e) Les transactions

On appelle transaction, un échange de données (archives) entre deux acteurs. Il existe cinq transactions distinctes :

- Transfert d’archive Transmission d’archives par un service versant à un service d’archives en vue de lui en confier la conservation.

XDEMAT

40

Rap

port

de

stag

e| 1

3/09

/20

10

- Communication d’archive Transmission d’archives par un service d’archives à un demandeur d’archives, avec l’autorisation, le cas échéant,

du service producteur et du service de contrôle compétent.

- Notification de modification d’archive Information envoyé par un service d’archive à un service producteur pour le prévenir que des archives provenant

de lui en été modifiées par ce dernier afin d’en assurer une bonne conservation. Les modifications peuvent porter

sur les données elles mêmes (conversion de format par exemple) ou sur les métadonnées (ajout, correction, mise

à jour).

- Restitution d’archive Transmission d’archives par un service d’archive à un service producteur en vue de lui en restituer la garde.

- Elimination d’archive Elimination d’archives, soit à la demande du service d’archives, avec l’autorisation du service producteur et du

service de contrôle compétent, soit à la demande du service producteur avec l’autorisation du service de contrôle

compétent.

Exemple : élimination d'archives à la demande du service d'archive20

Lorsqu'un service d'archives propose une élimination d'archives qu'il conserve au service producteur de

ces archives, il envoie au service producteur les métadonnées des documents concernés, voire une copie des

documents eux-mêmes, afin que le service producteur puisse se prononcer en toute connaissance de cause.

Ce message entraîne la production en retour d'un accusé de réception et, dans un second temps, d'une acceptation

ou d'un refus d'élimination par le service producteur.

Le message portant acceptation de l'élimination comporte les métadonnées des archives concernées, afin que le

service d'archives puisse se protéger en cas de litige.

Le rejet de la demande est suivi d'un accusé de réception de la part du service d'archives, cet accusé de réception

pouvant être utile au service producteur au cas où les archives seraient malgré tout détruites par le service

d'archives. En cas d'acceptation, le service d'archives fait parvenir, une fois l'élimination effectuée, une

notification de cette destruction, rappelant l'identification des archives concernées par cette élimination.

Dans certaines situations, pour les archives publiques, la demande d'élimination doit également être soumise à

l'autorisation de services de contrôle (Archives nationales, directions des archives départementales). Dans ce cas,

une fois acceptation de la part du service producteur, une demande d'élimination est faite auprès du service de

contrôle, selon la même structure que la demande faite auprès du service producteur ; de la même façon, suivent

un accusé de réception puis une acceptation ou un rejet de la demande.

Tous les messages liés à l'élimination d'archives peuvent être signés, à l'exception de la demande initiale du service

d'archives et de la notification d'élimination.

20 Un exemple de message de transfert encodé en XML SEDA est présent dans le manuel officiel du SEDA. Téléchargeable

sur le lien suivant : http://www.references.modernisation.gouv.fr/standard-dechange-de-donnees-pour-

larchivage-seda

XDEMAT

41

Rap

port

de

stag

e| 1

3/09

/20

10

J. Synthèse sur les normes (6):

La gestion des archives est soumis à de nombreux textes de lois ainsi que de nombreuses normes ce qui

rends difficile la compréhension des relations entre ces différents textes.

Le schéma ci-dessous présente une version extrêmement synthétique de ce contexte.

SEDA

Standard d'Echange de Données Archivistiques

ISAD(G)

Description des archives

OAIS

Contexte général : archivage électronique

MOREQ2

(Préconisation pour la mise en place d'un SAE)

Normes

Outils

EAD

ISAAR

Description des producteurs

d'archives

EAC

XDEMAT

42

Rap

port

de

stag

e| 1

3/09

/20

10

Chapitre 3 : Gestion de projet et outil

collaboratif.

I. Méthodologie de gestion de projet.

Pour réaliser notre projet de stage, nous nous sommes appuyés sur le modèle "cycle en V".

Le modèle du cycle en V est un modèle conceptuel de gestion de projet imaginé suite au problème de

réactivité du modèle en cascade. Il permet, en cas d'anomalie, de limiter un retour aux étapes précédentes. Les

phases de la partie montante doivent renvoyer de l'information sur les phases en vis-à-vis lorsque des défauts sont

détectés, afin d'améliorer le logiciel.

Le cycle en V est devenu un standard de l'Industrie logicielle depuis les années 1980 et depuis l'apparition de

l'Ingénierie des Systèmes est devenu un standard conceptuel dans tous les domaines de l'Industrie. Les phases à

Les étapes du modèle sont les suivantes :

Analyse des besoins et faisabilité

Spécification logicielle

Conception architecturale

Conception détaillée

Codage

Test unitaire

Test d'intégration

Test de validation (Recette Usine, Validation Usine - VAU)

Recette (Vérification d'Aptitude au Bon Fonctionnement - VABF)

Une des différences entre la recette usine et la recette finale est essentiellement contractuelle. Aussi, il

n'est pas rare que le MOA (Maître d'Ouvrage) délègue la validation auprès d'un organisme de validation, cet

organisme étant bien souvent constitué d'experts afin de diminuer les erreurs de validation.

XDEMAT

43

Rap

port

de

stag

e| 1

3/09

/20

10

II. L'Outil collaboratif : Microsoft Online Services

J'ai eu l'occasion durant le stage de travailler sur un outil collaboratif qui a attiré mon attention, et que je souhaite

vous présenter.

Le géant de l'informatique Microsoft, a créé des services accessibles via un portail, qui ont pour objectifs de

faciliter le travail en équipe et à distance. Il devient alors possible de collaborer avec ses collègues à distance. On

entend par collaborer : échange de documents, réaliser des réunions en vidéoconférence, synchroniser les

calendriers, liste des tâches, forum de discussion…etc.

Des collectivités privés et publiques utilisent ces services de plus en plus car, ils offrent un formidable moyens de

collaborer et de partager des documents, des présentations sans être présent physiquement.

J'ai découvert deux services intéressants que voici

A. SharePoint :

Les ingénieurs Microsoft ont pensé à créer un outil de travail de telle sorte que l’entreprise puisse créer une

collection de site par domaine de travail.

Dans un domaine bien précis, une entreprise peut avoir plusieurs projets. Par exemple, dans le domaine des

assurances, il peut y avoir un projet assurance automobile, assurance habitation…etc.

Dans une collection de site (appelé " site " par abus de langage), on peut créer plusieurs sites de divers modèles.

On peut voir ça comme un site contenant plusieurs pages internet, chaque page à un contenu bien spécifique.

Donc, chaque collection de sites peut contenir plusieurs sites de divers modèles : Site équipe de travail, Site

réunion, Wiki, Blog et un Site vide à remplir selon les besoins.

a) Les modèles de sites

- Site équipe de travail

Site qui permet aux équipes d'organiser et de partager rapidement des informations en toute simplicité. Il propose

une bibliothèque de documents et des listes de gestion des annonces, des éléments de calendrier, des tâches et des

discussions.

- Espace de travail de réunions de base

Site permettant de planifier, d'organiser et de collecter les résultats d'une réunion. Il propose des listes de gestion

de l'ordre du jour, des participants et des documents.

- Espace de travail du document

Site permettant à des collègues de travailler sur un même document. Il héberge une bibliothèque de documents

pour le stockage du document primaire et des fichiers connexes, une liste de tâches pour l'attribution de choses à

faire et une liste de liens renvoyant à des ressources relatives au document.

- Site wiki

Site permettant à une communauté d'organiser des brainstormings et de partager des idées. Il propose des pages

Web modifiables rapidement pour enregistrer des informations et ensuite liées à l'aide de mots-clés.

XDEMAT

44

Rap

port

de

stag

e| 1

3/09

/20

10

- Blog

Site permettant à une personne ou à une équipe de publier des idées, des observations et des connaissances que les

visiteurs du site peuvent commenter.

- Site vide :

Site vierge à configurer selon vos besoins.

Voici une illustration de la page d'accueil du portail entreprise :

B. Live Meeting :

Live meeting est le deuxième service offert par Microsoft Online, il fait parti des produits Microsoft

Office.

Cet un espace dédié aux réunions à distance en temps réel (Visio conférence). Après authentification, on

accède à la page du service "Live Meeting".

Les principales fonctionnalités sont disponibles sur le menu gauche de la page. Il est séparés en quatre actions :

Réunion, Gérer, afficher et administrer. Nous présentons dans ce rapport que la section réunion.

Réunion

Cette rubrique permet D'organiser une nouvelle réunion. Elle permet de définir les participants, le présentateur,

l'emplacement, la date et l'heure de la réunion, l'objet de la réunion, ainsi que d'envoyer des invitations par

courrier électronique aux participants. XDEMAT

45

Rap

port

de

stag

e| 1

3/09

/20

10

De créer une nouvelle conférence immédiatement : en cliquant sur "Conférence

maintenant", une nouvelle fenêtre s'ouvre donnant accès à une multitude de fonctions intuitives et

pratique pour une conférence. Vous pouvez inviter des participant par courrier électronique, parler avec

eux, partager des documents, faire une présentation PowerPoint en direct et même naviguer sur le web

Remarque :

Durant mon stage, j'ai réalisé deux manuels : utilisateur et administrateur pour le compte d'un client de

la société Reactis, à propos de l'utilisation des Services SharePoint. Ce travail m'a permis de maitriser les

différents concepts du point de vue administrateur et utilisateur.

XDEMAT

46

Rap

port

de

stag

e| 1

3/09

/20

10

Chapitre 4 : Rapport technique et

Contributions.

I. Présentation du sujet de stage :

L'objectif au début du stage est de concevoir une interface généralisée qui servira à faire le lien entre

des applications métier, et un système d’archivage électronique (SAE). Les applications métiers fourniront un ensemble

d’informations sous forme de documents qui formeront une ou plusieurs archives, ces documents seront fournis

dans divers formats (Word, Excel, PDF, XML, courriel, image JPG, carte géographique…etc.).

A partir de ces documents, nous effectuons un traitement au sein de l’interface généralisée qui nous donnera en

sortie un flux normalisé qui fera correspondre à chaque document un couple (description XML-EAD, document

original). Ce flux normalisé sera ensuite injecté dans le SAE afin d'assurer l'archivage, l'intégrité et la valeur

probante des données.

Le schéma ci-dessous présente les trois composants principaux :

A. Applications métiers

Beaucoup de services administratifs accumulent au fil du temps des quantités importantes de documents

papiers ou numériques. Avec l’air de la modernisation et de l’évolution technologique, le développement vers des

systèmes d’archivage électronique est très encouragé de par la facilité de trier les archives et la possibilité de

retrouver un document donné d’une manière automatiques.

Actuellement, les informations numériques peuvent être stockées dans différents types de documents liés

particulièrement aux logiciels utilisés (GED, Bureautiques, courriel, etc.) pour leurs productions. Ce qui fait

qu’on a des documents dans divers format (Word, Excel, PDF, XML, image JPG, carte géographique…etc.). Ces

documents seront le point d’entrée de notre interface généralisé.

Flux normalisé

Applications

métier

Interface généralisée

Normes EAD et SEDA

Cartographies

GED

Application

RH

……

SAE

XDEMAT

47

Rap

port

de

stag

e| 1

3/09

/20

10

B. Interface généralisée

Son but principal est de faciliter et d’automatiser l’opération de versement d’un service producteur vers

un service d’archive. L’échange de flux d’information se fait en respectant le standard SEDA (Standard d’échange

de données pour l’archivage) et les normes établis dans le domaine de l'archivage (Moreq2, NF Z 42 013). Ce

standard utilise notamment les métadonnées décrites en format XML-EAD.

Notre Interface comportera 2 parties principales :

Module générale : regroupe les fonctions communes aux progiciels (applications métiers) des services

producteurs

Modules Spécifiques : pour chaque application métier, il faudra développer un module spécifique qui

dépendra principalement du type de documents qu’elle fournira.

C. Les systèmes d’archivage électronique

L'archivage consiste à conserver, à moyen ou long terme des informations afin de pouvoir les exploiter

ultérieurement. L'archivage permet ainsi d'assurer la fidélité et la durabilité de l'information conservée.

En raison du développement considérable des données sous forme dématérialisée (numérique), les supports

traditionnels d'archivage des documents (papier ou microforme) sont progressivement remplacés par des

systèmes d'archivage électronique.

Il est devenu nécessaire de s'assurer que la valeur probante des documents électroniques ne sera pas altérée par le

temps et que ces documents constitueront une preuve admissible au même titre que les documents sous forme

papier, et ce, plusieurs années après leur archivage (30 ans ou plus).

Définition: Le Système d’Archivage Electronique (SAE) permet l’archivage à valeur probante de tous documents

grâce à des technologies innovantes éprouvées et aux respects des normes en vigueur en matière d’archivage

électronique à valeur probante (OAIS, Moreq2, NF Z 42 013, etc.).

Il permet de :

Maitrisez le cycle de vie des documents de patrimoine informationnel,

Archivez des documents électroniques avec la garantie de leur intégrité et pérennité,

Consultez et gérez les preuves numériques.

Le SAE met en œuvre un ensemble de technologies et de dispositifs vous garantissant la traçabilité, la

confidentialité et la sécurité des données et des documents :

Accès sécurisés et cryptage,

Horodatage,

Scellement et signature électronique,

Traçabilité grâce à la journalisation,

Archivage à valeur probante.

Sous certaines conditions le SAE permet la suppression des originaux papiers.

XDEMAT

48

Rap

port

de

stag

e| 1

3/09

/20

10

Voici un schéma plus détaillée, avec notamment la présence des métadonnées, des trois composants principaux du

système :

II. Analyse des besoins :

Afin de proposer une solution efficace au client (le tuteur du stage), on se devait de bien comprendre les besoins

et ce que chaque partie du système pouvait exporter et importer. On savait que les applications métier

fournissaient principalement des documents numériques, mais est-ce qu'elles fournissent des métadonnées

associées ou non? Ces applications métiers doivent-elles être enregistrées au niveau de l'interface généralisée? Une

liste de SAE devait être enregistrée au niveau de l'interface et lier chaque SAE à l'entreprise ou a l'ensemble

d'applications métier qui lui fourniront les documents numériques à archiver pour justement, faire le lien entre les

extrémités (Applications métier et SAE) du système.

A. Mission de l'interface généralisée

La mission de l'interface généralisée est de faciliter et automatiser l'opération de versement d'archives provenant

d'un service producteur vers un service d'archive (système d'archivage électronique (SAE)).

Les fonctionnalités principales à assurer sont :

Récupération des documents à archiver sous forme de boites (une ou plusieurs) suivant le

standard SEDA

Création d’une DTD EAD pour chaque archive versé par le service producteur

Création d’objet, pour chaque document, représentant une encapsulation de celui-ci avec ces

métadonnées.

Versement des archive après normalisation vers le SAE.

SAE

. . .

Interface généralisée

aux normes EAD et SEDA

GED Carto. Bure. metadata

metadata

metadata

Cartographies

GED

Bureautique

Module général

Flux

normalisé

App

licat

ions

mét

ier

XDEMAT

49

Rap

port

de

stag

e| 1

3/09

/20

10

III. Spécifications fonctionnelles

A. Identification des acteurs de l’interface généralisée

Notre système comporte trois acteurs principaux :

a) L’application métier

L’application qui produit le (ou les) document(s) à archiver. Elle interagit avec l’interface généralisée en lui envoyant les archives ainsi que ses données descriptives (métadonnées). Le nombre et le type de métadonnées sera définie par l’interface généralisée.

b) Le SAE

Après avoir effectué les traitements nécessaires, l’interface envoie au SAE les archives et ses métadonnées normées pour les stocker, les organiser et assurer leur intégrité à moyen et long terme.

c) L’administrateur

Lorsqu’une nouvelle application métier veut utiliser notre interface pour la première fois, elle devra créer un compte pour s’identifier. Ce nouveau compte devra être validé par l’administrateur. L’administrateur aura également la responsabilité de créer et de mettre à jour des comptes SAE, vers qui transférer les données à archiver.

Remarque L’interface est un système multiutilisateur, qui a pour objectif d’être la plus générique possible. Elle peut

coordonner plusieurs applications métier avec plusieurs SAE.

Dans la pratique, une société utilise un seul SAE, et donc, pour chaque utilisation de l’interface, il peut y avoir

plusieurs instances d’application métier à connecter vers une instance SAE.

B. Identification des cas d’utilisations

On définit dans cette section ce que pourra faire chaque acteur via l’interface généralisée.

L’application Métier :

Effectuer un versement d’archives avec leurs informations descriptives (métadonnées). Cette étape passe

obligatoirement par une séquence d’authentification.

L’administrateur de l'interface :

Créer les comptes applications métier et SAE.

Le SAE :

Récupérer le flux de données normées SEDA et les documents pour l’archivage versé par l’interface.

XDEMAT

50

Rap

port

de

stag

e| 1

3/09

/20

10

C. Diagramme des cas d’utilisation

D. Description textuelle des cas d’utilisation (8)

a) Cas d’utilisation N°1

Titre : générer un ou plusieurs fichier(s) normé(s) SEDA pour les archives de l’application métier Résumé : L’objectif principal de l’interface généralisée est de générer pour chaque archive des métadonnées en flux SEDA afin de pouvoir les transmettre au SAE sous une forme normalisée. Acteurs : l’application métier et le SAE Date de création : 29/04/2010 Date de mise à jour : 05/05/2010 Version : 1.1 Description des scénarios

a) Pré conditions: L’application métier et l’interface généralisée sont relié par réseau internet ; L’application métier s’est enregistrée auprès de l’interface généralisée ; L’interface généralisée a les informations du SAE responsable de l’archivage.

b) Scénario Nominale : L’application métier s’identifie auprès de l’interface généralisée ;

L’interface valide l’identification ;

L’application métier exporte les données : documents + métadonnées

L’interface récupère les archives (documents) et leurs informations descriptives (métadonnées) pour

le versement ;

XDEMAT

51

Rap

port

de

stag

e| 1

3/09

/20

10

L’interface vérifie que les informations obligatoires ont bien été fournies ;

L’interface génère un fichier XML normé avec les informations récupérées ;

L’interface effectue le versement vers le SAE.

c) Enchaînements alternatifs

A1 : Mauvais identifiant ou mot de passe saisi par l’application métier, l’enchaînement A1 commence au point 2 du scénario nominal.

2. L’interface indique à l’application métier que les informations d’identification sont incorrectes et l’invite à recommencer.

3. Le scénario nominal reprend au point 1. A3 : Absence des informations obligatoires. L’enchainement A3 commence au point 6 du scénario nominal.

6. L’interface envoie un message d’erreur lié à l’absence des informations obligatoires. 7. L’interface fournie des détails sur les informations obligatoires manquantes. 8. L’interface invite l’application à refaire l’opération ultérieurement. 9. Le scénario nominal reprend au point 1.

d) Les exceptions

E1 : l’interface n’arrive pas à communiquer avec l’application métier. L’exception E1 commence au point 1 du scénario nominal. L’interface enregistre les erreurs du problème réseau afin d’en avertir l’administrateur. L’interface envoie un mail à l’administrateur pour l’informer du problème réseau, le cas d’utilisation se termine par un échec. E2 : l’application métier n’arrive pas à exporter les données (documents + métadonnées). L’exception E2 commence au point 3 du scénario nominal. L’application métier envoie un message d’erreur d’exportation à l’interface. L’interface enregistre le problème d’exportation.

5. L’interface invite l’application à refaire l’opération ultérieurement ; Le scénario nominal se termine par un échec. E3 : L’interface n’arrive pas à récupérer les informations de description des archives, l’exception E3 commence au point 4 du scénario nominal.

4. L’interface envoie un message d’erreur de récupération des informations de description. 5. L’interface fournie des détails sur les informations de description manquantes ; 6. L’interface invite l’application à refaire l’opération ultérieurement ; Le scénario nominal se termine par un échec.

E4 : l’interface n’arrive pas à établir une connexion avec le SAE. L’exception E2 commence au point 6 du scénario nominal. L’interface fait une sauvegarde du travail effectué. L’interface envoie les données dès que la connexion avec le SAE est rétablie. L’interface enregistre les erreurs du problème réseau pour avertir l’administrateur.

XDEMAT

52

Rap

port

de

stag

e| 1

3/09

/20

10

L’interface envoie un mail à l’administrateur pour l’informer du problème de connexion, le cas d’utilisation se termine par un échec. e) Post conditions La transaction de versement est enregistrée par l’interface avec toutes les informations pertinentes (Nombre d’archives, date, informations de l’application métier, informations du SAE, etc.). Les détails de la transaction doivent être enregistrés aussi bien en cas de succès que d’échec.

b) Cas d’utilisation N°2

Titre : créer ou mettre à jour un compte application métier ou SAE. Résumé : l’application métier et le SAE devront être enregistrés auprès de l’interface pour pouvoir effectuer des versements via celle-ci. Ses comptes sont créés et mis à jour par l’administrateur de l’interface. Acteurs : l’administrateur Date de création : 29/04/2010 Date de mise à jour : 05/05/2010 Version : 1.1 Description des scénarios

a) Pré conditions: L’administrateur possède les informations nécessaires de l’application métier et du SAE concerné. La création d’un compte SAE et conditionné par l’existence du compte application métier qui l’utilisera.

b) Scénario Nominale : L’administrateur crée (ou met à jour) le compte de l’application métier et le sauvegarde au niveau de l’interface. L’administrateur crée (ou met à jour) le compte du SAE concerné et le sauvegarde au niveau de l’interface. L’administrateur envoie un mail pour confirmer la création (ou la mise à jour) du compte à l’utilisateur de l’application métier. L’administrateur envoie un mail pour confirmer la création (ou la mise à jour) du compte au responsable du SAE.

c) Post conditions : Les informations pertinentes de création des comptes, application métier et SAE, sont enregistrées.

c) Cas d’utilisation N°3

Titre : récupérer les informations (documents et métadonnées SEDA) à archiver Résumé : l’interface va envoyer au SAE les données à archiver accompagné des métadonnées normées générées. Acteurs : le SAE et l’application métier. Date de création : 29/04/2010 Date de mise à jour : 03/05/2010 Version : 1.0

XDEMAT

53

Rap

port

de

stag

e| 1

3/09

/20

10

Description des scénarios

d) Pré conditions: Les métadonnées normées ont bien été générées.

e) Scénario nominal L’interface envoie une demande de transfert normé SEDA au SAE

L’SAE envoie l’acceptation d’archivage à l’interface généralisée.

L’interface procède au transfert des archives avec les métadonnées associées.

Le SAE envoie un accusé de réception du transfert.

L’SAE envoie une notification d’acceptation du transfert.

f) Les exceptions :

E1 : L’SAE refuse le transfert des archives de l’application métier en question (manque d’espace,

résiliation de contrat, etc.). L’enchainement A1 commence au point 2 du scénario nominal.

L’interface envoie un accusé de réception du refus au SAE.

L’interface envoie, via un email, une notification de refus d’archivage à l’utilisateur de

l’application métier. Le scénario nominal se termine par un échec.

E2 : l’SAE envoie un Avis d’anomalie Error. L’enchainement A2 commence au point 5 du scénario

nominal.

L’SAE envoie un avis d’anomalie Error.

L’interface envoie un accusé de réception de l’avis d’anomalie au SAE.

L’interface envoie un email à l’utilisateur de l’application métier pour l’informer de l’avis

d’anomalie Error.

Le scénario se termine par un échec.

E. Description graphique des cas d’utilisation

XDEMAT

54

Rap

port

de

stag

e| 1

3/09

/20

10

a) Diagramme de séquence : génération de flux normé

b) Diagramme de séquence : création de comptes

XDEMAT

55

Rap

port

de

stag

e| 1

3/09

/20

10

c) Diagramme de séquence : effectuer le versement au SAE

Remarque A ce stade d'avancement du stage, nous pouvant constater que le sujet englobe deux thèmes principaux :

la normalisation des données avec le format EAD,

l'application du standard SEDA pour les échanges à effectuer avec les acteurs du système, à

savoir, les progiciels métiers et le SAE.

F. Evolution du cahier des charges :

En concertation avec le tuteur de stage, on projetait d'effectuer des échange de données en appliquant le

standard SEDA avec un des partenaires de la société Reactis, malheureusement, la coopération n'a pas aboutit.

Nous avons donc bien assimilé l'aspect théorique du standard, mais nous n'avons pas eu l'occasion de l'appliquer.

Pour le format EAD, nous avons voulu maitriser la chaine de manipulation d'un fichier Xml Ead, de sa création à

son utilisation. L'exploitation du fichier XML EAD était prévue via le logiciel open source PLEADE.

PLEADE est une application qui permet d'effectuer la recherche, la consultation et la publication d'instrument de

recherche normalisé selon La DTD EAD.

I- Générer un fichier XML EAD et automatiser la publication

Nous avons développé une application qui fournissait une IHM à l'utilisateur, de telle sorte qu'il puisse remplir un

bordereau de versement comme durant la procédure papier.

L'applications se chargeait ensuite de vérifier le bon remplissage du formulaire, et générait un fichier XML

normalisé selon le format EAD.

Ce fichiers XML EAD est ensuite publié sur PLEADE, et offre ainsi, la possibilité d'exploiter le formalisme EAD

dans sa totalité.

Pour finaliser le processus, l'application développée a pour mission de récupérer le statut de la publication et de

l'envoyer par email à l'utilisateur pour l'informer du bon déroulement du processus ou de l'échec, le cas échéant.

XDEMAT

56

Rap

port

de

stag

e| 1

3/09

/20

10

II- Validateur de fichier XML Ead

Nous avons également développé la fonction de validateur de Fichier XmlEad, ce validateur a pour mission de

vérifier si un fichier Xml est bien conforme à la DTD EAD.

IV. Spécifications techniques :

A. Outils utilisés :

Environnement de développement : Eclipse Galileo

Serveur de Base de données : MySql Server 5.1

Serveur d'application : TomCat 6.0.26

Editeur XML : Oxygen Editor V12.1 Free Editix 2010

Logiciel de conception de diagrammes UML : Booml

Gestionnaire de Subversion (SVN) :

http://code.google.com/p/webead/

Transformation d'XML en PDF Prince XML

B. Choix des outils et technologies :

a) Eclipse Galileo

Répertoire

ead

Utilisateur

BDD

MySQL

Persistance des objets en

BDD

II

I

Affichage du résultat

de la validation Validateur

Xml Ead

Fichiers

de Log

(1)

Création du

fichier Xml

(3)

Récupération du statut

de la publication

(4)

Envoie email avec le

statut de la publication

(2.a)

Affichage en format

PDF

(2.b) Publication automatique

(via le CRON) Processeur

XSLT

XDEMAT

57

Rap

port

de

stag

e| 1

3/09

/20

10

Eclipse est un environnement de développement intégré (Integrated Development Environment) dont le

but est de fournir une plate-forme modulaire pour permettre de réaliser des développements informatiques. Il est

principalement utilisé pour le développement d’applications en JAVA/JEE.

b) MySql

C’est un système de gestion de base de données (SGBD) open source que nous utilisons pour stocker les

informations récupérées par notre application.

c) Editeurs XML : Oxygen XML Editor et Editix - Free -2010

J'ai voulu présenter deux éditeurs que j'ai utilisés au courant de mon travail,

Editix Free 2010 : C’est un éditeur XML libre (Free), qu’on utilise pour la création, modification

et la validation de documents XML. Il est gratuit est assez pratique.

Oxygen XML Editor: c'est un outil très efficace pour la création et la manipulation de

documents XML et le travail sur des feuilles de styles XSL ou CSS. Très complet, c'est un outil

professionnel que je recommande vivement.

d) Java Persistence API (JPA) (9):

JPA est venu avec l'arrivé de Java EE 5, fortement inspiré par des outils open source tel qu'Hibernate, le

mapping objet/relationnelle et le langage de requête sont totalement différents de l'ancêtre entity bean 2.1. JPA

facilite considérablement la persistance des Objets java grâce aux annotations notamment.

JPA s'appuie sur JDBC (Java Data Base Connectivity) pour communiquer avec la base de données, et sur

Hibernate comme ORM (Object-Relationnel Mapping) pour faire la liaison (mapping) entre les objets Java (dans

l'application) et les tables relationnelles (dans la base de données).

e) Hibernate

Hibernate est un framework 21 open source gérant la persistance des objets en base de données

relationnelle. Il se charge de traduire les opérations CRUD (Create, Read, Update, Drop) en SQL.

f) Servlet et JSP (Java Server Page) :

Les servlets sont des programmes Java fonctionnant coté serveur au même titre que les langages de script

tels que ASP ou PHP. Les servlets permettent donc de recevoir des requêtes http, de les traiter et de fournir une

réponse dynamique au client.

Elle s'exécute dans un conteneur utilisé pour établir le lien entre la servlet et le serveur web. Les servlets étant

des programmes Java, elles peuvent utiliser toute les API Java afin de communiquer avec des applications externes,

se connecter à des bases de données, accéder aux entrée- sorties (fichiers par exemple)..etc.

Java Server Page, ou JSP, est une technologie basé sur Java qui permet aux développeurs de générer

dynamiquement du code HTML, XML, ou tout autre type de page web. Une page JSP (repérable par

21 Framework : ensemble de bibliothèques et de conventions permettant le développement rapide

d'applications. Il fournit suffisamment de briques logicielles et impose suffisamment de rigueur pour pouvoir produire une application aboutie et facile à maintenir.

XDEMAT

58

Rap

port

de

stag

e| 1

3/09

/20

10

l'extension .jsp) aura un contenu pouvant être différent selon certains paramètres (des informations stockés dans

une base de données, les préférences de l'utilisateur) tandis qu'une page web "statique" (dont l'extension est .htm

ou .html) affichera continuellement la même information.

Lorsqu'un utilisateur appelle une page JSP, le serveur web crée un code source Java à partir du script JSP (c.-à-d.

qu'il constitue une servlet à partir du script JSP), le compile puis l'exécute.

g) UML2 (Unified Modeling Language) :

UML est né de la fusion de trois méthodes qui ont le plus influencé la modélisation objet au milieu des

années 1990 : OMT, Booch et OOSE. Issu d'un travail d'expert reconnus (James Rumbaugh, Grady Booch et Ivar

Jacobson), UML est le résultat d'un large consensus qui est vite devenu un standard incontournable. Fin 1997, ce

langage est devenu une norme OMG (Object Management Group).

UML est un langage de modélisation Objet et non une démarche d'analyse. Il représente des concepts abstraits de

manière graphique. UML est donc un langage universel et visuel qui permet d'exprimer et d'élaborer des modèles

objets indépendamment de tout langage de programmation. Comme UML n'impose pas de méthode de travail

particulière, il peut être intégré à n'importe quel processus de développement logiciel de manière transparente.

UML2 introduit quatre nouveaux diagrammes (paquetages, structures composites, global d'interaction et de

temps) qui viennent enrichir les neufs initiaux (classes, objets, composants, déploiement, cas d'utilisation, états-

transitions, activités, séquence et communication).

Dans notre travail, nous avons utilisé le diagramme des cas d'utilisation, le diagramme des séquences et le

diagramme des classes.

h) JDOM pour manipuler des données XML :

JDOM est une API du langage Java développée indépendamment de Sun Microsystems. Elle permet de

manipuler des donnés XML plus simplement qu'avec les API classiques. Son utilisation est pratique pour tout

développeur Java et repose sur les API XML de Sun.

Dans notre travail, on se devait de trouver une technologie qui nous faciliterait la création et la manipulation de

données XML. Notre choix s'est porté vers JDOM parce qu'il propose une méthode assez simple de manipuler

l'arborescence du fichier XML.

JDOM utilise DOM pour manipuler les éléments d'un Document Object Model spécifique (créé grâce à un

constructeur basé sur SAX).

DOM est l'acronyme de Document Object Model. C'est une spécification du W3C pour proposer une API qui

permet de modéliser, de parcourir et de manipuler un document XML. Le principal rôle de DOM est de fournir

une représentation mémoire d'un document XML sous la forme d'un arbre d'objets et d'en permettre la

manipulation (parcours, recherche et mise à jour).

A partir de cette représentation (le modèle), DOM propose de parcourir le document mais aussi de pouvoir le

modifier. Ce dernier aspect est l'un des aspects les plus intéressants de DOM.

DOM est défini pour être indépendant du langage dans lequel il sera implémenté. DOM n'est qu'une spécification

qui, pour être utilisée, doit être implémentée par un éditeur tiers. DOM n'est donc pas spécifique à Java.

Le parseur DOM pour JAVA le plus répandu est Xerces.

XDEMAT

59

Rap

port

de

stag

e| 1

3/09

/20

10

JDOM permet donc de construire des documents, de naviguer dans leur structure, s'ajouter, de modifier, ou de

supprimer leur contenu.

Remarque : Pour la manipulation de données XML, il existe d'autres API assez intéressante comme JAXP (Java API for XML

Processig) et JAXB (Java Architecture for XML Binding). Au cours de mon stage, des développeurs

expérimentés m'ont fait part de leur préférence pour JAXB.

Mon choix s'est tourné vers JDOM pour sa simplicité d'utilisation et de manipulation des arbres XML.

i) JavaMail 1.4.3

Java Mail est l'API standard de gestion de courriers électronique de Java EE. Elle permet d'envoyer et de

recevoir du courrier électronique et de manipuler les messages (en-tête, sujet, corps, pièces jointes…etc.).

JavaMail n'est pas un serveur de courrier en tant que tel, mais plutôt un outil pour interagir avec ce type de

serveur. Il peut être vu comme un type de client de messagerie au même titre que Outlook, Lotus, Eudora, ..etc.

Pour envoyer ou recevoir des messages, JavaMail utilise différents protocoles comme SMTP, Imap ou POP.

j) Apache : FOP (Formatting Objects Processor)

Apache FOP est l'outil qui permet de générer les versions imprimables au format PDF à partir des

documents sources XML et d'une feuille de styles XSL-FO. Ce processeur est développé en Java et c'est

incontestablement l'outil libre le plus avancé sur la production de versions imprimables.

La version du Java Runtime Environment (JRE) influe beaucoup sur le fonctionnement de fop. Par conséquent, il est

préférable d'utiliser une version la plus récente possible.

C. Architecture de l'application :

Après analyse des besoins, nous avons opté pour le développement en Java/J2EE, l'architecture choisie est

l'architecture à 3 couches :

Le schéma suivant montre la disposition de chaque couche de l'application.

BDCouche métier Couche

présentation Couche DAO

Utilisateu

JPA

Hibernate XDEMAT

60

Rap

port

de

stag

e| 1

3/09

/20

10

a) Architecture de la base de données "dbead" :

Nous avons nommé notre base de données dbead (pour Data Base Encoded Archival description). Cette base est

constituée de six tables distinctes présentées dans le diagramme suivant :

On programmation orienté objet, ces tables sont représentés par des Java Beans. Qui utilise la technologie

JPA pour assurer le mapping avec la base de données relationnelle « dbead » via Hibernate. JPA utilise

principalement les annotations prévues pour persister les java beans (Objets Java) dans le contexte de persistance.

Hibernate se charge ensuite d’effectuer les requêtes SQL nécessaires avec la base de données MySql.

BordereauVersement

-idBv :long -dateVersement :Date -version :int

+BordereauVersment() +addOrganisation() +addPersonne()

Organisation

-idOrg : long -intitule :String -adresse :Adresse -sProducteur :boolean -sVersant :boolean -sArchive :boolean

+Organisation() +addPersonne()

Personne

-idPers : long -nom : String -prenom : String -fonction :String -service:String -tel:String

+Personne()

Archive

-idArchive: long - descArchive :String -metrageLineaire :String -conservation :String -dua :double -dateCom :Date -delaiCom :String -sortFinal :String

+Archive() +addDossier()

Dossier

-idDossier : long -intitule:String -description:String

+Dossier() +addDocument()

Adresse

-adr1 :String -adr2:String -adr3:String -codePostale:String -ville:String -cedex:String -pays:String

+Adresse()

Document

idDocument: long titre:String dateProduction :Date -version :int

+Document()

1..*

1..*

1..*

0,1

0,1 0,1

0,1

1..*

0,1

0,1

1..*

1,0

1..*

XDEMAT

61

Rap

port

de

stag

e| 1

3/09

/20

10

b) Couche DAO (Data Access Object)

La couche DAO pourra envoyer/recevoir les données vers/de la base de données.

Dans cette partie de l’application, nous avons conçu les méthodes nécessaires à la manipulation des données.

Afin d’assurer la réutilisation et la sécurité des données, on développe une interface listant les principales

méthodes à utiliser dans la manipulation des données, puis dans un classe implémentant l’interface, nous

définissons le corps de chaque méthode.

Pour chaque Java Bean (ou entité), ces méthodes sont les suivantes :

- findEntite(id long) : cette méthode sert à trouver une entité en utilisant son identifian « id »

- getAllEntite () : affiche la liste de toutes les entités enregistrées dans la base de données.

- getAllEntiteLike(String modele) : affiche la liste des entités dont le nom correspond à un

modele.

- addEntite(Entite ent) : Ajout d’une entité « ent » à la table Entité.

- updateEntite(Entite ent) : mise à jour des informations d’une entité.

- deleteEntite(Entite ent) : suppression d’un enregistrement via son « id ».

c) La couche métier :

Cette couche correspond à la partie fonctionnelle ou métier de l'application. Elle implémente la logique

et les règles de gestion permettant de répondre aux requêtes de la couche présentation.

Pour fournir ces services, elle s'appuie, le cas échéant, sur les données du système, accessible au travers

des services de la couche de données (DAO). En retour, elle renvoie à la couche présentation les

résultats qu'elle a calculés. (7)

d) La couche de présentation :

C'est la partie visible de l'application qui permet à un utilisateur d'interagir avec le système. Elle relaie les

requêtes de l'utilisateur à destination de la couche métier, et en retour lui présente les résultats renvoyés

par les traitements. On parle alors d'Interface Homme-Machine (IHM) et aucun traitement n'est

implémenté dans cette couche.

Pour sont développement, nous avons opté pour la technologie JSP/Servlet. Les pages JSP seront celles

affichées à l'utilisateur, et les servlets associées feront la correspondance avec la couche métier.

D. Diagramme des classes :

Nous présentons dans cette section la structure de l'application "EAD_WEB" que nous avons développé.

L'application "EAD_WEB" composé des différentes couches que nous avons citées plus haut, est structuré en 6

parties principales : les beans, la couche DAO, la couche métier, les servlets, la couche tests et la partie

présentation contenu dans le répertoire WebContent

XDEMAT

62

Rap

port

de

stag

e| 1

3/09

/20

10

Les beans (entités) : pour commencer, nous devions définir les entités qui composent notre

application. Ces entités appelées "beans" reflètent en générale, les tables de la base de données. C'est

pourquoi on retrouve les mêmes nominations: BordereauVersement, Organisation, Personne, Archive,

Dossier et document.

Nous avons donc conçu un package "fr.reactis.beans" avec 6 classes distinctes, une classe pour chaque bean.

La figure ci-dessous représente le diagramme des classes du package "fr.reactis.beans".

La couche DAO (Data Access Object) : en programmation, nous avons structuré cette couche avec

3 classes : une interface "Idao", son implémentation "DAOImpl" et une classe DAOException. Cette

façon de programmer est utilisée pour des raisons de sécurité afin que l'utilisateur ne puisse pas accéder

directement à la logique métier des méthodes implémentées.

- L'interface (classe abstraite)" Idao" sert à définir les méthodes d'accès aux données sans intégrer

le corps des méthodes.

- La classe "DAOImpl" qui contient le corps des méthodes et qui implémente l'interface

"Idao".

- La troisième classe est "Dao Exception", sert à gérer les exception qui peuvent survenir lors de

l'accès aux données.

La figure ci-dessous représente le diagramme de classe du package "fr.reactis.dao" :

XDEMAT

63

Rap

port

de

stag

e| 1

3/09

/20

10

La couche métier : cette couche est représenté par le package "fr.reactis.business", on a suivi la même

logique de programmation en définissant une interface "IEAD_Creation" et son implémentation

"EAD_CreationImpl", elle est composé de 4 classes distinctes :

L'interface IEAD_Creation: cette Interface est composé des déclarations des méthodes sans leur contenu.

La classe EAD_CreationImpl : cette classe implémente les méthodes de l'interface "IEAD_WEB" et

représente le cœur de la logique métier.

"XML Exception" et "TypeError" : ces classes ont été créées pour la gestion des erreurs.

La figure ci-dessous représente le diagramme des classes de la couche métier (du package "fr.reactis.business") : XDEMAT

64

Rap

port

de

stag

e| 1

3/09

/20

10

Voici ci-dessus des illustrations de l'arborescence de l'application EAD_WEB :

XDEMAT

65

Rap

port

de

stag

e| 1

3/09

/20

10

E. Présentation de l'application développée

L'application EAD_WEB est utilisée avec le serveur d'application TomCat. La présentation vue par l'utilisateur se

présente comme sur la figure suivante.

La page se présente avec 3 parties principales :

- L'entête et le pied de page : l'entête contient en général le titre de la page avec une brève

présentation.

- Le menu de navigation à gauche : ce menu regroupe les différentes pages que l'utilisateur peut

parcourir

- Le contenu au centre de la page.

XDEMAT

66

Rap

port

de

stag

e| 1

3/09

/20

10

La fonction principale du site, est de pouvoir générer un fichier XML EAD via un bordereau de versement.

L'utilisateur y a accès en cliquant sur "Bordereau de versement " dans le menu de gauche.

La page se présente comme sur les figures suivantes :

Figure 7 Bordereau de Versement 1/3 XDEMAT

67

Rap

port

de

stag

e| 1

3/09

/20

10

Figure 8 Bordereau de versement 2/3

Figure 9 Bordereau de versement 3/3

XDEMAT

68

Rap

port

de

stag

e| 1

3/09

/20

10

Nous avons intégré des fonctions JavaScript, qui s'exécute coté client pour faciliter l'utilisation et assuré que le

formulaire sont complété correctement.

Les fonctions que nous avons intégré en JavaScript son les suivante:

Génération dynamique du nombre de document (Figure 10).

Intégration d'un calendrier pour faciliter le choix de la date (Figure 11)

Vérification des champs obligatoires

Vérification de la syntaxe de l'adresse email.

Figure 10 Génération dynamique du nombre de documents

Figure 11 Affichage du calendrier en JavaScript

XDEMAT

69

Rap

port

de

stag

e| 1

3/09

/20

10

a) Générer le fichier en PDF :

Une fois le formulaire remplie, l'utilisateur lance la génération du fichier en cliquant sur "Générer", un message

s'affiche alors confirmant le bon déroulement de l'opération.

Le système propose à l'utilisateur de voir le contenu en format PDF.

Pour réaliser cette fonction, nous avons utilisé la transformation XSLT via l'API Apache FOP.

Remarque : Vous pouvez consulter un exemple de fichier XML EAD généré avec le fichier XSL associé en Annexe E.

b) Vérification d'un document XML EAD :

L'utilisateur a la possibilité de vérifier si un fichier XML est valide ou pas. La figure ci-dessous montre le cas ou le

fichier sélectionné n'est pas valide. Un tableau présente la liste des erreurs avec leur emplacement (n° de ligne, et

N° de colonne) afin que l'utilisateur puisse le corriger.

Apache

FOP

XSL

+

Sortie PDF

Apache

FOP +

XSL-FO

XSL-FO

XML - EAD

XML - EAD

XDEMAT

70

Rap

port

de

stag

e| 1

3/09

/20

10

V. PLEADE : Publication, Recherche et consultation de

documents d'archives

A. Présentation :

PLEADE est un logiciel Open Source de Recherche, Consultation et Publication, via une interface web,

d'instruments de recherche archivistiques structurés en format XML EAD. Cet environnement a été développé

conjointement par les sociétés AJLSM (Localisé à Bordeaux) et Anaphore et lancé au cours du premier semestre

de l'année 2003.

La société Anaphore est la créatrice d'un autre logiciel pour les archives, nommé Arkhaia.

C’est un outil de consultation, de recherche et de publication d’instrument de recherche archivistiques en format

EAD. La possibilité d’exploiter des formats EAD ont fait sa popularité auprès de nombreuses institution françaises

qui ont adopté la norme EAD.

PLEADE a été développé en Java, et utilise, dans sa version locale, le serveur d'application "Jetty".

Voici un aperçu de la page d'accueil de ce logiciel :

XDEMAT

71

Rap

port

de

stag

e| 1

3/09

/20

10

B. Les principales fonctionnalités :

PLEADE possède trois principales fonctionnalités qui sont les suivantes :

Consultation : présentation hiérarchisée de l'information, l'utilisateur à la possibilité de

parcourir l'arborescence d'un IR assez facilement, et intuitivement.

Publication : transformation avec XSLT (=>XHTML), FO (=>PDF) via l'API Cocoon.

Après authentification (User : admin, password : pleade; pour la version standard), l'utilisateur

à la possibilité de publier des fichiers XML structurés (EAD, EAC ou autres) et de pouvoir ainsi

les consulter ultérieurement en format HTML ou PDF. XDEMAT

72

Rap

port

de

stag

e| 1

3/09

/20

10

Recherche : PLEADE utilise un moteur SDX assez puissant, développé par le ministère de la

culture en France, qui affiche le résultat assez rapidement après une recherche simple ou

avancée, et cela, même parmi des centaines d'IR.

Exemple : si on fait une recherche simple avec le mot "Versailles", le résultat se présente comme sur la figure

suivante.

PLEADE a également d'autres fonctionnalités assez intéressantes, qui sont :

Explorer les images archivées dans PLEADE via la Visionneuse intégré,

Possibilité de recueillir les IR sélectionnées dans un panier (entrepôt de documents)

XDEMAT

73

Rap

port

de

stag

e| 1

3/09

/20

10

PLEADE c'est aussi :

Une installation sur différentes plates-formes (Windows, Mac, etc.)

Le support du protocole OAI pour, par exemple, intégrer les instruments de recherche dans un portail

documentaire externe

Le support du format EAC pour une description précise et structurée des producteurs d'archives

L'utilisation d'un puissant moteur de recherche XML qui permet d'ajouter des contenus non EAD (catalogue de

bibliothèque par exemple)

Remarque : PLEADE ne permet pas de saisir la description d'archive, il faudra donc lui fournir les fichiers XML conformes

(EAD, EAC, etc.) réalisé par d'autres outils.

C. Quelques références :

Voici quelque une des collectivités et des entreprises qui ont adopté PLEADE :

- Archive départementales de Loire-Atlantique

http://archives-inventaires.loire-atlantique.fr

- Ministère de la Défense - Direction de la mémoire, du patrimoine et des archives

(http://www.memoiredeshommes.sga.defense.gouv.fr/jmo/pages/index.html )

- Archives départementales des Pyrénées-Atlantiques

- Conservatoire SEB (Lyon, France)

- Archives départementales du Val-de-Marne

- Cité de l'architecture et du patrimoine

http://archiwebture.citechaillot.fr/awt/

D. Automatiser la publication avec PLEADE

Pour automatiser la publication de fichiers XmlEad dans PLEADE, il faut modifier le fichier de

configuration "cocoon.xconf" situé dans le répertoire "WEBINF", en suivant le chemin :

" ..\pleade\webapp\WEB-INF".

Vous devez procéder à deux modifications principales:

1) Mettre les bons paramètres pour le "cron" entre les balises "<triggers>"

2) Insérer les codes d'accès "user et password" dans la balise "<component>". Par défaut, ces

informations sont :

user : admin

password : pleade

XDEMAT

74

Rap

port

de

stag

e| 1

3/09

/20

10

Dans ce fichier de configuration, on s'aperçoit, qu'une partie commenté décrit un "trigger" nommé "auto-

publish", qui contient le "CRON" que l'on peut paramétrer.

Il est possible d'effectuer la configuration de deux manières :

- On utilise le nom de chaque paramètre dans une balise XML : <second>, <minutes/>,..etc.

- On utilise la balise "<cron>*/30 * * * * ? *</cron> ", c'est ce que je recommande.

Voici la partie commenté qui nous intéresse :

Une expression Cron est une chaine de caractères composée de 7 champs (dont les 6 premiers on obligatoires)

champ Valeurs autorisés Caractère spécial autorisé

Secondes 0-59 ,-*/

Minutes 0-59 ,-*/

Heures 0-23 ,-*/

Jour du mois 1-31 ,-*?/LW

Mois 1-12 ou Jan-Dec ,-*/

Jour de la semaine 1-7 ou SUN-SAT ,-*?/LW

Année Vide ou 1970-2099 ,-*/

<!--<trigger name="auto-publish"

target="org.apache.cocoon.components.cron.CronJob/auto-publish"

concurrent-runs="false">

<minutes>0</minutes>

<hours>1</hours>

<weekdays>MON-FRI</weekdays>

<cron>*/30 * * * * ? *</cron>

</trigger>-->

</triggers>

</component>

<!--+

| Sample definition of the CocoonPipelineCronJob cron job, used by

| trigger configuration above.

+-->

<!--<component role="org.apache.cocoon.components.cron.CronJob/auto-publish"

class="org.apache.cocoon.components.cron.CocoonPipelineCronJob"

logger="cron.pipeline">

<msg>Demarrage de la publication automatique de Pleade</msg>

<sleep>60000</sleep>

<pipeline>/edit/ead-publish-auto.txt?code={admin}&amp;pwd={pleade}</pipeline>

</component>-->

XDEMAT

75

Rap

port

de

stag

e| 1

3/09

/20

10

La liste de Caractères spéciaux autorisés :

* ("toutes les valeurs") - utilisée pour sélectionner toutes les valeurs dans un champ. Par exemple, "*" dans le domaine minutes "chaque minute".

? ("pas de valeur") - utile si vous avez besoin de préciser quelque chose dans l'un des deux domaines (Jour du mois ou Jour de la semaine) dans lesquels les caractères sont autorisés, mais pas l'autre. Par exemple, si je veux déclencher un job le 3èmejour du mois, indépendamment du jour la semaine "0 15 21 8 * ?". Mettre l'expression "0 15 21 8 * *", déclenche une Exception

java.lang.UnsupportedOperationException: Support for specifying both a day-of-week AND a day-of-month parameter is not implemented.

- utilisé pour indiquer une fourchette. Par exemple, "10-12" à l'heure domaine signifie "l'heure 10, 11 et 12".

, utilisés pour spécifier des valeurs. Par exemple, « MON,WED,FRI" signifie, "le jour lundi, mercredi et vendredi».

/ utilisé pour spécifier les incréments. Par exemple

-- "0 / 15" dans le champ des secondes signifie «la seconde 0, 15, 30 et 45"

--"5 / 15" dans le champ des secondes signifie «la seconde 5, 20, 35 et 50". Vous pouvez aussi spécifier "/" après le caractère''-''dans ce cas est équivalent à avoir «0» avant le «/»." 2 / 3 " dans le champ Jour du mois, "lancer le job tous les 3 jours à partir du deuxième jour du mois".

L ("dernier") - la valeur "L" dans Jour de la semaine, il signifie simplement "7" ou "SAT". - la valeur "L" dans « Jour du mois », signifie "le dernier jour du mois", donc 31 jours de Janvier, Février pour 28 jours sur les années non bissextiles. Mais si elle est utilisée après une autre valeur, il signifie "le xxx dernier jour du mois" - par exemple "6L" signifie "le dernier vendredi du mois".

W («semaine») - utilisée pour spécifier le jour de la semaine (lundi-vendredi) le plus proche de la journée. Par exemple, "15W": "le plus proche jour de la semaine du 15 du mois". Ainsi, si le 15 est un samedi, le job sera lancé, le vendredi 14, mais si le 15 est un dimanche, le job sera lancé le lundi 16. Si le 15 est un mardi, le job sera lancé, le mardi 15. Cas exceptionnel : "1W", si le 1er est un samedi, le job sera lancé le lundi 3 du mois, car il doit être lancé durant le mois. Autre cas « LW » : le dernier jour de la semaine du mois

# Signifie le Nième XXX jour du mois. "6#3" "le 3iemme vendredi du mois" (jour 6 = Friday). "2#1" = le premier Lundi du mois "4#5" = le 5iemme Mercredi du mois (si le mois ne comporte pas 5 mercredi, le job ne sera pas lancé

Exemple :

Si on fixe l'expression = "0 15 21 3 * ?"

Le résultat, de ("0 15 21 3 * ?") est : "le 03 du mois à 21:15:00"

Dans notre travail, nous avons modifié les paramètres du "cron" pour qu'il tourne toutes les 30 secondes. Voici le

résultat :

XDEMAT

76

Rap

port

de

stag

e| 1

3/09

/20

10

Mode de déroulement du processus :

Chaque 30 secondes, le CRON tourne et vérifie si un nouveau fichier Xml structuré (EAD, EAC,..etc.) est

présent dans le répertoire "ead" présent en suivant le chemin suivant : "..\pleade\webapp\exemples\ead"

Remarque :

Les différents actions du CRON sont enregistrées dans les fichiers de Log (..\pleade\webapp\WEB-INF\logs).

E. Les avantages :

Licence gratuite, open source

Moteur de recherche très puissant (recherche assez rapide et efficace)

Développé pour XML EAD => seul moteur connu à gérer l'héritage et l'indexation

Interface WEB complètement paramétrable

Grande communauté d'institutions utilisatrices en absolu.

<!--+

| Sample trigger definitions, use components defined below.

+-->

<trigger name="auto-publish"

target="org.apache.cocoon.components.cron.CronJob/auto-publish"

concurrent-runs="false">

<cron>*/30 * * * * ? *</cron>

</trigger>

</triggers>

</component>

<!--+

| Sample definition of the CocoonPipelineCronJob cron job, used by

| trigger configuration above.

+-->

<component role="org.apache.cocoon.components.cron.CronJob/auto-publish"

class="org.apache.cocoon.components.cron.CocoonPipelineCronJob"

logger="cron.pipeline">

<msg>Demarrage de la publication automatique de Pleade</msg>

<sleep>60000</sleep>

<pipeline>/edit/ead-publish-auto.txt?code=admin&amp;pwd=pleade</pipeline>

</component>

XDEMAT

77

Rap

port

de

stag

e| 1

3/09

/20

10

VI. Difficultés rencontrées

Durant le stage, j'ai souvent découvert des domaines passionnants mais parfois on se heurte à des difficultés,

parfois très coriaces.

A. Génération de fichier XML sous MAC OS X

Une des difficultés rencontrées, était la présence du fichier XML généré sous le système d'exploitation MAC OS

X. Alors que Eclipse me disait que la compilation s'est effectué correctement, je n'arrivais pas à retrouvé le fichier

Généré. Après avoir essayé le même programme sur le système d'exploitation Windows XP, le programme

s'exécute parfaitement bien et mon fichier Xml Ead est bien présent. Ou est le problème?

Solution trouvé : Au départ, j'ai décidé d'installer une machine virtuelle sur mon Mac et de travailler sur Windows, mais après

quelques jours de travail, un ami m'a proposé d'effectuer une recherche sur les fichiers cachés (dans Mac, les

fichiers cachés commencent par un point). Et c'est là que j'ai retrouvé les fichiers Xml Ead que j'avais générés

précédemment.

B. Compatibilité des rapports et des comptes rendu

Un autre problème auquel j'ai du faire face, et la compatibilité de mes rapports avec les logiciels utilisés par mes

tuteurs de stage. En effet, la plupart des utilisateurs sont adeptes de la solution bureautique Microsoft Office.

Malgré le fait que j'ai la version Mac de Microsoft office, je n'étais jamais sur s'ils avaient le même rendu que le

mien.

Solutions proposé : Pour y remédier, j'ai du installer le système d'exploitation Windows XP sur une machine virtuelle. Ce qui me

permettait de travailler sur deux systèmes différents selon les besoins.

C. Manque de documentation sur PLEADE

Etant un logiciel Open source, PLEADE n'avais pas une documentation complète et à jour. Ce qui a compliqué

relativement mes investigations pour maitriser les différentes facettes de ce logiciel. Néanmoins, un forum était

mis à disposition des utilisateurs, en cas de problème. Les réponses aux questions étaient relativement rapides

mais n'étaient pas assez précises parfois. Ces réponses étaient fournies par des informaticiens de la société AJLSM

D. Réutilisation des feuilles de style XSL de PLEADE :

J'ai eu à la fin du mois d'aout la mission d'encoder et d'indexer des instruments de recherche selon la norme EAD.

Et parmi les objectifs à atteindre, la réalisation des feuilles de styles XSL pour afficher les fichiers XML EAD en

HTML et en PDF.

Vu le nombre de balises existante dans la norme EAD (145 balises), nous avons pris la décision de réutiliser les

fichiers XSL du logiciel libre PLEADE. Cette décision été légitime puisque nous avions trouvé le fichier contenant

les "templates" nécessaires à nos besoins. La difficulté résidait dans la modification du fichier en question. En

effet, PLEADE utilise plusieurs paramètres : Indexation, moteur SDX, paramètres d'internationalisation

(i18n)..etc.

Le travail était vraiment complexe a réaliser, en plus du fait, que PLEADE fait une transformation vers du HTML,

puis du HTML vers le PDF. Alors que, nous pensions qu'il fallait créer deux fichiers distincts : une pour la

transformation du XML vers l' HTML, et l'autre du XML vers le PDF.

XDEMAT

78

Rap

port

de

stag

e| 1

3/09

/20

10

Solution proposé : Après quelques jours de recherche et d'investigation, nous avons fini par trouver une feuille de style en format

CSS pour l'EAD. Et la possibilité d'utiliser le logiciel "Prince XML22" pour l'affichage en PDF. Pour l'affichage en

HTML, il suffisait d'intégrer la feuille de style "ead.css" dans le fichier XML et de l'ouvrir avec un Navigateur.

E. Récupération du statut de publication de PLEADE

Après avoir réussi à automatiser la publication, on souhaiter récupérer le statut de publication et

l'envoyer aux personnes concernées pour les informer. On avait l'information que les données sur le statut se

trouvaient dans les fichiers de log, mais en parcourant ces fichiers, on les retrouvait pas.

L'autre difficulté qui s'ajoutait à celle là, est la façon dont il fallait procéder. On se devait de "parser" le fichier de

log, et de parcourir chaque ligne, pour vérifier s'il ya eu publication ou pas, sachant que le CRON tourne avec une

fréquence d'une minute, cela faisait un très grand nombre de ligne à parcourir.

VII. Conclusion et perspectives

Nous avons essayé de mener à bien le projet informatique définit pour le stage, commençant par l'analyse

des besoins et la compréhension des attentes du client.

La réalisation des spécifications fonctionnelles et techniques étaient important pour établir la procédure à suivre

dans la conception de l'application EAD_WEB.

Ceci dit, en amont, on se devait de s'investir dans le domaine des archives afin d'acquérir les connaissances métiers

nécessaire pour comprendre les besoins exactes du client.

Ce travail nous a dirigé vers l'exploration d'un logiciel Open source d'un très haut niveau, PLEADE, puisque c'est

un outil utilisé par plusieurs collectivités, et qui a fait ses preuves dans le domaine archivistique. Développé en

Java, nous avons éprouvé beaucoup d'enthousiasme à comprendre l'architecture utilisé pour réaliser PLEADE.

Une grande partie du programme PLEADE est basé sur l'utilisation du langage XML et des feuilles de style XSL.

Cela nous a beaucoup appris au niveau des mixages qu'il peut y avoir entre Java et XML.

Bien entendu, notre travail peut être amélioré, voici quelques pistes qui peuvent être explorées :

- Expérimenter l'application PLEADE avec des logiciels autre que PLEADE.

- Implémenter le standard SEAD, pour réussir l'échange des données entre deux ou plusieurs

systèmes informatiques.

- Elargir le champ d'application aux instruments de recherche autre que les bordereaux de

versement.

- Connecter l'application EAD_WEB avec les progiciels métier d'un coté et les SAE de l'autre,

avec une gestion des comptes utilisateurs.

22 www.princexml.com

XDEMAT

79

Rap

port

de

stag

e| 1

3/09

/20

10

Conclusion générale

La réalisation du ce stage, est pour moi, une formidable expérience professionnelle. Le thème du stage

m'a fait progresser sur deux secteurs qui, au départ, n'étaient pas forcément liés. L'informatique et l'archivage

électronique.

J'ai pu appliquer beaucoup de notions que j'ai acquises durant ma formation à Luminy, et en même temps, j'ai

découvert un domaine très passionnant et d'actualité, qui grandissait chaque jour : la dématérialisation et

l'archivage électronique. Ce domaine aspire à avoir des connaissances informatiques diverses et polyvalentes, et

spécialement dans la maitrise du langage XML et des domaines voisins comme XPath et XSLT.

La problématique du stage n'était pas évidente au départ, et le cahier des charges a évolué au fil du temps.

L'objectif principal était de maitriser la chine de production et de manipulation d'un document EAD. Nous avons

pu générer un document EAD conforme à la DTD EAD en vigueur et l'exploiter dans l'outil PLEADE qui est

destiné et utilisé par les archivistes.

A propos du standard SEDA, nous avons pu maitriser les connaissances théoriques et avoir des échos sur son

utilisation dans les collectivités comme le CINES.

Ce stage m'a également permis de rencontrer des informaticiens et des techniciens avec des connaissances accrues

dans leurs domaines, et avec qui, j'ai pu partager et évaluer mes compétences.

Je crois que l'expérience qui m'a le plus marqué, est la visite du CINES (Centre Informatique National de

l'Enseignement Supérieur) à Montpellier. Voir tous ces machines de calcul et les moyens mis en œuvre pour

assurer la sécurité et la pérennité des données était vraiment impressionnant.

XDEMAT

80

Rap

port

de

stag

e| 1

3/09

/20

10

1. Les Archives : pour quoi? pour qui? par qui? Portail International Archivistique Francophone. [En

ligne] http://www.piaf-archives.org/espace-formation/mod/resource/view.php?id=20.

2. Glossaire des techniques de l'information. [En ligne]

http://www.culture.gouv.fr/documentation/joconde/fr/partenaires/AIDEMUSEES/glossaire2.htm.

3. Supérieur, Centre Informatique National de l'Enseignement. Archivage numérique pérenne. [En

ligne] [Citation : 25 Juillet 2010.] http://www.cines.fr/spip.php?rubrique222.

4. Qu'est-ce-que le Dublin Core. Dublin Core. [En ligne]

http://www.bibl.ulaval.ca/DublinCore/usageguide-20000716fr.htm#1.2.

5. NFZ 42013. Wikipedia. [En ligne] http://fr.wikipedia.org/wiki/NF_Z_42-013.

6. BOUTIER, Claude. Analyse des besoins SAE Archive départementale - mise en place d'une maquette.

Marseille : Reactis, 2009.

7. Gonclave, Antonio. Les Cahiers du programmeur : Java EE5. s.l. : EYROLLES.

8. Midi-Pyrénées, Région. Archivage électronique à valeur probante dans les collectivités territoriales.

Septembre 2008.

9. [En ligne] DLM Forum. [Citation : 26 Aout 2010.] http://www.dlmforum.eu/.

10. AAF-ADBS, Le Groupe métiers. Comprendre et pratiquer le record management. 8 Avril 2005.

11. France, Direction des archives de. Dictionnaire de terminologie archivistique. 2002.

12. Thomas CHOPPY, Nicolas RICHETON. Livre blanc - GED Open source. s.l. : Smile.

13. Roques, Pascal. UML 2 par la pratique, Etude de cas et exercices corrigés. s.l. : EYROLLES, 2009.

14. DELANNOY, Claude. Programmer en Java. s.l. : EYROLLES, 2009.

15. Brillant, Alexandre. XML cours et exercices. 2007 : EYROLLES.

1 Bibliographie

XDEMAT

81

Rap

port

de

stag

e| 1

3/09

/20

10

VIII. Annexe A : Quelques terminologies archivistiques

1) Cadre de classement

Définition "Plan directeur préétabli qui fixe, au sein d’un service d’archives, la répartition des fonds et collections entre

de grandes divisions et subdivisions, appelées séries et sous-séries. Cette répartition détermine la cotation. Le cadre

de classement ne doit pas être confondu avec le plan de classement."

2) Collection

Définition "Réunion artificielle de documents en fonction de critères communs liés à leur contenu ou à leur support et

dont la juxtaposition est le fruit de la volonté ou du hasard, par opposition au fonds d'archives constitué de façon

organique par un producteur."

3) Durée d'utilité administrative

Définition "Durée légale ou pratique pendant laquelle un document est susceptible d'être utilisé par le service

producteur ou son successeur, au terme de laquelle est appliquée la décision concernant son traitement final. Le

document ne peut être détruit pendant cette période qui constitue sa durée minimale de conservation."

4) Fonds (d'archives)

Définition

"Ensemble de documents de toute nature constitué de façon organique par un producteur dans l'exercice

de ses activités et en fonction de ses attributions."

5) Indexation

Définition "Opération destinée à représenter par les éléments d'un langage documentaire ou naturel des données

résultant de l'analyse du contenu d'un document ou du document lui-même. "

6) Instrument de recherche

Définition "Outil papier ou informatisé énumérant ou décrivant un ensemble de documents d'archives de manière à les

faire connaître aux lecteurs. Les instruments de recherche fondamentaux sont, en allant du général au particulier,

les états des fonds et les guides, les états sommaires et états des versements, les répertoires méthodiques ou numériques et les

bordereaux de versement, les inventaires sommaires ou analytiques, les catalogues, les inventaires-index."

7) Mètre Linéaire

Définition Unité de mesure des archives correspondant à la quantité de documents rangés sur une tablette d'un mètre

de longueur.

XDEMAT

82

Rap

port

de

stag

e| 1

3/09

/20

10

8) Plan de classement

Définitions "(1) Système qui fixe l’organisation des archives courantes et intermédiaires en usage dans les bureaux

doivent être organisés, permettant de les ranger, de les classer et de les retrouver.

(2) Ordre dans lequel les archives définitives d’un fonds, d’une série ou d’un versement ont été classées et

ordonnées dans un service d’archives. A ne pas confondre avec cadre de classement."

9) Tableau de gestion

Définition État des documents produits par un service ou un organisme, reflétant son organisation et servant à gérer

ses archives courantes et intermédiaires et à procéder à l’archivage de ses archives historiques. Il fixe pour chaque

type de documents les délais d'utilité administrative, délai de versement au service d’archives compétent pour les

recevoir, traitement final et modalités de tri à lui appliquer.

XDEMAT

83

Rap

port

de

stag

e| 1

3/09

/20

10

IX. Annexe B : Les éléments de la norme Dublin Core

Élément Élément (en anglais)

Commentaire

1. Titre (métadonnée)

Title Titre principal du document

2.Créateur (métadonnée)

Creator Nom de la personne, de l'organisation ou du service à l'origine de la rédaction du document

3. Sujet (métadonnée) ou mots clés

Subject Mots-clefs, phrases de résumé, ou codes de classement

4. Description (métadonnée)

Description Résumé, table des matières, ou texte libre. Raffinements : table des matières, résumé

5. Éditeur Publisher Nom de la personne, de l'organisation ou du service à l'origine de la publication du document

6. Contributeur Contributor Nom d'une personne, d'une organisation ou d'un service qui contribue ou a contribué à l'élaboration du document. Chaque contributeur fait l'objet d'un élément Contributor séparé

7. Date (métadonnée)

Date Date d'un évènement dans le cycle de vie du document

8. Type de ressource

Type Genre du contenu

9. Format Format Type MIME, ou format physique du document

10. Identifiant de la ressource

Identifier Identificateur non ambigu : il est recommandé d'utiliser un système de référencement précis, afin que l'identifiant soit unique au sein du site, par exemple les URI ou les numéros ISBN.

11. Source Source Ressource dont dérive le document : le document peut découler en totalité ou en partie de la ressource en question. Il est recommandé d'utiliser une dénomination formelle des ressources, par exemple leur URI

12. Langue (métadonnée)

Language

13. Relation (métadonnée)

Relation Lien avec d'autres ressources. De nombreux raffinements permettent d'établir des liens précis, par exemple de version, de chapitres, de standard, etc.

14. Couverture (métadonnée)

Coverage Couverture spatiale (point géographique, pays, régions, noms de lieux) ou temporelle

15. Droits (métadonnée)

Rights Droits de propriété intellectuelle, Copyright, droits de propriété divers

XDEMAT

84

Rap

port

de

stag

e| 1

3/09

/20

10

X. Annexe C : Exemple d'instrument de recherche avec son

encodage en EAD

1S – Fonds du Centre hospitalier de Versailles, 1665-1982

« Maison de charité » dès le XVIIe siècle, l’hôpital royal est fondé par lettres patentes de juin 1720. Y est adjoint

une infirmerie royale en 1722. Il devient hôpital civil au milieu du XIXe siècle et se dote à partir de 1900 d’un

hospice de vieillards, l’hospice Despagne. Il devient dans les années 1950 le Centre hospitalier de Versailles, dont

le dernier agrandissement date de 1981, date à laquelle l’hôpital Mignot au Chesnay est inauguré. Aujourd’hui le

Centre hospitalier de Versailles comprend l’hôpital Mignot au Chesnay, rue de Versailles, où sont situées

l’essentiel des unités, l’hôpital Richaud, rue Richaud à Versailles, où sont encore présentes quelques unités, la

maison de retraite Despagne, rue Berthier à Versailles, et des services annexes.

Conformément à la circulaire AD 93-4 du 14 mai 1993 relative aux archives des établissements publics

d’hospitalisation, les archives classées sont ici répertoriées en sous-série 1 S suivi du numéro d’ordre général,

accompagné entre parenthèse de la cote intellectuelle du fonds issue des cadres de classement correspondant aux

différentes séries. A savoir le cadre de classement de 1854 sur les archives hospitalières antérieures à 1790 et celui

de 1968 pour les archives hospitalières postérieures à 1790. Cette double cotation doit être maintenue dans le

traitement d’encodage.

SÉRIE K- PERSONNEL

Personnel laïc de toutes catégories

1 S 67 (K1) Administrateurs, nominations : arrêtés, correspondance.

1859-1888

1 S 68* (K2*) Personnel : nomination et mouvement.

1822-1873

1 S 69* (K3*)-76* (K10*) Personnel, mouvement : registre matricule.

1874-1936

69* (K3*) 1er janvier 1874-30 août 1883

70* (K4*) 1er septembre 1883-30 novembre 1901

71* (K5*) 1er décembre 1901-31 décembre 1907

72* (K6*) 1er janvier 1908-31 septembre 1914

73* (K7*) 1er octobre 1914-31 décembre 1919

XDEMAT

85

Rap

port

de

stag

e| 1

3/09

/20

10

74* (K8*) 1er janvier 1920-30 juin 1925

75* (K9*) 1er juillet 1925-1er décembre 1930

76* (K10*) 1931-1er avril 1936

Personnel religieux hospitalier

1 S 77 (K11) Filles de la Charité, rétablissement de l'Ordre : arrêté du ministre de

l'Intérieur [imprimé] (1er nivôse an IX) (22 décembre 1800), décret impérial

[imprimé] (8 novembre 1809).

1800-1809

Corps médical hospitalier

1 S 78 (K12) Médecins et chirurgiens, nominations : correspondance, extraits des

délibérations de la commission administrative, états de service.

1858-1885

Caisse de retraites

1 S 79 (K13) Constitution : extrait des délibérations du conseil municipal de Versailles

(1818), correspondance (1819). Réunion en une caisse unique : copie d'une

ordonnance royale (1848), correspondance (1846-1848), état du supplément

de retenue à verser à la caisse des dépôts et consignations pour les employés

(1847), extraits des délibérations du conseil municipal de Versailles (1843,

1845).

1818-1848

Encodage et indexation de l'instrument de recherche "1S- fonds du Centre Hospitalier de

Versailles" en EAD :

<?xml version="1.0" encoding="UTF-8"?> <ead> <eadheader> <!-- identifiant EAD de l'IR : normé selon un modèle composé : - d'un premier segment composé de code Pays suivi du code institution - d'un deuxième segment composé du code de l'instrument de recherche --> <eadid>FRCH078_1S</eadid> <filedesc> <titlestmt> <!-- titre propre a l'instrument de recherche --> <titleproper>Répertoire Numérique du Fonds : 1S - Centre hospitalier de Versailles</titleproper> </titlestmt> </filedesc> <profiledesc>

XDEMAT

86

Rap

port

de

stag

e| 1

3/09

/20

10

<creation>Instrument de recherche encode en XML conforme ment a la DTD EAD (version 2002) par XDemat le <date normal="2010-08-23"> 23 août 2010</date></creation> </profiledesc> </eadheader> <!-- description de l'archives --> <archdesc level="fonds"> <did> <unitid countrycode="FR">1 S</unitid> <unittitle>1S - Fonds du Centre hospitalier de Versailles</unittitle> <unitdate normal="1665/1982">1665-1982</unitdate> <origination> <corpname>Centre hospitalier de Versailles</corpname> </origination> </did> <bioghist> <p> <corpname>« Maison de charité »</corpname> dès le <date normal="1601/1700">XVIIe siècle</date>, <corpname>l’hôpital royal</corpname> est fondé par lettres patentes de <date normal="1720-06">juin 1720</date>. Y est adjoint une <corpname>infirmerie royale</corpname> en <date>1722</date>. Il devient <corpname>hôpital civil</corpname> au milieu du <date normal="1801/1900">XIXe siècle</date> et se dote à partir de <date normal="1900">1900</date> d’un hospice de vieillards, <corpname>l’hospice Despagne</corpname>. Il devient dans les années <date normal="1950">1950</date> <corpname>le Centre hospitalier de Versailles</corpname>, dont le dernier agrandissement date de <date normal="1981">1981</date>, date à laquelle <corpname>l’hôpital Mignot au Chesnay</corpname> est inauguré. Aujourd’hui <corpname>le Centre hospitalier de Versailles</corpname> comprend <corpname>l’hôpital Mignot au Chesnay</corpname>,<address><addressline>rue de Versailles</addressline></address>, où sont situées l’essentiel des unités, <corpname>l’hôpital Richaud</corpname>, <address><addressline>rue Richaud à Versailles</addressline></address>, où sont encore présentes quelques unités, <corpname>la maison de retraite Despagne</corpname>, <address><addressline>rue Berthier à Versailles</addressline></address>, et des services annexes.</p> </bioghist> <processinfo> <p>Conformément à <extref>la circulaire AD 93-4</extref> du <date normal="1993-05-14">14 mai 1993</date> relative aux archives des <corpname>établissements publics d’hospitalisation</corpname>, les archives classées sont ici répertoriées en sous-série <ref>1 S</ref> suivi du numéro d’ordre général, accompagné entre parenthèse de la cote intellectuelle du fonds issue des cadres de classement correspondant aux différentes séries. A savoir le cadre de classement de <date>1854</date> sur les archives hospitalières antérieures à <date normal="1790">1790</date> et celui de <date normal="1968">1968</date> pour les archives hospitalières postérieures à <date normal="1790">1790</date>. Cette double cotation doit être maintenue dans le traitement d’encodage. </p> </processinfo> <dsc> <c level="series"> <did> <unittitle>SÉRIE K- PERSONNEL</unittitle> </did>

XDEMAT

87

Rap

port

de

stag

e| 1

3/09

/20

10

<c level="subseries"> <did> <unitid>1 S 67 - 1 S 76</unitid> <unitid type="cote_ancienne">K1 - K10*</unitid> <unittitle>Personnel laïc de toutes catégories</unittitle> <unitdate normal="1822/1936-04-01">1822 - 1 avril 1936</unitdate> </did> <c level="file"> <did> <unitid>1 S 67</unitid> <unitid type="cote_ancienne">K1</unitid> <unittitle><occupation>Administrateurs</occupation>, nominations : arrêtés, correspondance.</unittitle> <unitdate normal="1859/1888">1859-1888</unitdate> </did> </c> <c level="file"> <did> <unitid>1 S 68*</unitid> <unitid type="cote_ancienne">K2*</unitid> <unittitle>Personnel : nomination et mouvement.</unittitle> <unitdate normal="1822/1873">1822-1873</unitdate> </did> </c> <c level="file"> <did> <unitid>1 S 69* - 76*</unitid> <unitid type="cote_ancienne">K3* - K10*</unitid> <unittitle>Personnel, mouvement : registre matricule.</unittitle> <unitdate normal="1874/1936">1874-1936</unitdate> </did> <c level="item"> <did> <unitid>1 S 69*</unitid> <unitid type="cote_ancienne">K3*</unitid> <unittitle> <unitdate normal="1874-01-01/1883-08-30">1er janvier 1874-30 août 1883</unitdate> </unittitle> </did> </c> <c level="item"> <did> <unitid>1 S 70*</unitid> <unitid type="cote_ancienne">K4*</unitid> <unittitle> <unitdate normal="1883-09-01/1901-11-30">1er septembre 1883-30 novembre 1901</unitdate> </unittitle> </did> </c> <c level="item"> <did> <unitid>1 S 71*</unitid> <unitid type="cote_ancienne">K5*</unitid>

XDEMAT

88

Rap

port

de

stag

e| 1

3/09

/20

10

<unittitle> <unitdate normal="1901-12-01/1907-12-31">1er décembre 1901-31 décembre 1907</unitdate> </unittitle> </did> </c> <c level="item"> <did> <unitid>1 S 72*</unitid> <unitid type="cote_ancienne">K6*</unitid> <unittitle> <unitdate normal="1908-01-01/1914-09-31">1er janvier 1908-31 septembre 1914</unitdate> </unittitle> </did> </c> <c level="item"> <did> <unitid>1 S 73*</unitid> <unitid type="cote_ancienne">K7*</unitid> <unittitle> <unitdate normal="1914-10-01/1919-12-31">1er octobre 1914-31 décembre 1919</unitdate> </unittitle> </did> </c> <c level="item"> <did> <unitid>1 S 74*</unitid> <unitid type="cote_ancienne">K8*</unitid> <unittitle> <unitdate normal="1920-01-01/1925-06-30">1er janvier 1920-30 juin 1925</unitdate> </unittitle> </did> </c> <c level="item"> <did> <unitid>1 S 75*</unitid> <unitid type="cote_ancienne">K9*</unitid> <unittitle> <unitdate normal="1925-07-01/1930-12-01">1er juillet 1925-1er décembre 1930</unitdate> </unittitle> </did> </c> <c level="item"> <did> <unitid>1 S 76*</unitid> <unitid type="cote_ancienne">K10*</unitid> <unittitle> <unitdate normal="1931/1936-04-01">1931-1er avril 1936</unitdate> </unittitle> </did>

XDEMAT

89

Rap

port

de

stag

e| 1

3/09

/20

10

</c> </c> </c> <c level="subseries"> <did> <unitid>1 S 77</unitid> <unitid type="cote_ancienne">K11</unitid> <unittitle>Personnel religieux hospitalier</unittitle> <unitdate normal="1800/1809">1800-1809</unitdate> </did> <scopecontent> <p>Filles de la Charité, rétablissement de l'Ordre : arrêté du <corpname>ministre de l'Intérieur</corpname> [imprimé] (1er nivôse an IX) (<date normal="1800-12-22">22 décembre 1800</date>), décret impérial [imprimé] (<date normal="1809-11-08">8 novembre 1809</date>).</p> </scopecontent> </c> <c level="subseries"> <did> <unitid>1 S 78</unitid> <unitid type="cote_ancienne">K12</unitid> <unittitle>Corps médical hospitalier</unittitle> <unitdate normal="1858/1885">1858-1885</unitdate> </did> <scopecontent> <p><occupation>Médecins</occupation> et <occupation>chirurgiens</occupation>, nominations : correspondance, extraits des délibérations de la <corpname>commission administrative</corpname>, états de service.</p> </scopecontent> </c> <c level="subseries"> <did> <unitid>1 S 79</unitid> <unitid type="cote_ancienne">K13</unitid> <unittitle>Caisse de retraites</unittitle> <unitdate normal="1818/1848">1818-1848</unitdate> </did> <scopecontent> <p> Constitution : extrait des délibérations du <corpname>conseil municipal de Versailles</corpname> (<date>1818</date>), correspondance (<date>1819</date>). Réunion en une caisse unique : copie d'une ordonnance royale (<date>1848</date>), correspondance (<date normal="1846/1848">1846-1848</date>), état du supplément de retenue à verser à la <corpname>caisse des dépôts</corpname> et consignations pour les employés (<date>1847</date>), extraits des délibérations du <corpname>conseil municipal de Versailles</corpname> (<date normal="1843/1845">1843, 1845</date>). </p> </scopecontent> </c> </c>

XDEMAT

90

Rap

port

de

stag

e| 1

3/09

/20

10

</dsc> </archdesc> </ead>

XI. Annexe D : Exemple de fichier XmlEad généré avec

l'application EAD_WEB, le fichier XSL développé et le

résultat en PDF

<?xml version="1.0" encoding="UTF-8"?> <ead> <eadheader> <eadid>FRA013_00001</eadid> <filedesc> <titlestmt> <titleproper>Fonds du centre hospitalier</titleproper> </titlestmt> </filedesc> </eadheader> <archdesc level="fonds"> <did> <origination> <corpname role="producteur">Archives municipales de Versailles</corpname> </origination> <physdesc> Nombre d'articles 4, Métrage linéaire : 4.7ml <physfacet type="support">Papier</physfacet> </physdesc> <unitdate>1665-1982</unitdate> <unitid repositorycode="AM" countrycode="fr">W764RC</unitid> <unittitle>Centre hospitalier de Versailles</unittitle> </did> <accessrestrict> <p>Règles usuelles d'accès aux archives municipales</p> </accessrestrict> <acqinfo> <p>Type d'entrée : Versement date du versement : 12-09-2010</p> <p>Responsable du versement :Dupont Jean ces coordonnées : 0600000000, mail: jean.dupont@gmail.com. Sous la directions de monsieur : Carlton James, vous pouvez le contacter par courriel : james.carlton@yahoo.fr. Service Versant : Services de versement des AM Versailles Statut : Service du Conseil général ou établissement public départemental</p> </acqinfo> <dsc> <c level="item"> <did> <unitid>1S67</unitid> <unittitle>Arrêtés, correspondance</unittitle>

XDEMAT

91

Rap

port

de

stag

e| 1

3/09

/20

10

<unitdate>1859-1888</unitdate> <note> <p>Observ1</p> </note> </did> <scopecontent> <p>Desc1</p> </scopecontent> </c> <c level="item"> <did> <unitid>1S68</unitid> <unittitle>Personnel, mouvement : Registre matricule</unittitle> <unitdate>1874-1936</unitdate> <note> <p>Observ2</p> </note> </did> <scopecontent> <p>Desc2</p> </scopecontent> </c> <c level="item"> <did> <unitid>1S69</unitid> <unittitle>Personnel religieu hospitalier</unittitle> <unitdate>1800-1809</unitdate> <note> <p>Observ3</p> </note> </did> <scopecontent> <p>Desc3</p> </scopecontent> </c> <c level="item"> <did> <unitid>1S70</unitid> <unittitle>Corps médical hospitalier</unittitle> <unitdate>1858 - 1885</unitdate> <note> <p>Observ4</p> </note> </did> <scopecontent> <p>Desc4</p> </scopecontent> </c> </dsc> </archdesc> </ead>

XDEMAT

92

Rap

port

de

stag

e| 1

3/09

/20

10

Le fichier XmlEad.xsl servant à générer le fichier (l'instrument de recherche) XSLFO, puis en format PDF est le

suivant :

<?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0"> <xsl:output method="html" indent="yes" encoding="UTF-8" version="1.0"/> <xsl:template match="/"> <fo:root> <fo:layout-master-set> <fo:simple-page-master master-name="page" page-height="297mm" page-width="210mm" margin-bottom="2.5cm" margin-left="2.5cm" margin-right="2.5cm" margin-top="2.5cm"> <fo:region-body margin="1cm"/> </fo:simple-page-master> </fo:layout-master-set> <fo:page-sequence master-reference="page"> <fo:flow flow-name="xsl-region-body"> <fo:list-block> <!-- eadHeader --> <fo:list-item> <fo:list-item-label><fo:block></fo:block></fo:list-item-label> <fo:list-item-body> <fo:block> Identifiant du BV : <xsl:value-of select="/ead/eadheader/eadid/text()"/> </fo:block> </fo:list-item-body> </fo:list-item> <fo:list-item> <fo:list-item-label><fo:block></fo:block> </fo:list-item-label> <fo:list-item-body> <fo:block> Titre de l'archive : <xsl:value-of select="/ead/eadheader/filedesc/titlestmt/titleproper/text()" /> </fo:block> </fo:list-item-body> </fo:list-item> <fo:list-item> <fo:list-item-label><fo:block></fo:block> </fo:list-item-label> <fo:list-item-body> <fo:block> Titre du l'archive : <xsl:value-of select="/ead/eadheader/filedesc/titlestmt/titleproper/text()" /> </fo:block> </fo:list-item-body> </fo:list-item> </fo:list-block> <fo:list-block>

XDEMAT

93

Rap

port

de

stag

e| 1

3/09

/20

10

<fo:list-item> <fo:list-item-label> <fo:block> </fo:block> </fo:list-item-label> <fo:list-item-body> <fo:block>Type d'archive : <xsl:value-of select="/ead/archdesc/@level"/></fo:block> </fo:list-item-body> </fo:list-item> <fo:list-item> <fo:list-item-label> <fo:block></fo:block> </fo:list-item-label> <fo:list-item-body> <fo:block>Service producteur: <xsl:value-of select="/ead/archdesc/did/origination/corpname/text()" /></fo:block> </fo:list-item-body> </fo:list-item> <fo:list-item> <fo:list-item-label> <fo:block></fo:block> </fo:list-item-label> <fo:list-item-body> <fo:block>Identifiant de l'unite (unit id) : <xsl:value-of select="/ead/archdesc/did/unitid/text()"/></fo:block> </fo:list-item-body> </fo:list-item> <fo:list-item> <fo:list-item-label> <fo:block></fo:block> </fo:list-item-label> <fo:list-item-body> <fo:block>Description physique : <xsl:value-of select="/ead/archdesc/did/physdesc/text()"/> </fo:block> </fo:list-item-body> </fo:list-item> <fo:list-item> <fo:list-item-label> <fo:block></fo:block> </fo:list-item-label> <fo:list-item-body> <fo:block>Type d'archives : <xsl:value-of select="/ead/archdesc/did/unitid/@repositorycode" /></fo:block> <fo:block>code pays : <xsl:value-of select="/ead/archdesc/did/unitid/@countrycode"/></fo:block> </fo:list-item-body> </fo:list-item> <fo:list-item> <fo:list-item-label>

XDEMAT

94

Rap

port

de

stag

e| 1

3/09

/20

10

<fo:block></fo:block> </fo:list-item-label> <fo:list-item-body> <fo:block> Titre (unitTitle) : <xsl:value-of select="/ead/archdesc/did/unittitle/text()"/></fo:block> </fo:list-item-body> </fo:list-item> <fo:list-item> <fo:list-item-label> <fo:block></fo:block> </fo:list-item-label> <fo:list-item-body> <fo:block>Dates Extremes : <xsl:value-of select="/ead/archdesc/did/unitdate/text()"/></fo:block> </fo:list-item-body> </fo:list-item> </fo:list-block> <!-- Access restrict --> <fo:block> <xsl:value-of select="/ead/archdesc/accessrestrict/p/text()"/> </fo:block> <!-- Acq info : 2 paragraphe--> <fo:block> <xsl:value-of select="/ead/archdesc/acqinfo"/> <xsl:for-each select="p"> <xsl:value-of select="./text()"/> <fo:block>--------------------------------------------------</fo:block> </xsl:for-each> </fo:block> <!-- on se positionne au niveau de dsc --> <fo:list-block> <xsl:for-each select="/ead/archdesc/dsc/c"> <fo:list-item> <fo:list-item-label><fo:block></fo:block></fo:list-item-label> <fo:list-item-body><fo:block> Unitid : <xsl:value-of select="./did/unitid/text()"/></fo:block></fo:list-item-body> </fo:list-item> <fo:list-item> <fo:list-item-label><fo:block></fo:block></fo:list-item-label> <fo:list-item-body><fo:block> unitTitle <xsl:value-of select="./did/unittitle/text()"/></fo:block></fo:list-item-body> </fo:list-item> <fo:list-item> <fo:list-item-label><fo:block></fo:block></fo:list-item-label> <fo:list-item-body><fo:block>Dates extremes : <xsl:value-of select="./did/unitdate/text()"/></fo:block></fo:list-item-body> </fo:list-item> <fo:list-item> <fo:list-item-label><fo:block></fo:block></fo:list-item-label> <fo:list-item-body><fo:block> Observation : <xsl:value-of select="./did/note/p/text()"/></fo:block></fo:list-item-body>

XDEMAT

95

Rap

port

de

stag

e| 1

3/09

/20

10

</fo:list-item> <fo:list-item> <fo:list-item-label><fo:block></fo:block></fo:list-item-label> <fo:list-item-body><fo:block>Description du document : <xsl:value-of select="./scopecontent/p/text()"/></fo:block></fo:list-item-body> </fo:list-item> <fo:list-item> <fo:list-item-label><fo:block></fo:block></fo:list-item-label> <fo:list-item-body><fo:block>---------------------------------------------------------------------------------------------</fo:block></fo:list-item-body> </fo:list-item> </xsl:for-each> </fo:list-block> </fo:flow> </fo:page-sequence> </fo:root> </xsl:template> </xsl:stylesheet>

Le résultat en format PDF est le suivant :

XDEMAT

96

Rap

port

de

stag

e| 1

3/09

/20

10

XDEMAT