mercredi 24 juillet 2013

Open Data et Archivage électronique : suite sur quelques focus en réponse à Janus

Bonjour Janus,

Suite à tes commentaires, tu t'en doutes, je ne peux que me réjouir de faire progresser ma propre compréhension du domaine. Je ne prétends pas en effet tout connaître ou tout comprendre. Ma démarche est d'avancer petit à petit, en espérant mettre mes pas dans celui de mes prédécesseurs, mais en m'autorisant des écarts s'il me semble que ceux-ci ont ignoré quelques points (la raison la plus souvent étant que ces points sont "récents" ou peu connus et auraient donc amené ces mêmes prédécesseurs aux mêmes conclusions s'ils en avaient eu connaissance).

Les bases de données

Je suis d'accord avec toi sur les distinctions à apporter sur les "données" : documents, bases, enregistrements, transactions, ... Autant sur les documents, je pense que l'appréciation est totalement en phase, autant sur les autres, il peut y avoir des nuances (ma formation d'informaticien me conduisant sur d'autres chemins, pas opposés mais complémentaires). Sur les bases de données, je vois deux grands cas (et tous les sous cas intermédiaires, le diable est dans le détail effectivement).

1) Une base active avec modifications fréquentes : il s'agit effectivement de la plus grosse difficulté. Deux possibilités :
  • soit, comme tu le dis, on "date" les valeurs, ce qui permet éventuellement de les extraire pour "archivage" (on peut s'entendre ensuite sur ce que cela signifie, mais mettre dans un Datawarehouse, c'est une forme d'archivage aussi de mon point de vue d'informaticien, voir plus loin). En général, en informatique (notamment bancaire), on passe par un "log" ou équivalent, qui, lui, est daté par nature. C'est donc sans doute ce "log" qui doit être archivé (et qui l'est dans le monde bancaire), pas la base des transactions (en tout cas pas au même moment). J'y reviendrais plus loin dans ce billet.
  • soit le métier a des dates de validation (clôture d'exercice en fin de mois ou d'année), et là, tu l'admettras, c'est beaucoup plus facile (une comptabilité, des horaires de trains par exemple), puisque cette clôture implique la purge de la base et donc un archivage plus aisé.
2) une base statique ou inactive : une base statistique suite à une enquête par exemple. Dans ce cas, il est assez évident (pour moi) qu'il s'agit bien d'une donnée facilement "archivable", pour peu qu'il y ait la documentation associée (notamment les référentiels externes à la base).

Se pose ensuite la question du format des données. Si ce format concerne les données unitaires, alors une base de données, un Datawarehouse ou équivalent est obligatoire. Si ce format concerne un ensemble de données, les formats sont nombreux et il faut alors s'assurer qu'ils sont facilement exploitables par d'autres. Le format SIARD est intéressant mais est-il si facilement exploitable par d'autres ? Le format CSV est facile, mais est-il bien documenté ? Il y aura des travaux à mener, et je crois d'ailleurs que la France ou la Suisse ne sont pas les seuls à se poser cette question. En ce moment un grand projet européen devrait démarrer sur ce sujet : E-Ark (notamment au Danemark).

Les 3 âges revus selon l'angle de l'usage

La règle des 3 âges n'est citée que pour faire référence à un courant de pensée qui indique que ces 3 âges pour le numérique sont à redéfinir. Les précédentes notions avaient un rôle liées à l'unicité physique du support, le temps nécessaire pour y accéder. L'électronique détruit cette unicité et cette temporalité. Pour autant, je pense qu'il existe toujours différentes étapes, et je pense que l'on se rejoint sur le fond, même si sur la forme on peut diverger un peu.
Cette notion d'âges devrait plutôt laisser le pas à une notion de finesse des accès, liée à l'usage de ces données.
Selon moi, en tant qu'informaticien, en reprenant ton orientation, les 3 âges pourraient être :
  1. la production initiale : la donnée est dans son contexte strict (application, ordinateur du rédacteur, ...)
  2. la production référencée : la donnée vient de migrer vers un container toujours applicatif (GEIDE, Gestionnaire de courrier, Datawarehouse, ...)
  3. la production conservée : la donnée est conservée pour des raisons légales ou historiques (je ne fais plus de distinction ici)
Ainsi pour la production initiale, les données sont dans un format et un contexte qui ne demande nullement aucune transformation, puisqu'il s'agit du contexte de création de la donnée. Cette étape manque singulièrement en général de contextualisation et de documentation directement associées. En effet, celles-ci sont en fait métier, réglementaire, ou encore plus simplement dans la tête du rédacteur. Je ne parle pas de l'opération conduisant à la création, mais bien de l'étape où la donnée pourrait être considérée comme valide. Dans certains cas, elle ne l'est que lorsqu'elle passe à l'étape 2.

La production référencée est ici un container avec contextualisation explicite d'une donnée (via le plan de classement de la GEIDE, du gestionnaire de courrier ou les documentations du Datawarehouse, ...). Cette étape est importante car potentiellement, la donnée vient potentiellement d'être modifiée dans sa forme pour correspondre aux contraintes du container de référence. Elle est toujours intimement en lien avec le métier d'origine, mais elle n'est plus dans le système qui l'a produite. J'y reviendrais juste après, mais je ne fais pas une grande distinction entre cette étape et la suivante, hormis la contextualisation métier associée (authentification et habilitation des usagers).

La production conservée est un container a priori totalement déconnecté du métier d'origine. Les authentifications et habilitations des usagers ont moins d'importance (ici, c'est un raccourci de pensée, pas une réalité). Hors, entre l'étape 2 et l'étape 3, les différences sont justement cette interconnexion entre le métier présente en 2, absente en 3. Mais d'un point de vue des données, leur format, les métadonnées associées (éventuellement enrichies ou au contraire appauvries en 3), il y a une grande similitude. Tant et si bien que je suis persuadé que si le 3 est un SAE, rien n'empêche que celui-ci puisse être en back-office d'un 2 (front-office comme une Geide ou un gestionnaire de courrier par exemple), à la condition que :
  • le SAE stocke les informations de classement de l'outil front-office de façon à ce que ce dernier puisse requêter le SAE non seulement sur les données mais aussi sur les métadonnées comme il le ferait pour lui-même dans ses propres référentiels.
  • le cas échéant, si le front-office doit avoir un référentiel propre (car évoluant très vite, trop vite pour une bonne prise en compte dans le SAE, comme par exemple un référentiel métier "vivant" comme des comptes bancaires ou des identifiants de sociétés) ou pour des raisons de sécurité ou d'efficacité (le référentiel des usagers avec leur authentification et leur habilitation par exemple), alors le front-office doit conserver ces données pour ses propres besoins, et, quand c'est possible (que cela a du sens), les transférer en tant qu'archives complémentaires selon un rythme acceptable (1 à 2 fois par an par exemple) au SAE. Le référentiel des usagers ne me semblent par exemple pas utile. Par contre, celui métier oui...
Vous aurez remarqué que j'ai mis de côté le Datawarehouse...

Datawarehouse et SAE

Le cas du Datawarehouse est un cas particulier : est-ce un besoin d'accès ou un besoin de post-traitement sur les données pour obtenir de nouvelles données ? En effet un Datawarehouse ne fait pas que "stocker", il "calcule" aussi, produisant ainsi de nouvelles données.

Si nous restons dans le cadre du "stockage", puisque la production de nouvelles données est à l'évidence une problématique métier hors du périmètre d'un SAE, alors pourquoi le SAE ne pourrait-il pas le faire ? Dit autrement, le référentiel des données (métadonnées de toutes sortes), n'est-ce pas autre chose qu'un Datawarehouse ? Et le SAE dispose (ou devrait disposer) d'un tel outil.
Si nous parlons des données elles-mêmes, oui, le SAE ne va très certainement pas proposer un accès "unitaire à la ligne" de données d'une table. Il ne proposera que l'accès à la "table" entière.

Que peut-on en déduire ?
  • Si le besoin est d'accéder à une ligne (ou une valeur) d'une table, il s'agit d'un besoin métier précis, et un Datawarehouse dédié (ou autre technologie) est alors indispensable car il prend en compte des contraintes métiers que ne peut pas prendre en compte un SAE.
  • Si le besoin est d'accéder à une table, alors le SAE peut y répondre.
Or, pour l'Open Data, il ne s'agit pas d'accéder à une ligne ou une valeur, mais bien à une table, à charge ensuite aux sociétés d'utiliser ces données pour offrir un service d'accès à la ligne ou valeur (par exemple les horaires des trains pour une ligne de train donnée, voire pour une gare donnée).


Ainsi, dans le monde des transactions, la transaction dans une application (et incidemment dans la base associée, voire les bases associées) n'est selon moi pas du ressort de l'archiviste. Il doit se reposer sur les connaissances applicatives et métiers associées pour aider à déterminer ce qui a de l'importance et quand et comment la récupérer. Ainsi l'exemple que j'ai cité pour les transactions bancaires montre qu'en général, la base est utilisée pour l'immédiateté, l'interconnexion des données entre systèmes, mais que même les informaticiens, n'y faisant pas totalement confiance, utilisent en fait des logs (traces ou autres formats) hors base pour les stocker et les "archiver" (au sens de la preuve et du rejeu si nécessaire). Je ne nie pas les travaux existants sur le domaine, mais mon caractère me conduit à utiliser le proverbe chinois : "un problème sans solution n'est pas un problème". Dit autrement, je me concentre sur ce que l'on sait faire aujourd'hui, et si demain des nouvelles technologies ou nouvelles théories (archivistiques ou informaticiennes) voient le jour et permettre d'y répondre, le problème aura alors une solution.

Il s'agirait donc dans ce cas d'exploiter ces traces et non le contenu de la base, car ces traces sont sans doute plus fiables (car plus riches et plus "autonomes"). Mais à chaque cas son analyse et ses conclusions... Il n'y aura pas de baguette magique, et c'est là où les informaticiens ont besoin des archivistes, que ce soit pour les aider à déterminer et produire des données intelligibles, ou que ce soit plus simplement (du point de vue d'un informaticien toujours enclin à faire le moins de choses possibles) pour lui rappeler et l'obliger à traiter ces données, ou encore pour leur amener des évolutions théoriques ou techniques leur permettant d'aborder un problème de façon "pragmatique".

Une transaction a certes un existence en elle-même, mais elle peut aussi être regroupée en un lot de transaction pour des fins de "stockage". D'ailleurs, une base n'est rien d'autre que le stockage d'une transaction..., un log aussi. Si un SAE ne stockera pas unitairement une transaction (en raison de l'explosion des entrées induites dans le système, ce qui reste encore un problème), il peut par contre stocker celles du jour ou du mois ou de l'année en un bloc unique. Si le besoin métier demande un niveau de granularité plus fin, alors un Datawarehouse (ou autre) devra être créé pour gérer cet aspect métier. Que ce soit alors ce Datawarehouse qui soit le "versant" vers les archives, pourquoi pas, puisqu'il s'agit alors à nouveau d'une application métier. On décale d'un cran l'arrivée de la donnée dans le SAE, c'est tout...

Datawarehouse et Open Data

Mon point était que l'Open Data ne se positionne pas en tant que Datawarehouse "à la ligne", mais par bloc (ou alors, si c'est vraiment ce qu'ils veulent, c'est actuellement technologiquement impensable pour pouvoir répondre à l'ensemble des besoins métiers concernés potentiellement en un seul lieu - l'unité de temps, d'espace et d'action interdisant actuellement un tel regroupement si on n'accepte pas quelques "agrégats" ou création de lots de données -). 
Dit autrement, un SAE ou l'Open Data n'enlèveront pas le besoin d'un entrepôt de données orienté métier, ce n'est pas le grand soir des Datawarehouse que je propose. Je me place résolument, dans le contexte du billet, en fournisseur d'un service pour Open Data.
Ceci dit, je n'exclue pas que des applications métiers utilisent, tout comme l'Open Data, le SAE comme un entrepôt de données (par bloc structuré, pas à la ligne) pour leurs propres besoins, si ceux-ci peuvent être en adéquation avec les services qui peuvent être rendus par un SAE. Je sais que cela implique un niveau de performances que n'ont pas la plupart des SAE actuels, mais la technologie aidant, ce niveau de service peut maintenant être atteint, pour peu que l'on sache se limiter dans la granularité. Je n'exclue pas qu'à l'avenir il soit possible de descendre encore plus bas (à la ligne, voire la colonne). Mais petit à petit, on devient moins petit...

Sur la valeur des données ainsi stockées dans un SAE, cette valeur dépend de toute la chaîne de transmission. Elle ne commence pas au moment du versement dans le SAE mais bien en amont, au moment de sa production et par toutes les étapes qu'elle va connaître (par exemple, bureautique => GEIDE => SAE, ou transaction => application => Datawarehouse => SAE). Nous ne pouvons pas "tout" faire, mais conseiller et encourager les systèmes à tracer leur production, ça oui, on peut le faire... Si le juge estime qu'il a suffisamment d’éléments pour apprécier la qualité du suivi et des données (conservation, preuve, ...), c'est gagné... mais ce n'est pas simple (et considérer seulement le SAE comme l'objet de cette preuve est insuffisant).

Ceci dit, si on fait le parallèle avec le papier, qu'est-ce qui nous assure que le document papier fourni est bien l'original, sans tromperie, ou la bonne version ? Disons que la différence ici est la facilité donnée via le numérique à "falsifier" ou "ne pas transmettre la bonne version" lors du versement. La traçabilité de bout en bout est envisageable, mais elle suppose des moyens qui ne sont pas à ce jour suffisamment en place.
Il en va de même selon moi pour l'Open Data : qu'en est-il de la valeur des données qu'il proposerait si celles-ci n'ont aucune traçabilité ? 

C'est là où je pense sincèrement qu'il faut que les données suivent un circuit balisé, avec des personnes dont c'est la compétence (archivistes), pour être versées dans un SAE puis mise à disposition de l'Open Data. Et si ces données sont à faibles durées de vie, et bien, le SAE ne les conservera que peu de temps (simplifiant ainsi l'effort de pérennisation au sein du SAE), mais les autres composants (traçabilité, sécurité, conservation, ..), eux, seront toujours à réaliser.

Législation, Open Data et Archivage

Je suis d'accord avec toi, la législation, quel que soit le pays, ne semble pas en phase avec les principes contradictoires de communicabilité, confidentialité et protection de la vie privée. Et alors ? Faisons évoluer les lignes, une loi se change. Et si l'Open Data est un moteur pour cela, ne le refusons pas. Faisons entendre toutes les voix, toutes les expertises (mais pas QUE les experts, qui ont trop tendance à rester sur les positions des lois précédentes). Une société évolue, ainsi que ses lois. Ce n'est pas toujours simple, il faut parfois plusieurs étapes, mais c'est inévitable.
Oui il y a des contradictions, mais il s'agit aussi d'un mouvement démocratique où la profusion des données les concernant inquiétant les citoyens (à juste titre ? Big Brother ?) conduit à une contradiction (parmi d'autres) : 
  • en tant que citoyen, je ne veux que l'on ne me cache rien, j'ai le droit de savoir
  • en tant que citoyen, je ne veux pas que l'on sache tout de moi sans contrôle

Temporalité, Open Data et Archivage

Je suis d'accord avec toi, il est clair que l'Open Data favorise l'immédiateté, et qu'à l'inverse l'archivage favorise le temps long. Cependant, je pense qu'il n'est pas juste de les opposer :
  • L'Open Data propose certes des données "très" récentes, mais pas pour juste une journée. La durée de conservation (tiens donc !) est souvent de plusieurs années... N'est-ce pas là le rôle d'un SAE ?
  • L'Open Data propose des données avec des plans de classement "métier". Et alors ? Le SAE peut proposer plusieurs plans de classement pour une même donnée, dont celle de l'Open Data. Il peut même "gratuitement" donner plusieurs plans de classement d'une même donnée pour l'Open Data. Est-ce la responsabilité de l'Open Data de déterminer ce plan de classement ? Selon moi non, il s'agit d'un travail en partie de "record manager" et d'archiviste (et mieux encore quand les deux professions ne font qu'une ou du moins coopèrent).
  • L'accès via un Datawarehouse ? Si c'est par bloc, le SAE peut le faire tout aussi bien (il s'agira alors de critères de recherche dans une base de métadonnées riche et enrichie). Si c'est par ligne voire par champ, alors ni l'Open Data ni le SAE ne pourront le faire. L'Open Data n'a pas vocation à remplacer les applications métiers (état civil, impôts, recherche d'horaires de train, ...), mais de mettre à disposition des données structurées (documentaires ou bases dans un format exploitable) avec les métadonnées nécessaires à leur exploitation (contexte, description des tables, des champs, des valeurs possibles, référentiels). Là encore, le SAE peut y répondre.
  • L'archivage n'est pas concerné par des données de court terme (horaires de trains) ? Si, il l'est tout autant. Pas pour l'archivage définitif, historique bien sûr, mais pour ce que l'on appelait l'archivage courant et intermédiaire. Or nous pensons que technologiquement, le SAE doit savoir traiter ces deux cas de figure avec autant d'efficacité et de sécurité.
  • Si je reprends ton découpage en 4 étapes :
  • BD métier = travail quotidien des services de l’organisation (= pas d’open data)
  • Datawarehouse métier = travail de gestion des services (= open data éventuel)
  • Datawarehouse consolidé = travail de gestion de l’organisation (= open data)
  • SAE = Datawarehouse historicisé et pérennisé (= open data à long terme)
Je le réécrirais comme suit :
    • BD métier = travail quotidien des services de l’organisation (= pas d’open data)
    • Datawarehouse métier = travail de gestion des services (= pas d’open data)
      • car toujours intimement lié au métier et avec des besoins de requêtes à l'unité de la ligne voire du champ, inapplicable dans un contexte Open Data
      • il s'agit à nouveau d'une BD métier, pas de différence pour moi avec le premier item 
      • il peut par contre être un meilleur candidat pour le versement à l'étape suivante car ses données seront sans doute de meilleure qualité (exploitable, documentée, ...)
    • Datawarehouse consolidé = travail de gestion de l’organisation (= open data, oui, mais avec déport du stockage et de la conservation dans un SAE immédiatement)
      • Un SAE courant ou intermédiaire s'entendant bien sûr, mai un SAE quand même
      • L'intérêt est que ces données, si elles sont candidates à du long terme, elles sont tout de suite prise en compte par un SAE long terme (le même potentiellement)
    • SAE = Datawarehouse historicisé et pérennisé (= open data à long terme)
      • Je ne suis pas fana d'indiquer qu'un SAE n'a qu'un intérêt de long terme, comme tu l'auras compris. Pour moi, il a autant (voire plus) de valeur sur le court terme. Il assure la garantie des droits (plutôt long terme) et des informations utiles (plutôt court terme) des citoyens.
Des horaires de trains sont utiles maintenant et tout de suite, mais l'Open Data ne fournira pas de moyen de requêtes à l'unité, mais fournira un moyen d'accès à l'ensemble des données. Ensuite, c'est à la charge de ceux qui veulent exploiter ces données d'en faire un service (et donc à nouveau des applications "métiers") comme par exemple fournir des horaires de trains entre deux stations sans passer par le site de la compagnie concernée. Qu'est-ce qui empêcherait le SAE de les stoker en lieu et place de l'Open Data ?

Mais ne nous méprenons pas : l'Open Data c'est aussi l'accès, l'ouverture, l'implication de l'Etat dans la transparence, la réglementation associée. Et c'est là aussi où l'Open Data est utile. 

En effet, pour moi, le SAE ne peut pas prendre en compte les différents média aussi vite que l'Open Data pourrait le faire (tablette, internet, protocoles d'échange et de communication, ...). Le SAE ne peut pas prendre en compte une contextualisation des demandes pour tous les cas (il faudrait qu'il intègre toutes les notions métiers, ce qui le rendrait irréalisable, et ce même à l'échelle d'une petite organisation). En clair, l'Open Data est un candidat parfait pour un front-office d'un SAE, jouant pleinement son rôle d'accessibilité, de mise en page, de communication. 
Il joue aussi son rôle sur la sensibilisation des producteurs à verser ce qui peut être utile aux citoyens. En effet, l'archiviste peut ignorer certaines données, car elles ne répondent pas selon lui à un intérêt archivistique. Mais si l'Open Data détecte de nouvelles données pouvant avoir leur utilité, immédiate, mais aussi pourquoi pas, de plus ou moins long terme, alors l'archiviste sera tout content de pouvoir obtenir de nouvelles données à conserver. Il pourra étudier ces nouvelles données et identifiera peut être que certaines d'entre elles sont intéressantes dans le temps. 

Un exemple, nos fameux horaires de trains, si leur utilité immédiate est indéniable, un échantillonnage de ceux-ci seraient peut être utiles dans le temps (à titre scientifique et historique). Si l'archiviste n'a jamais connaissance que cette donnée existe, n'y a jamais accès, comment pourrait-il vouloir la conserver et avec les métadonnées nécessaires ?

C'est là où l'Open Data apporte aussi sa pierre à l'édifice... et le SAE à l'édifice Open Data.
En quelque sorte, pour décrire très grossièrement, l'Open Data est la partie métier de l'accès aux archives, qu'elles soient de très courtes durées ou de plus long termes, et le SAE le moyen de garantir leur pérennisation, leur conservation, leur intelligibilité.

RDF et métadonnées

Je fais un aparté sur le format RDF, si cher au contexte du web sémantique. Ce format me semble hélas une voie un peu sans issue. La notion de triplet ne me convainc pas. Cela nous entraînerait beaucoup trop loin dans la représentation des données, et compliquant de manière exponentielle (à ce jour des connaissances en traitement de l'information) les modes de calculs, de stockage et de requêtes associés. 

La nature humaine est un couple : clef = valeur. Un triplet peut permettre me dira-t-on d'associer un contexte, mais qui s'exprime très bien par clef = valeur ET contexte = valeur, soit une combinaison usuelle des critères de recherche. 
Toute notre technologie est orientée sur ce modèle clef = valeur. La tentative de penser en mode triplet est certes intellectuellement intéressante, mais est-ce qu'elle apporte réellement une plus-value au regard de la complexité induite ?

On pourrait me rétorquer que c'est une très bonne façon de stocker un graphe. Oui, mais en algorithmie, cela se traduit toujours par clef = valeur (mes pères sont [ liste de pères ] ou mes fils sont [ liste de pères ] et où le nom "mes pères" est la signification première du lien. Pour être plus précis, si 2 nœuds A et B sont en relation selon une propriété X, alors A.X = B ou B.X = A selon le sens de la relation. Il ne s'agit pas ici d'un triplet puisque A = une ligne et X un champ de cette ligne... 

Dit enfin autrement, une base de données classique (ou NoSQL) stocke ceci sans avoir besoin de passer par un triplet. Et les requêtes sont elles-mêmes parfaitement exprimables, selon un esprit humain (l'humain étant la pierre angulaire de notre façon de travailler, puisque c'est le seul logiciel qui n'évolue que très peu dans le temps).
Mais peut être les évolutions scientifiques (sciences des modèles de données, sciences algorithmiques, sciences du traitement de l'information, ...) nous permettront-elles d'évoluer là aussi vers une possibilité d'exploiter ce genre de représentation sans frein. 
A titre de contre-exemple, les bases dites "graphes" (et donc pouvant représenter des relations A.X = B) sont limitées en taille de nos jour, à tel point, que nous les avons écartées de notre modèle, pour le moment...

6 commentaires:

  1. D’accord sur (presque) tout. Tes précisions suscitent néanmoins quelques commentaires.

    « Le format SIARD est intéressant mais est-il si facilement exploitable par d’autres ? »
    Le format SIARD est un format d’archivage. Sa particularité est de rendre les données indépendantes des applications. Son inconvénient et qu’il faut un traitement d’uploading pour rendre les données consultables et cela ne se fait pas en quelques nanosecondes. De plus, il est adapté au SQL mais il n’a pas pour l’instant d’équivalent pour le NoSQL. Je vais suivre avec attention le projet E-Ark…

    Les 3 âges et l’informatique
    Ta reformulation des trois âges est intéressante et provocante et cela pourrait faire l’objet d’un atelier en soi : « Les trois âges à l’ère de l’informatique ». Petit clin d’œil aux membres de l’AAF qui lisent par-dessus nos épaules, manifestez votre intérêt.

    « le SAE stocke les informations de classement de l'outil front-office de façon à ce que ce dernier puisse requêter le SAE non seulement sur les données mais aussi sur les métadonnées comme il le ferait pour lui-même dans ses propres référentiels. »
    Par construction un SAE, selon la norme OAIS n’est interrogeable que par les métadonnées par nécessité de contrôler les droits d’accès.

    « Le cas du Datawarehouse est un cas particulier : est-ce un besoin d'accès ou un besoin de post-traitement sur les données pour obtenir de nouvelles données ? »
    Les deux bien sur. C’est ce qui fait son intérêt. Il libère les applications métier d’interrogation sur de grande masse de données qui péjorerait leur fonctionnement et permet des interrogations selon des requête nouvelle (c’est un des potentiel de l’open datat, si tant est que l’on sache s’en servir).

    « Si le besoin est d'accéder à une table, alors le SAE peut y répondre. »
    Oui mais non. On peut avoir les mêmes données dans la BD métier, dans des Datawarehouses, et dans des applications de visualisation de donnée (tableau de bord issu des Datawarehouses. Elles sont dans des formats différents, plus ou moins archivables et/ou « open datable ». Je suis en train de concocter un article sur le sujet mai il faudra attendre juin 20124.

    RépondreSupprimer
    Réponses
    1. Juste un point sur le SAE et le requêtage des métadonnées : si il est vrai que l'OAIS exclue l'interrogation (encore que, ce n'est pas si explicite) des métadonnées autre que celles relatives aux droits d'accès, je pense sincèrement qu'il s'agit détendre clairement le SAE a ses nouvelles fonctions liées au numériques, à savoir la capacité de rechercher non seulement des archives mais aussi rechercher des métadonnées. Lorsque je vois que statistiquement un "chercheur" s'arrête à 80% aux métadonnées de l'instrument de recherche pour le papier, je me dis qu'il serait plus qu'utile que le SAE intègre la possibilité de les requêter et de les rendre (sans l'archive).

      Du coup, on offre un univers de service plus large aux applications frontales qui n'auront pas à stocker ces métadonnées en double (avec du coup l'absence du problème sous-jacent de la mise à jour pouvant être faite dans 2 endroits sans corrélation).

      Et c'est à ce titre que le SAE devient une forme de "datawarehouse" mais sans traitement de calcul (pas de production de nouvelles données)... d'où ma distinction entre un simple entrepôt de données et un entrepôt avec production de nouvelles données.

      Supprimer
  2. Datawarehouse et Open Data
    Indépendamment de ton de point de vue open data, j’ai le sentiment, à travers les discussion du colloque de mars sur les « .. » divers échos aux forum des archiviste à Angers, qu’il y a un besoin de « SAE d’entreprise » qui réponde à un besoin d’archivage intermédiaire. Là encore un atelier nous serait nécessaire.

    « Il en va de même selon moi pour l'Open Data : qu'en est-il de la valeur des données qu'il proposerait si celles-ci n'ont aucune traçabilité ? »
    Oh oui, oh oui, oh oui !!!

    « Je suis d'accord avec toi, il est clair que l'Open Data favorise l'immédiateté, et qu'à l'inverse l'archivage favorise le temps long. Cependant, je pense qu'il n'est pas juste de les opposer »

    Il ne s’agit effectivement pas de les opposer en soi mais plutôt de mesurer les différentes contraintes que ce différentiel temporel implique. Ce que confirme ton analyse sur les 4 étapes que je proposais. C’est vraiment une hypothèse de travail et elle nécessite un développement (un nouvel atelier ???)

    « En effet, pour moi, le SAE ne peut pas prendre en compte les différents média aussi vite que l'Open Data pourrait le faire (tablette, internet, protocoles d'échange et de communication, ...). »
    Aujourd’hui ce n’est effectivement pas le cas, mais l’intérêt du modèle OAIS de proposer un module de communication qui est potentiellement en mesure de répondre aux nouveaux besoin des technologies émergentes, si tant est que les archivistes gérant les SAE s’y intéressent.

    RDF et métadonnés
    L’intérêt du RDF est de pouvoir faire communiquer des ressources provenant de différentes bases de données. Les archivistes (mais les bibliothécaires avant eux, voir les travaux d’Emmanuel Bermès à ce sujet) ont élaborés des normes de description qui repose justement sur une structure réticulaire (démo dans la présentation de mon collègue Hans von Rütte). Encore un autre sujet d’atelier…

    Avant tous ces chantiers à entreprendre, je m’accorde une petite pause vacances.

    RépondreSupprimer
  3. Que d'ateliers à réaliser ! Heureusement que nous ne sommes pas seuls !!!
    Bonnes vacances !

    RépondreSupprimer
  4. Bonjour Frédéric,
    Merci pour ces réflexions fournies et intéressantes. J'aimerais revenir sur la question de la théorie des 3 âges pour le cycle de vie du document. Je reste persuadée que cette théorie de base ne peut s'appliquer telle quelle au document électronique. Et même... l'enjeu est parfois ailleurs. En effet, je suis archiviste (ou e-archiviste) dans une institution d'archives cantonales. De par nos travaux sur l'archivage électronique à long terme, nous avons remonté le cycle de vie du document pour se positionner comme des acteurs RM et un centre de compétence en gouvernance des documents électroniques au sein de l'administration cantonale (7 départements et pouvoir judiciaire). Ce travail de longue haleine porte ses fruits, car les chefs de projets SI se tournent de plus en plus vers nous pour mettre en conformité leurs projets avec la gestion des documents électroniques. Dans les nombreuses séances avec des responsables départementaux des SI et des chefs de projets, nous devons faire comprendre rapidement et clairement la notion de cycle de vie du e-document, et cela à des non-professionnels de l'information. Un schéma clair vaut bien des discours, et celui que nous avons développé fonctionne bien. Il établit un cycle de vie en deux phases, la durée d'utilité administrative et légale (DUAL) puis l'archivage à très long terme (ou la destruction): http://present-hieretdemain.tumblr.com/post/22661817291/les-mains-dans-le-cambouis-et-la-theorie-des-3-ages .
    Je pense que la question sera débattue encore longtemps, mais dans ce cas il s'agit de pragmatisme, et d'adapter notre vocabulaire à nos interlocuteurs (real archivistique?).
    Que les échanges continuent ainsi, c'est passionnant!
    Bel été,
    Anouk Dunant Gonzenbach

    RépondreSupprimer
  5. Bonjour Anouk,

    Je vous propose de lire mon complément à vos interrogations.
    Bien sûr, comme toujours, j'avance en échangeant, donc je peux être dans l'erreur ou avoir oublié des points...

    http://archiverleternite.blogspot.com/2013/07/sae-oais-les-3-ages-vus-par-un.html
    Bien à vous,
    Frédéric Brégier

    RépondreSupprimer