OAIS

Cette section traite des diverses pratiques qui ont été - ou pourraient être -utilisées pour pérenniser l'information numérique et pour préserver les services d'accès à cette information numérique. Elle reprend les concepts de modélisation fonctionnelle et de modélisation de l'information décrits dans le chapitre précédent et les applique à ces pratiques, elle étend également la terminologie pour distinguer les aspects significatifs de ces pratiques.

Perennisation de l'information

L'évolution rapide de l'industrie informatique et la nature éphémère des supports de stockage de données électroniques sont contradictoires avec l'objectif majeur d'un OAIS : pérenniser l'information. Quel que soit le niveau de qualité avec lequel un OAIS maintient ses collections courantes, il sera certainement nécessaire d'en migrer un grand nombre vers des supports différents et/ou vers d'autres plates-formes logicielles et matérielles pour en préserver l'accès. Les supports de données numériques actuels ne se conservent pas plus de quelques dizaines d'années avant que la probabilité d'une perte irréversible de données ne se concrétise. De plus, le rythme rapide de l'évolution technologique accroît le poids financier de nombreux systèmes après seulement quelques années d’existence.

La Migration numérique est définie comme le transfert d'information numérique au sein d’un OAIS dans une optique de conservation. Elle se distingue des transferts, dans leur acception générale, par trois caractéristiques :

un objectif de conservation de l’intégralité des contenus d'information,
la perspective dans laquelle la nouvelle implémentation du système d’archivage de l'information se substituera à l'ancienne,
le pilotage et la responsabilité de tous les aspects du transfert comme parties intégrantes de l'OAIS.

Les facteurs declencheurs de la migration numérique

Trois facteurs majeurs peuvent conduire à une Migration numérique d'AIP au sein d’un OAIS. Ce sont :

-Une meilleure rentabilité : l'évolution rapide des matériels (lecteurs de disques et de bandes par exemple) et des logiciels permet un accroissement considérable des capacités de stockage et de transfert pour des coûts de plus en plus faibles. Cette évolution conduit aussi à une obsolescence de certains types de supports, bien avant qu'ils ne se dégradent. De plus, l’amélioration des empaquetages d’AIP peut induire une dépendance moindre de ces AIP vis-à-vis des supports et systèmes sous-jacents, ce qui simplifie les efforts de migration. Pour rester rentable, un OAIS doit s'appuyer sur ces technologies. Selon les technologies mises en œuvre, l'information d'AIP pourra être déplacée vers de nouveaux types de supports non pris en compte initialement et il peut s’avérer nécessaire de revoir l'implémentation de l'AIP pour en tirer parti.

-Nouvelles exigences de service à l'Utilisateur : les Utilisateurs d'un OAIS tirent aussi bénéfice des nouvelles technologies, de sorte que les types et niveaux de service qu'ils attendent d'un OAIS ne font que croître. Ces services étendus peuvent nécessiter de nouvelles formes de DIP pour servir certaines Communautés d'utilisateurs cibles, ce qui en retour peut conduire un OAIS à détenir de nouvelles formes d'AIP permettant de réduire les conversions en sortie. De plus, les AIP subissent généralement les effets de modes et l'OAIS peut devoir fournir des prestations d'accès de niveaux différents pour satisfaire à l’évolution des demandes d'Utilisateurs. Le transfert des AIP vers des supports différents offrant des accès plus ou moins performants est probablement un moyen d’y parvenir. En fin de compte, la Communauté d’utilisateurs cible pour un AIP donné peut s’élargir, avec pour conséquence la nécessité de réviser les formes de l’AIP de façon à ce qu'il soit compréhensible et utilisable par cette communauté élargie. Tout cela peut conduire à la migration d'AIP au sein d’un OAIS.

-Dégradation des supports : les supports numériques, au fil du temps, deviennent de moins en moins fiables en termes de sûreté de conservation des bits. Même ceux qui sont dotés de certains niveaux de corrections d'erreurs peuvent être à remplacer. Le résultat final de la dégradation des supports est que l'information d'AIP doit être transférée vers un nouveau support.

Les Migrations numériques prennent du temps, sont coûteuses et exposent l'OAIS à une augmentation des risques de perte d'information. C'est pourquoi un OAIS se doit de prendre en considération les problèmes de Migrations numériques et leurs différentes approches.

Contexte de migration

Les concepts clés du modèle fonctionnel et du modèle d’information sont résumés dans le chapitre précédent.

L'interface Utilisateur de l'OAIS de l'Entité « Accès » fournit un ou plusieurs identificateurs de Contenu d’information, avec les espaces de nommage associés, pour faciliter l'identification de l’Objet-contenu d’information intéressant. Un ou plusieurs de ces identificateurs du Contenu d’information sont inclus dans l'Information d'identification du PDI associé à cet Objet-contenu d’information. Dans l’Entité « Gestion de Données », l'Information de description relie chacun de ces identificateurs à l’identificateur d'AIP correspondant. L’Entité « Accès » utilise cette information pour obtenir l'identificateur de l'AIP et le transmettre à l’Entité « Stockage » afin de récupérer l'AIP associé.

Dans l’Entité « Stockage », l'identificateur d'AIP est relié à la localisation de l'Information d’empaquetage de l'AIP par le système de mise en correspondance de l’Entité « Stockage ». L'Information d’empaquetage de l'AIP, à son tour, délimite et identifie logiquement le Contenu d’information et le PDI, et les associe en une entité unique pour la conservation. Par exemple, supposons que le Contenu d’information et le PDI sont définis comme le contenu de plusieurs fichiers, les pointeurs vers les documents décrivant les représentations de ces fichiers, et les documents eux-mêmes. Dans ce cas, l’Information d’empaquetage serait logiquement définie comme l’ensemble incluant : la référence au système de fichiers qui gère les trains de bits, la structure de données comprenant les pointeurs, l'information utilisée pour distinguer le Contenu d’information du PDI, et une structure de données englobante qui identifie les fichiers et autres structures de données telles que les composantes du Paquet d’informations archivé. Le système de mise en correspondance de l’Entité « Stockage » pourrait alors être implémenté en tant que base de données reliant l’identificateur de l’AIP à la localisation de la structure de données englobante.

Le transfert d'une partie quelconque du Contenu d’information, du PDI ou de l'Information d’empaquetage vers le même support ou un nouveau support, dans le but de remplacer cette partie de l’AIP précédent, est considéré comme une Migration numérique de l'AIP. A noter qu'un simple changement dans l'information de correspondance de l’Entité « Stockage », qui est extérieur au concept d'AIP, n'est pas considéré comme une migration de cet AIP, même si de tels changements doivent être soigneusement contrôlés pour s’assurer que l'accès à l'AIP est préservé.

Les modalités selon lesquelles les AIP sont implémentés auront une influence déterminante à la fois sur le niveau d'automatisation et sur la probabilité de perte d'information au cours des migrations. De bonnes conceptions d'AIP peuvent à la fois accroître l'automatisation de la migration et réduire les probabilités de perte d'information. Pour mieux apprécier les impacts de ces facteurs sur la migration d'AIP il est utile de catégoriser les migrations en différents types et d’étudier les problèmes liés à chacune des approches retenues.

Types de migrations

A partir des modèles et concepts ci-dessus, il est possible d'identifier quatre principaux types de Migration numérique classés ci-dessous par ordre croissant de risque de perte d'information :

Rafraîchissement de support : Migration numérique dans laquelle un support, contenant un ou plusieurs AIP ou des parties d'AIP, est remplacé par un support du même type par copie bit à bit, support qui sera utilisé pour contenir les AIP. Au final, l'infrastructure de mise en correspondance de l’Entité « Stockage » est toujours en mesure -sans modifications - de localiser et de donner accès à l'AIP.
Duplication : Migration numérique dans laquelle il n'y a de changement ni dans l'Information d’empaquetage, ni dans le Contenu d'information, ni dans le PDI. Les bits représentant ces Objets-information sont conservés dans le transfert vers un support de même type ou vers un autre support. A noter que le Rafraîchissement est aussi une Duplication, mais une Duplication peut nécessiter des changements dans l'infrastructure de mise en correspondance de l’Entité « Stockage ».
Ré-empaquetage : Migration numérique qui produit quelques changements de bits de l'Information d’empaquetage.
Transformation: Migration numérique qui produit quelques changements dans les bits du Contenu d’information ou du PDI mais vise à conserver l'intégralité du Contenu d'information.

Le Rafraîchissement de support présente le plus faible risque de perte d'information puisque aucun des bits utilisés pour contenir l'information d'AIP ou pour permettre la recherche d’AIP et leur accès n'est modifié. Il y a également peu de risque de perte d'information dans le cas de la Duplication, puisque aucun des bits représentant l'information d’AIP n'a changé. Cependant, si on utilise un nouveau type de support, il sera nécessaire d'apporter quelques modifications à l'infrastructure de mise en correspondance de l’Entité « Stockage ». Des modifications inattendues des bits risquent d’apparaître à la suite d'une anomalie au cours de l’opération. Le Ré-empaquetage admet quelques changements de bits, mais ils sont circonscrits à l'information utilisée pour délimiter le Contenu d’information et le PDI, de sorte qu’ils n'altèrent généralement pas l'information portée par le Contenu d’information ou le PDI. Il subsiste toujours un risque d’anomalie ou d’erreur, et il est parfois impossible d’éviter des interactions entre l’Information d’empaquetage, le Contenu d’information ou le PDI. Cela accroît les risques de perte d'information. Finalement, c’est la Transformation qui présente le plus de risques à cause des modifications apportées au Contenu d’information ou au PDI.

Pour comprendre plus clairement les enjeux de ces types de migrations, il est nécessaire d’étudier les différentes implémentations possibles. On verra que certaines migrations sont dans la pratique un mixte de Ré-empaquetage et de Transformation. Il est également important de rappeler que, pour tout AIP, l'OAIS doit en premier lieu identifier ce qui constitue le Contenu d’information ; ce n’est qu’ensuite que le PDI peut être identifié, et puis ensuite l’Information d’empaquetage. En fait, il n'existe pas de définition « correcte » unique de ce que doit être le Contenu d’information dans la mesure où c’est à l'OAIS de le définir pour chaque AIP élaboré et archivé. Tous ces points sont abordés en détail dans les soussections qui suivent, à travers une série de scénarios d'implémentation et de migration.

Rafraîchissement de support

Une migration est un Rafraîchissement de support quand elle a pour effet de remplacer un support par une copie suffisamment exacte pour que tout le matériel et les logiciels de l’Entité « Stockage » continuent à fonctionner comme précédemment. Considérons le scénario suivant :

Le taux d'erreurs de bits à corriger sur un CD-ROM a atteint un seuil dangereux et on décide de lui substituer une copie exacte. Une fois la vérification de conformité effectuée, le nouveau CD-ROM remplace l'ancien et le Rafraîchissement de support est opéré. Les composants de l'AIP sur le CD-ROM restent inchangés.

Duplication

Une migration est une Duplication s’il n’y a pas de modification des bits de l'Information d’empaquetage, ni du Contenu d’information, ni du PDI. Selon l'implémentation, vérifier qu'aucun de ces bits n'a été modifié peut représenter une tâche importante. Considérons le scénario suivant :

Le Contenu d’information et le PDI pour un AIP sont encapsulés dans une structure d'empaquetage standard, contenue dans un seul fichier. Il est facile d’effectuer une migration de type Duplication par simple copie de la séquence de bits du fichier vers un nouveau fichier, sur le même support ou un autre. Le besoin de localisation du fichier peut nécessiter des modifications de l'infrastructure de mise en correspondance de l’Entité « Stockage », mais aucune modification de l’Information d’empaquetage, ni du Contenu d’information, ni du PDI n'est intervenue. La Duplication, avec ce type d'Information d’empaquetage, facilite la migration vers de nouveaux types de support avec une automatisation maximum et un faible risque de perte d'information.

Ré-empaquetage

Une migration est un Ré-empaquetage si le transfert s’accompagne de certaines modifications de l'Information d’empaquetage. L'Information d’empaquetage joue a minima un rôle critique pour délimiter et relier le Contenu d’information et le PDI. Si le Contenu d’information et le PDI sont eux-mêmes constitués de multiples composants, on peut demander à l'Information d’empaquetage de les délimiter et de les relier également. Ce sont des choix d’implémentation que l'OAIS doit explicitement reconnaître. Considérons le scénario suivant :

Tous les bits du Contenu d’information et du PDI pour un AIP sont contenus dans trois fichiers sur un CD-ROM. L’Information d’empaquetage est constituée par les bits utilisés pour implémenter la structure de fichiers et de répertoires qui donne accès à ces trois fichiers. Le contenu des trois fichiers est déplacé vers trois nouveaux fichiers sur un autre type de support, avec une nouvelle organisation de répertoires et de fichiers. Même si tous les noms de répertoires et de fichiers ont été préservés au cours du transfert, un Ré-empaquetage a bien eu lieu puisque les bits représentant l’Information d’empaquetage ont été modifiés.

Transformation

Les migrations Numériques qui requièrent certaines modifications du Contenu d’information ou de la PDI sont appelées Transformations. Ces modifications concerneront certains bits de l'Objet-contenu de données du Contenu d’information ou du PDI ainsi que les modifications correspondantes dans l’Information de représentation associée. Dans tous les cas, l’objectif est d’obtenir une conservation maximale de l’information. L’AIP résultant est censé remplacer totalement l’AIP qui est l’objet de la Transformation. Le nouvel AIP se définit comme une nouvelle Version du précédent AIP. La première Version de l’AIP est désignée comme AIP d’origine et peut être gardée en vue d’un contrôle de la conservation.

L’Information de représentation joue un rôle clé dans les Transformations, et les conséquences des modifications sur l’Information de représentation peuvent être utilisées pour définir les catégories de ces Transformations. Un Objet-information de représentation peut être modélisé comme étant constitué d’un ensemble élémentaire d’entités, un ensemble d’entités résultantes, et des règles de mise en correspondance, qui définissent les entités résultantes ainsi que leurs relations avec les entités élémentaires. Partant de ce modèle d’Objet-information de représentation, deux types de Transformations peuvent être définis : la Transformation réversible et la Transformation irréversible.

On parle d’une Transformation réversible quand la nouvelle représentation définit un ensemble (ou un sous-ensemble) d’entités résultantes équivalentes aux entités résultantes définies par la représentation d’origine. Ceci implique qu’il y ait une correspondance univoque vers la représentation d’origine et ses ensembles d’entités de base. On peut prendre pour exemple le remplacement d’une représentation qui utilise le jeu de caractères ASCII par une représentation utilisant le jeu de caractères UNICODE UTF-16. La Transformation va consister en un remplacement du codage sur 7-bits par un codage sur 16-bits dans l’objet AIP qui est l’objet du changement. La Transformation inverse peut ultérieurement être réalisée par le remplacement du jeu de caractères UNICODE UTF-16 par le jeu de caractères ASCII, et l'AIP d'origine est restauré.

On parle d’une Transformation irréversible quand on ne peut pas garantir que la transformation soit réversible. Par exemple, le remplacement d’un nombre représenté en virgule flottante IBM 7094 par un nombre représenté en virgule flottante IEEE constitue une Transformation irréversible, parce que les entités résultantes de ces deux représentations ne sont pas identiques. L’une est plus précise que l’autre. Cependant, elles peuvent être suffisamment équivalentes, selon l’usage qui est fait des valeurs qu’elles représentent, pour être effectivement interchangeables. Dans ce cas, une Transformation irréversible préserve effectivement le contenu de l’information. Pour des formats complexes, dans lesquels la définition des groupes et les relations entre groupes ont une signification, il peut être difficile d’affirmer qu’une Transformation irréversible a préservé convenablement le Contenu d’information. Des exemples de Transformations réversibles et irréversibles sont donnés dans les scénarios ci-après.

Le scénario suivant montre une Transformation réversible qui se produit lorsqu’on introduit une fonction de compression sans perte dans le Contenu d’information d’un AIP.

Tous les bits du Contenu d’information pour un AIP sont contenus dans trois fichiers sur un CD-ROM. L’Information d’empaquetage inclut les bits utilisés pour implémenter la structure de fichiers et de répertoires qui donne accès à ces trois fichiers. Les contenus des trois fichiers sont transférés vers un nouveau CD-ROM et sont compressés durant le processus avec un algorithme de compression sans perte. Ce transfert est une Transformation puisque la compression a modifié le Contenu d’information, et il s’agit d’une Transformation réversible parce qu’il existe un algorithme de décompression qui rétablira le contenu en bits du fichier d’origine. Les composantes utiles de l’Information de représentation du Contenu d’information d’origine doivent être mises à jour pour inclure l’algorithme de décompression, et l’information de la PDI doit être également mise à jour pour constituer la nouvelle Version de l’AIP.

Le scénario suivant montre une Transformation irréversible qui peut se produire quand le Contenu d’information a migré vers un nouveau format qui a la capacité d’exprimer un modèle de données plus diversifié que le format d’origine.

Tous les bits du Contenu d’information d’un AIP sont rassemblés dans trois fichiers sur un CD-ROM. L’Information d’empaquetage inclut les bits utilisés pour implémenter la structure de fichiers et de répertoires qui donne accès à ces trois fichiers. Les contenus des trois fichiers sont transférés vers un nouveau CD-ROM. Au cours du processus le troisième fichier est modifié parce qu’il n’existe plus d’outils disponibles permettant d’utiliser le contenu de ce fichier dans son format actuel. Le nouveau format, qui est communément utilisé, s’appuie sur un modèle de données différent de celui du format d’origine et il existe plusieurs façons de mettre l’information en correspondance dans le nouveau format. Cette mise en correspondance doit être réalisée soigneusement pour s’assurer qu’il n’y a pas de perte significative d’information pour la Communauté d’utilisateurs cible. La correspondance doit figurer dans le PDI et, bien entendu, l’Information de représentation décrivant le nouveau format va se substituer à celle du précédent format. Il en résulte une nouvelle Version de l’AIP. Il s’agit d’une migration de type Transformation qui constitue également une Transformation irréversible parce qu’il n’existe pas d’algorithme de restauration du fichier d’origine.

Le scénario suivant montre une Transformation réversible comprenant un Ré-empaquetage. C’est le cas lorsque le Contenu d’information contient un nom de fichier utilisé comme pointeur vers l’un de ses composants, et que ce Contenu d’information est transféré vers un nouveau type de support avec changement des noms des fichiers.

Le Contenu d’information d’un AIP est défini par le corps de trois fichiers sur un CDROM. Le premier de ces fichiers contient un nom interne qui le lie au troisième fichier et qui spécifie leur relation. L’Information d’empaquetage comprend la structure de répertoires et de fichiers permettant d’identifier ces trois fichiers. Au cours d’une migration vers un nouveau type de support, ces trois fichiers sont mis dans un nouveau répertoire et on leur donne de nouveaux noms. Ceci constitue une migration de type Ré-empaquetage parce qu’il s’agit d’une nouvelle implémentation de la structure de répertoires et de fichiers, qui remplit la fonction d’empaquetage. Cependant, le nom interne doit être également être mis à jour pour maintenir le lien entre le premier et le troisième fichier. Cette mise à jour modifie le Contenu d’information et signifie que la migration est également une Transformation. Si le nom interne avait été un identificateur universel, il n’aurait pas été nécessaire de le changer. Cependant, le cadre standardisé qui définit l’identificateur universel aurait inclus l’information de mise en correspondance conduisant à la localisation du troisième fichier et aurait par conséquent nécessité une mise à jour. Cette approche est avantageuse pour un OAIS parce qu’elle permet des mises à jour centralisées et plus facilement gérées. Cependant, la technologie mise en jeu est plus complexe et il n’existe pas de consensus sur la technique d’identification à employer.

Ce dernier scénario montre une Transformation irréversible comprenant un Ré-empaquetage. C’est le cas lorsque le Contenu d’information inclut des noms de fichiers, une structure de répertoires, et des attributs de fichiers associés. Le Contenu d’information est alors migré vers un nouveau type de support admettant une implémentation différente des structures de répertoires et de fichiers qui acceptent moins d’attributs.

Les bits du Contenu d’information et du PDI d’un AIC sont définis comme une agrégation d’AIU dans laquelle chaque AIU est constitué de trois fichiers sur un CDROM, de leurs noms de fichiers, des attributs de fichiers et des noms de répertoires. L’Information d’empaquetage se compose des bits utilisés pour implémenter la structure de fichiers et de répertoires qui donne accès à chacune des instances des trois fichiers, mais elle n’inclut pas les noms réels de répertoires et de fichiers. Il est possible de trouver des milliers d’AIU sur un seul CD-ROM. Le transfert de cet AIC vers un nouveau type de support qui utilise une nouvelle représentation de structure de fichiers et de répertoires acceptant moins d’attributs de fichier peut conduire à une Transformation irréversible aussi bien qu’à une migration de type Ré-empaquetage. Il s’agit d’une Transformation parce que le Contenu d’information stocké à l’origine dans les structures de fichiers et de répertoires doit être redistribué dans les nouvelles structures de fichiers et de répertoires et probablement dans les fichiers eux-mêmes. Il s’agit d’une Transformation irréversible s’il n’existe pas de mise en correspondance algorithmique terme à terme entre, d’une part, les structures de fichiers et de répertoires et les contenus de fichiers résultants, et d’autre part, ceux d’origine. Il s’agit d’un Réempaquetage car on a affaire à une nouvelle implémentation de la structure de répertoires et de fichiers, laquelle constituait un sous-ensemble de l’Information d’empaquetage. La pratique qui consiste à encoder le Contenu d’information dans un nom de fichier ou de répertoire augmente le risque de perte d’information parce que l’évolution d’un environnement de gestion de données est facilitée par la possibilité de mise à jour des noms de fichiers et de répertoires selon les besoins.

Distinctions entre versions d'AIP, Editions et AIP dérivés

A moins qu’une Migration numérique n’implique une Transformation, il n’est ni envisagé de créer une nouvelle Version d’AIP, ni nécessaire de mettre à jour son PDI. En d’autres termes, la Version d’AIP est considérée comme indépendante du Rafraîchissement, de la Duplication, et du Ré-empaquetage qui n’affectent pas le Contenu d’information ou le PDI. Ce qui ne signifie pas que l’OAIS ne garde pas trace de telles migrations, mais simplement qu’il n’est pas nécessaire de les tracer dans le PDI. Si ce processus est mené entièrement à l’intérieur de l’Entité « Stockage », l’identificateur d’AIP reste le même et il n’y a pas de conséquence sur les Notices descriptives ou les Outils d’accès.

Une Migration numérique qui entraîne une Transformation aboutit à une nouvelle Version de l’AIP comme cela est défini au 5.1.3.4. Dans ce cas, le PDI doit être mis à jour pour identifier l’AIP source et sa Version, et pour tracer ce qui a été fait et pourquoi. Le nouvel AIP est vu comme un remplaçant de l’AIP source dans lequel l’information a été conservée au mieux. L’identificateur d’AIP est également nouveau et la Notice descriptive doit être mise à jour. Ce qui n’implique pas que des modifications soient nécessaires dans les Outils d’accès sauf s’ils ont été implémentés avec des identificateurs d’AIP codés en dur.

Un AIP peut, dans certains environnements, être sujet à des mises à niveau ou améliorations dans le temps. Il ne s’agit pas d’une Migration numérique en ce sens que l’objectif n’est pas de conserver l’information, mais de l’enrichir ou de l’améliorer. Ce type de modification d’AIP peut être défini comme la création d’une nouvelle Edition. La nouvelle Edition est vue comme le remplacement de la précédente Edition, mais il peut être utile, à titre historique, de conserver la précédente Édition. Il en résulte également un nouvel identificateur d’AIP avec les mêmes conséquences sur les Notices descriptives et les Outils d’accès qu’une Migration numérique par Transformation.

Un OAIS peut aussi trouver avantage à fournir un AIP dérivé d’un AIP existant. Cela est possible par extraction de certaines informations ou par agrégation d’informations à partir de plusieurs AIP, afin de mieux servir les Utilisateurs. Ce type d’AIP résultant peut être désigné comme AIP dérivé. Il ne remplace aucun des AIP dont il est issu et ne constitue pas le résultat d’une Migration numérique. Il en découle également un nouvel identificateur d’AIP et de nouvelles Notices descriptives. Il se peut que cela requière de nouveaux Outils d’accès ou leur mise à jour, selon le type d’implémentation.

Préservation des services d'accès

Il peut être souhaitable pour un OAIS de conserver les services d’accès d’un Utilisateur face aux changements technologiques. Cette sous-section présente un ensemble de scénarios afin de cerner les problèmes relatifs à la conservation des services d’accès et de définir une terminologie.

API de diffusion

Le premier scénario suppose que la Communauté d’utilisateurs cible souhaite développer des applications qui permettent l’accès aux AIP en utilisant une Interface Programmatique (Application Programming Interface - API) maintenue par l’OAIS en tant que Logiciel d’accès. L’OAIS peut choisir de fournir cette API comme une implémentation alternative à la production et à la livraison d’un DIP physique pour la diffusion. Ce type de service autorise l’Utilisateur, en tant que client, à développer des applications qui permettent d’accéder directement aux AIP. Ce type d’accès pourrait être très utile pour des applications telles que la fouille de données, peu adaptées à la création et l’envoi de DIP contenant de grands AIC. Cette API pourrait permettre à une application de naviguer virtuellement dans un AIC, de fournir à l’application les bits d’un Objet-contenu de données pour les AIU sélectionnés et d’identifier leurs localisations afin d’obtenir l’Information de représentation associée et les PDI. Cependant, du fait de l’évolution de la technologie, l’OAIS est porté sur de nouveaux matériels, supports et systèmes d’exploitation. Si l’OAIS entend maintenir la même API pour ses Utilisateurs, il sera nécessaire de fournir une surcouche autour d’une partie de sa nouvelle infrastructure pour mettre ses services en conformité avec l’API en place. Cette API devra être documentée de manière appropriée et testée pour s’assurer qu’elle délivre correctement le Contenu d’information de l’AIU utilisant ce nouveau Logiciel d’accès. Cette approche ne devrait pas entraîner de modifications pour les logiciels développés par la communauté des Utilisateurs. Quand l’API est applicable à une grande quantité d’AIU de l’OAIS ou qu’il y a un nombre significatif d’applications d’Utilisateurs basées sur l’API, cette approche en couche est clairement réalisable et peut engendrer un rapport coût/bénéfice favorable pour l’OAIS et sa Communauté d'utilisateurs cible. Le « Modèle d'Information en couche » présenté en Annexe C de ce document décrit plus en détail quelques API potentiellement standard.

Conservation du "LOOK AND FEEL" du logiciel d'accès

Le deuxième scénario suppose que la Communauté d'utilisateurs cible souhaite conserver le « look and feel » d’origine du Contenu d’information d'un ensemble d'AIU tel qu’il se présente dans une application spécifique ou un ensemble d'applications. Conceptuellement, l'OAIS fournit un environnement qui permet à l'Utilisateur de visualiser le Contenu d’information d'AIU via les possibilités de transformation et de présentation de l'application. Par exemple, on peut vouloir utiliser une application spécifique qui extrait des données d'un CD-ROM ISO 9660 et les présente comme une image multi-spectrale. Cette application fonctionne sous un système d'exploitation particulier ; elle nécessite un ensemble d'informations de contrôle, requiert l'utilisation d'un lecteur de CD-ROM et transfère l'information au pilote d'un périphérique d'affichage spécifique. Dans certains cas, cette application peut offrir à tous les membres de la Communauté d'utilisateurs cible un accès en profondeur à l'environnement et l'OAIS se contente alors de désigner l'Objet-contenu de données comme le train de bits utilisé par l'application. Dans d’autres cas, si ce type d’environnement est moins facile d’accès, l’OAIS peut le fournir via le Logiciel d’accès. Cependant, lorsque l'OAIS et/ou la Communauté d'utilisateurs cible migrent vers de nouveaux environnements informatiques, l'application finira par ne plus fonctionner ou ne fonctionnera pas correctement.

La réponse de l’OAIS pour conserver un Logiciel d’accès dépendra probablement, en grande partie, du fait qu'il possède, ou qu’il puisse obtenir ou non, le code source du logiciel.

Méthodologies impliquant la disponibilité du code source

La réponse de l’OAIS pour conserver un service mettant en œuvre un Logiciel d’accès dépendra probablement, en partie, du fait qu’il dispose ou non du code source du logiciel. Si l’OAIS dispose du code source et de la documentation adéquate du logiciel, l’approche probable sera de porter ce logiciel vers le nouvel environnement et d’essayer de le valider suffisamment pour s’assurer qu’il fonctionne correctement., cette validation peut ne pas être évidente lorsque le logiciel tourne mais ne fonctionne pas correctement. Idéalement toutes les données de sortie doivent avoir été relevées au départ pour être utilisées comme référence afin de contrôler que le fonctionnement est correct après portage. Cependant, ce niveau de test risque d’entraîner un rapport coût/bénéfice inacceptable pour l’OAIS. Du fait que l’application a été compilée à partir du code source d’origine, les algorithmes sont supposés corrects. Il est alors probablement suffisant de réaliser une batterie de tests ou de réutiliser celle fournie dans la documentation de conception.

Si le Logiciel d’accès est un ensemble propriétaire, largement utilisé et disponible sur le marché, il est probable qu’il existe une passerelle logicielle commercialisée (c’est-à-dire la conversion) qui transforme les Objets-contenu de données courants en d’autres formes utilisées par le nouveau Logiciel d’accès ayant un « look and feel » semblable. Si on ne trouve aucune alternative commerciale, l’OAIS peut passer un accord avec le propriétaire du Logiciel d’accès d’origine pour développer et fournir le code source d’un outil simplifié pouvant lire -sans les modifier -les instances de données écrites avec ce format. Cette approche peut ne pas être viable pour des raisons de coûts ou de problèmes juridiques. Dans tous les cas, l’OAIS devra mettre en place les mécanismes pour vérifier qu’aucune information conservée n’a été perdue. Des critères doivent avoir été établis pour définir clairement ce qui constitue le Contenu d’information. De plus, l’OAIS doit s’assurer que le nouveau Logiciel d’accès est disponible pour la Communauté d’utilisateurs cible.

Approches potentielles d'émulation

Il se peut que la Communauté d'utilisateurs cible impose de maintenir le « look and feel » d'un Logiciel d’accès propriétaire, en raison du grand nombre d'AIU qui en dépendent. Dans ce cas, si l'OAIS est dans l'impossibilité d'obtenir le code source, il lui faudra envisager d'explorer une approche d'émulation.

L'OAIS peut étudier l'émulation du logiciel. Si le logiciel fournit un jeu bien connu de commandes et une API bien définie pour l'accès, l'API pourra être documentée et évaluée de façon appropriée pour tenter une émulation du logiciel. Cependant, si l'interface Utilisateur consiste surtout en un affichage ou d’autres dispositifs périphériques faisant appel aux sens humains (par exemple, le son), cette rétro-ingénierie est quasiment impossible. Comme décrit en 4.2, cela peut ne pas être évident lorsque le logiciel tourne mais qu'il ne fonctionne pas correctement. Pour prévenir de telles situations, il est nécessaire de sauvegarder les sorties du Logiciel d’accès obtenues dans un fonctionnement correct, ainsi que l'Information de représentation adéquate et le PDI, afin que toute cette information soit conservée. L'ensemble doit être confronté aux résultats obtenus après la migration dans un nouvel environnement. Cela peut s'avérer délicat si le logiciel a plusieurs modes de fonctionnement. De plus, si les sorties du logiciel sont principalement dirigées vers un périphérique d'affichage, l'enregistrement de ce flux ne garantit nullement que l'affichage sera le même dans le nouvel environnement et, par conséquent, il se peut que la combinaison du logiciel et de l'environnement ne restitue plus une information totalement correcte à l'Utilisateur. Le maintien d'un « look and feel » cohérent peut requérir en premier lieu de l’enregistrer séparément pour l’utiliser en tant qu'information de validation.

Une autre approche est l'émulation de la plate-forme matérielle. L'avantage de cette émulation réside dans l’assurance que lorsqu’une plate-forme matérielle a été émulée avec succès, tous les systèmes d'exploitation et les applications qui ont tourné sur la plate-forme d’origine peuvent être basculés sans modification sur la nouvelle. Cependant, cela ne tient pas compte des contraintes liées aux périphériques d’entrée/sortie. L’émulation rencontre beaucoup de succès lorsqu'un système d'exploitation très répandu doit tourner sur un matériel pour lequel il n'a pas été conçu, comme une version de Windows ™ sur un Apple ™. Cependant, même dans ce cas, lorsque les tendances fortes du marché favorisent cette approche, les applications ne tournent ou ne s'exécutent pas forcément correctement dans l'environnement émulé. Par exemple, il peut s'avérer impossible de simuler entièrement toutes les dépendances et contraintes de temps de matériels anciens, en raison des contraintes imposées par le nouvel environnement matériel. Par ailleurs, quand l'application présente l'information à une interface humaine, il est délicat de déterminer si le nouveau périphérique présente encore l'information correctement ; cela incite à prévoir un enregistrement séparé de la présentation de l'information pour la validation. Une fois le principe de l'émulation adopté, le système résultant est particulièrement sensible à des erreurs de logiciel inconnues jusqu'alors et qui peuvent sérieusement mettre en danger l'accès continu à l'information. Au vu de ces contraintes, les obstacles techniques et économiques à l'émulation de matériel ne sont pas négligeables.

Des recherches sur des approches d'émulation alternatives ont été faites, par exemple, le développement d'une architecture de machine virtuelle ou l'émulation au niveau du système d'exploitation. Ces approches résolvent certains des problèmes posés par l'émulation matérielle, mais soulèvent de nouvelles questions. Aucune des techniques d'émulation n'est à ce jour assez mûre pour en parler de manière significative. De plus, les travaux de recherche actuels sur l'émulation impliquent une architecture centralisée avec contrôle de tous les périphériques. Le niveau de complexité des interfaces et des interactions dans un contexte d'informatique entièrement distribuée (c'est-à-dire le WWW et JAVA) avec des clients hétérogènes peut impliquer des exigences qui vont au-delà du domaine des travaux actuels sur l'émulation.

Interopérabilité des archives

Les utilisateurs d'Archives OAIS multiples peuvent avoir des raisons de souhaiter un certain degré d'uniformisation ou de coopération entre ces Archives. Par exemple, les utilisateurs de plusieurs Archives peuvent souhaiter disposer :

d'Outils de recherche communs pour faciliter la localisation de l'information dans plusieurs Archives,
d'un schéma de Description de paquet commun pour l'accès, -d'un schéma de DIP commun pour la diffusion, ou
d'un site unique d'accès global.Les Producteurs peuvent vouloir disposer :
d'un schéma de SIP commun pour les versements à différentes Archives, ou
d'un dépôt unique pour toutes leurs productions.

Les gestionnaires peuvent vouloir disposer de solutions pour : -réduire les coûts en partageant des matériels, des logiciels et des travaux de conservation onéreux, et -accroître l’homogénéisation et la qualité des interactions entre plusieurs Archives.

Il peut donc se révéler avantageux pour des Archives de coopérer pour répondre à ces souhaits. L’initiative peut venir des Archives elles-mêmes ou d'une autorité ayant un certain poids pour pouvoir imposer cette coopération. Dans le premier cas, les motivations des Archives peuvent être diverses :

réduire les coûts,
satisfaire les Utilisateurs grâce à leurs produits,
satisfaire les Utilisateurs grâce à leur qualité de service, ou enfin
rivaliser avec d'autres Archives pour survivre ou se développer.

De telles situations peuvent avoir - et ont - motivé des accords, sans nécessiter pour autant la constitution formelle d’un Groupement d’archives instituant une autorité externe. Cependant, dans les cas où un tel groupement est mis en place, l'autorité externe est représentée dans ce Modèle de référence par le Management.

Niveaux techniques d'interaction entre archives OAIS

Les associations d’OAIS peuvent être catégorisées, au plan technique, selon des facteurs externes et internes. Les facteurs externes prennent en compte les caractéristiques des communautés de Producteurs et d'Utilisateurs.

Cette sous-section définit quatre catégories d'associations d'Archives. Les trois premières catégories correspondent à des degrés croissants d’interaction :

-Indépendantes : Archives motivées par des considérants locaux, sans interaction technique ou de gestion entre elles.

-Coopérantes : Archives qui peuvent avoir des Producteurs communs, des standards communs de versement et de diffusion, mais pas d’Outil de recherche commun.

-Groupements d’Archives : Archives ayant à la fois une Communauté locale (c'est-à-dire la Communauté d'utilisateurs cible d’origine servie par l'Archive) et une Communauté élargie (c'est-à-dire une Communauté d'utilisateurs cible étendue). Cette Communauté « élargie » est intéressée par les fonds de plusieurs Archives OAIS et a convaincu ces Archives de lui fournir un accès au travers d’un ou plusieurs Outils de recherche communs. Les besoins d'accès de la Communauté locale ont généralement priorité sur ceux de la Communauté élargie. La diffusion et les versements globaux sont des fonctionnalités optionnelles.

-Ressources Partagées : Archives qui ont passé des accords avec d'autres Archives pour partager des ressources, et éventuellement réduire les coûts. Cela impose de partager différents standards propres aux Archives (comme les interfaces entre fonctions de versement et de stockage, ou encore entre fonctions de stockage et d’accès), mais ne change pas la vision de l’Archive par la Communauté d’utilisateurs.

Archives indépendantes

Une Archive indépendante est supposée servir une seule Communauté d'utilisateurs cible. L'Archive et la Communauté d'utilisateurs cible doivent s’accorder sur la conception des SIP, DIP et des Outils de recherche. Une Archive indépendante peut choisir de concevoir ces structures à partir de standards formels ou de facto, ce qui permettrait la coopération avec d'autres Archives qui pratiquent les mêmes standards. Toutefois, les décisions d'utiliser ces standards ne sont pas dictées par la possibilité d'interopérabilité avec d'autres Archives, mais plutôt par des exigences locales et des soucis d'économie.

La qualification d'une Archive comme indépendante n'est liée ni à sa taille ni à l’existence d’une fonctionnalité distribuée. Une Archive indépendante peut occuper un site unique ou être physiquement répartie sur plusieurs sites. Elle peut utiliser plusieurs standards pour un élément interne donné. Cependant, s'il n'y a aucune interaction avec d'autres Archives, l'Archive est dite indépendante.

Archives coopérantes

Les Archives coopérantes sont fondées sur des accords de standards entre deux ou plusieurs Archives. La forme la plus simple de coopération entre Archives apparaît lorsqu'une Archive agit comme Utilisateur de données pour une autre Archive. Dans ce cas l'Archive utilisatrice doit accepter le format de DIP de l’Archive productrice comme format de SIP. Les Archives coopérantes ont des communautés d'intérêt liées, elles commandent et versent ainsi des données provenant d'autres Archives coopérantes et peuvent éventuellement avoir des Producteurs de données communs. Cela ne suppose aucun standard d’accès, de versement ou de diffusion communs. La seule condition pour cette architecture est que les groupes de coopération acceptent au moins un format commun de SIP et de DIP pour des requêtes inter-Archives. Le mécanisme mis en œuvre pour cette sorte d'interopérabilité peut consister en des Demandes d'abonnement auprès de chaque Archive.

A un niveau élémentaire d'interaction entre Archives, le schéma 6-1 représente un simple accord d'échange mutuel d'information. (Note : dans ce schéma et les suivants, l'OAIS est représenté comme un dispositif à « cinq ports » selon la configuration du schéma 6-1. Dans chaque cas, et pour plus de clarté on montre un groupement de deux Archives, bien que le concept puisse être étendu indéfiniment). L’exigence essentielle pour ce groupement est l’existence d’un ensemble de Protocoles de versement, de Demandes d'abonnement et de standards d'interface utilisateur mutuels permettant aux DIP d'une Archive d'être réceptionnés en tant que SIP par une autre. Cela suppose donc que des compatibilités réciproques soient mises en place entre Archives. En revanche, des méthodes d'accès, de diffusion et de versement communes pour tous les participants ne sont pas obligatoires, bien que cela puisse permettre plus d'échanges. Ce niveau d'accord est aussi utile quand les fonds d'une Archive ont été consolidés/transférés dans une autre Archive en raison de problèmes de Management.

Groupements d'archives

Un Groupement d’archives est conceptuellement orienté Utilisateur. En plus de la Communauté locale (c'est-à-dire, la Communauté d'utilisateurs cible d'origine servie par l'Archive), il existe une Communauté élargie (c'est-à-dire, une Communauté d'utilisateurs cible étendue) qui est intéressée par les fonds de plusieurs Archives OAIS et les a convaincues de donner accès à leurs collections au travers d’un ou de plusieurs Outils de recherche communs. Cependant, les Utilisateurs locaux ont probablement la priorité d'accès sur ceux de la Communauté élargie.

Au niveau du Groupement, des éléments externes peuvent être introduits pour améliorer l’interopérabilité. Par exemple, le schéma 6-3 illustre une architecture fonctionnelle susceptible de résoudre le problème d’accès décrit en 6.1.2, en utilisant une entité externe aux groupements d’OAIS. Dans ce cas, deux Archives OAIS qui ont des Communautés cibles semblables ont décidé de se grouper pour permettre aux Utilisateurs de localiser les Paquets d'informations qui les intéressent dans l'un ou l'autre OAIS lors d’une Session de recherche unique. Les catalogues et le gestionnaire de données communs représentent l'élément fédérateur global externe qui sert de point d'accès commun à l'information dans les deux Archives. Des DIP contenant les Outils de recherche de chaque OAIS sont versés dans le Catalogue commun. Le catalogue commun peut limiter son activité à servir d’Outil de recherche ; il peut aussi inclure la diffusion commune de produits de l'un ou l'autre des deux OAIS, comme indiqué par les tirets dans le schéma.

Les Groupements d’archives peuvent se subdiviser selon trois niveaux de fonctionnalité :

Site central : l'accès global est réalisé par l'export d'une Notice descriptive selon un format standard vers un site global. Le site global gère indépendamment un ensemble de descripteurs de plusieurs Archives et possède des Outils de recherche pour localiser quelles Archives disposent d’une collection intéressante. On donne à l'Utilisateur une vue synthétique des fonds de plusieurs sites, maintenue de manière centralisée. Pour prendre connaissance des détails relatifs aux documents archivés, l'Utilisateur doit accéder au site qui détient le document réel. Cela est plus facile quand les sites et les clients acceptent un jeu standard de protocoles.
Outil de recherche distribué : l'accès global est réalisé par la mise en œuvre d'un nœud global qui peut distribuer une requête aux diverses Archives locales. Cela signifie que l'Entité « Gestion de données » locale doit stocker une Notice descriptive complémentaire dans le format global ou disposer d’un traducteur des requêtes globales vers les requêtes locales. Une option dans ce cas consiste à établir un format de DIP commun pour réduire la charge de travail des Utilisateurs susceptibles de commander des produits de plusieurs Archives.
Outil d’accès distribué : à la fonctionnalité d’Outils de recherche distribués traitée cidessus, s’ajoute dans ce cas un mécanisme standard de commande et de diffusion disponible via des nœuds globaux. C'est un système fédéré entièrement fonctionnel. Ici, le système global peut influer sur la conception du schéma de Notice descriptive dans chaque Archive locale. Il serait optimal de construire de nouvelles Archives locales fondées sur les schémas et les Outils de recherche globaux pour assurer de hauts niveaux d'interopérabilité. Il y a plusieurs questions importantes de politique et/ou de technologie qui doivent être traitées quand un OAIS rejoint un Groupement d’archives ou quand plusieurs OAIS indépendants décident de créer un tel Groupement. Ces questions comprennent :
- L’unicité des noms pour chaque AIP dans le Groupement. Un OAIS a la responsabilité d’identifier de manière unique chacun de ses AIP. Quand un OAIS rejoint un Groupement, il n'y a aucune certitude qu'un de ses identificateurs courants d'AIP n’ait pas déjà été utilisé par d'autres membres du Groupement. On peut résoudre ce problème en définissant les identificateurs d'AIP au sein du Groupement par l’attribution d’un identificateur unique à chaque OAIS du Groupement et en le concaténant à chaque identificateur original d’AIP de cet OAIS. Ce nom d'OAIS pourrait être formaté selon une norme qui donne au Client ou à d'autres membres du Groupement l'information nécessaire pour établir une connexion avec l'OAIS qui détient l'AIP considéré. Ce peut être par exemple la norme ISO X.500, nommage des Services d’annuaire.
- La duplication d'AIP dans plusieurs OAIS différents ayant des identificateurs d'AIP différents. Ce problème vient du fait qu'avant d’adhérer au Groupement, un OAIS aura fait un double du Contenu d’information d'un AIP provenant d'autres OAIS pour permettre l'accès des Utilisateurs locaux. Dans ce cas un Utilisateur global verra tous les exemplaires comme des AIP distincts mais identifiés comme uniques. L'examen détaillé du PDI associé au Contenu d’information devrait permettre à l'Utilisateur de localiser l'exemplaire original qui fait foi, mais le processus de recherche risque d’être très laborieux. On peut aussi traiter ce problème à l’aide d’un champ spécifique dans la Notice descriptive de tout AIP qui identifie s'il s'agit de l'original ou d'une copie. Ce procédé n'est pas efficace si, avant le Groupement, deux ou plusieurs Archives ont reçu le Contenu d’information du Producteur pour archivage. Dans ce cas les Groupements d’archives verraient ces AIP doublonnés comme des AIP uniques et originaux.
- Le maintien de l’accès du Groupement aux AIP quand un OAIS cesse son activité. Il arrive souvent, malheureusement, que des Archives ferment alors que leurs fonds ont encore de la valeur pour la communauté du Groupement. Il faudrait alors que le Groupement souscrive un accord avec chaque OAIS membre afin de définir quel autre OAIS aurait la responsabilité de ses fonds en cas de fermeture.
- L’authentification d'Utilisateur et la gestion d'accès pour les utilisateurs de la Communauté élargie. Si un OAIS a une politique qui limite l'accès à certains de ses AIP ou facture la diffusion de certains Paquets d'informations, alors se pose le problème d’identifier et d’authentifier l'Utilisateur qui fait des demandes via le nœud central. Chaque OAIS aura mis en œuvre un système de gestion d'accès et d’authentification pour ses Utilisateurs locaux et l'infrastructure pour cette fonction devra être étendue aux Utilisateurs de la Communauté élargie. Voici quelques exemples de techniques utilisées dans les systèmes actuels :
  - un premier niveau par défaut où tous les membres du nœud global partagent un ensemble commun de contraintes d'accès, le nœud global prend en charge toute la chaîne d’authentification et vérifie que l'Utilisateur est bien un Utilisateur légitime du nœud global. L'authentification auprès de l’OAIS membre est réalisée en présupposant que toute demande parvenant du nœud global provient d'un Utilisateur légitime.
  - l'admission d'Utilisateur par identification où l'Utilisateur distant en question peut être authentifié par tout OAIS du Groupement, le nœud global agit simplement comme un intermédiaire dans le dialogue d'identification. Ceci est assez délicat du point de vue de la sécurité au regard des technologies existantes, mais la technique de certification X.509 du WWW est prometteuse.

Il existe de nombreux critères pour décider laquelle de ces techniques devrait être utilisée par un Groupement d’Archives spécifique. Le critère majeur est la granularité des contraintes d'accès au sein du Groupement. S'il y a des données peu confidentielles et aucune facturation pour la diffusion de données, il est tout à fait raisonnable d’adopter une politique qui détermine les contraintes d'accès d'un Utilisateur à partir de la source de repérage et de commande des AIP. Cela implique peu de modifications du système OAIS d'identification : un simple ajout du nœud global comme Utilisateur. Le nœud global devra inclure des mécanismes pour identifier les Utilisateurs globaux au niveau de chacun des mécanismes d'identification des Groupements d’OAIS.

S'il y a facturation pour la diffusion de l'information archivée ou si des données privées suffisamment confidentielles nécessitent l'authentification individualisée des utilisateurs, les techniques de proxy seront insuffisantes. En ce cas, les techniques d’identification d'Utilisateur telles que mots de passe et certificats doivent être appliquées. Les technologies permettant la mise en œuvre de tels mécanismes continuent de se développer.

Archives avec des domaines fonctionnels partagés

Dans ce type d'association, le Management a passé des accords avec d’autres Archives dans le but de partager ou d’intégrer certains domaines fonctionnels. La motivation peut en être de devoir partager des ressources coûteuses comme un système de gestion hiérarchique des fichiers pour l’Entité « Stockage », un périphérique pour le versement ou la diffusion de Paquets d'informations ou enfin des super-calculateurs utilisés pour les transformations complexes entre SIP, AIP ou DIP. Cette association diffère fondamentalement des exemples précédents, en ce sens qu'on ne peut plus ignorer l'architecture interne des Archives.

Le Management des groupements d'archives

Les exemples ci-dessus montrent que le modèle OAIS est compatible avec la mise en place de groupements dans le but de satisfaire tel ou tel objectif. Cependant, on pourrait aussi considérer que certains de ces objectifs peuvent être atteints à partir d’initiatives volontaristes. Il s’agit là d’un aspect important dans l'association de systèmes, et notamment pour les Archives, parce qu'il définit le degré d'autonomie de chaque système. Au cœur de la question de l'autonomie réside la facilité avec laquelle une association peut être modifiée par l’un de ses membres. Citons quelques caractérisations possibles des niveaux d'autonomie :

pas d'interactions donc pas d'association,
les associations dont chaque membre garde sa propre autonomie. Le membre d'une telle association peut avoir à remplir certaines conditions mais il peut quitter l'association sans avertissement et sans répercussion. Un exemple est la participation à Internet, y compris comme opérateur de serveurs de noms de domaines. Tout membre devra satisfaire à certaines exigences, il devra notamment maintenir un site ayant des caractéristiques données, mais ce membre sera de fait rayé de l'association si le site en question n’est plus conforme à ces exigences. Il n'y a cependant aucune pénalité dans ce cas. Les membres restent toujours totalement autonomes, ils sont libres de leurs actions, sans pénalité particulière,
les associations où l’adhésion est contractuelle. Pour changer la nature de cette association, un membre devra renégocier son contrat. Le degré d'autonomie est fonction de la difficulté de négocier ces changements. Cette difficulté est a priori proportionnelle au nombre de membres.

Ainsi, la dimension d’autonomie est un aspect clef pour les Archives qui interagissent. Elle détermine la facilité avec laquelle chacun peut apporter des modifications à la nature de l'association ainsi que les conséquences/pénalités pour chacun s'il veut recouvrer une pleine autonomie. Cette dimension diffère du degré d'homogénéité technique que l'association met en place ou accepte, mais elle n'en est pas totalement indépendante. Par exemple, un haut niveau d'homogénéité technique peut être réalisé dans une grande association, où chaque entité participante est libre de partir sans pénalité. Mais on ne peut garantir dans ce cas la permanence d'une telle association ; cette permanence peut être améliorée en rendant la renégociation du contrat d’adhésion plus difficile ou en prévoyant des pénalités en cas de volonté de retour à une pleine autonomie. De la même manière, un niveau donné d'homogénéité technique peut être atteint plus rapidement et à moindre coût si le contrat est plus contraignant.