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

Publicités

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.