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