L’OAIS est un modèle conceptuel pour l’archivage de documents (numériques en particulier). Cela signifie qu’il constitue une référence décrivant dans les grandes lignes les fonctions, les responsabilités et l’organisation d’un système qui voudrait préserver de l’information, en particulier des données numériques, sur le long terme. Le long terme est défini comme suffisamment long pour être soumis à l’impact des évolutions technologiques, c’est à dire, pour ce qui concerne le document numérique, très court en fait.
L’OAIS a été défini au départ dans le domaine aérospatial, par le CCSDS qui est l’organisme de normalisation de ce domaine. Aujourd’hui il est très largement adopté au-delà de cette communauté et il a été reçu comme norme par l’ISO sous le numéro 14721.

Que fait / ne fait pas l’OAIS ?

Ce que fait l’OAIS :

• il donne une terminologie fiable et unique pour manipuler tous les concepts liés à la préservation des données numériques
• il fait le tour de toutes les questions à se poser au moment de mettre en place un système de préservation
• il décrit les composantes d’un tel système au niveau de l’organisation interne et externe

Ce qu’il ne fait pas :

• il ne donne pas de formats, schémas, règles ou techniques pour préserver les documents numériques
• il ne décrit pas les applications informatiques et techniques à mettre en œuvre, ni logicielles, ni matérielles
• il ne donne pas de méthodologie concrète de réalisation d’un tel système (cahier des charges, workbook ou autre).

Les grands principes du modèle peuvent être décrits par un schéma simple (mais également par un schéma compliqué si on veut ;-) cf. ci-dessus (cliquer sur l’image pour agrandir). En gros, le modèle est conçu comme une boîte dans laquelle on manipule des paquets. Cette boîte a un ou plusieurs rôles ou missions, et elle interagit avec les producteurs des données en amont, les administrateurs du système, et la communauté d’utilisateurs en aval.

Les paquets

Le modèle OAIS repose sur l’idée que l’information constitue des paquets, et que ces paquets ne sont pas les mêmes suivant qu’on est en train de produire l’information, d’essayer de la conserver, ou de la communiquer à un utilisateur. On a donc trois sortes de paquets :

• les paquets de versement (SIP) préparés par les producteurs à destination de l’archive
• les paquets d’archivage (AIP) transformés par l’archive à partir du SIP dans une forme plus facile à conserver dans le temps
• les paquets de diffusion (DIP) transformés par l’archive à partir de l’AIP dans une forme plus facile à communiquer notamment sur le réseau.

Dans chaque paquet, à chaque stade, on va trouver des fichiers informatiques qui correspondent à l’objet ou au document qu’on veut conserver, et des informations sur ce document c’est à dire des métadonnées. Je ne vais pas rentrer dans le détail, mais la façon de constituer les paquets, y compris et surtout le genre de métadonnées dont on a besoin pour que ça ait une chance de fonctionner, sont très bien décrits dans le modèle.

Les missions d’une archive OAIS

Le but de la mise en place d’une archive OAIS est d’avoir une instance, cette archive, qui va endosser la responsabilité de la préservation à long terme des documents qu’on lui confie en vue de les communiquer à une communauté définie d’utilisateurs. Il y a plusieurs idées importantes ici :

• la préservation se fait en vue de la communication
• l’archive cible une communauté d’utilisateurs et s’efforce de répondre aux besoins de cette communauté.

Si on prend l’exemple d’une bibliothèque, la communauté n’est pas la même pour une BU que pour une bibliothèque publique, vous savez cela aussi bien que moi. Donc les services ne seront pas les mêmes non plus.
L’idée de responsabilité est très forte dans le modèle ; à tout moment l’archive doit savoir prouver qu’elle a bien fait son travail – surtout si elle échoue, j’imagine.
Cette responsabilité inclut les relations avec les producteurs : il s’agit de négocier des accords concernant les versements, en particulier les clauses techniques (l’archive et le producteur définissent ensemble à quoi doit ressembler le SIP). Cela inclut aussi le fait d’obtenir de la part du producteur tous les droits nécessaires à la manipulation des documents, en particulier les droits de propriété intellectuelle.
L’archive garantit aussi qu’elle fournira à sa communauté d’utilisateurs des documents compréhensibles, disponibles, et qu’elle mettra en œuvre tout ce qui est en son pouvoir pour préserver les documents dans le temps : c’est une sorte de contrat entre l’archive et sa communauté d’utilisateurs.

L’organisation

Le modèle OAIS va ensuite définir l’organisation de l’archive, c’est à dire comment elle doit s’y prendre pour gérer ses paquets sans rien oublier. Pour cela, on définit des entités organisationnelles et la façon dont elles s’articulent entre elles. Pour prendre un exemple, il y a une entité « entrées » dont le rôle est de recevoir les paquets SIP et de les transformer en paquets AIP ; cette entité est en relation avec l’entité « stockage » à qui elle confie les AIP. Elle a aussi d’autres rôles comme envoyer un accusé de réception au producteur pour certifier qu’elle a bien pris en charge son paquet, ce qui transfère la responsabilité du paquet du producteur vers l’archive.
Je ne vais pas détailler mais tout est un peu sur ce modèle. Les différentes entités sont :

• les entrées
• le stockage
• la gestion des données (en fait, des métadonnées)
• l’administration qui pilote le tout
• la planification de la préservation qui prend en charge les actions de veille technologique pour décider des opérations à mettre en œuvre
• et enfin, l’accès.

Chacune de ces entités a ses rôles, ses fonctions, et doit communiquer avec les autres sous la forme de flux de données. En réalité, tout cela est conceptuel, cela veut dire que dans la mise en œuvre réelle, on n’est pas obligé d’avoir des gens ou des services qui travaillent spécifiquement sur une et une seule de ces entités. Mais toutes les fonctions et les interactions doivent exister.

Migrations, émulations

Ensuite, le modèle OAIS aborde les différentes méthodes qui peuvent être utilisées plus concrètement pour pérenniser l’information. Il y en principalement deux sortes : la migration et l’émulation.
La migration consiste à prendre un AIP et à le transformer en autre chose. Il y a plusieurs sortes de migrations possibles en fonction du type de problème rencontré : par exemple, si on a un support qui se dégrade mais que le document enregistré dessus ne pose pas de problème, on procède à un simple renouvellement (rafraîchissement de support) ou on passe à un support plus récent (duplication). C’est le type de migration qui a le moins d’impact sur l’accès à l’AIP. Par contre, si c’est le format du document ou les logiciels associés qui posent problème, on aura des migrations plus musclées qui modifient la structure même de l’AIP et rendent nécessaire la gestion de versions d’AIP.
Dans l’émulation, on ne touche pas à l’AIP mais on s’efforce de conserver ou reproduire les conditions d’accès au document, de la manière la plus proche possible de ce qu’étaient les conditions de consultation à l’origine. C’est le mode qu’on utilise de préférence pour les documents dans des formats propriétaires et les documents qui ont des comportements très spécifiques, comme les jeux vidéos par exemple.

Et après ?

Maintenant qu’on sait tout cela, et qu’on a acquis la vision d’ensemble des problématiques de conservation des données numériques, ainsi qu’un début de solution pour mettre en œuvre un système d’archivage, yapuka… définir quel sera le stockage, quels seront les formats acceptés dans les paquets, les formats de métadonnées utilisés, les relations avec les producteurs, les services d’accès et de recherche, définir et acquérir ou développer des logiciels qui remplissent toutes ces fonctions, et surveiller de très près son archive, une fois qu’elle est bien remplie, pour s’assurer que les migrations et les émulations sont effectuées à temps. Car dans le domaine numérique, toute conservation est nécessairement préventive : quand on s’aperçoit qu’un document a été altéré, il est généralement trop tard pour faire quoi que ce soit.
Le modèle OAIS ne donne pas de clefs pour mettre tout ceci en œuvre et c’est sans doute la principale difficulté : comment passer de l’abstraction à l’application. En attendant qu’on nous propose des logiciels de type « MyOAIS » clef en main, il est probable qu’on devra s’en remettre, le plus souvent, à des archives centralisées ou à des tiers archiveurs privés. Ces derniers, pour prouver que le modèle OAIS n’est pas pour eux qu’une belle parole, devront sans doute obtenir un niveau de certification officiel et international. C’est pour demain.

Source : le modèle OAIS en français.

PS : Les documents protégés par des DRM ne pourront être, ni migrés, ni émulés. La loi interdisant (prochainement) de créer des logiciels qui retirent ces protections techniques, ainsi que des logiciels qui les ignorent ou les contournent, aucune solution ne pourra être apportée à leur conservation au-delà de la durée de vie de leur support ou de leur environnement matériel et logiciel. Si leurs producteurs ne font pas l’effort de confier à une archive OAIS une version débloquée et documentée (un SIP, quoi), ils seront perdus à jamais. Dommage, quand même.