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

Publicités

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

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…

Saint-Cloud, archivez pour nous…

L’APROGED (Association des professionnels pour l’économie numérique) a publié le 15 janvier 2014, un livre blanc intitulé « Archivage sur le Cloud – Pratiques et perspectives ».

Cet intéressant document de 65 pages définit dans un premier temps les différentes possibilités d’archivage dans le Cloud :

Copyright APROGED

Copyright APROGED

Il aborde également les spécificités d’un archivage, contraintes que le Cloud doit supporter :

  • Localisation des données
  • Gestion des données personnelles
  • Sécurité des données
  • Réversibilités des données
  • Audit, traçabilité

Que ce soit pour un projet d’archivage ou pour un autre projet, la décision d’aller sur le Cloud est plutôt une décision de l’IT qu’une décision de la Maîtrise d’Ouvrage. En effet, à partir d’une description exhaustive des besoins et contraintes, le projet pourra définir si l’alternative Cloud a du sens dans son contexte.

Mais dans le cadre d’un projet d’archivage, il est clair que les fonctions de stockage offertes par un service de Cloud « basique » ne suffisent pas. L’offre de services doit s’enrichir pour répondre aux spécificités de l’archivage.

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 🙂

Faut-il archiver les emails ?

Le périmètre de cet article concerne les emails engageants. Je ne prends pas en compte « l’archivage » pour faire de la place dans les boîtes aux lettres.

La réponse à la question du titre est simple. Je parle d’email engageant et comme toute information engageante, je dois prévoir son archivage.
Bon d’accord, j’ai déjà répondu à la question mais vous avez quand même le droit de continuer la lecture de cet article 😉

Un email a-t-il des caractéristiques spéciales que n’aurait pas un document « classique » ?

Voici quelques spécificités de l’email :

  • La volumétrie exponentielle : les chiffres autour du nombre d’emails échangés donnent le tournis
  • La complexité du format d’un email (parties structurées au niveau des métadonnées, pièces attachées, corps de texte avec une mise en page évoluée, des fils de discussion, fonctions de transfert…) et la non-existence d’un format ouvert, standard et pérenne
  • Les aspects juridiques avec la protection en France sur la correspondance privée
  • La diversité des mails échangés et la difficulté à identifier ceux qui sont engageants

Concrètement, s’attaquer à l’archivage des mails demande une approche au bon niveau et s’intègre dans une politique globale (la fameuse Retention Policy) de l’entreprise.

Un projet d’archivage d’email doit traiter les points suivants :

  • Aspects fonctionnels : processus lié à la sélection des mails, définir les durées de conservation, les fonctions permettant de consulter/rechercher un mail archivé
  • Aspect technique : identifier le format d’archivage qui sera retenu [ce point sera traité dans un autre article]

Sur le premier point, plusieurs approches existent :

  • Archiver toutes les entrées/sorties des serveurs de messagerie. L’avantage est de ne pas ‘oublier’ par erreur un email engageant. Les inconvénients sont d’une part un risque d’archiver des mails personnels et d’autre part la nécessité de devoir mettre en place une infrastructure très importante pour absorber la volumétrie
  • A l’opposé, laisser l’utilisateur final gérer manuellement et unitairement les mails qu’il juge engageant depuis son client de messagerie. Cela nécessite un accompagnement important pour que l’utilisateur se sente impliqué et qu’il ait les clés pour identifier les « bons » emails.

Et entre les deux, nous avons toutes les variantes avec des mix possibles.

Des réflexions/études en cours ont amené à différentes approches qui peuvent être complémentaires :

  • Identifier les services/profils/postes ou niveaux de responsabilité qui sont amenés à manipuler des emails engageants. C’est le cas de l’approche Capstone aux USA proposée par la NARA (The U.S. National Archives and Records Administration)  qui se base sur le niveau de responsabilité.
  • Proposer des filtres pour aider l’utilisateur à pré-sélectionner les emails. Ils exploitent les métadonnées comme le titre, le nom de domaine de l’émetteur (client, fournisseur…), des mots-clés… Le futur serait d’aller vers des outils de recherche plus performants allant vers l’analyse sémantique du contenu. Pour ma part, je milite pour que les mails engageants soient gérés directement dans des applications dédiées (permet un contrôle de la mise en forme, du contenu et un archivage maîtrisé…), pour que les mails ne contiennent plus de PJ (utilisation de plates-formes collaboratives en extranet avec traçabilité des échanges qui seront archivés), bref, un monde avec moins d’emails, le bonheur quoi !

Il y a un point à bien prendre en compte : pouvoir garantir l’intégrité du mail. Pour cela, il faut que le processus de capture d’email soit bien géré et sans faille, idéalement au plus près du serveur de messagerie.

Pour aller plus loin :

En conclusion, on peut dire que la prise en compte des emails doit faire partie du projet d’archivage de l’entreprise. car il est nécessaire de prendre en compte les informations engageantes quel que soit le format. Il est possible de ne pas les traiter, on se trouve devant une gestion des risques, c’est une décision de l’entreprise.

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