Après Elsevier et Gallica, voici un nouvel épisode de ma série sur le data mining. Cette fois-ci je m’attaque à L’industrie majeure du web, celle qui fait figure de métaphore de l’internet tout entier : Google. Ou, plus exactement, son service d’indexation bibliométrique des articles scientifiques, Google Scholar (même si les problématiques abordées ici sont largement applicables à l’ensemble de l’écosystème Google).

Les techniques de data mining (ou extraction automatique des données en bon français) s’apparentent à autant de sympathiques secrétaires, prompts à assister le chercheur dans la moindre de ses tâches. Ils peuvent être employées dans des projets d’analyse classique portant sur un corpus proprement délimité (c’était l’objectif de ma petite application d’extraction des textes journalistiques hébergés sur Gallica, Pyllica). Ils ont aussi une vocation plus méta : permettre de saisir rapidement un champ de recherche en moissonnant les méta-données bibliographiques.

Modéliser un champ de recherche avec Google Scholar

À ce jour, Scholar est la principale alternative gratuite aux grandes bases de données scientifiques telles que le Web of Science de Reuters ou Scorpus d’Elsevier. Par-delà son accessibilité, le service se distingue par une conception volontairement laxiste de la référence scientifique : est référencée sur Google Scholar toute publication déjà citée dans un publication présente sur Google Scholar. Cette ouverture présente plus d’avantage que d’inconvénients. Les conférences ou les working papers, globalement absents de Scorpus, sont correctement recensés. Par compensation, les résultats doivent être appréhendés avec un certain esprit critique (mais c’est de toute façon nécessaire pour n’importe quelle recherche bibliographique : même la revue la plus réputée qui soit peut se tromper et publier un article de qualité relative).

Scholar intègre une fonction très utile pour les recherches bibliographiques : la fonction « cité par ». Concrètement, il est possible d’évaluer l’influence d’une étude en retrouvant l’ensemble des études ultérieures qui la citent. Je me sers fréquemment de cette fonction pour reconstruire rapidement l’état d’un champ de recherche (dans le jargon académique on parle aussi de faire l’état de l’art).

Dans certains cas, le nombre de citations est considérable : des publications influentes peuvent être citées des centaines voire des milliers de fois. Sauf à y passer des heures, il devient difficile d’avoir un tableau global de cette littérature dérivée. C’est là qu’intervient le data mining. L’extraction automatisée des métadonnées bibliographiques permettrait de repérer rapidement certaines tendances structurelles (typiquement, le nombre de publication par années, les mots-clés utilisés dans les résumés). Évidemment, ce repérage ne prétend pas se suppléer à une lecture approfondie, mais il permet un gain de temps substantiel.

Pourquoi Google Scholar n’a pas d’API ?

On pourrait penser que Google Scholar serait le terrain de jeu idéal pour une série d’extractions automatisées. Après tout, Google se donne fréquemment une image de firme open, amie du logiciel libre et du mouvement d’ouverture des savoirs. Et pourtant ce n’est pas du tout le cas.

Avant toute chose, nous nous mettons en quête d’une API. Pour mémoire, une API, ou Application Programming Interface, désigne un programme permettant à une interface de communiquer ses données avec l’extérieur. Les APIs montrent vite leurs limites pour une recherche sophistiquée : le détenteur de l’interface définit en effet des catégories pré-remplies qui limitent fortement le champ des recherches possibles. Néanmoins, notre projet (récupérer toutes les métadonnées des références qui citent une référence pré-définie) reste assez simple. On peut légitimement espérer que l’API de Google Scholar permette de réaliser quelque chose qui s’en approche.

Or, il n’existe pas d’API pour récupérer les données de Google Scholar. C’est là une anomalie curieuse. Google Books dispose d’une API depuis plusieurs années. Pourquoi Google néglige-t-il de développer un service d’extraction pour Scholar ? L’intérêt du public ciblé est pourtant patent : Scholar s’adresse à des chercheurs plutôt familiers des nouvelles technologies, soit des gens a priori intéressés (et motivés) pour utiliser des outils de recherche un peu poussés. Vraisemblablement, Google ne tient pas à froisser les multinationales de l’édition scientifique. Google Scholar n’a que vocation à enrichir « l’expérience utilisateur » : il n’est pas valorisé en tant que tel. Google ne tient pas à saborder le business d’Elsevier et Reuters (d’autant plus que ces deux entreprises ont vraisemblablement des budgets d’e-marketing non négligeables).

Je suis donc amené à rédiger mon propre petit programme d’extraction. En combinant une bibliothèque de parsing HTML (Beautiful Soup) et des expressions régulières, j’arrive rapidement à obtenir des résultats satisfaisants. Pour des raisons qui deviendront vite évidentes par la suite, je n’ai pas republié ce bout de code sur Github.

Le titre, l’année, le nom de la revue, le nombre de citations : toutes ces données sont correctement extraites et reportées dans un document csv.

Il y a pourtant un petit souci. Lorsque le nom de la revue est trop long, Google Scholar le présente sous une forme abrégé. Ce problème survient assez peu souvent. Il reste envisageable de le corriger à la main ou, si les résultats deviennent trop nombreux, de l’ignorer purement et simplement (lorsqu’on manipule une base de données de bonne taille, on n’est pas à une marge d’erreur près).

Tout fonctionne pour le mieux… Il y a pourtant un hic. Tout comme Elsevier, Google interdit formellement le parsing : on est prié de se servir d’une API sauf que, dans le cas de Google Scholar, l’API n’existe pas. Faute de mieux, je maquille mon programme d’extraction en navigateur web standard. Je prends soin d’inclure un temps d’attente de quelques secondes entre chaque ouverture de page : après tout, il m’arrive d’ouvrir compulsivement des pages de résultats de cette manière.

Mes précautions sont vaines. Google finit par me repérer. Mon petit programme est bloqué et n’extrait plus rien. Lorsque je rouvre Google Scholar par des voies traditionnelles, je dois rentrer un captcha pour prouver que je ne suis pas une machine. Il va falloir trouver une tactique plus subtile pour tromper l’attention de big brother.

Quand le data scientist se fait hacker…

Le maquillage de mon programme en navigateur standard ou l’utilisation d’un temps d’attente entre chaque ouverture de page n’étaient que des détournements élémentaires. Pour faire du data mining « sauvage » avec les contenus publiés par les grandes industries du web, il n’y a d’autres alternatives que le hacking pur et dur.

Une première stratégie efficace consiste à travestir complètement notre algorithme en humain. Cela suppose d’opter pour des intervalles d’ouverture de page aléatoires (typiquement dans une échelle allant de 15 à 60 secondes), en prenant un temps minimal au moins supérieur à 15 secondes. Les résultats de cette stratégie sont améliorés si l’on change de navigateurs en cours de route. Seulement, dans ce cadre, l’extraction devient looooooooooongue… Pour 60 pages de Google Scholar il faut compter au minimum une demi-heure. Bref, ce n’est praticable que l’on ne s’intéresse qu’à un nombre de pages assez limité (pas beaucoup plus d’une cinquantaine).

Une seconde stratégie, beaucoup plus ambitieuse, vise à empêcher toute tentative d’identification pérenne en passant sur le réseau TOR. La mascarade va beaucoup plus loin : Google ne va pas croire que notre programme est une personne, mais qu’il est plusieurs personnes, l’adresse IP n’arrêtant pas de changer. Je n’ai pas encore tenté l’affaire. Cette nouvelle stratégie demande une préparation non négligeable : le navigateur TOR doit être préalablement configuré pour être utilisé par un script externe.

Faire de la bibliographie un bien commun

Que conclure de cette petite mésaventure ?

D’abord que Google n’est pas une organisation caritative. L’accès apparemment gratuit ne doit pas induire en erreur : la firme californienne veille jalousement sur son patrimoine numérique. Ses nombreuses activités ne sont peut-être pas immédiatement rentables, mais elles aspirent toutes à une rentabilité à terme. Google Scholar fait typiquement partie de ces opportunités en attente. Avec, l’intégration des mesures quantitatives du web dans les métriques d’évaluation, le tournant numérique des grands éditeurs scientifiques et le développement des réseaux sociaux scientifiques, les diverses statistiques de Scholar (notamment la consultation) prennent de plus en plus de valeur.

Ensuite, les bibliographies scientifiques sont soumises à d’importantes enclosures. Avec le déclin des revues traditionnelles, le modèle économique des industries académiques  se déporte de plus en plus vers l’accès aux données et métadonnées scientifiques. Or, les métadonnées bibliographiques font partie du domaine public de l’information : leur privatisation de facto est totalement illégale. Rien ne devrait empêcher leur libre reprise.

Faute de mieux, Google et Elsevier recourent à un argument qui ne fait guère illusion : l’extraction automatisée risque de casser les serveurs en mobilisant excessivement leur ressources (un programme d’extraction adossé à une bonne connexion internet peut récupérer plusieurs milliers de pages en une minute). C’est un exemple typique du sophisme de l’épouvantail : prendre un exemple extrême pour rejeter la totalité d’une proposition. Il est tout à fait envisageable d’autoriser un usage modéré du data mining (pour un site aussi light que Google Scholar, 100 pages par minute est tout-à-fait supportable : une vidéo de YouTube en haute qualité consomme bien plus de ressource).

Comme le soulignait un collègue blogger en 2009, il serait grand temps de faire de ces ressources bibliographique un bien commun. Certains projets s’y emploient. C’est le cas de Wikidata qui vise à créer des entrées pour la plupart des sources fiables afin de référencer et de vérifier les données dans une approche typiquement wikipédienne. Si je disposais d’un peu plus de temps, je suis presque tenté de pomper une bonne partie de Google Scholar pour le transférer sur Wikidata (une opération-commando de libération du savoir tout-à-fait légale soit dit en passant…).

Enfin, comme pour Gallica, voici une petite évaluation de l’accessibilité de Google Scholar aux projets de data mining (je pourrais presque finir par créer les data mining awards) :

Accessibilité des pages : 0/20. Les choses sont simple : c’est catch me if you can. Sauf à truquer la surveillance de l’ami Google, Google Scholar est complètement inaccessible

Lisibilité des urls : 7/20. Je n’ai pas eu l’occasion d’en parler : les urls sont suffisamment lisibles pour lancer des boucles, mais demeurent un peu cryptiques.

Sémantisation des documents : 5/20 : Les marqueurs HTML sont corrects. Par contre, des indications sont volontairement parcellaires, peut-être pour décourager les tentatives de recueil automatisé.

Statut légal : 0/20. Bien que les métadonnées soient, pour l’essentiel dans le domaine public de l’information (les résumés font peut-être exception), Google interdit complètement l’extraction automatisée.

Note globale : 4. La conception de Google Scholar n’est pas rebutante en soi et permet de monter en peu de temps un programme d’extraction automatisé potable. Seulement, Google ne vous aime pas, et le fait savoir.

---

---