Vous êtes sur la page 1sur 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 2 3 4 DOMAINE D'APPLICATION .................................................................................................................. 6 TEXTES LGISLATIFS, RGLEMENTAIRES ET DOCUMENTS DE RFRENCE................... 6 DFINITIONS............................................................................................................................................. 6 OBJECTIFS, CONTEXTE ET PRIMTRE DU CAHIER DES CHARGES .................................... 9 4.1 4.2 4.3 4.4 4.5 5 OBJECTIFS DU CAHIER DES CHARGES .................................................................................................... 9 DESCRIPTION DE LA PERSONNE PUBLIQUE ............................................................................................ 9 DESCRIPTION DE LA SITUATION PRSENTE ............................................................................................ 9 LES OBJECTIFS DU SYSTME DARCHIVAGE LECTRONIQUE ............................................................... 10 PRIMTRE ......................................................................................................................................... 10

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

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

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 8.2 8.3 CONSERVATION DES DOCUMENTS LECTRONIQUES DANS LA SPHRE PUBLIQUE ................................ 41 DONNES CARACTRE PERSONNEL .................................................................................................. 43 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. 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

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 Services versants

Utilisateurs

Systme Archivage Electronique


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

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 E R V I C E V E R S A N T
Information de description

F3. Gestion des donnes descriptives


Rponses Demandes

PIV

F1. Versement

Interrogations

F4. Consultation Communication


PID

F5. Administration

PIA Requtes

PID

U T I L I S A T E U R S

F2. Stockage

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

PIV

P3.Contrler conformit
PIV

AR Information Identification

F2. Stockage P6.Convertir


PIV

Service versant

PIV

P1.Recevoir versement
AR

P4.Journaliser

P7.Gnrer PIA

PIA

P8.Coordonner Mises jour

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 PID

F1. Versement

PIA

P1.Recevoir

PIA

P2.Mode de stockage
PIA

P4.Garantir lintgrit

P6.Prparer PID

F4. Consultation Communication

AR Information Identification

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 magntooptique, 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 lien
Information identification Information identification

P2.Mettre jour

P3.Garantir lintgrit

P4.Administrer

F5. Administration

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

Communicabilit

P1.Vrifier accs

Droits daccs

F2. Stockage

Requte

P2.Grer demandes

Demandes

Utilisateurs

PID

P3.Excuter requtes

Transmission requtes

PID PID

P4.Mettre en forme

PID

P5.Communiquer

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

Accs

Services versant Utilisateurs

Accs

SITE 1
Serveur frontal Serveur Web Rseau scuris Serveur applicatif

SITE 2
Serveur applicatif/stockage

Donnes de gestion

Paquets archivs

Rseau Serveur stockage

Donnes de gestion

Paquets 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 donnes descriptives Consultation Communication X X

Versement Serveur frontal Serveur WEB Serveurs applicatifs : - versement - base de donnes - commandes - administration Serveur stockage Espace stockage donnes de gestion Espace stockage paquets dinformations archivs X

Stockage

Administration

X X X X X X X

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. SITE 1 Type rplication Entre Sites 1 et 2 SITE 2 Type transmission entre Sites1/2 et 3 SITE 3 Risques rsiduels - 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 rplication ; - 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 donnes dont limportance reste lie la frquence de rplication ; - Possibilit de problmes particuliers mais rares conduisant la modification dintgrit dune partie des donnes que le systme ne pourra pas corriger dans son intgralit. - Trs faible possibilit de problme matriel sur site 1 conduisant larrt du service ; - Risque quasi inexistant de perte de donnes ; - Possibilit trs faible de modification dintgrit, de toute faon limite aux donnes entre deux rplications de bandes. - Trs faible possibilit de problme matriel sur site 1 conduisant larrt du service ; - Risque quasi inexistant de perte de donnes ; - Possibilit trs faible de modification dintgrit, de toute faon limite la frquence de rplication retenue, 1h 1/2journe. - Risque darrt du service quasi inexistant ; - Risque quasi inexistant de perte de donnes ; - Possibilit trs faible de modification dintgrit, de toute faon limite la frquence de rplication retenue, 1h 1/2journe.

Accs simple Stockage simple

Sauvegarde en continu

Stockage simple

Accs simple Stockage doubl

Sauvegarde en continu

Stockage simple ou doubl

Accs doubl Stockage doubl Serveur applicatif en secours Accs doubl Stockage doubl

Synchronisation

Stockage simple ou doubl

Manuelle frquence rgulire, a priori la journe

Armoire de bandes Robot de bandes ou autre support (Facilite lexploitation) Robot de bandes ou autre support

Synchronisation

Stockage simple ou doubl

Rseau

Accs doubl Stockage doubl Serveur applicatif en secours

Synchronisation

Accs doubl Stockage doubl

Rseau

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 ciaprs. 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. Dossiers de scnario de tests Dossier de mise en exploitation (MEX) Cahier de recette Page 35 sur 46

Livrables

SGDN / DCSSI / SDO / BCS 6.3.3.2 Intgration

Archivage scuris Cahier des charges 10 fvrier 2006

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 ceuxPage 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 ? Si oui : Pensez-vous qu'il puisse tre amlior dans son fond ? Oui 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 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 ? .......................................................................................................................................... .......................................................................................................................................... Non Non

Oui

Non

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 1

Rfrence

nonc de la remarque

Solution propose

Merci de votre contribution