lundi 22 juillet 2013

Open Data et Archivage électronique

Il est clair pour moi que l'Open Data est en lien avec l'archivage électronique. Et ce billet voudrait présenter quelques points pour le confirmer. Ceci n'est bien sûr qu'un point de vue d'un informaticien au contact d'archivistes.

Je fais référence à mes sources :


Une donnée ou une archive ?

Dès que la donnée est validée, que le circuit de validation a abouti, celle-ci est alors une archive. Pour le papier, il fallait mécaniquement considérer trois étapes (courant, intermédiaire, définitif). Mais pour l'électronique, ces 3 étapes relèvent plus d'un transfert de responsabilité que d'une étape réelle. En effet, une fois validée, la donnée peut soit être dupliquée immédiatement dans 3 containers d'archives (courant, intermédiaire, définitif), soit se voir stocker dans un seul container (ou toute autre solution intermédiaire).
Dans le cas de la duplication, cela permet de prendre très tôt le fichier en compte, et ainsi de pouvoir assurer sa conservation (notamment son format, mais aussi la qualité de ses métadonnées par leur fraicheur) dans d'excellentes conditions (pour l'intermédiaire - notamment si la DUA est de plus de 10 ans -, mais aussi à l'évidence pour le définitif). La copie, assurée conforme via les outils de traçabilités, d'empreintes et d'horodatages, est ainsi valide dès le jour J de sa validation.
La mutualisation des containers (1 seule copie) est possible grâce aux interfaces envisageables (et envisagées) entre un Système d'Archivage Électronique (SAE) et les applications métiers frontales. Pourquoi demander à une application métier de gérer des problématiques complexes regroupant l'indexation et les requêtes associées, la transformation de format dans le temps, les migrations de support, ... alors qu'un SAE sait le faire (ou devrait savoir le faire).
Le document d'activité, ou plus généralement les données (le contenu d'une base peut-il totalement être assimilé à la notion de document d'activité, sans doute) sont des archives dès leur premier jour.

Par cette mise au point préliminaire, il est aussi démenti qu'une archive est poussière et n'intéresse que les "chercheurs". Une fiche de paye, l'état civil, une enquête statistique, ..., tout ceci sont des archives et personne n'irait imaginer qu'elles n'ont pas d'utilité maintenant, tout de suite !

Open Data = je peux tout voir ?

Oui, et non... Il s'agit là de savoir de quelles données nous parlons.
Oui car les données de l'Open Data sont des données publiques, et donc qui appartiennent à tout le monde. Non, car toutes les données de l'état (ses archives) ne sont pas publiquement accessibles. Certaines sont soient confidentielles (sécurité nationale par exemple), soient présentent des informations à caractères nominatifs mettant en cause le droit à la vie privée, soient peuvent relever du droit à l'oubli.
C'est là que trois notions interviennent :
  • le niveau de confidentialité (confidentiel défense, secret défense, ...) qui peut avoir un impact sur les possibilités offertes de diffusion d'une donnée
  • la durée d'incommunicabilité, éventuellement en lien avec le point précédent, elle a aussi pour objet de préserver la vie privée des citoyens
  • l'anonymisation dont l'objet est de pouvoir rendre accessible une information dont le contenu ne serait pas communicable sinon
Les archives ne sont pas la propriété des archivistes, ils n'en sont que les serviteurs. Ils en assurent la conservation, la qualité, la capacité d'accès et l'accès lui-même. La propriété est donc bien à l'ensemble de la nation.
La liberté d'accès aux données est un droit pour tous, dans la limite des confidentialités ou incommunicabilités. En effet, personne ne souhaiterait par exemple que soient étalés au grand jour et accessible par n'importe qui la liste de ses relations amicales, le contenu de sa feuille d'imposition, le contenu de son casier judiciaire, l'ensemble des bulletins de notes de sa classe de CP... Il faut donc bien quelques limites.
Mais si la donnée est anonymisée, voire anonyme, alors, hormis une clause de sécurité nationale, cette information est librement accessible et communicable.

Ainsi les archivistes ne font-ils pas différemment de l'Open Data. Et si la législation semble trop restrictive, il appartient au législateur de la modifier... C'est là où le mouvement Open Data peut conduire à une réforme des textes en vigueur pour mieux définir ce qui est librement communicable de ce qui ne l'est pas. Les défenseurs de l'Open Data gagneraient en effet à faire bouger un peu les lignes, et ils seraient surpris de voir que nombre d'archivistes les suivraient sans réserve.

Open Data = comment la trouver, sous quel format et par quelle méthode d'accès ?

Le classement (ou mieux, les multiples classements) d'une donnée permet à l'évidence de mieux la retrouver. Mais cela suffit-il ? Les métadonnées qui accompagnent la donnée sont toutes aussi importantes, car elles contextualisent l'information.
Il faut qu'elle soit intelligible. Un écrit en cunéiforme est pour le moins difficile à lire, n'est-ce pas ? C'est la même chose pour une donnée numérique : elle doit être compréhensible dans un format approprié à son époque.
Il faut aussi qu'elle puisse être accédée facilement, selon les technologies de l'époque. Nous n'allons quand même pas faxer une donnée de nos jours... Alors qu'internet et les différents moyens de communications, plateformes de diffusion, protocoles multiples et matériels tout aussi multiples sont tout autour de nous.

C'est là où selon moi le SAE a sa part de travail à fournir pour que l'Open Data aboutisse avec une aisance et une transparence plus que satisfaisante. Le SAE peut stocker les archives, dans différents contextes (natif ou anonymisé), dans différentes formes (natif, format web, format image, format CSV, ...), avec de la documentation associée (pour une table de données, quelles sont les significations des colonnes, des valeurs...), et avec des moyens d'accès sécurisés mais ouvert technologiquement.
Le SAE n'a pas pour objet de fournir directement l'accès au public, mais il peut par contre être en back-office d'un Open Data, qui lui gère ses clients, leurs droits d'accès et la typologie des formats attendus. Le classement, la conservation et la préservation est un métier, difficile. Sachons répartir les rôles...

On ne demande pas au pilote de l'avion de faire le plein lui-même, ou de remplacer les pneus de l'appareil. Il y a des équipes techniques pour cela. Et bien, les équipes techniques seraient un peu le SAE (mêlant archivistes et informaticiens) au service d'une plateforme Open Data frontale dont son métier serait de piloter les accès, inciter les services à verser leurs archives, communiquer...

Un point souvent oublié avec les SAE, hélas, les métadonnées (toutes les métadonnées) se doivent d'être également avec le SAE, pour des raisons de pérennité de l'information. Du coup, pourquoi imposer que les applications frontales stockent elles-aussi cette information ? Pourquoi ne pas simplement lui permettre de requêter ces métadonnées stockées par le SAE, de manière efficace, performante, scalable et simple ?
Selon moi, c'est là aussi le rôle d'un SAE : offrir la capacité à des applications frontales de pouvoir requêter facilement et efficacement les métadonnées des archives (données), en vue de soit retrouver une archive, soit d'obtenir des compléments d'information relatifs à cette archive (sa description, son modèle de données, sa structuration, sa date de création, si d'autres données sont connexes à celle-ci...).

Ainsi un SAE peut-il être un atout pour une plateforme Open Data. Elle peut la décharger de travaux fastidieux et coûteux, tandis que la plateforme Open Data se concentrerait sur ses objectifs : faciliter l'identification des données utiles, accueillir plus de contributions, en permettant par exemple des indexations complémentaires, être un outil d'aide à l'innovation.

Open Data front-office d'un SAE back-office ?

Une plateforme OpenData ne devrait pas prendre en charge le stockage des données, ni leur indexation. Elle devrait laisser cette lourde tâche à un SAE et se concentrer sur ce qui relève de son métier : la communication, améliorer les fonds présents en encourageant les services publics à verser leurs données, la fédération des accès et leur sécurité et leur performances, leur adaptabilité aux technologies récentes, ... bref, tout ce qui concerne la communication et en amont de convaincre les services versants.

Mais je vois en ce moment un danger se profiler : Open Data réceptionne déjà des données numériques, dont aucune copie n'est fournie aux archives. Ces données, bien trop souvent, manquent de documentation (on appelle ça aussi la gouvernance des données de nos jours, mais cela fait depuis au moins le XVIIème siècle que les archivistes font cela). Open Data n'assure pas officiellement de garantie dans le temps (pour cause, ce n'est pas un service d'archives).

Résultat : des données numériques sont appelées à disparaître car les services versants ne feront pas l'effort de verser deux fois : une fois à l'Open Data, une fois aux archives.

Un État exemplaire : Open Data et Services d'archives en coopération

A l'époque du "dites-le nous une fois", il serait judicieux que l'on ne demande pas aux services producteurs de verser deux fois (au risque que l'une des deux ne se fasse jamais). Si les archives pouvaient recevoir directement ces données, elles seraient alors immédiatement disponibles pour Open Data et avec une qualité (documentation, format, mode d'accès, requêtage) qui ne peut que servir les intérêts de l'Open Data.

A l'époque du "mutualisons les services de l’État", il serait judicieux que l'Open Data français s'appuie sur des services qui pourraient lui apporter beaucoup, lui enlever une sérieuse épine du pied (le stockage, la conservation, la durabilité des formats, le contrôle des métadonnées, ...), tout en lui permettant du coup de disposer d'un fond de données très large et très rapidement. A l'inverse, les équipes de l'Open Data ont une approche très pragmatique, technologique, de services (aux citoyens et aux entreprises), avec des objectifs économiques pour la France, objectifs que n'ont pas les archivistes. 
Chacun des métiers concernés est nécessaire : ignorer l'un c'est risquer l'échec, coopérer c'est prendre le meilleur des deux.

A l'époque du "réduisons les dépenses de l'État", il serait judicieux de ne pas doublonner tous les coûts liés au stockage, aux efforts liés à la conservation et aux métadonnées, aux serveurs et logiciels afférents, aux équipes d'exploitation ou d'expertise, au développement et à la maintenance associé, ... La liste est presque sans fin. La coopération ne peut être que profitable au budget de l’État.

L'avenir de l'Open Data est dans ses données : le (ou les) SAE de l’État est (sont) une brique incontournable de celles-ci. Le savoir-faire est présent chez les archivistes et les informaticiens qui travaillent avec eux. 
Mais ce n'est pas que cela l'Open Data, et c'est pourquoi il est nécessaire que les archivistes acceptent aussi que ce service différent s'agrandisse, se développe, au service des entreprises et des citoyens. Du coup, les archivistes auraient une offre de service à proposer à Open Data, et non être en opposition. 

Les archivistes ne feront pas l'Open Data, mais l'Open Data ne peut pas atteindre ses objectifs sans les archivistes.

5 commentaires:

  1. Cher Frédéric.
    Globalement je suis d’accord avec toi pour dire qu’open data et archivage doivent se parler.
    Cependant, le diable est dans le détail et je pense qu’il faut préciser les zones d’action, qui ne sont pas exactement les mêmes. Je passe en revue ces détails qui peuvent potentiellement nous fâcher.

    Une données une archive ?

    « Dès qu’une données est validée.. »
    Dit comme cela a une valeur d’évidence. Dans la réalité les choses sont différentes. Alors que dans le monde du papier chaque étape (= chaque document) est figé au moment de sa validation (soit sa signature et/ou son expédition), dans une base de données la validation, comme elle porte sur une donnée et une seule, peut être beaucoup plus difficile à identifier comme validée. Dans le système bancaire par exemple, on attache une « date valeur » à une transaction afin justement d’éviter des problèmes ultérieurs. Cela implique que si l’on veut assumer une « validation » robuste à une base de données, il faut qu’une « date valeur » soit attribuée à chaque donnée (cela peut se faire par héritage mais ce n’est quand même pas trivial). Par ailleurs, il peut avoir des rétroactions dans le temps. Dans ce cadre je te conseille vivement la lecture de la thèse d’Isabelle Boydens, qui est juste magistrale à ce sujet (BOYDENS Isabelle, Informatique, normes et temps. Bruxelles : Éditions E. Bruylant, 1999). Incidemment, tout Boydens est à lire dans ce domaine.

    « Une fois validée, la donnée peut être dupliquée immédiatement… »
    Oui cela est vrai mais la nature des conteneurs doit être clarifiée. Utiliser les 3 âges des archives me paraît ici contre-indiqué et je préfère pour ma part viser un datawarehouse, je m’en explique plus loin.

    « Le contenu d’une base [de données] peut-il totalement être assimilé à le notion de document d’activité, sans doute. »
    Et bien non ! Pour la théorie je te renvoie à mon article :
    Collecter et organiser à l’ère de l’administration électronique : Données – Documents - Transactions
    Actes des 11ème Journées des archives de l’Université Catholique de Louvain (UCL)
    Dématérialisation des archives et métiers de l'archiviste. Les chantiers du numérique.
    Louvain-la-Neuve, 24 et 25 mars 2011, Academia-Bruyland, juin 2012, pp. 60-73.
    http://www.uclouvain.be/232161.html http://www.uclouvain.be/416589.html
    Accessible sur @rchivesic : http://archivesic.ccsd.cnrs.fr/sic_00723874
    Pour l’exemple pratique, je te renvoie à la décision de justice sur un document issu de données dans le cas de la CPAM de la Marne (juillet 2010) : http://www.racine.eu/publications/articles/119/Flash-Info-Arret-Cass-2e-civ-01-07-2010-echanges-numeriques-Isabelle-Renard.pdf

    RépondreSupprimer
  2. SUITE
    Open data = je peux tout voir ?

    La question de l’open data renouvelle une vieille question antérieure de partage entre la protection des données (le domaine de la CNIL) et celui de la transparence de l’administration (le domaine de la CADA). Tous les pays qui ont légiféré séparément dans ces domaines se trouvent aujourd’hui confrontés à des problèmes de conflit de législation épineux. Même dans les cas ou ces domaines ont été regroupés réglementairement (c’est le cas du canton de Genève où j’habite) un conflit subsiste avec la législation archivistique. Ainsi, le règlement d’application récemment modifié (en 2011) institue le fait que, sauf protection des données, les documents/données actifs sont communicables au public tant qu’ils sont en main de l’administration productrice, mais qu’ils sont protégés par un délai de protection (en général 30 ans) à partir du moment où ils sont versés aux archives, pour redevenir communicables après ce délai ; chercher l’erreur !

    « Ainsi les archivistes ne font-ils pas différemment de l’Open Data. »
    Encore une fois, c’est vrai si l’on parle uniquement de données mais en fait la tradition archivistique fait de « l’open records » ce qui n’est pas tout à fait pareil (records = documents, et document ≠ données, voir mon article plus haut).

    Dans cette question (et j’y reviendrai quant au partage des tâches entre open data et SAE) il y a une dimension que tu as totalement ignoré et qui à mon point de vue est cruciale, mais aussi discriminante, c’est le problème de la temporalité. Pour faire simple, mais tout n’est pas aussi tranché, l’open data est orienté sur l’ici et maintenant du citoyen, alors que l’archive et son outil numérique le SAE est focalisé sur le temps long.

    Open data = comment le trouver…

    « C’est là où selon moi le SAE a sa part de travail à fournir pour que l’Open Data aboutisse avec une aisance et une transparence plus que satisfaisante. »

    Et c’est là ou je dis qu’il faut insérer une couche de datawarehouse, et je m’en explique. Les bases de données métier sont faite pour résoudre des questions de l’ici est maintenant. Dans ce cadre, c’est la dynamique des transactions successives qui fait sens, et l’approximation n’est pas forcément dommageable (une correction est en général possible, c’est justement l’intérêt des bases de données). Par contre sur le temps plus long (que l’on pourrait assimiler à l’archivage intermédiaire) la validation des données prend tout son sens et le versement régulier (au jour-1 par exemple) après validation/normalisation des données est une formule efficace (d’autant qu’elle peut permettre une anonymisation qui autorisera la communication ultérieure dans un délai pas trop long).

    Raison pour laquelle je te propose cette grille de répartition entre les fonctions de l’open data et de l’archive, liée à la temporalité que j’évoquais plus haut :

    RépondreSupprimer
  3. SUITE 2


    Types de données Temps court (24 h) Temps long (+ 20 ans)
    Donnée ponctuelle Open data sans mémoire Sans intérêt archivistique
    (ex : horaire de bus au lieu X)
    Grandes séries de données Open data à mémoire Haute valeur d’archives
    (ex : budgets annuels (mais métadonnées riches
    de l’organisme Y) obligatoires)

    Ceci est une ébauche qui demande à être discutée/développée.

    « Sachons répartit les rôles »
    Oui, mais il y un a que tu as oublié et qui est problématique ; qui est le « data owner » (ou en français le propriétaire du processus métier) ?

    « Du coup, pourquoi imposer que les applications frontales stockent elles-aussi ces information ? »
    Parce que leurs utilisateurs en ont besoin immédiatement et qu’envoyer une requête à un SAE qui devra reformater les données conservées dans un format indépendant des applications, comme SIARD par exemple (et incidemment vérifier les droits d’accès) sera probablement trop coûteux en temps (le problème n’est pas grave quand il s’agit de texte/données, mais pour les images hautes définition, oui).

    Open Data front-office d’un SAE back-office ?

    Sur l’idée de base je suis pour, mais les obstacles évoqués plus haut me font réitérer mes remarques sur les questions de temporalité. Mon expérience actuelle me ferait plutôt pencher vers la structure suivante :

    BD métier  Datawarehouse métier  Datawarehouse consolidé  SAE

    Répondant aux besoins suivants :

    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)

    Les interfaces nécessaires sont loin d’être simples et je prépare également une publication sur l’archivage de ces différentes couches (printemps 2014).

    Ce modèle répond à ton postulat que les services versant ne feront pas l’effort de verser deux fois. L’avantage qu’il présente est que le datawarehouse métier est directement utile à l’utilisateur et qu’il sera en principe d’accord d’investir un effort sur cet interface, alors que le SAE lui apparaît actuellement trop éloigné (conceptuellement et dans le temps) pour y consacrer ne serait-ce qu’un seconde…

    Au plaisir d’une prochaine réponse.

    RépondreSupprimer
  4. Merci Janus !
    J'ai du coup, comme tu t'en doutais, poster un complément (vu la longueur, cela ne tenait pas dans une réponse simple)...

    J'adore ces discussions ! Elles me font progresser (je l'espère)...

    http://archiverleternite.blogspot.fr/2013/07/open-data-et-archivage-electronique_24.html

    RépondreSupprimer
  5. Merci pour toutes ces explications. J'apprécie beaucoup votre travail afin de fournir toute cette information. C'est super !!!

    RépondreSupprimer