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 » 😉  !

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.

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 :

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

Archivage et technologie NoSQL

Les résultats d’une étude  du projet VITAM (projet d’archivage électronique porté par le ministère des Affaires étrangères, le ministère de la Défense et le ministère de la Culture, dont les Archives nationales ; VITAM voulant dire Valeurs Immatérielles Transférées aux Archives pour Mémoire) ont été publiés en septembre 2013.

Cette étude détaille un POC (Proof Of Concept) visant à évaluer l’intérêt de la technologie NoSQL pour des systèmes d’archivages.

Habituellement, les bases de données sont représentées sous forme de modèle relationnel. Ce modèle  peut avoir des limites (volumétrie et performances) et manquer de souplesse (architecture, modèle de données) dans certains cas.

D’où l’apparition de cette « nouvelle » approche baptisée « NoSQL ». Attention, cela ne veut pas dire « No SQL » mais « Not Only SQL », la nuance est importante… (pour aller plus loin sur le NoSQL, une présentation rapide et claire).

Le POC réalisé utilise la base MongoDB et les conclusions sont assez enthousiastes :

…perfect choice in term of performance, requests capabilities and adaptation to the digital administration and to the future digital information governance

CNIL et coffre-fort numérique

La CNIL (Commission Nationale de l’Informatique et des Libertés) a publié le 19 septembre 2013 une recommandation sur le coffre-fort électronique, service que l’on trouve de plus en plus sur Internet (et qui fera l’objet d’un autre billet prochainement).

On peut y lire notamment quelques principes que le prestataire de services doit suivre.

Notamment :

l’hébergement de données de santé est soumis à un régime juridique spécifique

Il est nécessaire ainsi d’obtenir un agrément ministériel spécifique. Autrement, il ne faut pas proposer la possibilité d’héberger les résultats d’un examen de santé par exemple.

La CNIL insiste évidement sur toutes les problématiques liées à la sécurité du système (cryptage du contenu, gestion des mots de passe, accès aux données).

Elle précise également les services que le prestataire doit offrir. On peut y lire :

les fournisseurs doivent rendre accessible, sans surcoût, un outil permettant aux utilisateurs de récupérer l’intégralité du contenu de leur coffre-fort de façon simple, sans manipulation complexe ou répétitive, et ce afin de faciliter le changement de fournisseur

C’est effectivement un point très important et je ne pense pas que les solutions actuelles du marché suivent ce point. Elles n’offrent qu’une fonction de récupération document par document.

Bref, il serait intéressant de demander à son prestataire (via une mutuelle, banque…) son avis sur cette recommandation.