French 
English 
L'archivage d'une base de données ne permet pas de conserver l'application qui rendait cette base de données utile.
Le standard SIARD constitue un excellent point de départ. Il offre un format ouvert, indépendant des logiciels, permettant de préserver la structure et le contenu des bases de données relationnelles. Il réduit la dépendance vis-à-vis des formats de sauvegarde propriétaires des bases de données et, à l'aide d'outils compatibles SIARD adaptés, permet, si nécessaire, le transfert des données archivées vers une base de données relationnelle.
C'est précieux. Mais cela ne représente qu'une partie du problème lié à la mise hors service des applications.
Une fois le système d'origine mis hors service, les utilisateurs ultérieurs demandent rarement à consulter un dossier. Ils ont besoin de retrouver un dossier, de comprendre une facture, d'accéder aux documents liés à un résultat de laboratoire ou de reconstituer les éléments justifiant une décision.
Une simple exportation de base de données ne leur apporte pas cette expérience.
Ce que le SIARD conserve bien
SIARD a été conçu pour la conservation à long terme des bases de données relationnelles. Il capture le contenu de la base de données ainsi que les métadonnées structurelles dans un conteneur ZIP64, en utilisant les langages XML et XML Schema et en s'appuyant sur les normes SQL pour les identifiants et les types de données.
C'est ce qui fait de SIARD un format utile tant pour la conservation que pour la migration. Il permet aux organisations de conserver leurs données sans devoir maintenir indéfiniment le logiciel de base de données d'origine.
Les Archives fédérales suisses soulignent également une limitation importante : un fichier SIARD n'est généralement pas suffisamment explicite en soi pour garantir que les données archivées resteront interprétables. Il peut s'avérer nécessaire de conserver parallèlement à ce fichier la documentation relative au système source et au modèle de données, notamment les descriptions de données, les listes de codes, les spécifications du système, les manuels d'utilisation et les captures d'écran.
C'est là que cette distinction prend toute son importance.
SIARD préserve le contenu et la structure d'une base de données relationnelle dans les limites définies par le format. La mise hors service d'une application doit permettre de conserver les informations dont les utilisateurs ont encore besoin.
Le problème survient lorsque quelqu'un a à nouveau besoin de ces données
Une fois qu'une base de données brute a été archivée, son accès nécessite toujours une solution technique. Il faut disposer d'un outil de visualisation, d'une nouvelle interface utilisateur ou d'une base de données dans laquelle les données peuvent être chargées.
Même dans ce cas, l'utilisateur peut voir des noms de tables et de colonnes plutôt que les objets métier qui existaient dans l'application.
La couche manquante peut comprendre :
- Le lien entre une affaire et ses pièces ;
- L'en-tête, les lignes et les pièces jointes qui, ensemble, constituent une facture ;
- Les libellés, les listes de codes et les définitions nécessaires à l'interprétation des valeurs calculées ;
- Documentation des processus et des règles métier pertinents ;
- Le contexte dans lequel un résultat a été obtenu ;
- Les chemins de recherche sur lesquels les utilisateurs se fiaient ;
- Les conditions d'accès, le contexte d'audit et les règles de conservation qui doivent être maintenus.
Plus l'application source est spécialisée, plus cet écart peut s'accentuer. Les systèmes ERP, les systèmes de laboratoire et les systèmes d'instrumentation en sont des exemples évidents, mais cela vaut également pour presque toutes les solutions dotées d'un modèle de données complexe. Leurs données peuvent rester techniquement présentes tout en devenant difficiles à interpréter sans le contexte, les relations et les représentations lisibles qui les entourent.
Commencez par l'objet métier, et non par la table
Une approche plus complète de la mise hors service d'une application commence par se demander ce dont les utilisateurs auront besoin de récupérer une fois le système supprimé.
Dans le cadre d'une application financière, il peut s'agir d'une facture comprenant ses postes détaillés et ses pièces jointes. Pour la gestion des dossiers, il peut s'agir d'un dossier complet. Dans le cadre d'un système de laboratoire, il peut s'agir d'un résultat d'analyse accompagné des informations relatives à l'instrument, à l'analyste, à la méthode, à la date et aux fichiers associés nécessaires à sa compréhension.
Il s'agit d'objets métier. Leur structure correspond rarement parfaitement à une seule table de base de données.
Dans une solution de mise hors service d'applications Docbyte Vault, les données sources sont analysées et regroupées autour de ces objets métier. Les données, métadonnées et fichiers pertinents peuvent ensuite être regroupés en vue d'une intégration contrôlée dans les archives. Le schéma d'archivage définit la structure de l'objet, tandis qu'une vue lisible aide les futurs utilisateurs à l'interpréter sans avoir à recréer l'application mise hors service.
Cela ne signifie pas pour autant que SIARD n'ait plus d'intérêt. Une exportation SIARD ou un dump de base de données native peut toujours constituer une source utile ou un élément de conservation. La différence réside dans le fait qu'il n'est pas considéré comme l'expérience utilisateur finale.
Préserver l'accès ainsi que le contenu
Les archives doivent également permettre d'accéder facilement à ces informations.
Vault Explorer offre aux utilisateurs autorisés une interface simple d'utilisation pour rechercher, parcourir et consulter le contenu archivé. Les configurations de recherche permettent d'afficher les champs, les filtres et les colonnes de résultats pertinents pour un groupe d'utilisateurs spécifique. Les recherches liées permettent de relier des objets connexes, ce qui permet de passer d'un dossier à ses documents ou d'un enregistrement parent aux éléments associés.
La visionneuse distingue les métadonnées, l'aperçu et les représentations disponibles. Les utilisateurs peuvent ainsi consulter le contexte de l'enregistrement, examiner le contenu lisible et accéder aux formats conservés sans avoir à intervenir directement sur les tables de la base de données.
C'est là que réside la différence opérationnelle entre la conservation des données et la mise hors service d'une application de manière responsable.
Cinq questions à vous poser avant de mettre hors service le système source
Avant d'opter pour l'exportation d'une base de données comme solution de mise hors service, posez-vous les questions suivantes :
- De quels objets métier les utilisateurs auront-ils besoin par la suite ?
- Leurs relations et leurs liens affectifs sont-ils préservés ?
- Les utilisateurs pourront-ils comprendre les champs, les codes et le contexte sans disposer de l'application d'origine ?
- Existe-t-il un moyen clair et structuré de rechercher, parcourir et consulter les dossiers ?
- L'organisation est-elle en mesure de garantir l'exhaustivité, l'intégrité, la conservation et un accès contrôlé après la mise hors service ?
Si la réponse à ces questions implique de devoir reconstruire l'application source ultérieurement, la conception de la mise hors service est incomplète.
SIARD est un élément, et non la solution dans son ensemble
SIARD apporte une solution à un véritable problème de conservation. Il offre une alternative ouverte aux formats propriétaires des bases de données relationnelles et permet de garantir la disponibilité du contenu des bases de données au-delà de la durée de vie du logiciel d'origine.
Mais une archive de fin de vie d'une application ne doit pas se contenter de conserver des tables.
Il doit préserver le sens, les relations, la lisibilité des représentations et la facilité d'accès. Il doit permettre aux futurs utilisateurs de trouver des documents complets et de comprendre ce qu'ils consultent. Il doit également conserver les mécanismes de contrôle et les éléments justificatifs nécessaires à la gestion de ces documents au fil du temps.
La question n'est donc pas simplement de savoir si la base de données a été archivée.
La question qu'il convient plutôt de se poser est la suivante : lorsque quelqu'un aura besoin de ces informations dans cinq ou dix ans, que pourra-t-il exactement retrouver, comprendre et prouver ?
