CSV Validator, le XML du pauvre ?

Les Archives Anglaises ont défini un format  pour faciliter la récupération d’informations à archiver depuis une application source.

Le constat était simple : « it was recognised that it was too difficult and/or expensive for many suppliers to produce the desired metadata in XML »

Le format CSV, quant à lui, est un bon candidat, car facile à générer. En revanche, il est trop laxiste et trop limité.

D’où la notion d’un fichier CSV (ce n’est donc pas un nouveau format) qui suivrait un « schéma CSV » permettant de définir des règles de formattage.
Un schéma CSV permettra par exemple de :

• Définir des informations générales que doit respecter le fichier (séparateur de colonnes, nombre de colonnes)
• Indiquer le type de colonne : entier, date, chaîne…
• Indiquer une contrainte plus forte sur le contenu d’une colonne : liste de valeurs autorisées, expression régulière, nombre de caractères,chemin de fichier valide…

« CSV validator » est l’outil qui valide un fichier .csv par rapport à un schéma CSV. Il sort une log d’erreur si une règle n’est pas respectée.

Ce fichier schéma CSV (extension .csvs) est,fichier texte ayant une syntaxe relativement simple pour exprimer les règles que le fichier CSV doit suivre.

Par exemple, le schéma (csv avec 3 colonnes : un nom, un age et le genre) :

version 1.0
@separator ‘;’
@totalColumns 3
name: notEmpty
age: range(0, 120)
gender: is(« m ») or is(« f ») or is(« t ») or is(« n »)

L’utilisation de ce format pour l’archivage est effectivement à étudier. Bien qu’il soit préférable de gérer du XML, le CSV Validator pourrait être une solution alternative intéressante. Mais plutôt que d’archiver directement ce fichier CSV (dans ce cas avec son fichier .csvs), il serait plus intéressant d’avoir un préprocesseur en entrée du système d’archivage qui prendrait ces fichiers CSV et les transformerait en fichiers XML.

 

PS : cet outil fait partie de la liste des outils Open Source identifiés par le NARA (The U.S. National Archives and Records Administration) dans le document Open Source Tools for Records Management Report de mars 2015

On ne se mooc pas de vous ! Inscrivez-vous avant le 7 mars 2015

Sollicité par des centaines (voire milliers ?) de lecteurs, je reprends du service avec la publication de ce court article…

Car il y a urgence !

En effet, la plateforme FUN, met à disposition un MOOC (Massive Open Online Courses) proposé par le CR2PA sur l’archivage

Et les inscriptions se terminent le 7 mars 2015.

Le fait de s’inscrire permet d’accéder aux vidéos et documents, ressources très intéressantes sur le sujet.

Donc n’hésitez pas…

Archivage : Exemple d’un ‘bon’ cycle de vie

En publiant mon précédent article sur l’archivage dans le Cloud, je suis tombé sur un graphique présentant le cycle de vie d’un document, toujours extrait du même document de l’Aproged :

Copyright APROGED

Ce graphique  a le mérite d’être simple et d’utiliser des concepts qui me plaisent :

• En effet, on ne parle pas « d’archives courantes » pour désigner des documents en cours d’élaboration.
• Sous l’angle IT, on parle d’un outil de GED pour traiter la gestion du document . En parallèle, et dès le document validé, on parle de SAE. Le document peut donc se trouver dans le deux systèmes à un moment donné. On peut imaginer un système hybride avec une interface GED qui pointe sur les documents stockés en SAE.
• On ne met pas un graphique avec une notion de fréquence d’accès : un SAE n’a pas vocation à récupérer les documents d’une GED qui ne sont pas ‘souvent’ lus.
• On voit bien que la fonction Records Management couvre les fonctions de GED et SAE sur la partie Archives intermédiaire. C’est bien l’ensemble du cycle de vie qu’il est important de gérer comme un tout, seule façon d’assurer une valeur probante au document.

La Théorie des 3 âges, sujet très régulièrement abordé sur la toile, définit sur un vocabulaire qui m’inspire beaucoup moins…

Archivage : quel est LE SAE idéal ?

Le choix d’un progiciel est une phase classique dans un projet du système d’Information.

Ce billet a vocation à mettre en lumière quelques points spécifiques sur le choix d’un progiciel d’archivage (SAE : Système d’Archivage Électronique).

1 – Processus de sélection d’un progiciel

Chaque DSI a sa manière de traiter cette phase de sélection, je resterai donc à un niveau macro. De plus, le processus est à adapter en fonction de l’importance du projet.

Habituellement, dans le choix d’un outil, il y a une phase de prospection visant à définir une liste de produits qui font « référence sur le marché » (au travers de la veille, d’études de marché…). Ensuite, on établit une liste de critères que doit remplir le progiciel (avec pondération éventuelle) répartis sur trois thèmes :

• Partie Fonctionnelle : par rapport à une expression de besoin listant les exigences, notation des différents produits. Il peut être intéressant d’avoir une réponse nuancée : le produit répond au besoin / répond avec un paramétrage / répond avec un développement / ne répond pas au besoin
• Partie Technique : partie essentiellement rédigée par la DSI autour des technologies utilisées, des protocoles supportés, des possibilités d’interface…
• Partie Commune : partie souvent négligée que je trouve importante. Il s’agit de bien mesurer l’importance du produit pour l’éditeur (% du CA du produit / CA total, nombre de clients, nombre de développeurs, fréquence de publication de version, horaires de la hot-line, existence d’un club Utilisateur…). Il y a également les informations classiques sur l’entreprise elle-même, ses références et les prix (licence au volume à l’utilisateur, maintenance). Il est indispensable d’obtenir des noms d’entreprise utilisant le produit pour aller les interroger et avoir un « véritable » retour terrain.

Il est d’usage d’adresser ce questionnaire aux différents éditeurs mais, étrangement, l’outil est parfait selon l’éditeur et répond à tous les besoins. Il est impératif d’avoir un regard critique, d’avoir des soutenances avec les éditeurs pour échanger  autour de leur proposition…

A la fin de cette étape, il ne devrait rester plus que 1 ou 2 candidats. Des maquettes peuvent éventuellement être mises en place pour valider certains points et déterminer l’heureux gagnant.

2 – Spécificités de l’archivage

Lorsque le domaine concerne l’archivage, voici quelques points assez essentiels et déterminants pour le choix :

• Archivage physique, de documents électronique ou mixte
• Gestion de la durée de conservation, Gel
• Sort final – définition d’un workflow (paramétrage, souplesse), alertes sur échéances
• Réversibilité : lorsqu’on parle d’archivage, on peut parler de durées de conservation importantes. Il faut donc envisager la possibilité de changer de système d’archivage. Il doit donc offrir des fonctionnalités pour extraire les données
• Ouverture flux entrants + système d’import : automatiser des versements applicatifs
• Interrogation depuis une autre application
• Connecteurs standards avec d’autres composants du SI (SAP, SharePoint). Bien analyser les possibilités de paramétrage de ces connecteurs
• Mise en place de son propre connecteur pour s’interfacer avec une application « maison » (le développement de ce connecteur pourvant se faire en totale autonomie ou en sous-traitance)
• Gestion de la migration de formats (les formats de fichiers évoluant, il sera peut être nécessaire de transformer les formats des document selon un processus contrôlé)
• Gestion des supports (doit être transparent) : déplacement sur un media plus lent (plus économique)
• Respect normes & standards ? Il n’est jamais facile de s’y retrouver dans la jungle des normes et standards autour de l’archivage. De toute façon, l’éditeur vous dira que son progiciel respecte  l’OAIS, MOREQ, NF Z 42-013…
  Tant qu’il n’y a pas de certification, difficile d’y voir clair. Il est néanmoins intéressant de les utiliser comme check-list afin de poser des questions sur certains thèmes : gestion des logs, horodatage pour la 42-013 ;  gestion des plans de classement, des métadonnées, gestion des rôles pour MOREQ ; gestion des versements et consultation avec l’OAIS…
• Outil séparé ou module de l’ECM ? Les deux approches existent :  soit, j’ai un « pure player » spécialisé dans l’archivage, soit j’utilise un module de mon ECM. Dans ce dernier cas, il faut bien s’assurer que la brique Archivage est autonome, qu’elle est capable de traiter des versements provenant d’autres applications que l’ECM…

Voilà, maintenant vous avez toutes les billes pour trouver l’outil en parfaite adéquation avec vos besoins 🙂

CMIS : CKOA ?

1 – Introduction

CMIS (Content Management Interoperability Services) est un standard OASIS (Organization for the Advancement of Structured Information Standards) paru en mai 2010 pour la V1 et en décembre 2012 pour la V1.1.

Il décrit une interface standard pour accéder à un ECM (Enterprise Content Management) comme Alfresco, SharePoint…

2 – Description

Ce standard définit un modèle de données « universel » dans le monde de l’ECM ainsi que les fonctions associées pour manipuler ces données.

Les principaux concepts (je laisse les termes en anglais) sont décrits avec leurs propriétés ainsi que les différentes fonctions permettant de les manipuler.

Au niveau des objets

• Repository : permet d’avoir des conteneurs
• Objets pouvant être de différents types : de type Document, Folder, Relationship, Policy et Item
• Document : peut être versionnable, contenir de 0 à N fichiers. Un fichier est appelé un Content Stream. Des Renditions (représentation alternative comme un PDF pour un fichier bureautique) peuvent être associées à un document
• Folder : conteneur pour des Documents et/ou Folders
• Relationship : permet de faire un lien depuis un objet source vers un objet cible
• Policy :
• Item : permet d’étendre le modèle CMIS en définissant du’autres objets
• ACL (Access Control List) : gestion des droits d’accès
• Query : système permettant d’interroger la base CMIS au travers d’un langage de requête

Au niveau des fonctions, on retrouve des fonctions classiques de gestion documentaires :

• Gestion des objets : création, lecture, destruction
• Gestion des versions (check-in, check-out, version mineure/majeure)
• Gestion des droits d’accès : lire les droits d’accès sur un objet ou les positionner
• Fonction de recherche

Ce standard définit également les implémentations associées au travers de protocoles plutôt que d’API (Application Programming Interface) trop liées à un environnement/langage.

• AtomPub : AtomPub (RFC4287 par l’IETF) est un protocole à base de XML au dessus d’HTTP
• Web Services : protocole classique SOAP
• Browser : repose sur JSON (Java Script Object Notation, [RFC4627])

Comme on peut le voir, CMIS est un protocole détaillé (le document de référence fait plus de 300 pages…) qui permet de définir un moyen d’interagir avec un CMS au travers de fonctions permettant de manipuler des objets.

3 – Cas d’usage

Comme on peut le voir sur Wikipedia, les principaux éditeurs proposent une interface CMIS pour leur ECM : Alfresco, EMC Documentum, IBM Filenet, Microssoft SharePont, Nuxeo, OpenText Content Server… (Remarque : la version française et anglaise sont plutôt complémentaires

Intérêt et cas d’usage :

• Proposer un portail qui accède à différents ECM au travers de la même interface
• Proposer un navigateur universel accédant à différents conteneurs CMIS
• Proposer un connecteur universel d’un ECM en interface avec le SAE 

Lorsqu’on travaille dans le le monde de l’archivage, on ne peut pas s’empêcher de faire l’analogie avec la norme 45-020 (voir mon autre article). Mais autant CMIS est une interface assez complète pour qu’il y ait plusieurs implémentations, autant la norme 45-020 reste au niveau de spécifications de trop haut niveau.

Coffre-Fort Numérique et norme NF Z 42-020 : Est-ce utile ?

1 – Introduction

La norme AFNOR NF Z 42-020 est sortie en juillet 2012 sous le titre :

Spécifications fonctionnelles d’un composant Coffre-Fort Numérique destiné à la conservation d’informations numériques dans des conditions de nature à en garantir leur intégrité dans le temps (là, vous pouvez respirer 😉 )

Comme le titre l’indique, cette norme est une spécification : elle décrit les fonctions permettant d’interagir avec un  CCFN (ou Composant Coffre-Fort Numérique).

2 – Contenu de la norme

La norme est un petit document de 23 pages décrivant les concepts et les exigences fonctionnelles que doit suivre un CCFN.

Les principaux concepts :

• Un CCFN contient des conteneurs. Un conteneur contient des objets numériques. Un objet numérique pouvant contenir un ou plusieurs fichiers. A un objet numérique sont associées des métadonnées techniques obligatoires (identifiant d’objet, l’identifiant de l’utilisateur ayant déposé l’objet, la date de dépôt, la taille de l’objet, l’algorithme pour le calcul de l’empreinte et l’empreinte elle-même)
• Trois types d’utilisateurs définis : l’Administrateur Général (gérer les administrateurs fonctionnels), l’Administrateur Fonctionnel (gestion des utilisateurs, gestion des conteneurs) et le Simple Utilisateur (lecture/écriture)
• Un CCFN doit proposer la notion de journal pour tracer toutes les appels de fonction sur le CCFN

Les fonctions :

• Déposer un objet numérique (l’empreinte peut être fournie par l’application ou calculée par le CCFN)
• Lire un objet numérique
• Détruire un objet numérique (et ses métadonnées)
• Lire les Métadonnées Techniques d’un objet numérique
• Contrôler un objet numérique pour vérifier l’intégrité d’un objet numérique
• Lire Journal pour récupérer toutes les opérations répondant au critère (objet numérique, entre deux dates)
• Lister pour obtenir les objets numériques répondant au critère (par rapport aux métadonnées techniques par exemple)
• Compter le nombre d’objets numériques répondant au critère (par rapport aux métadonnées techniques par exemple)

3 – Cas d’usage

Maintenant que la norme est présentée, la question de son utilité peut se poser.

Quand un éditeur se proclame compatible 42-020, qu’est ce que cela veut dire ? Personnellement, je suis assez réservé car il est difficile d’être compatible d’exigences fonctionnelles pour un logiciel. Il faudrait descendre à un plus bas niveau.

Autrement, sur le principe,cette norme permet de définir les bases de tout CCFN qui faciliteraient l’intégration d’un SAE dans le système d’information :

• Un SAE pourrait écrire et lire dans différents CCFN à partir de la même interface
• En cas de reprise, il serait facile de récupérer les données au travers de cette interface
• Une application tierce pourra lire et écrire des données et l’interface n’aura pas besoin d’être modifiée si le CCFN est changé

4 – Et la suite ?

Baptisé NF 203 CCFN, une certification NF logicielle est en cours pour permettre de valider la conformité d’un produit à cette norme.

A mon avis, il manque certains points importants au niveau de l’administration (gestion des conteneurs, gestion des droits d’accès) et des besoins fonctionnels comme la gestion de la durée de conservation des objets.  L’approche, pour les concepteurs de la norme, était, je pense, de décrire un composant technique interne au SAE. Les autres fonctions seraient alors plutôt au niveau du SAE.

Par analogie avec un autre standard : dans le monde des ECM (Enterprise Content Management), il existe un standard similaire appelé CMIS (Content Management Interoperability Services).

Mais contrairement à la norme 42-020, CMIS va beaucoup plus loin dans les détails en définissant avec précision les interfaces . Il aurait été intéressant que la 42-020 s’inspire de ce standard.

Pour ceux intéressés, n’hésitez à parcourir mon billet sur CMIS.

Archivage d’un email : oui, mais quel format ?

Nous avons vu dans un précédent article la nécessité d’archiver les emails engageants.

Il s’agit maintenant d’identifier le format adapté à l’archivage pour ces emails.

Existe-t-il « un » format  d’archivage pour les emails ?

Cet article, sans être trop technique, se focalise sur le format proprement dit. De manière générale, pour qu’un format soit candidat à l’archivage, il est recommandé de s’appuyer sur un format pérenne, ouvert, normalisé, fidèle…

J’élimine donc tout de suite, les fonctions « d’archivage’ proposées par les clients de messagerie, trop propriétaires (format base PST ou similaire).

Un email est un objet complexe composé d’informations structurées (émetteur, destinataires, date, objet) et non structurées (le corps du message plus ou moins complexe et les différentes pièces jointes). Les formats sont normalisés au travers de RFC (Request For Comments) gérées par l’IETF : la partie structurée d’un email dans la RCF 2822 et des extensions pour gérer notamment les pièces jointes de différents formats (notion de type MIME) dans les RFC 2045, RFC 2046, RFC 2047, RFC 2048 et RFC 2049.

Les principaux formats rencontrés sont :

• .msg (format Outlook) est un format propriétaire Microsoft dont les spécifications sont publiques. Il se base sur le principe d’un document composite englobant les différentes pièces jointes.
• .eml, équivalent à un .mht, est un format texte avec les pièces jointes encodées dans le format Base64. Cet encodage ne pose pas de problème particulier car la table de conversion est publique. mais au final, on récupère les PJ dans leurs formats d’origine qui peuvent être propriétaires (Office par exemple)
• MBOX (http://tools.ietf.org/html/rfc4155) et ses variantes.

Aucun de ces formats ne remplit les critères pour être archivé mais il est techniquement faisable de les transformer dans un format standard bien qu’un tel format n’existe pas. XML est bien adapté pour représenter la partie structurée d’un email et de nombreux projets ont vu le jour (XMTP, draft IETF, projet XMaiL) sans qu’aucun n’ait vraiment percé…

La gestion XML ne traite que la partie structurée d’un email. Il est donc important de ne pas oublier de traiter les pièces jointes en les transformant dans le « bon » format (PDF/A-2 pour la bureautique par exemple).

Concrètement, l’archivage d’un email demande un traitement à la source des emails identifiés comme étant à archiver. Il est conseillé d’archiver le mail source ainsi qu’une représentation de cet email (format XML du mail et transformation des pièces jointes dans un format pérenne).

Coffre-Fort Numérique pour le grand public : avez-vous lu les « CGU » ?

Depuis quelques années, des banques, assurances et mutuelles proposent un service de Coffre-Fort Numérique (CFN) à leurs clients.

Avant d’entrer dans le vif du sujet, quelques précisions :

• La norme NF Z 42-020 (je reviendrai sur cette norme dans un autre article) parle de Composant Coffre-Fort Numérique (CCFN). Il y a donc une petite différence avec le CFN grand public puisque cette norme décrit les exigences fonctionnelles qu’un « composant » doit respecter, sachant que le « composant » est à considérer comme étant une sous-partie d’une application.
• La CNIL a émis une recommandation sur le sujet (voir un précédent billet).

 

Comme tout consommateur averti, j’aime bien lire les Conditions Générales d’Utilisation (CGU) pour bien comprendre le service offert. Et concernant les CFN, j’étais très curieux de voir quel niveau de service était proposé par ces organismes.

Il s’agit de bien vérifier les points suivants :

• Comment est décrit le service offert et quel est l’engagement ?
• Quelles sont les limites en terme de taille et de format des fichiers ?
• Quelles sont les conditions d’arrêt du service (si je ne suis plus client…) ? attention, souvent la récupération du contenu doit se faire dans un temps limité (sous 1 mois)
• Quelles sont les fonctions offertes en plus du versement/récupération ? Il peut y avoir un dépôt par messagerie, la possibilité d’inviter d’autres personnes à pouvoir lire des documents

Petit florilège de contenus des CGU…

…Sur la définition du service :

[…] met à disposition de ses Abonnés un coffre sécurisé à vocation probatoire conformément à la norme AFNOR NF Z 42-013 et ce pendant la durée définie contractuellement avec les Expéditeurs.

Dans le cadre du Service, met en oeuvre les moyens nécessaires à assurer la sécurité, l’intégrité, et la confidentialité des Documents.

…Sur les limites :

il deviendra Titulaire d’un Coffre-fort Electronique […] d’une capacité illimitée

La taille de chaque fichier téléchargé ne doit pas dépasser deux cent cinquante méga octets (250 M o). La taille du coffre-fort numérique est limitée à un giga octet (1 Go)

La capacité de stockage du Coffre est de 3 Go

…Sur la notion de copie/original :

L’attention du Titulaire est portée sur le fait que les Documents qu’il dépose dans le coffre-fort numérique constituent des copies numériques et qu’il lui est en conséquence recommandé de conserver par-devers lui les documents originaux à titre de preuve.

Il est rappelé que le Service ne donne pas, à ces documents ainsi numérisés et stockés, de valeur probante particulière. Ces documents numérisés et stockés sont de simples copies des documents originaux. En conséquence, le Client est invité à ne pas détruire les documents originaux et à leur apporter tous les soins nécessaires à leur conservation.

…Sur la clôture :

Le Titulaire devra, préalablement à cette clôture, prendre soin de sauvegarder les Documents sur un support qui lui est propre et de les supprimer du Coffre-fort Electronique

Dans ce cas, le Client doit avoir, avant fermeture, récupéré l’ensemble de ses documents stockés dans son coffre-fort par téléchargement à l’aide de la commande « Extraire »

…Autres clauses :

L’Hébergeur s’engage à ce que les documents stockés ne soient ni copiés, ni reproduits, ni dupliqués.

La Banque se rapprochera des ayants droit ou du notaire chargé de la succession s’agissant du devenir des Documents

Et pour terminer, un détour par l’offre du public :

Au travers du portail service-public.fr, un service de « porte-documents’ est offert à tout citoyen pour gérer ses documents administratifs :

En créant un compte mon.service-public.fr, vous disposez gratuitement d’un mode d’archivage sûr et innovant : le porte-documents électronique. Vous pouvez y conserver en toute confiance tous vos documents numérisés (pièces d’identité, factures, attestations etc.) ainsi que les pièces justificatives échangées avec l’administration. Votre document doit être au format PDF et sa taille ne peut excéder 1Mo

Après la lecture de cet article, plus qu’une chose à faire : lires les « CGU » 😉  !

Archinnovez !

Archivage et innovation ?

On a souvent tendance à les exclure…

Or pour moi, il y a de nombreuses opportunités pour remettre l’archivage au goût du jour 🙂

Pour rappel, je vois l’archivage sur deux axes :

• L’archivage à valeur probante, dans le cas d’une réglementation, d’une clause contractuelle…
• L’archivage autour du savoir-faire, lié au patrimoine de l’entreprise (attention, je ne parle pas du patrimoine qui se déversera dans les archives historiques mais plutôt de la gestion des connaissances)

Et c’est sur ce 2ème axe qu’un système d’archivage peut apporter de nombreuses fonctionnalités qui pourraient favoriser des démarches d’innovation.

Je trouve dommage que les éditeurs d’outil n’essaient pas de valoriser ces gisements d’information. On retrouve les mêmes problématiques que pour les ECM : classement, gestion des métadonnées, système de recherche…

Les éditeurs doivent eux-mêmes innover 😉 dans leurs produits afin de faciliter l’accès aux informations au travers de navigations intelligentes, de plans de classement dynamiques, d’aides à la gestion du sort final…

Et voir enfin le SAE comme composant d’une démarche globale d’innovation.

Archivage d’une base de données : intérêt du format SIARD ?

Je risque d’être un peu provocateur mais la première question est de revenir au besoin. En effet, archiver une base de données ne veut pas dire grand-chose. Autant le contenu d’un document bureautique est compréhensible par un humain (à condition de disposer du bon lecteur évidemment), autant le contenu d’une base de données ne représente que des datas élémentaires. Et archiver une donnée sans son contexte n’a pas d’intérêt.

Si j’ai la valeur 100 dans la base il faut que je sache si cela représente 100€ ou 100k€ ou 100°C, que je connaisse ce que cela représente (un montant de facture, une température…) et son environnement (facture n° 123 du client ABC…, température maximale supportée par le composant X).

Il est donc souvent nécessaire de revenir à l’application au dessus de cette base de données pour analyser le besoin d’archivage. Et la solution sera différente suivant le besoin.

Je mets de côté le besoin IT de faire « maigrir » une application en enlevant des données pour avoir des meilleures performances. Je ne considère pas cela comme de l’archivage pur. La solution passe alors par des mécanismes internes offerts par le système de gestion de la base de données.

La solution, très lourde, consistant à conserver l’environnement complet (ordinateur, logiciels…) est à éviter mais certains contextes n’offrent pas d’autre alternative.

Voici quelques exemples de besoins :

• Paie : je n’ai pas besoin d’archiver la base de données de la paie. En revanche, je dois archiver les bulletins de salaire. On revient à la problématique de l’archivage du document (papier ou électronique)
• Données métiers (base interne) : données d’observation, données de modélisation d’un système…
  Il est nécessaire d’identifier une représentation externe de cette information et fournir le moyen de ‘relire’ le contenu. Plus le modèle de données est compliqué, plus la fonction de relecture le sera également. La tâche est encore plus compliquée si l’application au dessus de la base de données fournit des fonctions de calculs, agrégation… Dans ce cas, il faut également conserver les concepts et algorithmes permettant de manipuler les données.
• PLM (Product Lifecycle Management). Ces applications permettent de gérer en configuration des produits (voiture, train, téléphone) tout au long de leur vie. Un tel système repose sur un modèle de données complexes (nomenclature) souvent propriétaire (pouvant comporter des centaines de ‘tables’), des millions de documents (des plans, des documents techniques…)
  La norme ISO STEP (STandard for the Exchange of Product model data) peut apporter quelques éléments de réponse mais cela nécessite une investigation poussée. Il arrive donc souvent que les données soient conservées en ligne…

Sur la problématique technique, les Archives Fédérales Suisses (AFS) ont défini un format standard SIARD (Software Independent Archiving of Relational Database) qui est un format de fichier ouvert pour l’archivage des contenus de bases de données relationnelles (utilisation du XML pour avoir une représentation générique du modèle de données avec typage des informations, gestion des relations ce qui est un plus important par rapport à un export brut en CSV). De plus, l’outillage (SIARD Suite) est également offert pour convertir une base de données relationnelle dans le format SIARD (et fonction inverse d’import pour pouvoir utiliser la puissance des requêtes SQL).

Le CINES (Centre informatique National de l’Enseignement Supérieur) a publié un intéressant guide (V1.1 du 16 avril 2013) autour de la problématique de l’archivage d’une base de données. Il pose notamment de bonnes questions sur la démarche à suivre, les avantages et inconvénients de différents formats candidats (Dump, CSV, XML, SIARD).

Pour conclure, SIARD est une approche à étudier lorsqu’on souhaite exporter des données d’une base de données ayant un modèle de données relativement simple (ou facilement compréhensible). Mais la clé est d’analyser le besoin initial pour identifier quoi archiver et quand…

PS : SIARD version 1.0 est approuvé depuis le 21.03.2013 par eCH sous la référence eCH-0165.

eCH :

développe et adopte des normes de cyberadministration, des solutions type, et des documents auxiliaires [au niveau de la Suisse]. Les normes ont valeur de recommandations et sont mises à disposition gratuitement