/home/nicomo/

Le groupe de travail sur les archives ouvertes a publié (signalé par Urfist-info) un document intitulé “Principes pour les échanges entre systèmes locaux et HAL” (.doc)

Si on en juge par les rédacteurs des diverses versions du document, on peut considérer qu’il vient du côté CNRS/Recherche plutôt que du côté Universités/Couperin, même si le groupe de travail a des membres de tous ces partenaires.

C’est un étrange document, qui mêle technique et politique.

Par exemple, on lit dans les principes généraux que “Les documents numériques en texte intégral relevant du périmètre de HAL DOIVENT être stockés dans HAL”. Impérativement. Ce n’est pas un jugement politique local de l’université, c’est une obligation nationale. Qui le dit? Le Groupe de Travail. Bon.

On lit aussi que dans le cas où vous stockez dans votre système local une copie du texte intégral qui se trouve par ailleurs dans HAL, vous DEVEZ mettre un lien qui renvoit à la version de HAL. Comme dans: “cette image est tirée d’Amazon“. L’argument technique avancé est d’éviter la prolifération des versions des documents: il faut “favoriser une référence unique pour les documents de l’archive ouverte commune”; et la référence en question sera le numéro HAL. Mais pour ce qui me concerne, d’une part je ne vois pas en quoi la prolifération des documents est un problème, et d’autre part je conteste qu’il s’agisse d’une “archive ouverte commune”: archives-ouvertes.fr, c’est HAL.
Il est dommage qu’on n’ait pas retenu l’idée qu’il y a des systèmes locaux, articulés à un système national et aussi, pourquoi pas, à d’autres systèmes, thématiques, internationaux: articulés, mais différents. Et qui alimentent à égalité une plateforme archives-ouvertes.fr.

Evidemment, pour que ça marche bien et à partir du moment où on est parti de l’idée que HAL était en position centrale et hiérarchiquement supérieure aux système locaux, l’articulation devient tout de suite plus simple: HAL définit son système de métadonnées, ses identifiants, et les systèmes locaux doivent l’intégrer.

Je n’ai pas regardé le schéma proposé, AO.fr, et je n’ai donc pas de jugement à porter sur sa qualité, excellente sans doute (tout le document en question est très bien fait, même si je n’en partage pas tous les points de vue). Par contre, sur le principe: avait-on vraiment besoin, encore une fois, de faire une quelque chose de national, spécifique, .fr? Ne pouvait-on pas réutiliser un schéma existant, international? TEF? AO.fr? C’est quoi l’idée? On refait Unimarc?

Le document renvoit, pour le détail des web services, à un document du CCSD: http://www.ccsd.cnrs.fr/IMG/pdf/webServices.pdf.
HAL fait des choix techniques spécifiques pour les web services: c’est SOAP. Id est: il y a une porte d’entrée, et une seule, qui a sa taille et sa forme, à vous de vous débrouiller pour rentrer par cette porte-là. Or SOAP est un choix plus complexe à mettre en oeuvre que REST: le choix exclusif de SOAP limite de facto l’ouverture du système, c’est-à-dire les chances qu’on a de voir divers partenaires institutionnels ou individuels se brancher sur HAL pour exploiter les données de façon rapide, facile, inventive. Toujours la même idée: si on veut vraiment que les web services soient utilisés largement, il faut ouvrir la porte plus que ça. Ceci étant, c’est un choix qui s’explique quand on est dans une approche où on maîtrise le jeu au niveau central et qu’on impose ses technologies à un nombre de partenaires restreint et bien identifiés (les universités).

Je ne voudrais pas qu’on se méprenne sur ma position: ce document représente certainement une avancée, et désormais une vraie intégration entre systèmes locaux et HAL est possible; par ailleurs, si les universités avaient fait le travail là-dessus, HAL n’aurait pas pris toute la place: ils ont bossé, ils récoltent les fruits de leur travail… fair enough.
Malgré tout je ne peux m’empêcher de regretter qu’on n’ait pas poussé plus loin dans l’idée d’une décentralisation technique de la gestion des AO: ça permet d’avancer, c’est certain, mais en même temps on limite les opportunités: le cadre est très contraint, et les chances que quelqu’un fasse demain une utilisation très innovante – et qu’on n’aurait pas a priori imaginée – de ces données en est d’autant réduite.