Big data et bibliothèques

Le big data (« mégadonnées » pour ceux qui veulent parler français) ce n’est pas tout neuf, cela fait quelques années qu’on en parle ; d’ailleurs, le Gartner hype cycle le place en 2014 sur la pente descendante qui va plonger dans le ravin de la désillusion. J’en déduis que c’est le bon moment pour les bibliothèques de commencer à s’y intéresser sérieusement  – mais non, pas parce que les bibliothèques ne s’intéressent qu’à ce qui est dépassé, mais parce qu’on commence à voir au-delà du « buzz » pour se diriger vers le plateau de la stabilité.

En tout cas, c’est le moment que j’ai choisi pour ma part pour lancer une veille sur le sujet. D’avance je sollicite l’indulgence des éventuels lecteurs du Figoblog, ce travail étant rétrospectif et réalisé dans un temps limité. Si vous avez des critiques ou des références intéressantes que j’aurais loupées, n’hésitez pas à les mentionner en commentaire.

D’abord quelques éléments de définition (vous pouvez aussi lire Wikipédia) : le big data se caractérise par la règle des 3 V : volume, vélocité, variété. On parle de masses énormes de données (de l’ordre du téra ou du péta octet, voire plus) produites dans une temporalité de l’ordre de la seconde et qui peuvent être de toute sorte : structurées ou non, du texte, de l’image, du mail, n’importe quoi. L’exemple emblématique c’est Twitter qui génère 7 téra-octets de données par jour (toujours selon Wikipédia).

A cause de ces 3 V, les données en questions ne sont pas manipulables avec des outils classiques comme les bases de données relationnelles. Et ce d’autant que l’enjeu est de les exploiter en temps réel (l’exemple typique étant l’analyse des données de la bourse par les traders, où tout peut se jouer dans une nanoseconde). Des outils spécifiques ont donc été créés pour permettre de les stocker et de paralléliser les requêtes, le plus connu étant sans doute le framework Hadoop.

Pour savoir en quoi cela peut nous intéresser, nous bibliothécaires, je vous invite à lire par exemple cette introduction de base au big data sur le site de l’ALA (2013) ou à feuilleter ce diaporama de la Library of Congress (2012). Si vous avez un peu plus de temps, un cours en ligne (environ 1h, 2013) est disponible sur le site Digitization 101 (sur lequel je n’avais pas mis les pieds depuis une éternité, ça fait plaisir de retrouver Jill en vidéo !) Vous allez me dire que je ne vous propose que des vieux trucs en anglais… alors vous pouvez tenter les vidéos du colloque « Quelles stratégies de recherche face à la nouvelle massification des données » organisé par l’ADBU en décembre 2014. Cependant, on y trouve plutôt un panorama des enjeux stratégiques que des explications ou solutions techniques.

Pour synthétiser, j’identifie aujourd’hui trois pistes de réflexion pour les bibliothèques.

La première réside dans le fait que les « data » sont de plus en plus un objet que les bibliothèques de recherche en particulier vont être amenées à collecter et conserver, en tant que produit du travail des chercheurs, au même titre qu’on le faisait auparavant pour leur production documentaire imprimée puis numérique (articles, thèses, etc.). Or ces données ont des caractéristiques différentes des documents : elles se présentent sous la forme de flux et non de stock (« data is a lifecycle » ) et nécessitent des outils d’analyse pour pouvoir être utilisées.
Un exemple d’application de ces réflexions à la bibliothèque de l’Université de San Diego est détaillé dans cette vidéo de 30 mn (déc. 2013) :

Deuxième piste de réflexion : l’utilisation du big data pour analyser les statistiques de consultation des bibliothèques en vue de fournir de nouveaux services aux usagers ou aux bibliothécaires. C’est ce que fait le réseau des bibliothèques de Singapour : un réseau de bibliothèques publiques qui a développé l’utilisation du big data pour analyser les statistiques des prêts en lien avec les données bibliographiques, et ainsi proposer à ses usagers des recommandations.
Cette technologie est aussi utilisée pour gérer la politique d’acquisition en prenant en compte des données telles que le profil sociologique des lecteurs qui fréquentent chaque bibliothèque du réseau, les contraintes de place et le taux de rotation des collections.
L’article présente des développements intéressants sur la méthodologie de mise en place « des » projets big data : en effet, chaque application big data pour un usage particulier est perçue comme un projet à part entière, avec son équipe propre qui travaille sur le profilage des données à utiliser.

Enfin, la troisième piste c’est l’évolution des usages des chercheurs. Je suis tombée un peu par hasard sur ce compte-rendu d’une journée d’étude tenue par des sociologues à la British Library (2013) qui me semble bien illustrer le problème. Dans certaines disciplines, notamment en sciences humaines, l’enjeu de l’exploitation des collections par les chercheurs est en train de se déplacer : ils ne veulent plus « lire » le contenu des documents mais exploiter de façon globale la collection et son organisation par les bibliothécaires, qui devient signifiante en tant que telle. Savoir combien de documents concernant tel ou tel sujet ont été publiés entre telle ou telle date, combien d’occurrences du nom d’une personne, d’un lieu ou d’un concept apparaissent dans un corpus donné deviennent des clefs de recherche aussi intéressantes que ce qu’on pourrait apprendre en dépouillant dans le détail ces documents ou ces corpus.
Dès lors, la question va être de savoir si les bibliothèques seront capables d’offrir aux chercheurs un service de big data sur les collections qu’elles conservent : leur permettre de définir leur propre corpus, leurs critères et d’appliquer des outils d’analyse pour extraire de nouvelles informations à partir des données.

Ayant eu récemment le plaisir de rouvrir le dossier Archives de l’Internet, j’ai enfin réussi à entrevoir l’étape qui prendra la suite de la vision que j’avais eue en 2009 lors de la journée IIPC. Il me manquait alors l’idée que les outils qui permettraient d’étudier cette collection ne se limiteraient pas à la restituer telle quelle ou à l’indexer en plein texte, mais nécessiteraient de la triturer sous tous les angles en extrayant, autant que possible, les data. Si dans les archives du Web il y a de la donnée structurée (par exemple celle qui serait issue du Web de données…) cela pourrait bien être un atout de premier plan. Je pense que j’aurai l’occasion de creuser cette idée dans les mois à venir.

Je vais conclure cette réflexion avec cet article récent sur le big data en France (via GFII) qui s’inquiète de ne pas le voir décoller. On pourra aussi utilement feuilleter la feuille de route big data du ministère de l’Économie pour achever de se convaincre que les bibliothèques françaises ont encore quelques années lumières à parcourir avant d’apparaître dans le paysage. Mais ce seront des années intéressantes.

Un dernier lien à ne cliquer que si vous êtes un geek hardcore, trouvé sur le profil twitter de Got que je remercie comme d’habitude pour les discussions sur le canapé.

Pourquoi j’ai accepté de sacrifier mes URL

Suite au déménagement du Figoblog, certaines personnes ont été émues par ma décision de ne pas assurer la continuité de service sur les URL des billets. En effet, comment peut-on consacrer tant d’énergie à défendre la cause des identifiants pérennes et se retrouver au final, tel le cordonnier, si mal chaussé ? Quelques explications s’imposent.

D’abord, un mot sur la cause technique. Comme je l’indiquais dans mon précédent billet, le Figoblog tourne maintenant sur une plateforme hébergée, à savoir WordPress.com. Si Got avait eu la main sur le serveur, il aurait pu mettre en place une réécriture d’URL : mes adresses en « /node/[identifiant-du-billet] » étaient en effet suffisamment simples pour que cela puisse fonctionner et l’identifiant a bien été récupéré dans les métadonnées du billet lors de la migration. Mais c’est ça, le problème du SAAS : on n’a pas toutes les fonctionnalités qu’on veut.

Ceci posé, comment aurais-je pu faire pour éviter ce drame, ce génocide, la mort de plus de 600 pauvres petites URL qui n’avaient fait de mal à personne ?

Pour commencer, j’aurais pu choisir une autre plateforme offrant cette fonctionnalité. Il aurait alors fallu que je fasse un critère de priorité de cette fonction, critère qui se serait trouvé prépondérant par rapport aux autres intérêts de WordPress.com (notoriété, gratuité, simplicité d’utilisation, etc.) bon, ce n’est pas le choix que j’ai fait ; il me semblait que les avantages de l’utilisation de cette plateforme, dont le fait qu’on a migré en 24h chrono, surpassaient les inconvénients.

J’aurais aussi pu choisir de laisser mon blog où il était et d’en commencer un nouveau. Après tout, c’est ce que font beaucoup de gens : voyez par exemple ARHV qui a déménagé pour l’Atelier des icônes avant de fermer boutique et passer sur Image sociale. Sur chacun de ses « anciens » blogs, un message indique qu’il est fermé et pour lire la suite, renvoie au nouveau. De fait, les vieux liens vers ARHV que j’ai pu créer dans mes anciens billets fonctionnent toujours.
C’est à dire qu’au lieu de tuer 600 URL, j’aurais pu accepter de laisser mourir mon blog tout seul… Mais tout entier.
Ah non. Ça, ce n’était pas possible. Vous voyez, je suis quelqu’un qui a besoin de changement. Souvent, je déplace tous les meubles de mon salon. Et quand j’en ai marre de déplacer les meubles et que je recherche un changement plus radical, je déménage. Mais je n’ai encore jamais déménagé en abandonnant tous mes meubles et mes cartons derrière moi.
En plus, pour être très franche, je n’ai pas l’intention de me remettre à bloguer beaucoup plus souvent ; alors quitter un blog pour en créer un nouveau qui resterait vide, cela n’avait pas tellement de sens.
Enfin, dans l’opération, j’aurais perdu la notoriété associée à mon nom de domaine : figoblog.org. Le fait que les gens le connaissent, ainsi que son référencement.

Donc quand Got m’a annoncé que les URL allaient être brisées, j’ai dit « tant pis ».
Comment puis-je encore me regarder dans une glace et dormir sur mes deux oreilles après avoir pris une décision pareille ? J’ai plusieurs choses à dire pour ma défense.
La première, c’est que ce n’est qu’un blog. Je n’ai jamais pris le moindre engagement institutionnel quant à la pérennité des URL de chaque billet. Le web change, bouge, chaque jour des URL naissent et meurent. Il y a des dizaines, des centaines de liens morts dans les vieux billets du Figoblog que j’ai emmenés avec moi dans ce déménagement. C’est la vie. Si on veut une image figée du web, il faut aller dans les archives (ou le dépôt légal).
La deuxième, c’est que d’un point de vue fonctionnel, j’estime qu’aujourd’hui on dispose de tous les outils nécessaires pour retrouver un billet, à commencer par le moteur de recherche intégré (là, à gauche). Et grâce à ma nouvelle plateforme, on tombe directement sur ce moteur quand on arrive sur un lien mort sur mon blog.
Last but not least, il me semble que l’usage principal d’un blog n’est pas (ou rarement) d’accéder aux vieux billets par des favoris. En général on les retrouve par son moteur de recherche préféré et de toute façon ce sont les nouveaux billets qui comptent (même si en me relisant j’ai trouvé quelques vieux trucs intéressants !) Quant aux twitts et autres posts Facebook qui sont mes principaux référents, ils sont encore plus éphémères…

Que peut-on retenir de cette aventure ? Et bien, que la pérennité a un coût. Maintenir des URL implique de trouver un équilibre entre le niveau de pérennité nécessaire et attendu des identifiants et les moyens dont on dispose pour les maintenir.
Sur mon ancien blog, le fait même de bloguer était devenu compliqué, laborieux, je ne pouvais plus voir le design en peinture, il y avait des bugs et du spam et plein d’autres inconvénients. Il fallait migrer. Got et moi n’avions que des moyens humains très réduits à consacrer à cette migration et nous avons dû faire des choix. Nous avions tout testé avec succès sur WordPress.com : l’import des anciens billets, les fonctionnalités front et back-office… Si je m’étais crispée sur cette histoire d’URL, tout était à refaire et la migration sans doute remise aux calendes grecques.

Pour résumer, la maintenance des URL était une fonction secondaire en termes d’usage, pour laquelle nous n’avions pas de politique stricte, et dont le coût était tel qu’il était susceptible de menacer l’activité elle-même (le blog). Dans ces cas-là, il faut savoir faire son deuil.

Le Figoblog nouveau est arrivé

Pour fêter en beauté le nouveau cru 2015, le Figoblog fait peau neuve.

Ça fait du bien (le design du site n’avait pas été rénové depuis 2008) mais surtout, mon très cher administrateur du site et moi-même avons décidé d’aller dans le sens de l’histoire. Nous abandonnons un système basé sur un logiciel open source et une exploitation internalisée (dans notre salon) pour aller vers une plateforme en SAAS (Software as a service).

Cette évolution va certes limiter un peu les fonctionnalités, mais elle permettra au Figoblog de bénéficier régulièrement et sans douleur des améliorations courantes de la plateforme et de son support. Par exemple, je devrais voir disparaître mes problèmes de spam et vous pourrez de nouveau mettre des commentaires (youpi !) Finis les thèmes mitonnés à la main avec notre plus beau Photoshop+CSS, là aussi je rentre dans le rang en adoptant l’un des nombreux thèmes librement disponibles.

Par ailleurs je quitte Drupal pour WordPress, non pas parce que je n’étais plus heureuse avec Drupal (et nous resterons bons amis) mais parce que les fonctionnalités de WordPress sont suffisantes pour mes besoins.

Bon, il y a juste un « léger » « petit » inconvénient : dans l’opération, toutes les URL des anciens billets vont être perdues. Pensez également à rafraîchir vos flux RSS. Je pense que la page 404 va être la plus visitée du site pendant un temps. Ah, les identifiants pérennes…