Anda di halaman 1dari 46

PREMIER MINISTRE

Secrtariat gnral de la dfense nationale


Direction centrale de la scurit des systmes dinformation
Sous-direction des oprations
Bureau conseil

Archivage lectronique scuris


CAHIER DES CHARGES
POUR UN SYSTME D'ARCHIVAGE LECTRONIQUE
(SPHRE PUBLIQUE)

Version du 16 mai 2006

51 boulevard de La Tour-Maubourg - 75700 PARIS 07 SP - Tl 01 71 75 84 15 - Fax 01 71 75 84 00


SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges SAE 16 mai 2006

Ce document a t ralis par le bureau conseil de la DCSSI


(SGDN / DCSSI / SDO / BCS)

avec le concours

de la Direction des Archives de France (DAF)


du ministre de la Culture et de la communication

et de la Direction gnrale pour la modernisation de l'tat (DGME)


du ministre de l'conomie, des finances et de l'industrie

sur la base d'une prestation de CAPRIOLI & ASSOCIES et JMR CONSULTANTS

Les commentaires et suggestions sont encourags et peuvent tre adresss l'adresse suivante :

Secrtariat gnral de la dfense nationale


Direction centrale de la scurit des systmes d'information
Sous-direction des oprations
Bureau Conseil
51 boulevard de La Tour-Maubourg
75700 PARIS 07 SP

conseil.dcssi@sgdn.pm.gouv.fr

Page 2 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges SAE 16 mai 2006

Historique des modifications

Version Objet de la modification Statut

Cration du document sur la base d'un march public (NCO05000012 du


Version de
107/02/2006 20 juin 2005, sur la fourniture d'une tude relative la scurit globale des
travail
services d'archivage)
16/05/2006 Finalisation Valid

Page 3 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges SAE 16 mai 2006

Table des matires


1 DOMAINE D'APPLICATION .................................................................................................................. 6

2 TEXTES LGISLATIFS, RGLEMENTAIRES ET DOCUMENTS DE RFRENCE................... 6

3 DFINITIONS............................................................................................................................................. 6

4 OBJECTIFS, CONTEXTE ET PRIMTRE DU CAHIER DES CHARGES .................................... 9


4.1 OBJECTIFS DU CAHIER DES CHARGES .................................................................................................... 9
4.2 DESCRIPTION DE LA PERSONNE PUBLIQUE ............................................................................................ 9
4.3 DESCRIPTION DE LA SITUATION PRSENTE ............................................................................................ 9
4.4 LES OBJECTIFS DU SYSTME DARCHIVAGE LECTRONIQUE ............................................................... 10
4.5 PRIMTRE ......................................................................................................................................... 10
5 PRSENTATION DES FONCTIONNALITS DU SAE...................................................................... 11
5.1 REPRSENTATION DE LINFORMATION ................................................................................................ 11
5.1.1 Contenu dinformation ............................................................................................................. 11
5.1.2 Information de prennisation ................................................................................................... 11
5.1.3 Dfinition dun paquet dinformation (ou lot).......................................................................... 12
5.1.4 Information de description ....................................................................................................... 13
5.2 PRSENTATION DES FONCTIONNALITS DU SAE................................................................................. 14
5.2.1 Contenu dun paquet dinformation ......................................................................................... 14
5.2.2 Fonctionnalits du SAE ............................................................................................................ 14
5.2.3 Dtail fonctionnel du Systme dArchivage lectronique ........................................................ 15
5.2.3.1 F1. Versement...................................................................................................................... 16
5.2.3.2 F2. Stockage ........................................................................................................................ 18
5.2.3.3 F3. Gestion des donnes descriptives .................................................................................. 22
5.2.3.4 F4. Communication / Consultation des Archives ................................................................ 23
5.2.3.5 F5. Administration du Systme darchivage lectronique ................................................... 25
5.2.3.6 Reprise de l'existant ............................................................................................................. 26
5.2.3.7 Composants applicatifs........................................................................................................ 27
5.2.4 Proposition darchitecture gnrale ........................................................................................ 27
5.2.4.1 volutivit de la solution propose...................................................................................... 29
5.2.4.2 Gestion de la duplication des informations.......................................................................... 29
5.2.4.3 Rsum des configurations possibles et comparaison ......................................................... 31
6 PROCDURE............................................................................................................................................ 34
6.1 FORME DE LA RPONSE ....................................................................................................................... 34
6.2 MAQUETTAGE..................................................................................................................................... 34
6.3 DCOUPAGE DU PROJET ...................................................................................................................... 34
6.3.1. Lancement du projet ................................................................................................................. 35
6.3.2. Conception dtaille................................................................................................................ 35
6.3.3. Ralisation............................................................................................................................... 35
6.3.3.1 Dveloppement.................................................................................................................... 35
6.3.3.2 Intgration............................................................................................................................ 36
6.3.3.3 Qualification et recette......................................................................................................... 36
6.3.4 Exploitation .............................................................................................................................. 36
6.3.4.1 Mise en production .............................................................................................................. 36
6.3.4.2 Dploiement......................................................................................................................... 36
6.3.4.3 Maintenance/Support........................................................................................................... 36
7 DISPOSITIONS JURIDIQUES ............................................................................................................... 37
7.1 FIABILIT DU SYSTME ....................................................................................................................... 37
7.2 PROPRIT INTELLECTUELLE .............................................................................................................. 37
7.2.1. Dispositions gnrales....................................................................................................................... 37
7.2.2. Documents et dveloppements spcifiques ........................................................................................ 38
7.2.3. Garantie de jouissance paisible......................................................................................................... 38
7.3 DONNES CARACTRE PERSONNEL .................................................................................................. 39

Page 4 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges SAE 16 mai 2006

7.3.1. Formalits pralables........................................................................................................................ 39


7.3.2. Scurit des donnes caractre personnel...................................................................................... 39
7.4 INTEROPRABILIT ............................................................................................................................. 39
7.5 RVERSIBILIT.................................................................................................................................... 39
7.6 CONTINUIT DE SERVICE..................................................................................................................... 40
7.7 ASSURANCE ........................................................................................................................................ 40
7.8 FORCE MAJEURE ................................................................................................................................. 40
8 ANNEXE LISTE DES TEXTES ET DOCUMENTS DE RFRENCE .......................................... 41
8.1 CONSERVATION DES DOCUMENTS LECTRONIQUES DANS LA SPHRE PUBLIQUE ................................ 41
8.2 DONNES CARACTRE PERSONNEL .................................................................................................. 43
8.3 AUTRES DOCUMENTS .......................................................................................................................... 44
FORMULAIRE DE RECUEIL DE COMMENTAIRES ................................................................................ 45

Page 5 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

1 Domaine d'application
Le prsent document a pour objet de faciliter les relations entre les administrations clientes dun
systme darchivage lectronique et les Prestataires potentiels pour un tel systme. Il est ainsi entre
autres prcis quelles sont les informations qu'il est conseill de faire figurer dans un cahier des
charges pour l'acquisition de tels systmes par une administration.

Ce document est adapter par la personne publique ou la personne prive charge dune mission de
service public.

2 Textes lgislatifs, rglementaires et documents de


rfrence
Au pralable, il est ncessaire didentifier les textes applicables dune part aux documents archivs
(nature juridique, valeur juridique), dautre part, aux archives publiques ainsi constitues (finalit de
larchivage, personnes comptentes, dure). Dans ce cadre, il est produit en annexe une liste des
textes juridiques applicables et adapter selon la nature de la personne concerne (ainsi une
collectivit locale nest pas soumise exactement aux mmes textes que les administrations de ltat,
notamment en ce qui concerne lorganisation des archives).

3 Dfinitions
- Archive : Paquet dinformations reu, conserv et communiqu par un Service darchives
(cette dfinition issue du standard dchange est la dfinition de rfrence dans le prsent
Cahier des charges).

- Archives : documents sous forme lectronique, quels que soient leur date et leur support,
produits ou reus par tout service ou organisme public ou priv, dans lexercice de leur activit
(dfinition issue du code du patrimoine).

- Archive courante : les Archives qui sont dutilisation habituelle pour lactivit des services,
tablissements et organismes qui les ont produites ou reues.

- Archive dfinitive : les Archives qui ont subi les tris et liminations dfinis aux articles 15 et
16 du dcret n 79-1037 du 3 dcembre 1979.

- Archive intermdiaire : les Archives qui ont cess dtre considres comme des Archives
courantes et les Archives qui ne peuvent encore, en raison de leur intrt administratif, faire
lobjet de tri et dlimination conformment larticle 16 du dcret n 79-1037 du 3 dcembre
1979.

- Authentification : procd visant vrifier l'identification dune personne physique par des
moyens techniques, tels que mot ou phrase de passe, un code secret, une rponse un dfi
ou encore une scurisation numrique (Certificat).

- Autorit darchivage : entit responsable de la gestion du service darchive et du systme


darchivage.

- Certificat : document sous forme lectronique attestant du lien entre lidentit du titulaire et
les donnes de vrification de signature lectronique.

- Communication : fait de porter lArchive ou toute information relative lArchive la


connaissance dune personne dtermine ou dun groupe dintresss ou des Usagers.

- Conservation : opration(s) juridique(s) ou (et) matrielle(s) destines assurer la


sauvegarde dun droit, dune chose, dun patrimoine

Page 6 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

- Consultation : interrogation du Systme darchivage lectronique destine vrifier


lexistence ou non dun Objet darchives.

- Contenu dinformation : ensemble dinformations constituant lobjet principal de la


prennisation.

- limination (ou Destruction) : opration autorise par un visa dlimination consistant, aprs
tri, dtruire lObjet darchive.

- Empreinte (empreinte numrique ou condensat ou hash) : Rsultat dune fonction de


hachage applique sur une chane de caractres de longueur quelconque visant rduire
celle-ci en une donne de longueur fixe reprsentative de cette chane de caractres.
Lempreinte est lun des lments permettant de vrifier lintgrit dun document, dun flux,
dun lot, dune transmission (comparaison dempreintes).

- Information de prennisation : se dcomposant en information de provenance, information


didentification, information dintgrit et information de contexte, linformation de
prennisation accompagne le Contenu dinformation afin quil puisse tre correctement
conserv.

- Journaux dvnement : Enregistrement dun ensemble de donnes relatives aux diffrentes


oprations effectues ou anomalies survenues au sein du SAE et destin assurer la
traabilit du service. Par ailleurs ces journaux doivent tre conservs pendant une priode
dfinir et donc faire lobjet dune procdure de sauvegarde particulire.

- Mtadonnes : description de lObjet darchives et ventuellement des parties de cet objet.


Les mtadonnes portent la fois sur le contenu, la gestion et le format.

- Migration de formats : opration qui consiste migrer le contenu de certains types de


formats vers dautres types afin que le format de fichier utilis pour la conservation des
Archives reste adapt compte tenu de lvolution des technologies.

- Migration de supports : opration qui consiste migrer le contenu de certains types de


supports vers dautres types, notamment afin danticiper lobsolescence du support concern.

- Module de scurit : systme de confiance bas sur une ressource cryptographique


prouve. Une ressource sera considre comme prouve si elle a subi une valuation
selon des critres dvaluation de la scurit des systmes dinformation en vigueur, avec une
cible de scurit et un niveau dassurance et de rsistance suffisant.

- Objet darchives : Donnes qui font lobjet de larchivage (dfinition issue de du Standard
dchange)

- Oprateur darchivage : entit qui fournit les services, lis au Service darchivage, demands
et spcifis par lAutorit darchivage au bnfice de cette dernire, oprant dans un cadre
hirarchique, rglementaire ou contractuel.

- Paquet dInformations : association du Contenu dinformation et de son Information de


prennisation. A ce Paquet dinformations est associe une information dempaquetage qui
permet de relier et didentifier les composants dun Paquet dinformations.

On distingue trois types de paquets :

o Les Paquets dinformation verser : Paquets dinformations livrs par le Service


producteur au Systme darchivage lectronique pour llaboration dun ou plusieurs
Paquets dinformations archivs.

o Les Paquets dinformation archivs : Paquets dinformations conservs dans le


Systme darchivage lectronique et constitu dun Contenu dinformation et de
lInformation de prennisation associe.

Page 7 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

o Les Paquets dinformations diffuss : Paquets dinformations reus par lUtilisateur en


rponse sa requte au Systme darchivage lectronique. Ce paquet provient dun
ou plusieurs Paquets dinformations archivs.

- Politique d'archivage : ensemble de rgles portant un nom qui indique les exigences
relatives un archivage lectronique scuris pour une communaut particulire et/ou une
classe d'application avec des exigences de scurit communes.

- Politique de scurit : ensemble de rgles portant un nom qui dfinit les exigences
physiques, techniques et logiques afin de garantir un niveau de scurit dtermin pour une
communaut particulire et/ou une classe d'applications.

- Prestataire : le fournisseur du Systme darchivage lectronique.

- Service darchives : dsigne lentit destinataire du Versement et assurant la gestion des


Archives verses par les Services versants et destines tre communiques aux Services
versants / producteurs, et, dans le respect des dlais de communicabilit, aux Usagers. Le
Service darchives assure galement une mission de conseil auprs des Services versants ou
des Services producteurs.

- Service producteur : entit qui a initialement reu ou produit lArchive et qui en est
propritaire. Le Service producteur et le Service darchives peuvent tre assurs par une
mme personne juridique.

- Service versant : entit qui verse un Paquet dinformations un Service darchives.

- Support : tout instrument permettant lUtilisateur de stocker des informations, de telle sorte
que celles-ci puissent tre consultes ultrieurement pendant une priode adapte lobjectif
de ces informations, et permettant la reproduction exacte des informations stockes.

- Stockage : opration consistant garder des Archives sur un Support pendant une dure
dtermine et dans un format prenne.

- Systme darchivage lectronique : systme consistant recevoir, conserver, traiter,


restituer des Archives, des Paquets dinformations, des Objets darchives, et qui sappuie sur
une plate-forme informatique.

- Usager : personne physique ou morale autorise consulter les Archives conserves sur le
Systme darchivage lectronique dans le respect de la lgislation applicable en matire de
communication des Archives.

- Utilisateur : toute personne physique ou morale autorise utiliser un Systme darchivage


lectronique.

- Versement : transmission par un Service versant dun Paquet dinformations un Service


darchives.

Page 8 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

4 Objectifs, contexte et primtre du cahier des charges

4.1 Objectifs du cahier des charges


Le cahier des charges spcifie les besoins et les contraintes de ladministration et permet celle-ci,
tout la fois de :
- progresser dans la conception du nouveau systme ;
- dfinir les critres de choix lorsque plusieurs solutions sont en comptition ;
- tablir les bases du cadre contractuel avec le Prestataire retenu.

Il est recommand de commencer le cahier des charges par un rsum qui fournisse les lments cl
du projet darchivage lectronique.

Notamment, il est ncessaire de prsenter de faon gnrale le ou les buts du Systme darchivage
lectronique envisag. Il est souvent utile de prciser en plus dune certaine ncessit, les gains
attendus : meilleure diffusion de linformation, suppression dArchives sous forme papier, rduction du
temps de traitement de dossiers

Il est aussi important de situer ce Systme darchivage lectronique au sein du systme d'information
de ladministration, en particulier identifier les liens quil peut avoir avec les autres outils informatiques.

Il convient galement de rappeler que le cahier des charges doit sappuyer sur la Politique darchivage
lectronique tablie par ladministration rdactrice du cahier des charges. Il est en effet indispensable
que le Systme darchivage lectronique rponde aux exigences poses dans la Politique
darchivage, dfaut le manque de cohrence serait prjudiciable la fiabilit de larchivage
lectronique mis en place.

4.2 Description de la personne publique


[ adapter en fonction de ladministration concerne Il nexiste pas de clause type]

Afin de permettre au Prestataire de mieux apprhender la problmatique de la personne publique


cliente, il est ncessaire de prsenter les missions, les activits, les besoins et les contraintes de
celle-ci.

Il convient aussi de prciser si le Systme darchivage lectronique objet du cahier des charges est
destin lensemble dune administration (centralise, dconcentre, dcentralise), ou si il ne
concerne quune direction, un service, voire un sous-ensemble de services.

Des organigrammes, des spcifications de poste peuvent tre fournis en annexe du cahier des
charges pour complter cette prsentation et permettre une meilleure apprhension du contexte du
projet.

4.3 Description de la situation prsente


Il convient de prsenter la situation prsente de ladministration dans la mesure o le Service
darchivage lectronique devra sy intgrer. Il sagira notamment de prsenter :
- Lenvironnement informatique global ;
- Le schma directeur informatique ou un dispositif en tenant lieu (le cas chant, le joindre en
annexe) ;
- Le schma directeur pour la scurit des systmes dinformation (le cas chant le joindre en
annexe) ;
- La ou les politique(s) de Rfrencement Intersectoriel de Scurit ;
- La ou les politiques de Rfrencement Interministriel dInteroprabilit ;
- Le systme darchivage lectronique dj existant, le cas chant.

Page 9 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

4.4 Les objectifs du Systme darchivage lectronique


Il importe de bien prciser quels sont les objectifs du Systme darchivage lectronique et de les
hirarchiser.

Lun des points fondamentaux dun Systme darchivage lectronique rside dans le respect des
obligations lgales et rglementaires relatives au Service darchives et aux Archives traites.

En ce sens, le Systme darchivage lectronique doit respecter le rgime juridique applicable la


gestion des archives publiques. En effet, si des contraintes spcifiques existent, il appartiendra la
personne publique de les prciser dans le cahier des charges. Il en est ainsi par exemple des
obligations tenant larchivage qui doit tre ralis dans des btiments publics, sur le territoire
national et de linterdiction dexternalisation du service public darchives pour les collectivits
territoriales.

La mise en place du Systme darchivage lectronique devra galement respecter les obligations
lgales et rglementaires relatives aux donnes caractre personnel, aux dclarations auprs de la
CNIL ds lors que des donnes caractre personnel sont en cause.

ce titre, le Prestataire devra effectuer les formalits adquates auprs de la CNIL en ce qui
concerne la conservation des donnes caractre personnel traites dans le cadre des prestations
quil devra assurer (voir galement les clauses ddies cette question dans le prsent Cahier des
charges ; ce point est important car le Prestataire a des obligations qui lui incombent en tant que
responsable de ses traitements mais galement en tant que Prestataire des personnes publiques qui
peuvent tre elles mme responsables de traitements et doivent, de ce fait, sassurer de la scurit
des traitements quelles mettent en place ou font mettre en place).

4.5 Primtre
Il convient d'indiquer dans le cahier des charges les types dArchives devant tre traits par le
Systme darchivage lectronique et de prciser notamment leur statut initial tel que tlprocdures,
messages lectroniques, fichiers bureautiques, fichiers images, Gestion lectronique des Documents.

De plus, pour chaque type dArchives, il convient :


- didentifier le ou les Services producteurs / Services versant devant effectuer le Versement
auprs du Service darchivage lectronique ;
- Leur dure de conservation ;
- Les lments gnraux de volumtrie.

Ladministration prcisera galement les impratifs de scurit souhaits selon la politique de scurit
qui lui est applicable.

Page 10 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

5 Prsentation des fonctionnalits du SAE


Afin de clarifier la suite du prsent document, sont reprises ci-aprs les dfinitions de certains termes
utiliss ainsi que leur interconnexion. Sont ensuite prsentes les fonctionnalits du SAE.

5.1 Reprsentation de linformation

5.1.1 Contenu dinformation


Si lon se rfre au modle OAIS, un contenu dinformation (Content Information) est un ensemble
dinformations constituant lobjet principal de la prennisation dvolue au SAE. Il est compos d'un
objet contenu de donnes (Content Data Object) et de son information de reprsentation
(Representation Information).

Contenu dinformation

Objet contenu de donnes

Information de reprsentation

Un objet contenu de donnes peut tre un objet physique ou un objet numrique sachant que ne sont
traits ici que des objets numriques. Un objet numrique (Digital Object) est un objet constitu dune
suite de bits qui prend la forme dun fichier lectronique gnr dans un format donn (par exemple
un format image ou un format texte).

Linformation de reprsentation (Reprsentation Information) est linformation qui traduit un objet


contenu en des concepts plus explicites. Il pourra sagir par exemple de la dfinition et de la
description du format image dans lequel a t gnr le fichier et qui permettra de convertir la
squence de bits dont il se compose sous une forme intelligible par lutilisateur. Cette information de
reprsentation peut soit tre fournie par le service versant avec lobjet contenu de donnes, soit tre
gre sparment par le service darchives dans une base de connaissances. Dans ce dernier cas le
service darchives a la charge de contrler, lors des versements, lexistence de la documentation
correspondante dans sa base de connaissances.

Par exemple dans le cadre de dlibrations transmises par les collectivits aux prfectures pour le
contrle de lgalit, la correspondance avec les dfinitions prcdentes pourrait tre :
- Objet contenu de donnes : fichiers PDF correspondant aux dlibrations transmises et les
informations de signatures ventuelles associes
- Informations de reprsentation : indication du format PDF

5.1.2 Information de prennisation


Afin quun contenu dinformation puisse tre correctement conserv, il doit tre accompagn dune
information de prennisation (Preservation Description Information - PDI) qui se dcompose de la
faon suivante :
- Information de provenance (Provenance Information) : information qui documente l'historique
du contenu dinformation. Cette information renseigne sur l'origine ou la source du contenu
dinformation, sur toute modification intervenue depuis sa cration et sur ceux qui en ont eu la
responsabilit. Exemple : nom du principal responsable de l'enregistrement des donnes,
informations relatives au stockage, la manipulation et la migration des donnes.

Page 11 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

- Information de contexte (Context Information) : information qui dcrit les liens entre un
contenu dinformation et son environnement. Elle inclut entre autres les raisons de la cration
de ce contenu dinformation et son rapport avec dautres objets contenu de donnes.

- Information didentification (Reference Information) : information qui identifie et si ncessaire


dcrit le ou les mcanismes dattribution des identificateurs au contenu dinformation. Elle
inclut aussi les identificateurs qui permettent un systme externe de se rfrer sans
quivoque un contenu dinformation particulier. Exemple : un ISBN (International Standard
Book Number).

- Information dintgrit (Fixity Information) : description des mcanismes et des cls


dauthentification garantissant que le contenu dinformation na pas subi de modification sans
que celle-ci ait t trace. Par exemple, le code CRC (contrle de redondance cyclique) pour
un fichier ou mieux le calcul dempreinte.

Information de prennisation

Information de provenance

Information de contexte

Information didentification

Information dintgrit

5.1.3 Dfinition dun paquet dinformation (ou lot)


Daprs lOAIS, lensemble des changes dinformations effectus entre le systme darchivage et
lextrieur seffectue par lintermdiaire de paquets dinformations.
Un paquet dinformations (Information Package IP) est lassociation du Contenu dinformation et de
son Information de prennisation (PDI). A ce paquet dinformations est aussi associe une Information
dempaquetage qui permet de relier et didentifier les composants d'un Paquet dinformations.

Paquet dinformation

Contenu dinformation Information de prennisation

Information dempaquetage

On distingue ainsi trois types de paquets :

- Les paquets dinformations verser (Submission Information Package - SIP) : Paquet


dinformations livr par le service producteur ou service versant au systme darchivage
pour l'laboration d'un ou plusieurs Paquets dinformations archivs (AIP).

- Les paquets dinformations archivs (Archival Information Package - AIP) : Paquet


dinformations conserv dans le systme darchivage et constitu dun Contenu
dinformation et de lInformation de prennisation (PDI) associe.

Page 12 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

- Les paquets dinformations diffuss (Dissemination Information Package - DIP) : Paquet


dinformations reu par lUtilisateur en rponse sa requte au systme darchivage. Ce
paquet provient dun ou de plusieurs Paquets dinformations archivs (AIP).

5.1.4 Information de description


Enfin, lInformation de description (Descriptive Information) est un ensemble dinformations, extraites
de l'information de reprsentation et des informations de prennisation, constitu principalement de
descriptions de paquets et permettant aux utilisateurs de rechercher, commander et rcuprer des
informations du systme darchivage.

Par exemple dans le cadre du contrle de la lgalit cette information descriptive, destine identifier
une dlibration, pourrait tre la date de la dlibration et le nom de la collectivit mettrice.

Page 13 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

5.2 Prsentation des fonctionnalits du SAE


En terme de flux dinformation, le schma ci-aprs fournit le fonctionnement gnral des changes du
SAE avec les services producteurs et les utilisateurs.

Producteurs
Utilisateurs
Services versants

Systme Archivage Electronique


Paquets
Paquets
dinformations
dinformations Paquet dinformation archiv diffuss
verser
Paquet dinformation archiv
Paquet dinformation archiv
Paquet dinformation archiv

5.2.1 Contenu dun paquet dinformation


Afin de prciser le dtail du contenu effectif de chaque paquet dinformation, lAdministration pourra se
rfrer au standard dchange sachant que le principe de base retenu est de sappuyer sur le modle
OAIS et les possibilits offertes par la DTD EAD, pour la description de lObjet archiv.

Dans le cas du Versement il est ainsi propos que soient transfrs les diffrents fichiers constituant
lObjet archiver, ainsi que linformation de prennisation associe dcrite suivant les rgles de la
DTD EAD, lensemble tant rassembl sous un numro unique didentifiant du versement.

Dans certains cas, lobjet archiver correspondra un fichier XML, pouvant encapsuler, en Base64,
les diffrents fichiers si ceux-ci taient initialement sous un format binaire.

Devront par ailleurs tre spcifis, partir dun rfrentiel laborer par la direction des Archives de
France, partir dune part du cadre commun dinteroprabilit et, dautre part du registre de formats
PRONOM, les formats des fichiers, les seuls formats accepts pour larchivage moyen et long terme
tant des formats dont les spcifications sont publiques.

5.2.2 Fonctionnalits du SAE


Afin de bien dfinir ses besoins, lAdministration prcisera par ailleurs le dtail des fonctionnalits
attendues du SAE destin permettre lexcution des trois objectifs de base de tout SAE que sont la
ralisation des changes prcdents, la prennisation et la garantie dintgrit des donnes qui lui
sont confies.

Est brivement rappel ci-dessous lensemble des fonctions attendues par le SAE avant de le dcrire
plus en dtail.

F1. Versement : permet le traitement des paquets dinformations en provenance des Services
versants dans son ensemble. Cette fonction inclut tous les mcanismes de prparation, transmission,
contrle, rejet, complment dinformation ainsi que tous les traitements de ces informations pour une
intgration dans le dispositif de Stockage des contenus et celui de gestion des donnes descriptives ;

F2. Stockage : gre lensemble des services lis la conservation des paquets dinformations
archivs partir du moment o ils sont mis sa disposition par la fonction de Versement jusqu leur

Page 14 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

destruction/limination sil y a lieu tout en garantissant leur intgrit. Cette fonction prend entre autres
en compte les aspects de choix de supports et de gestion de lensemble des migrations ;

F3. Gestion des donnes descriptives : assure la conservation, la mise disposition et la mise
jour des informations descriptives associes aux contenus dinformations, conservs par la fonction
Stockage. Ces informations doivent servir aux utilisateurs comme point dentre au SAE et permettre
de retrouver les donnes quils recherchent en assurant le lien avec leur identification de localisation
dans le systme de stockage ;

F4. Consultation et communication : prvoit lensemble des mcanismes permettant daccder, de


consulter et de livrer les informations disponibles dans le SAE, quil sagisse des donnes descriptives
ou du contenu lui-mme. Elle comprend la mise disposition dune interface de consultation, un
systme de recherche effectue partir des donnes descriptives, un principe de visualisation du
rsultat, la slection de contenus communiquer et la livraison effective de ces contenus sous forme
de paquets dinformations diffuss. Dans la mesure o la communication du contenu peut tre diffre
par rapport au moment de linterrogation, cette fonction doit galement prvoir un mcanisme de
commandes destination des utilisateurs, le suivi tant assur par la fonction Administration ;

F5. Administration : permet dassurer lexploitation d'ensemble du Systme d'archivage lectronique


et sa prennisation ainsi que la gestion des utilisateurs du SAE au sens de leurs droits daccs.

5.2.3 Dtail fonctionnel du Systme dArchivage lectronique


Le schma ci-aprs prcise les liens entre les diffrentes fonctions auxquelles doit rpondre le SAE
envisag.

Systme Archivage Electronique

S F3. Gestion des donnes


E Information descriptives
de
description U
R Rponses
Demandes T
V
I
I F4. Consultation
F1. Versement Interrogations L
C PIV
Communication I
E
PID
S
A
V F5. Administration
T
E
E
R
U
S PIA PID
Requtes R
A
S
N
F2. Stockage
T

Page 15 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

5.2.3.1 F1. Versement


La finalit du versement est de transformer les paquets dinformations verss en un ou plusieurs
paquets dinformations archivs. LAdministration rdactrice du cahier des charges pourra galement
se rfrer au Standard dchange.

F1. FONCTION VERSEMENT

P2.Vrifier
transmission

PIV
P5.Consulter AR
Information Identification
PIV
P3.Contrler
conformit
F2. Stockage
PIV
P6.Convertir

Service P1.Recevoir P7.Gnrer P8.Coordonner


PIV P4.Journaliser PIV PIA
versant versement PIA Mises jour

AR
F3. Gestion
donnes
descriptives

AR

PIV : Paquet dinformation vers


PIA : Paquet dinformation archiv

La fonction versement peut tre dcompose en huit processus :


- P1.Recevoir versement : Ce processus consiste effectivement rceptionner dans un
espace de stockage tampon, les Paquets dinformations verss (PIV) en provenance du
Service versant. La transmission entre les deux services peut tre effectue en ligne ou
via un support amovible dans le cas par exemple de fichiers volumineux envoys faible
frquence ;

- P2.Vrifier transmission: Ce processus vrifie que le Paquet dinformations transmis par le


Service versant a bien t rceptionn dans son intgralit et sans altration. Lintgrit
globale de lenvoi ainsi que lintgrit des diffrents Paquets dinformations transmis et
reus devront tre contrles. En matire de contrle dintgrit le standard dchange
prconise lutilisation dune empreinte dont lalgorithme de calcul est indiqu dans lenvoi,
le systme de contrle devra donc tre capable de traiter plusieurs algorithmes et
dvoluer dans ce sens.

- P3.Contrler conformit : Ce processus contrle que le paquet dinformations vers est


conforme et respecte bien les conditions dfinies entre le service versant et le service
darchives, entre autres en matire de structuration de lensemble des donnes et de leur
compltude, en matire de format de description, en matire de respect des formats
dencodage des objets verss et de leurs composants ;

- P4.Journaliser : Ce processus rpond un impratif que lon retrouve dans lensemble du


SAE consistant enregistrer dans un journal lintgralit des oprations effectues et des
vnements. En parallle, ce processus envoie un accus de rception (ou un rapport
danomalie en cas de contrles ngatifs) au Service versant prcisant le rsultat de
lopration, suite aux diffrents contrles effectus ;

- P5.Consulter : Ce processus doit permettre si ncessaire, aux personnes habilites du


service darchive, de consulter le contenu du paquet dinformation vers ;

Page 16 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

- P6.Convertir : Ce processus est optionnel et rpond au besoin rsultant du cas o le


service producteur nest pas en mesure de produire le paquet dinformation vers en
respectant les spcifications attendues. On peut ainsi envisager que, dans certains cas, le
SAE opre une migration de formats soit larrive soit au terme dun dlai dpendant de
lobsolescence du format dorigine ;

- P7.Gnrer PIA : Ce processus revient constituer un Paquet dinformations archiv


conforme aux normes de documentation et de formatage des donnes telles que dfinies
pour le SAE dans le Standard dchanges. Ce processus prend galement en compte les
conditions darchivage spcifiques aux paquets dinformations verss : conditions de
prservation, de communication et ventuellement de destruction ;

- P8.Coordonner les mises jour : Ce processus consiste dune part transmettre la


fonction stockage le contenu dinformation conserver et dautre part transmettre la
fonction gestion des donnes descriptives les donnes correspondantes. Lensemble de
ces informations se retrouve dans le Paquet dinformation archiv. Le processus attend
ensuite en retour laccus de rception du rsultat de lopration. Dans le cas du
stockage, laccus de rception doit contenir linformation didentification de lespace de
stockage. Cette dernire donne est ensuite envoye en complment des informations
prcdentes la fonction gestion des donnes descriptives ;
En complment ces lments purement fonctionnels, lAdministration devra notamment spcifier :
- les lments de volumtrie affrents suivant la nature des archives (intermdiaire ou
dfinitive), leurs formats et le type des archives (dossiers comptables, individuels,
contentieux, judiciaires) ;
- le type (en ligne ou sur support amovible) et la frquence des transmissions auquel il
faudra avoir recours pour chaque type darchives ;
- dans le cas dun Versement en ligne, il conviendra de prciser quels types de protocoles
pourront tre utiliss.

ce stade le facteur cot trouvera toute son importance quant au dimensionnement des capacits de
transmission en entre. En effet, techniquement, il sera toujours possible de mettre en place
larchitecture correspondant exactement aux besoins exprims, tant en nombre daccs simultans
quen matire de volumtrie absorber. Par contre les cots sont dautant plus importants que ces
dernires valeurs sont leves. Il sera donc primordial que lAdministration dfinisse ses besoins en
tenant compte du fait que certains versements sont traiter avec moins durgence que dautres et en
consquence ne pas hsiter prvoir peut-tre plus de transferts sur support externe, nettement
moins onreux.

Page 17 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

5.2.3.2 F2. Stockage


Lobjectif du stockage dans un SAE est absolument essentiel dans la mesure o il consiste garantir
la prennit et lintgrit de lensemble des informations qui y sont conserves. Par souci de clart le
terme de paquet dinformations archiv est utilis par la suite alors que dans la ralit et si lon se
rfre au standard dchange il sagirait plutt du contenu dinformation au sens OAIS.

F2. FONCTION STOCKAGE

P3.Dtruire

PIA
F4. Consultation
PID
Communication
P2.Mode de P4.Garantir P6.Prparer
F1. Versement PIA P1.Recevoir PIA
stockage lintgrit PID

AR
Information Identification PIA F5. Administration

P5.Grer les
migrations
P7.Fournir
statistiques
F3. Gestion
donnes
descriptives

PIA : Paquet dinformation archiv


PID : Paquet dinformation diffus

Le stockage comprend les sept processus suivants :


- P1.Recevoir : Ce processus revient rceptionner les paquets dinformations archivs en
provenance du processus de Versement et les transfrer physiquement vers le volume
de stockage le mieux appropri et correspondant aux conditions darchivage (dure,
frquence de consultation, communication en ligne ou diffre, destruction in fine)
indiques au moment du versement. Lorsque les paquets dinformations archivs sont
effectivement crits sur le support de stockage adapt, il y a transmission au processus
de Versement du rsultat de lopration comprenant linformation didentification
correspondant lespace de stockage o se trouve physiquement les paquets
dinformations archivs qui viennent dtre traits ;

Remarque par rapport lcriture effective


Au sujet de lcriture sur un support de stockage quel quil soit, il est important de vrifier que laccus
de rception du systme est bien envoy lorsque lcriture est vritablement effective sur le support
en question et non pas en attente de traitement dans un espace mmoire tampon. En effet, dans la
majorit des cas et suite un ordre dcriture par exemple sur disque, linformation concerne se
trouve en mmoire vive de lordinateur et est donc sujette disparition en cas de coupure de courant.
Il est vrai que la majorit des systmes possdent des scurits en matire dalimentation lectrique
mais il est nanmoins prudent de demander et de vrifier quel moment prcis laccus de rception
dcriture est effectivement gnr.
Ce premier point se complique galement du fait que linfrastructure dun SAE est gnralement
compose dau moins deux sites. Dans le cas dune rplication, dtaille par la suite, il sagit donc
galement de vrifier que laccus de rception parvient aprs lcriture effective sur les deux sites. Si
tel nest pas le cas il faudra alors analyser quel risque est encouru de pouvoir se trouver dans une
situation, certes extrme, o linformation pourrait par exemple avoir t crite sur le premier site et
non sur le second et prvoir les procdures associes afin dy remdier.

- P2.Mode de stockage : Ce processus consiste conserver effectivement les paquets


dinformations archivs et choisir le support adquat en fonction dun certain nombre de

Page 18 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

critres dont les principaux sont laccessibilit et la dure. Pour ce faire il pourra tre
envisag de mettre en place un systme de HSM (hierarchical storage management) afin
daider cette gestion des diffrents supports ;

Remarque sur le HSM (hierarchical storage management)


Lobjectif dun tel processus revient optimiser les cots de stockage partant du principe que les
supports nont pas tous les mmes performances ni les mmes cots associs et que les donnes
conserves nont pas toutes les mmes exigences. Ce processus consiste ainsi de faon gnrique,
suivre les statistiques dutilisation des donnes afin de les changer automatiquement de support en
fonction de leur frquence daccs et de demande de communication. En rgle gnrale lon
commence par utiliser un support performant pour passer ensuite vers des supports dont le cot est
de plus en plus faible mais les temps daccs de plus en plus longs et ce au fur et mesure que la
frquence dutilisation de la donne diminue. Au niveau des accs, les supports peuvent tre classs
comme tant en ligne ou on line , cas de disques magntiques, quasiment en ligne ou
near line , exemple des robots de disques optiques, enfin hors ligne ou off line , cas des
supports conservs sur tagre. Dans le cas dun HSM, lon passera ainsi successivement, par
exemple, du disque magntique (on line) au disque magnto optique (near line) puis de la bande
magntique en silo puis sur tagre (off line). A linverse, ds que la frquence dutilisation des
donnes a tendance augmenter, le processus de changement de support a lieu dans lautres sens,
savoir du support le moins cher et le moins accessible vers le support le plus onreux et le plus
accessible.

- P3.Dtruire : Ce processus est destin traiter le cas chant la destruction des paquets
dinformations archivs de faon manuelle ou automatique ;

Remarque sur la destruction


Plusieurs solutions existent permettant de ne plus avoir accs une information. Ainsi lorsquil sagira
de destruction, le SAE devra possder une telle fonction comportant au minimum un dispositif de
suppression des accs aux contenus dinformations par suppression des index et mieux un vritable
dispositif deffacement des contenus dinformation. Ce dispositif devra par ailleurs tre conu de telle
sorte ne laisser aucune trace sur le support dorigine, due entre autre au phnomne physique de
rmanence des supports magntiques. En ce qui concerne les supports amovibles type bande ou CD,
la destruction sera opre sur lensemble du contenu et du contenant.

- P4.Garantir lintgrit : Ce processus est extrmement important dans la mesure o il doit


garantir lintgrit de lensemble des paquets dinformations archivs et en consquence,
la vrifier systmatiquement. Il est en effet ncessaire de contrler rgulirement les
paquets dinformations archivs sur les diffrents supports afin danticiper dventuelles
erreurs et surtout de prvoir des dispositifs davertissement dune part et de correction
dautre part. En cas de dtection dune erreur dintgrit la seule faon de la corriger est
de remplacer les donnes concernes par un jeu de donnes identiques non corrompues
dont on disposera grce un systme de duplication adapt de lensemble des donnes ;

Remarque par rapport au contrle dintgrit


Il est important de noter quil existe en ralit plusieurs faons de contrler lintgrit.
Contrle ponctuel : Le contrle na lieu quau moment de laccs lobjet concern c'est--dire au
moment de sa communication. Le principal inconvnient rside dans le fait quil peut tre trop tard
dans le sens o lon va effectivement dtecter une erreur dintgrit mais sans pouvoir y remdier du
fait que lon ne possde pas ou plus de jeu sain de ces donnes.
Contrle rgulier par sondage : Ce type de contrle est opr de faon totalement automatique sur
les contenus dinformations choisis de faon alatoire (sauf cas particulier de contenus dinformations
particulirement sensibles traiter en globalit). Ces contrles doivent galement pouvoir tre
paramtrs en fonction du type de supports et de leurs ges respectifs.
Contrle continu : Comme indiqu, ces contrles sont oprs de faon continue sur un ensemble
dfini de paquets dinformations archivs. Signalons ce niveau quun tel contrle existe de faon
native sur certains systmes de stockage.

- P5.Grer les migrations : Il sagit de matriser lensemble des migrations (voir ci aprs)
requises par le systme tant des supports que des formats. Ces migrations interviennent

Page 19 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

soit de faon planifie (voir fonction Administration) soit par exemple pour corriger des
erreurs dtectes sur tel ou tel support ;

Remarque par rapport aux diffrents types de migrations


Sans vouloir trop entrer dans les dtails il est cependant important de prciser quil existe plusieurs
types de migrations abords ci-dessous.

Changement de supports : Ce premier type de migration consiste permettre de remplacer,


renouveler des supports sur lesquels les donnes sont conserves. Ces changements pourront faire
suite des erreurs rptitives sur un support ou tout simplement tre programms au pralable en
fonction du type de support et de leur ge. Les erreurs dont il est ici fait mention sont essentiellement
de deux types : erreurs de lecture du support ou erreur dintgrit. Dans les deux cas il est ncessaire
et indispensable de disposer dun dispositif de correction automatique de ces erreurs dont la
consquence principale revient justement changer de support.
Le management de la hirarchie du stockage ou HSM peut galement tre vu comme un bon
exemple de migration de support.

Changement de format : Au-del du simple changement de support, il existe un autre type de


migration destin permettre dassurer le changement des formats (au sens logique du terme) dans
le cas par exemple de lutilisation de nouveaux supports dun point de vue technologique. Il pourra
ainsi sagir de supports fonctionnant sous un nouveau systme dexploitation disposant dune gestion
de fichiers spcifique. La migration de formats pourra galement tre rendue ncessaire en raison
dune obsolescence technologique des formats de donnes archivs, en raison dune veille
technologique anticipant la disparition de tels formats ou au contraire de lapparition sur le march,
dun nouveau format plus appropri la prennisation (par exemple, des fichiers au format PDF vers
le format PDF/A normalis ISO 19005).

Par rapports ce qui prcde en matire de migration il est important dattirer lattention sur le fait que
les technologies se prtent plus ou moins bien aux migrations. Ainsi certains systmes possdent par
exemple une logique de cellules de stockage indpendantes, particulirement bien adapte pour les
migrations dans la mesure o le volume migrer est limit la taille dune cellule et limpact sur le
reste des donnes est donc forcment rduit. Il conviendra par consquent de bien prendre en
compte cette fonctionnalit dans le choix qui sera fait.

- P6.Prparer : Ce processus est destin transmettre les paquets dinformations diffuss


suite une sollicitation du processus de communication ;

- P7.Fournir les statistiques : Il sagit de btir des statistiques dexploitation relatives dune
part aux capacits utilises par rapport aux diffrents supports et espaces de stockage,
ainsi que sur ltat des supports et dautre part en matire de communication des paquets
dinformations archivs, en complments aux statistiques de consultation, sans oublier
lvolution des paquets dinformations verss.

En rsum, un systme de stockage doit avoir les caractristiques suivantes : fiabilit, disponibilit,
maintenabilit, scurit mais doit galement permettre labstraction de la plate-forme matrielle, tre
extensible, interoprable et volutif.

En fonction de ses besoins lAdministration pourra indiquer, le cas chant, les divers types de
supports ou typologies de stockage pouvant tre utiliss par le SAE :
- Typologie darchitecture (NAS, SAN) ou organisations spcifiques autour du concept du
CAS (content addressed storage) ou encore choix dun systme plutt organis en
cellules indpendantes et autonomes ;
- Supports magntiques (bande, disque, cartouche) ;
- Supports optiques rinscriptibles ou non rinscriptibles (disque optique ou magnto-
optique, CD-R, CD-RW, DVD, carte).

Page 20 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

Nanmoins il sera prfrable de laisser au prestataire le soin de faire des propositions en matire de
types de supports. LAdministration devra de prfrence se limiter bien dfinir le type de donnes
archiver et surtout dans quelles conditions de dure et daccessibilit. Il faudra galement avoir soin
de prciser le format logique utilisable sachant que lon pourra ce niveau se rfrer au standard
dchange tel quvoqu.

Dans le cas des CD et sauf volumtries trs rduites, on ne prconise pas leur utilisation comme
supports de conservation du fait principalement de leur faible capacit de stockage, des manipulations
ncessaires, du processus de validation des lots de CD mettre en place en matire de processus
qualit, de la relative fragilit du support. Il en est de mme pour les DVD pour lesquels bien que la
capacit soit suprieure celle des CD, la fiabilit est loin dtre assure et les formats encore trop
peu standardiss et normaliss.

Page 21 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

5.2.3.3 F3. Gestion des donnes descriptives


La finalit de cette fonction est dassurer la gestion des informations descriptives disponibles relatives
aux contenus dinformations conservs par la fonction Stockage. Rappelons que si lon se rfre la
DTD EAD tel que le prvoit le standard dchange, lensemble des donnes descriptives correspond
en fait aux informations de prennisation et aux informations de description au sens de lOAIS. De
faon globale la gestion des donnes descriptives doit ainsi permettre lenrichissement et/ou lajout de
mtadonnes destines dcrire les archives par rapport leur contexte, leur contenu et leur
structure.

F3. FONCTION GESTION DES DONNEES DESCRIPTIVES

F1. Versement Information de description

P1.Assurer P2.Mettre P3.Garantir


P4.Administrer F5. Administration
lien jour lintgrit
Information identification

Information identification

F2. Stockage

La fonction gestion des donnes descriptives est compose des quatre processus suivants :
- P1.Assurer lien : Ce processus consiste maintenir le lien entre les informations
descriptives et la localisation physique ou lectronique des contenus dinformations ;

- P2.Mettre jour : Le processus doit permettre la mise jour des donnes


correspondantes et au besoin en enregistrer de nouvelles suite un nouveau versement
ou suite une opration de migration ;

- P3.Garantir lintgrit : Ce processus revient garantir lintgrit de lensemble des


donnes gres et la vrifier rgulirement. Il est ainsi ncessaire de contrler
dventuelles erreurs laide de fonctionnalits appropries compltes par des systmes
davertissement et si possible de correction ;

- P4.Administrer : De faon spcifique par rapport la fonction dadministration densemble


du SAE, ce processus doit administrer les fonctions de la base de donnes le cas
chant, savoir conserver et tenir jour les schmas des tables utilises, les dfinitions
des vues et autres tats ainsi que garantir son intgrit rfrentielle.

Page 22 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

5.2.3.4 F4. Communication / Consultation des Archives


Cette fonction constitue lobjectif principal de tout SAE savoir offrir l'utilisateur la possibilit de
retrouver une information. Au-del de cette vrification dexistence cette fonction processus permet
galement lutilisateur de demander recevoir le ou les contenus dinformation, accompagns
dinformations complmentaires constituant au final un ou plusieurs paquets dinformations diffuss.

F4. FONCTION CONSULTATION /COMMUNICATION

P1.Vrifier
Communicabilit Droits daccs
accs

P2.Grer
F2. Stockage Requte Demandes Utilisateurs
demandes

P3.Excuter
PID Transmission requtes
requtes

PID
P4.Mettre
PID PID P5.Communiquer
en forme

PIA : Paquet dinformation archiv

Les cinq processus composant cette fonction sont dcrits ci-aprs :


- P1.Vrifier les accs : Ce processus revt un double objectif, tout dabord vrifier les
autorisations daccs des utilisateurs et dautre part vrifier la communicabilit des
paquets dinformations archivs ;

- P2.Grer demandes : Ce processus permet aux utilisateurs denregistrer des demandes


sous forme de commandes ou suivant un principe dabonnement. Il assure galement
linformation des utilisateurs quant lavancement du traitement de leurs commandes.
Pour effectuer ces demandes le processus devra mettre disposition des utilisateurs un
systme de consultation accessible en ligne sappuyant sur les donnes descriptives ;

- P3.Excuter requtes : Ce processus lance les requtes destines rechercher les


lments rclams par lutilisateur et assure le lien avec la fonction stockage afin dobtenir
les contenus dinformation dsirs. Ce processus devra galement contrler lintgrit de
linformation obtenue en retour avant de la transmettre lutilisateur ;

- P4.Mettre en forme : Ce processus consiste prparer les paquets dinformation diffuss,


rsultat de la recherche, avant leur communication ;

- P5.Communiquer : Comme son nom lindique, ce processus revient communiquer les


paquets dinformations diffuss aux utilisateurs. En fonction du type de demande, la
communication des rsultats de la recherche pourra tre obtenue soit directement en
ligne, soit tre transmise sur tout autre support ;

Page 23 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

Au-del de ces diffrents processus, lAdministration devra galement prciser ses demandes
spcifiques concernant :
- Le nombre de consultations envisages (minimum, maximum, moyenne) de faon globale
(10xxx interrogations par mois) et simultane (10xxx interrogations par seconde) en
fonction de la nature de larchive (intermdiaire ou dfinitive) et de son type (dossiers
comptables, individuels, contentieux, judiciaires) ;
- Le nombre a priori de communications prvoir en frquence, volumtrie et type
(tltransmission ou support physique) en fonction de la nature et du type darchive ;
- Les diffrents impratifs de temps d'accs aux archives en fonction de leur nature et de
leur type ;
Lensemble de ces spcifications pourra galement tre complt en introduisant un critre
dvolution des besoins en fonction de lge de larchive.

ce stade il est galement extrmement important de prendre en compte le facteur cot et de


lanticiper. En effet, mme si a priori certaines archives pouvaient tre consultes en ligne permettant
ainsi une communication immdiate, les investissements ncessaires tant au niveau du
dimensionnement des rseaux et de la scurit affrente que des systmes de stockage, pourront
finalement conduire retenir une solution moins performante et surtout beaucoup moins onreuse
mais tout aussi acceptable pour lutilisateur. Voir la partie infrastructure plus avant pour obtenir plus de
dtail.

Supports physiques
En ce qui concerne les supports physiques de communication des archives, il est ncessaire que
lAdministration prcise a priori les types de supports quelle souhaite proposer. Sont cits ici pour
mmoire :
- supports papier, pour lesquels on pourra au besoin prciser :
o Type(s) d'imprimante (matricielle, jet d'encre, laser, transfert thermique,
lectrostatique),
o Noir & blanc ou couleur,
o Format(s) des copies,
o Recto ou recto/verso,
o Rsolution(s) (en points/millimtre ou en points/pouce),
o Vitesse(s) d'impression en nombre de pages par minute,
o Production journalire souhaite (en page par jour).
- supports magntiques :
o Bande (format, densit, label, compression, ...),
o Cassette (format, densit, label, mode de compression, ...),
o Disque dur externe (format, capacit, connectivit),
o Cl USB.
- supports optiques :
o Non rinscriptible du type WORM (format, densit, label, ...) tels les CD-R, DVD-R,
o Rinscriptible (format, densit, label, ...), tels les CD-RW, DVD-RW,

Tltransmission
Pour ce qui est de la communication des archives par voie lectronique il convient den prciser les
modalits en fonction des besoins propres lAdministration. Il pourra sagir dune consultation :
- par un rseau local (type de rseaux, dbit, protocole, type de cblage physique) ;
- distance (type de rseaux, mode de transmission, protocole, dbit) ;
- lintrieur de rseaux existant de type intranet ou extranet ;
- en utilisant les capacits dinternet avec par exemple la mise en place de serveurs Web.

Page 24 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

5.2.3.5 F5. Administration du Systme darchivage lectronique


Lobjectif de cette fonction est dassurer lexploitation d'ensemble du SAE tant au niveau des
utilisateurs quen ce qui concerne son fonctionnement interne. De faon plus dtaille, sont fournis ci-
aprs les principaux processus prendre en considration, classs par thmes.

Exploitation
- Grer la configuration du matriel et des logiciels du SAE consistant en assurer la
matrise technique destine surveiller en permanence son fonctionnement global ;
- Contrler lexploitation du SAE, de son fonctionnement et de ses performances en
fonction de lutilisation qui en est faite en fournissant entre autres des statistiques
dtailles. Par ailleurs ds quune anomalie quelle quelle soit est dtecte une alerte doit
automatiquement tre gnre et transmise pour information et traitement ;

Remarque par rapport aux statistiques


En fonction de ses propres besoins lAdministration pourra galement dtailler ses demandes en
matire de statistiques selon les exemples suivants :
- Versement :
. Nombre et volume de paquets dinformations verss par nature darchive (intermdiaires,
dfinitives) et par type (dossiers comptables, individuels, contentieux, judiciaires) ;
. Nombre de transmissions effectues ;
. Nombre de traitements effectus (y compris les versements sur supports externe) ;
. Volumtrie des paquets dinformations verss sur une priode de temps donne pour
chaque Service producteur/versant.
- Consultation :
. Nombre de consultations, par heure, par jour, par mois, ...
. Nombre de commandes enregistres, par mois
. Nombre dimpressions par jour, par mois, ...
. Nombre de supports utiliss ;
. Nombre et volume de paquets dinformations diffuss, communiqus par tltransmission ou
sur supports physiques.
- Exploitation (utiles pour la gestion du stockage):
. Cartographie des espaces de stockage disponibles, pourcentage doccupation et
Accroissement, tat des supports ;
. Temps daccs moyen aux Archives ;
. Frquences daccs par plage horaire, par jour, par mois, par an ;
. Nombre dincidents classs par type et frquence ;
. Nombre et types de migrations effectues par mois

- Anticiper toute augmentation des capacits de stockage en fonction des statistiques


obtenues par la fonction stockage ;
- Planifier les migrations de supports et de format en dehors des migrations rendues
obligatoires suite des erreurs ;

Scurit
- Contrler laccs physique au SAE en fonction des rgles de scurit dfinies et des
dispositifs de scurit adopts en consquence ;
- Assurer la protection de lensemble des donnes gres par le SAE dont certaines sont
confidentielles : contenus dinformations, informations descriptives, donnes de gestion.
Ce processus devra assurer la sauvegarde globale de lensemble des informations ;
- Permettre la restauration totale ou partielle des donnes suite un sinistre ;
- Assurer la traabilit complte de tout ce qui se passe dans le SAE au travers de la
gestion dun journal dvnement y compris le suivi de rsolution des incidents rencontrs
quelle quen soit lorigine. Ce processus devra galement permettre lenregistrement des
tentatives daccs par des utilisateurs non autoriss ;

Gestion
- Permettre un suivi des commandes de communication en cours afin de pouvoir
renseigner les utilisateurs sur lavancement des traitements ;

Page 25 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

- Grer les donnes administratives comme celles relatives aux utilisateurs afin den
assurer le suivi et permettre le cas chant la production des lments de facturation
rsultants des commandes effectues ;
- Vrifier et garantir lintgrit de lensemble des donnes administratives directement lies
lexploitation vis--vis des utilisateurs mais aussi en interne ;

Conformit
- laborer et maintenir des standards et rgles applicables au SAE comme les normes ou
formats applicables, lensemble des procdures suivre pour les oprations de
Versement ou de migration pour le stockage afin dviter lobsolescence du SAE ;
- Grer les protocoles de versement avec les services versants en dfinissant les modalits
dchange et de transfert, un chancier de Versement des Paquets dinformations
verss, les besoins associs en matire de ressources ;

volutivit
- Veiller aux volutions des exigences des Utilisateurs cibles en matire par exemple de
formats de donnes, de type de supports, des progiciels ou plates-formes informatiques
cibles ;
- Assurer une veille tant technologique que du point de vue des volutions des
recommandations dans le domaine des normes et autres rgles et pratiques d'archivage ;
- Proposer dadapter les dispositifs existants en fonction des volutions technologiques ;
- Poursuivre le dveloppement de stratgies et de standards de prennisation afin
danticiper au mieux les changements venir concernant lvolution des exigences des
Utilisateurs et les changements technologiques ayant pour consquence de ncessiter
des migrations.

Remarque sur la transparence


Dune manire gnrale, les volutions de la plate-forme de stockage doivent tre sans consquence
sur lorganisation logique de larchivage. De mme lensemble des oprations dexploitation doit tre
transparent du point de vue de lutilisateur.

En complment ce qui prcde, lAdministration pourra prciser ses besoins en terme dutilitaire
dadministration du systme ainsi que ses besoins en terme de gestion des utilisateurs :
- Annuaires dutilisateurs type LDAP ou autre dj existant ou non ;
- Gestion des droits daccs et volutions. Quelle information, pour qui ;
- Type dauthentification requis (login - mot de passe, certificat)

Sans que la fonction suivante fasse proprement parl du systme darchivage lectronique mettre
en place, il est nanmoins important de la prvoir.

5.2.3.6 Reprise de l'existant


LAdministration prcisera sil est ncessaire deffectuer une reprise partielle o totale de ses
Archives.

Dans le cas effectif dune reprise, elle indiquera les volumes dArchives rcuprer sur le systme
darchivage dj en place ainsi que le dtail des caractristiques techniques de ces Archives, entre
autres formats, systme de description

LAdministration devra indiquer si elle souhaite raliser cette opration en interne avec ses propres
agents, en interne avec le personnel dune socit extrieure ou bien en recourant totalement la
sous-traitance. Dans ces deux dernires hypothses, lAdministration devra imposer le respect du
secret professionnel au personnel amen effectuer le travail.

Par rapport au dtail des fonctionnalits est prsent ci-aprs un exemple de demande plus prcise
que pourrait faire lAdministration au prestataire afin de satisfaire lensemble des processus
correspondants. Seront ainsi successivement abords les composants applicatifs puis larchitecture
gnrale.

Page 26 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

5.2.3.7 Composants applicatifs


Les composants applicatifs pourront reposer en matire de Livrables
- sur un ou plusieurs progiciels intgrs ;
- faire lobjet dun dveloppement spcifique complet ;
- un mixte entre des progiciels intgrs et des dveloppements spcifiques complmentaires.

Lensemble de la solution propose devra se composer des lments suivants :


- un annuaire utilisateur ;
- une base de donnes destine grer les donnes descriptives ;
- une interface rserve au service darchives ;
- une interface destine aux services versants, producteurs et autres utilisateurs pour la
consultation et les demandes de communications ;
- une application de gestion des versements ;
- une application de gestion des commandes ;
- une gestion du stockage ;
- une application de suivi de ladministration du SAE ;
- une base de connaissance destine entre autres pouvoir interprter les donnes de
reprsentation.

5.2.4 Proposition darchitecture gnrale


En matire darchitecture lon ne prcisera pas le dtail des technologies de stockage, laiss la libre
apprciation du prestataire. Par contre il est important de prciser quel type dorganisation peut tre
mise en place de faon prenniser lensemble des donnes gres par un SAE.

Le schma ci-dessous prsente ce que lon pourrait qualifier de synthse des systmes actuels. En ce
qui concerne la partie plus particulirement stockage, ont t volontairement dissocis les systmes
destins pour lun grer les donnes de gestion et les informations de descriptions, pour lautre celui
destin conserver les paquets dinformations archivs et plus prcisment les contenus
dinformations.

Services versant
Accs Accs
Utilisateurs

SITE 1 SITE 2

Serveur frontal Serveur


Serveur Web applicatif/stockage
Rseau scuris

Donnes de Paquets
Serveur applicatif gestion archivs

Rseau
Serveur stockage

Donnes de Paquets
gestion archivs
SITE 3

Page 27 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

Le tableau ci-dessous est destin montrer la correspondance entre les fonctionnalits dfinies
prcdemment pour le SAE et les aspects plus orients architecture. Lon retrouve ainsi en colonnes
les diffrentes fonctionnalits et en lignes les lments dinfrastructure. La prsence dune croix dans
une case indique que le matriel correspondant la ligne influence la ralisation de la fonction relative
la colonne. Le serveur applicatif a galement t ventil afin de donner plus de visibilit au prsent
tableau.

Gestion
Consultation
Versement Stockage donnes Administration
Communication
descriptives
Serveur frontal X X
Serveur WEB X
Serveurs applicatifs :
- versement X
- base de donnes X
- commandes X
- administration X
Serveur stockage X
Espace stockage
X X
donnes de gestion
Espace stockage
paquets
X X
dinformations
archivs

Remarques et limites concernant larchitecture propose

Nombre de sites
Concernant lutilit du troisime site, il est important de prciser quil est possible de sen passer mais
tout dpendra de la technologie de rplication mise en place entre les sites 1 et 2. En effet, par
exemple dans le cas o lon dtecterait une modification dintgrit ou toute autre erreur de donne
sur le site numro 1 pour un paquet dinformation archiv et si le dispositif de rplication est
compltement automatique et synchronis, il y a fort parier que la mme erreur se retrouve sur le
site numro 2. Le troisime site, dsynchronis des deux prcdents, permettra ainsi dans ce cas de
retrouver le bon paquet dinformation archiv en question afin de pouvoir corriger lanomalie dtecte.
Le type de rplication est ainsi trs important, voir ci-dessous, car une automatisation totale peut
conduire rpliquer des erreurs.

Par ailleurs il est clair que les trois sites prsents ci-dessus doivent tre gographiquement distincts,
au moins les sites 1 et 2. Les paquets dinformation archivs existeront ainsi sur trois supports
diffrents dans trois endroits diffrents. Ceci ne tient videmment pas compte des possibilits de
scurit offerte directement par les systmes de stockage eux-mmes comme par exemple la
technologie RAID qui duplique automatiquement les donnes. De ce fait et en supposant que lon
dispose dun tel systme sur les site 1 et 2, les paquets dinformations archivs seront disponibles en
cinq exemplaires (2 sur le site 1, 2 sur le site2, 1 sur le site 3).

La copie sur bande ou tout autre support pour le site numro 3 peut tre effectue indiffremment
partir du site numro 1 ou du site numro 2. Afin de gagner en efficacit et en capacit il faut prvoir
le recours un robot de gestion de bandes. Dans ce dernier cas une solution galement envisageable
consisterait connecter soit le site numro 1, soit le site numro 2 directement sur le site numro 3
via un rseau scuris, vitant du mme coup lensemble des manipulations de bandes ou autre
support.

Distinction des serveurs


Concernant la distinction faite au niveau des serveurs il est nanmoins possible en matire de
matriel de regrouper par exemple les fonctions applicatives et stockage au sein dune seule et mme
machine. Cependant la partie serveur frontal devra dans la majorit des cas rester indpendante. En
matire de stockage tout dpendra galement de la solution propose par le prestataire. Par exemple

Page 28 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

pour une solution fonctionnant comme un guichet darchivage, la partie stockage sera de faite
compltement isole.

Stockage en logique guichet


Le principe de base consiste envoyer au systme un fichier en lui demandant de le conserver. En
retour, le systme de stockage fournit lquivalent de ce que lon pourrait qualifier un ticket de
consigne correspondant de un code ou suite doctets. Pour rcuprer le fichier stock il suffira
ensuite dindiquer au systme de stockage ce mme code. A aucun moment et contrairement
dautres systmes de stockage il nest besoin de connatre lorganisation interne du systme qui de
faon classique est dcoup en volumes et rpertoires dont il faut se souvenir.

linverse dautres solutions intgrent de fait une partie applicative avec le systme de stockage,
auquel cas le dcoupage sera galement obtenu de facto.

Par rapport lensemble des variantes possibles, lAdministration pourra ainsi demander au
prestataire de prsenter et chiffrer les diffrentes solutions envisages sous forme doptions. Laspect
cot sera l encore un des points dterminants pour choisir telle ou telle solution. Attention galement
au fait que lAdministration devra bien prendre soin de considrer lensemble des cots savoir le
cot direct de la solution propose ainsi que les cots dexploitation associs tant en interne pour son
usage au quotidien quen matire de maintenance.

Interoprabilit
LAdministration devra galement porter une attention toute particulire concernant linteroprabilit
des systmes installer. Un changement de plate-forme de stockage doit en effet tre transparent
pour les utilisateurs et lorganisation logique des archives. De mme il doit tre possible de changer
une brique du systme sans devoir tout remettre en cause. La conception globale de ce dernier doit
ainsi prvoir linteroprabilit par une organisation si possible en couches logiques, quasiment
indpendantes les unes des autres, ce qui autorise leur changement sans perturber lensemble.
LAdministration aura galement soin dviter de retenir des solutions dites propritaires dont la
principale consquence est justement daller lencontre de cette interoprabilit.

La configuration telle que prsente prcdemment permet davoir un trs bon niveau de scurit en
matire de conservation. Par contre une telle configuration ne garantit pas la disponibilit parfaite du
service. En effet les utilisateurs ne peuvent accder quau site numro 1 et si lun des serveurs tombe
en panne, le service est interrompu pendant tout le temps de la rparation de ce dernier.

5.2.4.1 volutivit de la solution propose


Par rapport aux remarques prcdentes lon pourra galement voluer vers une meilleure
disponibilit du service par tapes successives prsentes ci-aprs :
- la mise disposition dun matriel quivalent en secours sur le site numro 1 qui pourrait
indiffremment servir remplacer lun des serveurs identifis dans le schma prcdent ;
- la mise en place dun systme totalement redondant sur le site numro 1, tant pour le
stockage quau niveau des accs assurant ainsi une continuit de service sauf incident au
niveau global du site ;
- la mise en place dun accs pour les utilisateurs sur le site numro 2 avec un systme de
basculement automatique dun site lautre. Il sera ds lors galement possible de rpartir la
charge des accs des utilisateurs sur les deux sites. Un dimensionnement fin devra tre opr
afin de tenir compte de ces trois lments que sont :
o le nombre daccs simultans au niveau des producteurs, services versants ;
o le nombre daccs simultans au niveau des utilisateurs ;
o les cots gnrs par louverture des accs sur le site numro 2.

5.2.4.2 Gestion de la duplication des informations


Par rapport ce qui prcde reste le problme de la gestion du deuxime site par rapport au premier
en matire de mise jour des informations et de rplication. Deux grands axes sont possibles pour
lesquels lAdministration devra marquer sa prfrence.

Page 29 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

Principe de la sauvegarde

Sauvegarde traditionnelle : Le premier site se sauvegarde sur le deuxime intervalles rguliers, par
exemple la journe, voire la demi-journe.
Avantages : Facile mettre en uvre partir des logiciels du march
Inconvnients :
- Perte potentielle dinformation en cas de problme, directement fonction de lintervalle retenu
entre deux sauvegardes ;
- Pas de vritable redondance dans la mesure o le deuxime site nest pas directement
oprationnel en cas de problme. Il faut en effet relancer le premier et recharger au besoin
linformation sauvegarde sur le deuxime.

Sauvegarde en continu selon le concept CDP (continuous data protection). Le principe consiste
effectuer des sauvegardes intervalle trs court et ne transmettre que le diffrentiel de donnes par
rapport la sauvegarde prcdente, sur le deuxime site afin de ne pas surcharger le rseau.
Avantages :
- Pas de perte dinformation entre les deux sites ;
- A priori relativement conomique ;
- Possibilit de restaurer une heure et un jour donns (et non en fonction dune version).
Inconvnients :
- Pas de vritable redondance dans la mesure o le deuxime site nest pas directement
oprationnel vis--vis de lextrieur mais sert uniquement aux sauvegardes.

Principe de synchronisation

Utilisation dun outil de synchronisation standard du march de serveur serveur.


Avantages :
- Meilleure scurit ;
- Parfaite redondance des sites.
Inconvnients :
- Choisir le bon outil ;
- A priori cot lev de la solution.

Dveloppement spcifique ou fonctionnalit dj disponible au niveau de lapplicatif du


prestataire. Deux solutions sont envisageables dtailles ci-aprs :

1. Une premire solution pour ce complment logiciel consiste effectuer une double mise
jour de lensemble des informations, une pour chaque site.
Avantage : notion de redondance vritablement synchronise.
Inconvnient : performances quant lcriture sur le site distant pouvant tre ralenties du fait
mme de lloignement, peut tre partiellement limin si le logiciel est conu de telle sorte ne pas
attendre le deuxime accus de rception dcriture sur le site 2 (peu recommand).

2. Une autre solution revient travailler selon la logique de messages posts. Afin de pallier
linconvnient relatif la performance de la solution prcdente lon pourra avoir recours une autre
logique qui consisterait enregistrer dans un journal sur le site numro 1 lensemble des oprations
effectues avec les donnes correspondantes. Un autre applicatif sur le deuxime site lirait
rgulirement le journal ainsi cr afin danalyser si des oprations sont ou non effectuer. Dans
laffirmative, le programme serait alors capable dinterprter les lments du journal afin de les traiter
sur le site numro 2, deffectuer les mises jour et dindiquer au site numro 1que ces lments ont
bien t pris en compte.
Avantages :
- Vritable synchronisation ;
- Le site 2 est matre de ses accs au site 1 et non linverse.
Inconvnients :
- Lger dcalage dans les mises jour, du fait mme de la logique propose ;
- Perte potentielle de donnes si non protges sur site 1 (cf attente possible sur site 1 avant
traitement site 2) ;
- Complexit et cot du dveloppement sil nest pas propos en standard.

Page 30 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

5.2.4.3 Rsum des configurations possibles et comparaison


En fonction de ce qui prcde lAdministration pourra par exemple retenir les diffrents critres
dvolutions suivants :
- Type de stockage, simple ou doubl. Il sagit en fait de lutilisation ou non de technologies de type
RAID ou autres, permettant davoir lquivalent dune rplication systmatique et locale de
linformation stocke. A titre dexemple lon pourra citer une des technologies les plus simples mais
pas la moins efficace, savoir la technique RAID1 correspondant la notion de miroir ;
- Accs vis--vis de lextrieur, simple ou doubl. L encore il ne sagit pas de trop entrer dans les
dtails techniques. Il suffira donc de simplement retenir que ceci revient quasiment doubler les
quipements correspondant aux accs ;
- Serveur applicatif de secours ou non ;
- Existence dun troisime site ou non;
- Type de rplication, sauvegarde ou synchronisation.

Page 31 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

Le tableau ci-dessous permet de mettre en vidence les diffrentes configurations possibles et leur volution en fonction de la disponibilit des accs au
service darchivage dun point de vue global. Il est clair que cette accessibilit devra tre relaye par lutilisation des systmes de stockage ad hoc permettant
entre autres un accs en ligne de gros volumes dinformation. Il faudra ainsi viter davoir des systmes de stockage off line sur bandes si lon dsire un
accs direct aux donnes.
Les informations indiques au niveau des risques constituent en fait le risque rsiduel existant en fonction de la configuration retenue.

Type rplication Type transmission


SITE 1 SITE 2 SITE 3 Risques rsiduels
Entre Sites 1 et 2 entre Sites1/2 et 3
- Possibilit de problme matriel sur site 1 et arrt du service ;
- Suite un problme sur site 1, possibilit dune perte de
donnes dont limportance est directement lie la frquence de
Accs simple Sauvegarde en Stockage
rplication ;
Stockage simple continu simple
- Possibilit de problmes particuliers mais rares conduisant la
modification dintgrit dune partie des donnes que le systme
ne pourra pas corriger dans son intgralit.
- Faible possibilit de problme matriel sur site 1 et arrt du
service ;
- Suite un problme sur site 1, faible possibilit de perte de
Stockage
Accs simple Sauvegarde en donnes dont limportance reste lie la frquence de
simple ou
Stockage doubl continu rplication ;
doubl
- Possibilit de problmes particuliers mais rares conduisant la
modification dintgrit dune partie des donnes que le systme
ne pourra pas corriger dans son intgralit.
Accs doubl - Trs faible possibilit de problme matriel sur site 1 conduisant
Manuelle
Stockage doubl Stockage larrt du service ;
frquence Armoire de
Serveur Synchronisation simple ou - Risque quasi inexistant de perte de donnes ;
rgulire, a priori la bandes
applicatif en doubl - Possibilit trs faible de modification dintgrit, de toute faon
journe
secours limite aux donnes entre deux rplications de bandes.
Robot de - Trs faible possibilit de problme matriel sur site 1 conduisant
Accs doubl Stockage bandes ou autre larrt du service ;
Stockage doubl Synchronisation simple ou Rseau support - Risque quasi inexistant de perte de donnes ;
doubl (Facilite - Possibilit trs faible de modification dintgrit, de toute faon
lexploitation) limite la frquence de rplication retenue, 1h 1/2journe.
Accs doubl - Risque darrt du service quasi inexistant ;
Stockage doubl Accs doubl Robot de - Risque quasi inexistant de perte de donnes ;
Serveur Synchronisation Stockage Rseau bandes ou autre - Possibilit trs faible de modification dintgrit, de toute faon
applicatif en doubl support limite la frquence de rplication retenue, 1h 1/2journe.
secours

Page 32 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

Afin dtre le plus exhaustif possible, lAdministration pourra galement complter le tableau
prcdent avec le critre concernant le contrle de lintgrit mis en place, savoir quil pourrait tre :
ponctuel, par sondages rguliers ou continus.

Enfin ce tableau pourra tre utilis au moment du dpouillement des appels doffre en y introduisant
les notions de cots. En effet au fur et mesure que lon descend dans les lignes afin daugmenter la
disponibilit des accs au service et de diminuer globalement le risque darrt, le montant des
investissements correspondant croit en consquence. Il sera ainsi sans doute trs utile pour
lAdministration de pouvoir choisir un niveau daccessibilit en toute connaissance de cause et en lien
avec le budget allou.

Page 33 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

6 Procdure

6.1 Forme de la rponse


Le cahier des charges devra contenir un descriptif de la forme tant matriel que logique que devront
avoir les rponses des candidats.

Il convient de prciser :
- Le nombre d'exemplaires souhaits ;
- Le format de documents admissibles ;
- S'il y a des imprims, documents spciaux, fiches ou des tableaux remplir.

Il est aussi ncessaire d'indiquer si des variantes sont admissibles.

D'une faon gnrale, un cahier des charges peut tre conu :


- Soit sans prcisions techniques spcifiques (par exemple sans demande particulire
concernant le choix de tels ou tels supports d'archivage) ;
- Soit avec une description technique dtaille.

Dans le premier cas, la forme de la rponse devra tre relativement ouverte, en particulier pour que le
prestataire puisse justifier ses choix.

Dans le second cas, la forme de la rponse sera gnralement plus ferme.

Enfin, dans tous les cas, il est indispensable de demander un calendrier prvisionnel de mise en place
du Systme (ce calendrier sera dtermin au vu du descriptif de la procdure tablie larticle 8 du
prsent cahier des charges), en prenant en compte les priodes o lAdministration devra participer
cette mise en place (analyse dtaille, tests demands).

6.2 Maquettage
En fonction de ses besoins, lAdministration pourra souhaiter disposer dun maquettage du SAE et
dans ce cas il y aura lieu de prciser quel niveau ce maquettages doit se trouver :
- Soit lors de la phase de slection du Prestataire ;
- Soit lors du processus de dveloppement de lapplication.

6.3 Dcoupage du projet


Les offres devront se positionner par rapport aux diffrentes phases dun projet telles que dfinies ci-
aprs. Les trois premires tapes sont rappeles ici titre indicatif dans la mesure o ltape 3 de
Conception gnrale doit justement permettre llaboration du prsent cahier des charges.

tape 1 tude d'opportunit


L'tude d'opportunit vise dfinir le cadre potentiel du projet, son intrt pour l'organisme :
analyse et hirarchisation des enjeux, analyse des freins et des leviers (organisation, technologie,
culture et motivation), identification et valuation des ressources internes et externes mettre en
uvre, estimation du retour sur investissement.

tape 2 tude de faisabilit


L'tude de faisabilit vise analyser la faisabilit conomique, organisationnelle et technique du
projet. On s'interrogera notamment sur la faisabilit du projet en termes de produits prouvs,
rendement, ressources, comptences, capacit, financement et risques induits.

tape 3 Conception gnrale


Lors de la conception gnrale, on s'attachera affiner l'expression de besoins fonctionnels sans
rechercher les solutions techniques. On prcisera galement l'ensemble des contraintes et les
diffrentes phases du projet permettant daboutir au prsent cahier des charges.

Page 34 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

tape 4 Conception dtaille


cette tape, la matrise d'uvre est choisie, le travail est donc ralis conjointement avec la matrise
d'ouvrage et matrise d'uvre dans l'objectif de dcrire finement l'engagement des deux parties en
terme de ralisation. Cette tape permet d'aboutir au livrable appel cahier des clauses techniques
particulires (CCTP).

tape 5 Ralisation
La phase de ralisation comprend la ralisation des composantes du systme d'information, c'est
dire le dveloppement, l'intgration, la qualification et la recette.
Les phases de dveloppement, intgration et qualification sont de la responsabilit du matre d'uvre,
sous contrle du matre d'ouvrage. En revanche, la recette qui est la vrification de la conformit du
projet par rapport la demande formule dans le dossier valid de conception gnrale, est du
ressort de la matrise d'ouvrage.

tape 6 Exploitation
Cette tape comprend l'homologation du systme d'information, son dploiement, sa mise en uvre
en situation oprationnelle, sa maintenance jusqu' sa fin de vie.

Ds lors que le prestataire aura t retenu en tant que matre duvre, le projet pourra tre lanc en
respectant les diffrentes tapes suivantes.

6.3.1. Lancement du projet


Dtail des actions mener
- Formalisation du primtre du projet
- Dfinition des modalits de fonctionnement
- laboration du planning
- Organisation et mise en place des quipes projets :
- constitution de lquipe projet du ct de lAdministration,
- constitution du comit de pilotage,
- fonctionnement du comit de pilotage.

Livrables Note de synthse du lancement


Plan dAssurance Qualit
Planning

6.3.2. Conception dtaille


Dtail des actions mener
- Prparer ltude et la dfinition prcise des interfaces et des fonctionnalits demandes,
- Prparer le cahier de recette.

Livrables Cahier des clauses techniques particulires (CCTP).


Dossier de spcifications dtailles
Cahier de recette
Planning dtaill des dveloppements
Procdures de scurit

6.3.3. Ralisation

6.3.3.1 Dveloppement
Mettre en uvre les spcifications dtailles rpondant au cahier des charges.

Dtail des actions mener

- Raliser les dveloppements


- Paramtrer le systme
- laborer le document de mise en exploitation.

Livrables Dossiers de scnario de tests


Dossier de mise en exploitation (MEX)
Cahier de recette

Page 35 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

6.3.3.2 Intgration
Intgrer la solution et sassurer que le service fourni rpond aux besoins fonctionnels exprims.

Dtail des actions mener


- Intgrer la solution
- Dfinition du mode opratoire de fonctionnement (signalement des anomalies et suivi des
corrections)
- Mettre en uvre les interfaces avec les autres services et solutions.

Livrables Version dfinitive du MEX et des sources

6.3.3.3 Qualification et recette


Appliquer les jeux de tests conformment au cahier de recette et vrifier la conformit de lensemble
des prestations au Plan dAssurance Qualit.

Dtail des actions mener


- Recette technique
- Recette fonctionnelle

Livrables Procs-verbal de recette

6.3.4 Exploitation

6.3.4.1 Mise en production


Dtail des actions mener
- Passage de la solution de lenvironnement dintgration vers lenvironnement de production
- Organisation et animations de sessions de formation (programme dfinir)

En matire de formation lAdministration pourra entre autres prciser :


- Le nombre de personnes former,
- Le type de formation en fonction des personnels,
- Le ou les lieux de formation (sur le ou les sites de lAdministration ou chez le Prestataire),
- Les contraintes d'organisation de cette formation (par exemple, la ncessit de la continuit
du service)

Livrables Manuel dutilisation de loutil


Manuel de formation
Planning de formation

6.3.4.2 Dploiement
Le cas chant lAdministration pourra prvoir un plan de dploiement du service, entre autres en
matire dextension des sessions de formation vis--vis par exemple des services producteurs, des
services versants et des utilisateurs.

6.3.4.3 Maintenance/Support
Cette tape doit permettre de dfinir les conditions dans lesquelles le service sera maintenu et suivi.
LAdministration aura soin de dcrire les garanties souhaites sur le matriel et le logiciel, ainsi que le
type de maintenance prvoir :
- Diffrents niveaux de support
- Dlais d'intervention (variables ou non suivant les sites gographiques, les types
d'quipement),
- Dlais d'indisponibilit,
- Modes d'intervention des techniciens du ou des Prestataires,
- Habilitation et certification des personnels,
- Modes de contrle des interventions,
- Calcul des pnalits de retard,
- Les possibilits de tl-maintenance

Page 36 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

7 Dispositions juridiques
Le Prestataire retenu sengagera respecter certaines clauses qui seront reprises dans le contrat.
Mais les engagements les plus importants doivent tre ports la connaissance du Prestataire ds la
remise du cahier des charges.

ce titre, les clauses suivantes ne pourront pas faire lobjet de modifications. La rponse lappel
candidature entrane lacceptation des prsentes clauses.

7.1 Fiabilit du systme


Le Prestataire devra excuter ses obligations au titre des prestations dtailles dans le prsent cahier
des charges dans le cadre dun engagement de rsultat pour les critres quantifiables figurant dans la
convention de service notamment au rang desquels figureront la disponibilit du serveur, la hot line

tant donn lobjet de la prestation, savoir un archivage lectronique scuris, le Prestataire devra
sengager sur la fiabilit du Systme darchivage mis en place. Les procdures de sauvegarde, de
redondance, de scurit du systme doivent tre optimales pour assurer la conservation, lintgrit et
la prennit de la plate-forme darchivage.

7.2 Proprit intellectuelle


Ces clauses sont donnes titre indicatif. Chaque administration se reportera si elle le souhaite, aux
clauses types tablies dans cette finalit dans les cahiers des charges des personnes publiques.

7.2.1. Dispositions gnrales


Ladministration met la disposition du Prestataire, sur demande de ce dernier, les renseignements et
informations ncessaires l'excution des prestations en sa possession et dont il a la libre jouissance,
tant entendu que la personne publique en reste propritaire et que cette mise disposition ne peut
en aucun cas et d'aucune manire tre considre comme confrant au Prestataire un quelconque
droit d'usage (autre que le droit dutiliser lesdits renseignements et informations pour les seuls besoins
de lexcution des prestations) ou une quelconque licence sur les droits de proprit intellectuelle ou
industrielle affrents aux dits renseignements et informations.

Le Prestataire et la personne publique conservent la proprit exclusive des brevets, des logiciels,
des dessins et modles, du savoir-faire et des informations leur appartenant, dvelopps ou acquis
antrieurement l'entre en vigueur du contrat les liant ou en dehors du cadre de celui-ci.

Le Prestataire mettant disposition de ladministration, des programmes ou donnes dont les droits
ont t rservs par des tiers garantit quil a obtenu les autorisations ncessaires cet effet et informe
ladministration des restrictions ventuelles lusage de ces programmes et donnes.

Pour ce qui est des lments composants le Systme darchivage que le Prestataire met en uvre
dans le cadre des prestations, le Prestataire dclare disposer de tous les droits ncessaires
lexcution conforme de ses obligations contractuelles.

Suivant loption retenue par ladministration, eu gard aux offres de chaque candidat, le Prestataire :
- cdera lensemble des droits de proprit intellectuelle relatifs au systme dinformation mis
en uvre pour laccomplissement des prestations ;
- ou concdera une licence dutilisation pour le systme dinformation mis en uvre par le
Prestataire titre exclusif pendant toute la dure du contrat liant le Prestataire
ladministration.
En tout cas, le Prestataire sengage dposer auprs de ladministration les programmes et codes
sources ncessaires aux prestations fournies qui pourra les utiliser en cas de dfaillance du
Prestataire ou de fin de contrat et ce quelle quen soit la cause.

En cas dexpiration du contrat liant le Prestataire ladministration, quelle quen soit la cause, le
Prestataire sengage assister la personne publique, vis vis des diteurs des progiciels utiliss par
le Prestataire pour lexcution des prestations, pour obtenir au profit de ladministration une licence
dutilisation desdits progiciels pour la dure de protection des droits de proprit intellectuelle de ceux-

Page 37 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

ci, telle que reconnue par les lois prsentes ou venir, les conventions internationales et pour le
territoire de la Rpublique franaise.

7.2.2. Documents et dveloppements spcifiques


Tous les documents raliss ainsi que les rsultats (dcouvertes, amliorations, mises au point,
crations logicielles, inventions brevetables ou non, mises jour... ) obtenus dans le cadre des
prestations effectues pour les besoins de ladministration par le Prestataire, qu'ils soient sous forme
crite ou sous toute autre forme lisible par l'homme ou par la machine, et les dveloppements
spcifiques raliss dans le cadre des prestations pour ladministration par le Prestataire et/ou ses
sous-traitants, en vue de rpondre des fonctionnalits demandes pour la personne publique sont et
restent la proprit exclusive de ladministration au fur et mesure de leur ralisation (tous ces
lments sont ci-aprs dnomms les Travaux ).

Concernant ces Travaux, le Prestataire cde donc dfinitivement ladministration, conformment aux
dispositions du Code de la Proprit Intellectuelle, avec l'ensemble des garanties de droit et de fait,
l'intgralit des droits d'exploitation dfinis ci-aprs :
- le droit de reproduire ou faire reproduire en tout sur tout support connu ou inconnu ce jour,
- le droit dadapter ou de faire adapter tout ou partie de ces Travaux, le droit de corriger, de
faire voluer, de maintenir, de dcompiler, de modifier, dassembler, de transcrire, darranger,
de traduire ces Travaux ;
- le droit de diffuser ou faire diffuser tout ou partie de ces Travaux de quelque manire que ce
soit, par tous procds quels quils soient, connus ou inconnus ce jour, et notamment par
tous rseaux de tlcommunication, actuels ou futurs, tels que lInternet, lIntranet, le Minitel,
par tous moyens de tldiffusion ainsi que la radiodiffusion par tous moyens de
tlcommunication ;
- le droit de commercialiser, y compris la location et le prt titre gratuit ou onreux ;
- le droit de faire tout usage et toute exploitation, titre personnel ou au bnfice de tiers, titre
onreux ou gratuit, de ces dveloppements spcifiques et de la documentation associe.

La cession du droit dexploitation de ces Travaux est consentie titre exclusif ladministration pour la
dure de protection des droits de proprit intellectuelle telle que reconnue par les lois prsentes ou
venir, les conventions internationales et dans le monde entier sans restriction.

Compte tenu de ce qui prcde, le Prestataire est tenu de ne pas diffuser, sous quelque forme que ce
soit, reproduire, traduire, adapter, commercialiser ou utiliser autrement les Travaux, sauf pour
lexcution des prestations accomplies pour ladministration.

7.2.3. Garantie de jouissance paisible


Le Prestataire garantit ladministration contre toute action, revendication ou opposition intente par
des tiers au motif notamment que les Travaux et/ou les prestations ralises par le Prestataire
constituent une contrefaon de droits prexistants de proprit intellectuelle revendiqus par des tiers,
ou un acte de concurrence dloyale et/ou parasitaire auquel lexcution des prestations aurait port
atteinte, ladministration ne pouvant tre recherche ou inquite ce sujet.

En consquence, le Prestataire prendra sa charge tous dommages et intrts auxquels


ladministration serait condamne en raison d'un acte de contrefaon ou de concurrence dloyale ou
plus gnralement en raison de latteinte aux droits dun tiers rsultant de la prestation du Prestataire.

En cas de rclamation, le Prestataire doit ses frais et au choix de ladministration et dans des dlais
compatibles avec l'obligation de ladministration d'assurer la continuit de fourniture de son service :
- soit modifier tout ou partie de l'lment litigieux afin d'viter la contrefaon ;
- soit obtenir lautorisation de continuer utiliser les lments litigieux ;
- soit fournir une solution de remplacement condition qu'un tel remplacement ou qu'une telle
modification n'affecte pas le fonctionnement du systme dinformation mis en uvre.

Il est entendu que le Prestataire prend en charge tout frais, cot ou indemnit ncessaire pour
permettre ladministration de continuer utiliser llment litigieux jusqu la mise en uvre de la
solution choisie conformment aux dispositions prcites.

Page 38 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

7.3 Donnes caractre personnel

7.3.1. Formalits pralables


Le Prestataire devra effectuer les formalits lgislatives et rglementaires adaptes au traitement de
donnes caractre personnel en cause, auprs de la CNIL, dans le cadre des prestations quil devra
assurer.

7.3.2. Scurit des donnes caractre personnel


Le Prestataire doit mettre en uvre les mesures techniques et dorganisation appropries pour
protger les donnes archives contre toute destruction accidentelle ou illicite, toute perte
accidentelle, altration, diffusion ou accs non autoriss, ainsi que contre toute forme de traitement
illicite, et ce, notamment lorsque le traitement comporte des transmissions de donnes.

Le niveau de scurit mis en uvre doit tre doit tre adapt au regard des risques prsents par le
traitement et la nature des donnes protger.

Le Prestataire doit apporter ladministration les garanties suffisantes au regard des mesures de
scurit technique et dorganisation relatives aux traitements effectuer et doit veiller constamment
au respect de ces mesures.

Sagissant de la scurit des autres types de donnes, ladministration devra se rfrer la Politique
de scurit ainsi qu la Politique darchivage.

7.4 Interoprabilit
titre pralable, il convient de noter que linteroprabilit dsigne une solution non propritaire
ouverte et compatible avec les autres solutions non propritaires et standard .

Le Prestataire sengage ce que les technologies utilises dans le cadre du Systme darchivage
lectronique soient interoprables avec les technologies en principe utilises par ltat de lart. Plus
spcialement, le Prestataire sengage respecter le Rfrentiel gnral dinteroprabilit tel que dfini
par lAgence pour le dveloppement de ladministration lectronique (ADAE) et la Direction centrale
de la scurit des systmes dinformation (DCSSI).

7.5 Rversibilit
Le processus de rversibilit a pour but de faire basculer les traitements raliss par le Prestataire sur
le Systme darchivage vers ladministration ou tout tiers dsign par elle.
Cette clause trouvera sappliquer lorsquil sera ncessaire deffectuer un transfert dun service vers
un autre.

Le primtre de la rversibilit porte sur les lments suivants :


- dveloppements informatiques spcifiques raliss pendant lexcution des prestations,
- bases de donnes,
- les Archives, Paquets dinformations, Objets darchives,
- autres ( dterminer suivant loffre retenue).

Le Prestataire garantit quil continuera durant la phase de rversibilit fournir les prestations
contractuelles, dans des conditions identiques. Le Prestataire garantit quil assistera ladministration
ou tout tiers dsign par elle avec toute la diligence ncessaire pour ce type dobligation afin de
mener bien la rversibilit.

Le Prestataire sengage :
a) informer systmatiquement ladministration de toute modification pouvant avoir une
incidence sur le primtre de la rversibilit,
b) fournir ladministration, dans les cinq (5) jours ouvrs suivant chaque demande, une copie
de la dernire situation affrente la solution, quant aux informations et donnes sous une
forme informatiquement exploitable.

Page 39 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

c) restituer ladministration, dans un dlai maximal de trois (3) mois, avant la date de
terminaison du Contrat lorsque la date de la terminaison est connue ou au jour de la
terminaison lorsque celle-ci est inopine, lintgralit des informations, donnes, exploites par
le Prestataire pour lexcution des prestations et n'en conserver aucune copie. ce titre, le
Prestataire renonce tout droit de rtention sur un quelconque lment appartenant
ladministration, y compris les ventuels droits sur des logiciels ou dveloppements spcifiques,
et mis la disposition du Prestataire au titre des prestations. Le Prestataire tiendra jour les
dossiers techniques et d'exploitation relatifs au primtre de rversibilit et les fournira
ladministration.

l'issue du Contrat et pendant les douze (12) mois qui suivront, le Prestataire s'engage rpondre
toute demande d'assistance manant de ladministration portant sur l'exploitation de la solution.

7.6 Continuit de service


Le Prestataire sengage assurer la parfaite, totale et complte continuit des services objet des
prsentes prestations.
Le Prestataire sengage fournir un plan dtaill des mesures mises en place pour assurer la
continuit dactivit.

7.7 Assurance
Le Prestataire atteste avoir souscrit une assurance Responsabilit civile professionnelle concernant
lensemble des activits relatives au prsent cahier des charges.

Il sengage assurer et maintenir en vigueur son contrat dassurance auprs dune compagnie
dassurance notoirement solvable et tablie, en France, pour toutes les consquences pcuniaires de
sa responsabilit civile professionnelle vis--vis de dommages corporels, matriels et immatriels
conscutifs ou non causs au Prestataire et tout tiers dans le cadre de lexcution des prestations.

7.8 Force majeure


Le Prestataire et ladministration ne sauraient tre tenus responsables pour tout retard dans
lexcution de leurs obligations ou pour toute inexcution de leurs obligations rsultant de lexcution
des prestations lorsque les circonstances y donnant lieu relvent de la force majeure au sens de
larticle 1148 du Code civil.

Dans un premier temps, les cas de force majeure suspendront lexcution des prestations. Si les cas
de force majeure ont une dure suprieure trente (30) jours, le contrat est rsili et la clause de
rversibilit produit ses effets.

Page 40 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

8 ANNEXE Liste des textes et documents de rfrence

8.1 Conservation des documents lectroniques dans la sphre


publique
Outre le Code du patrimoine et le Code gnral des collectivits territoriales et notamment leurs
parties rglementaires, il convient de se reporter aux textes suivants :

- Loi n 78-753 du 17 juillet 1978 portant diverses mesures damlioration des relations
entre ladministration et le public et diverses dispositions dordre administratif, social et
fiscal (J.O. du 18 juillet 1978, p. 2851 et s.) modifie.

- Loi n 79-18 du 3 janvier 1979 sur les archives (J.O. du 5 janvier 1979, p. 43 et s.).

- Loi n 94-126 du 11 fvrier 1994 relative linitiative et lentreprise individuelle dite


loi Madelin (J.O. du 13 fvrier 1994, p. 2493).

- Loi n 2000-321 du 12 avril 2000 relative aux droits des citoyens dans leurs relations
avec les administrations (J.O. du 13 avril 2000, p. 5646 et s.).

- Loi n 2001-1246 du 21 dcembre 2001 de financement de la scurit sociale pour


2002 (J.O. du 26 dcembre 2001, p. 20552).

- Loi n 2002-276 du 27 fvrier 2002 relative la dmocratie de proximit (J.O. du 28


fvrier 2002, p. 3808 et s.).

- Loi n 2003-591 du 2 juillet 2003 habilitant le Gouvernement simplifier le droit (J.O. du


3 juillet 2003, p. 11192 et s.).

- Loi n 2004-809 du 13 aot 2004 relative aux liberts et responsabilits locales (J.O. du
17 aot 2004, p. 14545).

- Loi n 2004-1343 du 9 dcembre 2004 de simplification du droit (J.O. du 10 dcembre


2004, p. 20857).

- Ordonnance n 2004-164 du 20 fvrier 2004 relative aux modalits et effets de la


publication des lois et de certains actes administratifs (J.O. du 21 fvrier 2004, p. 3514)..

- Ordonnance n 2004-178 du 20 fvrier 2004 relative la partie lgislative du code du


patrimoine (J.O. du 24 fvrier 2004, p. 37048 et s.).

- Ordonnance n 2005-650 du 6 juin 2005 relative la libert daccs aux documents


administratifs et la rutilisation des informations publiques (J.O. du 7 juin 2005, p.
10022 et s.).

- Ordonnance n 2005-1516 du 8 dcembre 2005 relative aux changes lectroniques


entre usagers et autorits administratives et entre autorits administratives (J.O. du 9
dcembre 2005).

- Dcret n 79-1037 du 3 dcembre 1979 relatif la comptence des services darchives


publics et la coopration entre les administrations pour la collecte, la conservation et la
communication des archives publiques (J.O.R.F. du 5 dcembre 1979).

- Dcret n 79-1038 du 3 janvier 1979 relatif la communicabilit des documents


darchives publiques (J.O. du 5 dcembre 1979, p. 3058).

- Dcret n 79-1040 du 3 dcembre 1979 relatif la sauvegarde des archives prives


prsentant du point de vue de lHistoire un intrt public (J.O. du 5 dcembre 1979,
p. 3059).

Page 41 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

- Dcret n 99-68 du 2 septembre 1999 relatif la mise en ligne des formulaires


administratifs (J.O. du 4 septembre 1999, p. 1775).

- Dcret n 2000-318 du 7 avril 2000 relatif la partie Rglementaire du code gnral des
collectivits territoriales (J.O. du 9 avril 2000, p. 5769 et s.). Ce dcret codifie dans la
partie rglementaire du code gnral des collectivits territoriales les dispositions
issues du dcret n 88-849 du 28 juillet 1988, les article R. 317.1 R. 317-4 du code
des communes et les articles 6, 7 et 8 du dcret n 79-1037 du 3 dcembre 1979 et
abroge ces derniers.

- Dcret n 2001-492 du 6 juin 2001 pris pour lapplication du chapitre II du titre II de la loi
n 2000-321 du 12 avril 2000 et relatif laccus de rception des demandes prsentes
aux autorits administratives (J.O. du 10 juin 2001, p. 9246 et s.).

- Dcret n 2001-493 du 6 juin 2001 pris pour lapplication de larticle 4 de la loi n 78-753
du 17 juillet 1978 et relatif aux modalits de communication des documents administratifs
(J.O. du 10 juin 2001, p. 9246 et s.).

- Dcret n 2001-846 du 18 septembre 2001 pris en application du 3 de larticle 56 du


code des marchs publics et relatifs aux enchres lectroniques (J.O. du 19 septembre
2001, p. 14847 et s.).

- Dcret n 2002-535 du 18 avril 2002 relatif lvaluation et la certification de la


scurit offerte par les produits et les systmes des technologies de linformation (J.O. du
19 avril 2002, p. 6944).

- Dcret n 2002-692 du 30 avril 2002 pris en application du 1 et du 2 de larticle 56 du


code des marchs publics et relatifs la dmatrialisation des procdures de passation
des marchs publics (J.O. du 3 mai 2002, p. 8064).

- Code des marchs publics issu du dcret n 2004-15 du 7 janvier 2004 (J.O. du 8
janvier 2004, p. 37003).

- Dcret n 2004-617 du 29 juin 2004 relatif aux modalits et effets de la publication sous
forme lectronique de certains actes administratifs au Journal officiel de la Rpublique
franaise (J.O. du 30 juin 2004).

- Dcret n 2004-114 du 26 octobre 2004 relatif lexcution des marchs publics par
carte dachat (J.O. du 29 octobre 2004, p. 18259 et s.).

- Dcret n 2004-1298 du 26 novembre 2004 relatif diverses dispositions concernant


les marchs de ltat et des collectivits territoriales (J.O. du 30 novembre 2004, p.
20310 et s.).

- Dcret n 2004-459 du 28 mai 2004 fixant les catgories dactes individuels ne pouvant
faire lobjet dune publication sous forme lectronique au Journal Officiel de la Rpublique
franaise (J.O. du 29 mai 2004, p. 9583).

- Dcret n 2005-324 du 7 avril 2005 relatif la transmission par voie lectronique des
actes des collectivits territoriales soumis au contrle de lgalit et modifiant la partie
rglementaire du code gnral des collectivits territoriales (J.O. du 8 avril 2005, p.
6340).

- Dcret n 2005-222 du 10 mars 2005 relatif lexprimentation de lintroduction et de la


communication des requtes et mmoires et de la notification des dcisions par voie
lectronique (J.O. du 11 mars 2005, p. 4212 et s.).

- Dcret n2005-972 du 10 aot 2005 modifiant le dcret n56-222 du 29 fvrier 1956 pris
pour lapplication de lordonnance du 2 novembre 1945 relative au statut des huissiers de
justice, (J.O. du 11 aot 2005, p. 13095) et dcret n2005-973 du 10 aot 2005
modifiant le dcret n71-941 du 26 novembre 1971 relatif aux actes tablis par les
notaires, (J.O. du 11 aot 2005, p. 13096).

Page 42 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

- Arrt du 18 avril 2005 relatif aux conditions de protection du secret et des informations
concernant la dfense nationale et la sret de ltat dans les contrats (J.O. du 20 avril
2005, p. 6914).

- Arrt du 26 octobre 2005 portant approbation dun cahier des charges des dispositifs
de tltransmission des actes soumis au contrle de lgalit et fixant une procdure
dhomologation de ces dispositifs (J.O. du 3 novembre 2005, p. 17289).

- Circulaire du 2 novembre 2001 relative la gestion des archives dans les services
et tablissements publics de ltat (PRMX0105139C).

- Circulaires du 21 janvier 2002 dfinissant le cadre dinteroprabilit des systmes


dinformation publics communs aux administrations de ltat.

- Circulaire du 4 dcembre 2002 du Premier ministre, prcisant les conditions de la mise


en uvre du cadre commun dinteroprabilit dfinit par le circulaire du 21 janvier 2002
(version 2)

- Circulaire du 7 janvier 2004 portant manuel dapplication du code des marchs publics
(J.O. du 8 janvier 2004, p. 37031 et s.) modifie par la circulaire du 16 dcembre 2004
(J.O. du 1er janvier 2004, p. 12813 et s.).

- Note dinformation du 18 octobre 2004 rdige par F. BANAT-BERGER, intitule


Rsum du rapport de J.-F. BLANCHETTE sur "la conservation de la signature
lectronique : Perspectives archivistiques, septembre 2004" (DITN/RES/2004/04).

- Instruction du 14 janvier 2005 relative aux modalits de dlivrance du visa dlimination


des documents papier transfrs sur support numrique ou micrographique
(DITN/DPACI/RES/2005/001).

- Instruction du 3 mars 2005 relative aux actions entreprises par la direction des archives
de France en matire darchivage lectronique dans le cadre du dveloppement de
ladministration lectronique (DITN/RES/2005/002).

- Recommandations du 29 mars 2005 relatives la gravure, la conservation et


lvaluation des CD-R (DITN/RES/2005/004) Rfrentiel gnral dinteroprabilit vis
par le projet dordonnance pris en application de larticle 3 de la loi n 2004-1343 du 9
dcembre 2004 de simplification du droit (J.O. du 10 dcembre 2004, p. 20857).

8.2 Donnes caractre personnel


Ces textes sont mentionns dans la mesure o les rgles de conservation des donnes caractre
personnel sont spcifiques. Elles doivent tre prises en compte dans le cadre de larchivage
lectronique le cas chant.

- Loi n 78-17 du 6 janvier 1978 relative linformatique, aux fichiers et aux liberts (J.O.
du 7 janvier 1978, p. 7 et s.).

- Loi n 2004-801 du 6 aot 2004 relative la protection des personnes physiques


lgard des traitements de donnes caractre personnel et modifiant la loi n 78-17 du 6
janvier 1978 relative linformatique, aux fichiers et aux liberts (J.O. du 7 aot 2004, p.
14063 et s.).

- Loi n 2004-810 du 13 aot 2004 relative lassurance maladie (J.O. du 17 aot


2004, p 14598 et s.). Cette loi a introduit un article L. 161-36-1 A du code de la scurit
sociale qui dispose dans son I alina 4 : Afin de garantir la confidentialit des
informations mdicales mentionnes aux alinas prcdents, leur conservation sur
support informatique comme leur transmission par voie lectronique entre professionnels,
sont soumises des rgles dfinies par dcret en Conseil dtat pris aprs avis public et
motiv de la Commission Nationale de lInformatique et des Liberts. .

Page 43 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

- Dcret n 2005-1309 du 20 octobre 2005 pris pour lapplication de la loi n 78-17 du 6


janvier 1978 relative linformatique, aux fichiers et aux liberts, modifie par la loi n
2004-80 du 6 aot 2004 (J.O. du 22 octobre 2005).

8.3 Autres documents


titre principal :

- Le guide Conservation des informations et des documents numriques pour les


tlprocdures, les intranets et les sites internet : format, support, mtadonnes,
organisation, XML et normalisation de lAgence pour les Technologies de
lInformation et de la Communication dans lAdministration (ATICA) repris par lAgence
pour le Dveloppement de lAdministration lectronique (ADAE).

- Politique de Rfrencement Intersectoriel de Scurit (PRIS) - V1 - relative la mise


en place dun rfrentiel documentaire identifiant des niveaux croissants de scurit
sappliquant diffrents services de confiance et disponible sur le site www.adae.gouv.fr.

- Politique de Rfrencement Intersectoriel de Scurit (PRIS) V2, en matire


darchivage, la PC Type Authentification.

- Le cadre commun dinteroprabilit des systmes dinformation publics


(version 2), publi par lADAE en fvrier 2003, disponible ladresse : www.adae.gouv.fr.

- Standard dchange de donnes pour larchivage lectronique versement


communication - limination, tabli par lADAE et la Direction des Archives de France.
Le standard dchange fait actuellement lobjet dun appel commentaires et sera, en
principe, stabilis au cours du premier trimestre 2006. Ce standard dont lobjectif vise
permettre une interoprabilit entre les systmes dinformation entre services
producteurs, services darchives et tierces entits, porte sur la normalisation des
schmas de donnes intervenant dans le versement et la communication de documents
lectroniques. Il a vocation tre intgr au rfrentiel gnral dinteroprabilit prvu
par lordonnance n 2005-1516 du 8 dcembre 2005 relative aux changes lectroniques
entre les usagers et les autorits administratives et entre les autorits administratives
(J.O. du 9 dcembre 2005, p. 18986).

- Les archives lectroniques, Manuel pratique publi par la Direction des archives de
France, Catherine Dhrent, 2002, disponible sur commande ladresse suivante :
http://larecherche.servicepublic.fr/df/oxide?criteriaContent=dherent&page=resultsdfB&acti
on=launchsearch&DynRubrique=Catalogue&DynCorpus=&DynDomain=Catalogue

- Manuel Archivage des documents bureautique , ralis par J. Poivre et la Direction


des Archives de France, 2004, paru la Documentation franaise, commander
ladresse : www.ladocumentationfranaise.fr.

- Guide pour l'laboration d'une politique de scurit de systme d'information


(PSSI), DCSSI, mars 2004, disponible sur le site de la DCSSI http://www.ssi.gouv.fr.

Page 44 sur 46
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

Formulaire de recueil de commentaires

Ce formulaire peut tre envoy l'adresse suivante :

Secrtariat gnral de la dfense nationale


Direction centrale de la scurit des systmes d'information
Sous-direction des oprations
Bureau conseil
51 boulevard de La Tour-Maubourg
75700 PARIS 07 SP
conseil.dcssi@sgdn.pm.gouv.fr

Identification de la contribution
Nom et organisme (facultatif) : ..................................................................................................................
Adresse lectronique : ...............................................................................................................................
Date : .........................................................................................................................................................

Remarques gnrales sur le document


Le document rpond-il vos besoins ? Oui  Non 

Si oui :

Pensez-vous qu'il puisse tre amlior dans son fond ? Oui  Non 

Si oui :

Qu'auriez-vous souhait y trouver d'autre ?


.................................................................................................................
.................................................................................................................

Quelles parties du document vous paraissent-elles inutiles ou mal


adaptes ?
.................................................................................................................
.................................................................................................................

Pensez-vous qu'il puisse tre amlior dans sa forme ? Oui  Non 

Si oui :

Dans quel domaine peut-on l'amliorer ?


- lisibilit, comprhension 
- prsentation 
- autre 

Prcisez vos souhaits quant la forme :


.................................................................................................................
.................................................................................................................

Si non :

Prcisez le domaine pour lequel il ne vous convient pas et dfinissez ce qui vous
aurait convenu :
..........................................................................................................................................
..........................................................................................................................................

Quels autres sujets souhaiteriez-vous voir traiter ?


..........................................................................................................................................
..........................................................................................................................................
SGDN / DCSSI / SDO / BCS Archivage scuris Cahier des charges 10 fvrier 2006

Remarques particulires sur le document


Des commentaires dtaills peuvent tre formuls l'aide du tableau suivant.
"N" indique un numro d'ordre.
"Type" est compos de deux lettres :
La premire lettre prcise la catgorie de remarque :
- O Faute d'orthographe ou de grammaire
- E Manque d'explications ou de clarification d'un point existant
- I Texte incomplet ou manquant
- R Erreur
La seconde lettre prcise son caractre :
- m mineur
- M Majeur
"Rfrence" indique la localisation prcise dans le texte (numro de paragraphe, ligne).
"nonc de la remarque" permet de formaliser le commentaire.
"Solution propose" permet de soumettre le moyen de rsoudre le problme nonc.

N Type Rfrence nonc de la remarque Solution propose


1

Merci de votre contribution

Anda mungkin juga menyukai