Archivage & Open Source font-ils bon ménage ?

Un mois de mars 2015 riche dans le domaine des archives :

• La publication le 18 mars 2015 par le NARA (The U.S. National Archives and Records Administration) d’une liste d’outils autour du Records Management
• L’annonce faite le 10 mars 2015 par le gouvernement du lancement officiel du programme VITAM (Valeurs Immatérielles Transmises aux Archives pour Mémoire)
• Un nouveau module RM pour Maarch annoncé le 24 mars 2015

Ces 3 événements ont un lien commun car ils parlent tous d’Open Source. Est-ce une tendance de fond ? Est-ce une « bonne » idée d’introduire de l’Open Source dans un système d’archivage ?

Pour moi la question n’est pas là : le système doit répondre aux besoins exprimés et standards du marché avec une gestion de la durée de la conservation, une écriture en Y des contenus, une réversibilité, la gestion des empreintes pour garantir l’intégrité des données et les fonctions habituelles autour du document (accès, métadonnées, recherche…).

Dans le cadre de VITAM,  des briques Open Source seront utilisées  pour fournir un service de dépôt et consultation à base d’API. Pour certains composants, on peut penser qu’ils vont suivre le SILL (Socle Interministériel de Logiciels Libres dont la dernière version est sortie au début du mois de mars)  avec Apache, Tomcat, OpenLDAP, MangoDB (plutôt que PostgreSQL), ElasticSearch…

Mais cela ne concerne que les composants techniques. Il y aura donc des développements autour des spécificités de l’archivage pour implémenter les principes de l’OAIS, de MEDONA, de la 42-013 de MOREQ…

Développements qui seront eux-mêmes proposés en Open Source.

Bref, un beau projet qui n’est pas sans risques notamment au niveau de la capacité à proposer un modèle assez générique pour répondre au versement des différentes applications sources…

PS : Concernant la liste du NARA, j’y reviendrai dans d’autres articles en détaillant certaines solutions intéressantes.

 

2D-DOC ou Cachet Electronique Visible : technologie à suivre !

La FNTC (Fédération Nationale des Tiers de Confiance) était intervenue lors d’une réunion du CR2PA (Club des Responsables et Politiques d’Archivage) en mars 2014.

A cette occasion, la technologie 2D-DOC a été présentée par Eric Normand.

Un an plus tard, lors du prochain salon Documation-Mis, la FNTC propose une conférence le 19/03/2015 à 12h30 sur le thème du Cachet Electronique Visible (CEV).

A l’origine, l’état Français souhaitait un système permettant de limiter les faux papier (rien de plus facile que de sortir un faux justificatif de domicile par exemple).

Il consiste en la matérialisation d’un code à barres (style QR-CODE) sur le document pour ‘prouver’ que le contenu du document est correct.

Je vois plusieurs aspects intéressants au Cachet Electronique Visible 2D-DOC :

• simple pour l’utilisateur : le code est matérialisé sur le document et peut être scanné facilement (application android ou ios). La copie ne pose pas de problème
• mode mixte : peut être utilisé aussi bien pour un document papier que pour ‘un document électronique
• Axe entreprise : le code permet d’extraire les données du document sans procéder à une lecture intelligente du document (analyse de zone) qui n’est pas sûre à 100%. L’exemple d’une facture devient très facile à lire avec ce système.

Au niveau technique, le 2D-DOC repose sur les mécanismes suivants :

• Création du code :

1. Identification des informations « essentielles » du document. Pour une quittance de loyer, on aurait l’adresse, le nom du locataire, la date et le montant du loyer
2. Génération d’une empreinte unique à partir de ces informations
3. Cette empreinte est signée via un certificat (clé privée de l’émetteur) délivré par l’ANTS (Agence Nationale des Titres Sécurisés)
4. Les informations essentielles ainsi que l’empreinte signée sont utilisées pour générer un code (équivalent d’un QR-CODE)
5. Ce code est inséré dans le document

• Lecture du code :

1. La personne lit le code à barres au travers d’une application et récupère les informations sur l’émetteur
2. L’application se connecte sur le site de l’ANTS pour vérifier que tout est valide
3. La personne peut comparer les données décryptées avec celles présentes sur le document et ainsi être certaine que son contenu n’a pas été falsifié

En revanche, ce mécanisme n’est pas prévu pour gérer tout type de document : les informations « essentielles » doivent être limitées pour être coder. On pourrait mettre une facture mais pas un contrat avec toutes ses clauses…

Pour aller plus loin :

• Site de l’ANTS
• Détails du processus

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

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.

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 :

• Des fiches pratiques autour de la problématique de l’archivage des mails proposées par la FEDISA (date de 2008 mais toujours d’actualité)
• Etude détaillée et complète (100 pages) par le projet VITAM (septembre 2013)
• Livre blanc sur l’archivage des mails par le CR2PA (synthèse, il faut être membre pour accéder au livre) datant de 2011

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.

PDF/A : LE format pour archiver ?

Le PDF (Portable Document Format), défini par la société Adobe, est normalisé depuis juillet 2008 (ISO 32000-1). Il repose sur la version 1.7 et correspond à Acrobat V8.

On peut souvent lire : « PDF est un bon format pour archiver car on ne peut pas le modifier ». Malheureusement, ce n’est pas vrai. Il existe des outils permettant de manipuler le contenu. Et un bon format à archiver repose sur d’autres critères : ouvert, libre, « lisible »…

En plus du classique PDF, il existe une famille adaptée à l’archivage appelée PDF/A (A pour … Archive). Ces formats sont également normalisés (ISO 19005-1, ISO 19005-2 et ISO 19005-3) et apportent au PDF classique des caractéristiques adaptées à l’archivage.

La principale restriction par rapport au PDF concerne tout ce qui touche à l’aspect dynamique et le caractère non-autoporteur qui sont antinomiques avec l’archivage. Donc le PDF/A « embarque » les polices de caractères, n’autorise pas un affichage dynamique (le format PDF peut afficher des informations ou non suivant des paramètres), n’autorise pas l’inclusion de scripts d’action…

Cependant, comme énoncé plus haut, il existe 3 versions (avec différents niveaux de conformité dans chacune d’elle) :

• PDF/A-1 (ISO 19005-1:2005) est basée sur le format PDF v1.4. Le cryptage du document n’est pas autorisé
• PDF/A-2 (ISO 19005-2:2010) est basée sur le format PDF v1.7 (lui même  ISO 32000-1:2008). Il permet d’utiliser la transparence, d’insérer d’autres fichiers PDF/A, supporte le JPGEG2000 et peut inclure une signature numérique
• PDF/A-3 (ISO 19005-3:2012) est basée sur le format PDF v1.7. Il permet d’insérer des documents de tout format

Le PDF/A est un des formats à considérer pour l’archivage. Notamment pour tous les documents bureautiques. Mais il faut préciser exactement la version et le niveau de conformité retenus. Et n’oubliez pas de mettre en place un processus de validation du format avec un outil qui testera que le fichier est bien conforme à ce qu’il prétend être.

Pour l’archivage, la version PDF/A-3 est à utiliser avec précaution. En effet, il est possible d’inclure dans le fichier PDF, un fichier au format propriétaire. Une utilisation possible est de mettre, par exemple, le fichier Word source inséré dans le fichier PDF qui pourrait représenter le document signé. On a ainsi l’ensemble des informations dans un seul fichier. Une autre utilisation potentielle de la version A-3 est de représenter un email…
L’alternative, que je préfère, est d’archiver les fichiers séparément tout en gardant un lien (via une métadonnée indiquant la référence par exemple).

Ma préférence va donc au format PDF/A-2.

Pour aller plus loin sur le PDF et PDF/A, voici quelques ressources supplémentaires :

• PDF/A in a nutshell, publication de la « PDF Association » sortie en mai 2013
• Le format de fichier PDF -Guide méthodologique, étude détaillée d’août 2012, réalisée par le SIAF/CINES/…