OCLC DevNet

Je reviens d’une réunion organisée par OCLC: le pendant européen d’une réunion similaire tenue aux Etats-Unis il y a deux mois, consacrée à un double thème, le développement par OCLC d’une nouvelle gamme de services réseau (i.e.: des web services), et la volonté, qui lui est liée, de contribuer à la naissance d’un réseau de développeurs qui exploiterait/contribuerait à ces services.

Un exemple existant: xISBN, un web service très simple qui permet, en envoyant un ISBN, de récupérer d’OCLC la liste des ISBN correspondant à d’autres éditions de la même oeuvre: histoire de “FRBRiser” vos collections.
OCLC souhaite développer tout un ensemble de web services de ce type, certains simples, comme xISBN, d’autres beaucoup plus complexes. Le but de la réunion était pour eux de réunir un petit groupe de bibliothécaires pour avoir, à ce stade où il reste encore pas mal de marges de manoeuvre pour modifier les choses, notre feedback sur leur projet.

Côté OCLC il y avait Paul Harvey, Don Hamparian et Roy Tennant. Le groupe était composé de l’Allemand Jakob Voss, d’un collègue Danois, d’un Français (votre serviteur), quelques Néerlandais (la bibliothèque royale, les BU d’Amsterdam et Gröningen – où André Keyzer fait des choses vraiment très intéressantes avec Metalib et SFX (projet Livetrix)), quelques Anglais (Dave Pattern – “self-plagiarism is style” et Université d’Huddersfield ; Ashley Sanders (Université de Manchester, qui travaille en particulier sur le catalogue collectif COPAC) et le sieur Youngshusband de chez Unilever).

L’objectif global est pour OCLC de proposer de nouveaux services qui ne passent pas par la mise en oeuvre de nouvelle fonctionnalités dans les interfaces existantes ou de nouvelles interfaces. Mais de proposer des services (existants ou nouveaux) qui passent par des web services, pour permettre une « consommation » croissante et différente de ce qui fait, finalement, la richesse d’oclc, et des bibliothèques généralement: les données.

Au-delà d’xISBN, le service le plus naturel à développer est une API XML de recherche sur WorldCat. Elle sera proposée en beta au cours de janvier 2008.
Mais les projets vont bien au-delà: une API pour faire des paiements en ligne, par exemple pour gérer les balances entre institutions participant au peb et éviter ainsi les facturations croisées; une API pour faire des conversions de notices bibliographiques d’un format dans un autre; une API pour récupérer les informations enrichies (images, etc) liées à une notice; API d’authentification pour accéder à la documentation électronique; API autour des services sociaux, tagging, résumés, etc. API pour obtenir des statistiques; API pour des alertes diverses et variées; API pour récupérer des identifiants; API pour attaquer WorldCat Identities. API pour catalogage automatique: j’envois un pdf, je reçois un index et des metadonnées générées. API donnant accès à des registres: registre des services en ligne proposés par les éditeurs de documentation en ligne; registre, pour commencer, des bibliothèques, qui comprenne par exemple l’adresse du résolveur de liens OpenURL de l’institution et ses IP en plus de l’adresse et du numéro de téléphone.
La liste est longue comme la bras. Certaines ne verront peut-être finalement pas le jour, mais même si on en voit émerger la moitié, il y a du travail…

Plein de questions restent en suspens.
Quel sera le business model de ces services? Il est certain que si on veut que les API soient utilisées, et qu’une communauté de développeurs émerge autour de ça, il faut être ouvert. Mais jusqu’à quel point?

Reste aussi, pour moi, la question de savoir si nous serons en mesure d’exploiter ces services dans les bibliothèques françaises.
Pour les plus simples, type xISBN, certainement. Au moins quelques établissements. et il est certain qu’il serait intéressant pour OCLC de commencer par les services les plus simples pour pouvoir stimuler leur adoption.
Mais pour les services plus complets, plus complexes? Il faudrait déjà, pour les BU françaises, que nos données soient dans WorldCat. Ce problème peut et, j’en suis sûr, va se régler rapidement.
Mais il faudrait aussi, et surtout, que nous, bibliothèques, nous dotions des moyens nécessaires à l’exploitation de ces services. En clair il faut, pour l’informatique documentaire, nous regrouper. Il faut, absolument, qu’on arrive à une situation où l’équipe gérant l’informatique documentaire dans un environnement donné ne fasse jamais moins de 10 personnes, en comprenant au moins une moitié d’informaticiens. Qui ne soient pas consacrés au dépannage des imprimantes: des développeurs. S’il faut faire un service informatique commun à 10 bibliothèques pour avoir ces 10 personnes: ainsi soit-il! Ce qui est certain, et ce que cette journée de discussion m’a très concrétement fait comprendre, c’est que la pratique de bricoleurs amateurs qui, pour l’essentiel, est la nôtre actuellement atteint largement ses limites. Il faut passer à un autre stade, rapidemment. Sauf à ne pas participer à ce monde global de l’offre bibliographique mondiale: car personne, finalement, n’est obligé d’y participer. Dans la bibliothéconomie comme, j’imagine, dans l’industrie, il y a la globalisation à laquelle on participe et dont on est en mesure de profiter, et celle qu’on subit.

OCLC est une not-for-profit qui ressemble beaucoup à un fournisseur classique, certes. Mais d’une part les fournisseurs, for-profit ou non, peuvent apprendre, et en particulier apprendre que dans les applications web l’accès aux données est une demande différente, et finalement plus cruciale, que le statut de la licence logicielle (libre ou pas).

Et d’autre part l’arrivée dans notre paysage documentaire en ligne, qu’on le veuille ou non, d’entités comme Google ou Amazon change complétement la donne: seul OCLC a la taille requise pour faire quelque chose dans ce paysage. Et pour nous, nous devons aussi grossir, non pas pour concevoir ces services avec nos petits bras, mais pour seulement pouvoir les exploiter, et participer de ce réseau.