La reconnaissance d’une exception au data mining s’accélère depuis quelques mois. De plus en plus, l’extraction automatisée des textes, des données et des images semble indissociable du droit de lire.
L’échec du processus du Licences for Europe a, du moins pour un temps, signé l’échec de la tentative de « féodalisation » du droit par les éditeurs scientifiques : ceux-ci ne sont pas parvenus à imposer le principe de licences contractuelles d’accès à leurs corpus éditoriaux. La commission européenne multiplie les signes de revirement. Un rapport a été commandé au juriste britannique Hargreaves, partisan d’un assouplissement du droit des bases de données. Un autre rapport du juriste belge Jean-Paul Trialle, dévoilé début avril, allait dans le même sens.
Les États européens redoutent de se faire distancer par les États-Unis, où la législation, plus flexible, s’est mieux adaptée à la généralisation des pratiques d’extraction. Le dernier jugement rendu dans le cadre du procès Google Books a globalement acté l’idée que le data mining à des fins scientifiques ou pédagogiques rentrait dans le périmètre du fair use.
À la fin mars, le Royaume-Uni a officiellement adopté une exception qui reprend pour l’essentiel les propositions de Hargreaves (je vous invite à lire l’excellente synthèse de Lionel Maurel sur cette évolution en demi-teinte). La France s’interroge également. Le Conseil Supérieur de la Propriété Littéraire et Artistique va prochainement publier un rapport sur le sujet. Il intègrera notamment une synthèse du collectif Savoirscom1, que j’ai rédigé avec Lionel Maurel. L’affaire Elsevier a également contribué à susciter un débat public : l’ABDU et le consortium Couperin ont récemment dénoncé les méfaits d’un data mining contractualisé (sans pour autant remettre en cause l’accord avec Elsevier).
Des nouveaux outils commencent également à émerger pour tenir compte de ces nouveaux usages. Destiné à être opérationnel en 2015, Europeana Newspapers intègrera une reconnaissance sémantique des différents articles de la presse ancienne.
En attendant… c’est bien compliqué. Je me suis mis en quête d’extraire automatiquement une série de textes hébergés sur Gallica : des chroniques boursières publiées dans le Journal des débats. Aux incertitudes légales s’ajoutent des complications techniques pas forcément justifiées.
Data mining en milieu inhospitalier…
La politique légale de la BNF est très ambiguë. Mes collègues de Wikisource en savent quelque chose : la BNF interdit officiellement certains usages, mais les tolèrent de facto…
Les œuvres et les créations passées dans le domaine public sont publiés sous une licence non-commerciale dans Gallica. Cette protection indue constitue un exemple typique de copyfraud : la BNF improvise des restrictions totalement contraires à la définition usuelle du domaine public dans la jurisprudence française. Et le pire reste à venir : les contrats proquest accordent une exclusivité complète d’utilisations de fichiers dans le domaine public à un acteur privé.
Or, Wikisource réutilise très largement des fichiers de Gallica, sans reprendre la licence non-commerciale : les œuvres sont republiées sous le statut général du domaine public. À ma connaissance, la BNF ne s’est jamais plainte de ce détournement évident de leurs conditions d’utilisation. Elle encourage en fait ces reprises, qui contribuent à enrichir le patrimoine intellectuel francophone. La communauté ne se contente pas de reproduire : elle enrichit les documents originels en créant une version textuelle corrigée manuellement (nul OCR n’est parfait).
Le data mining soulève des problématiques similaires. Les conditions d’utilisation de Gallica brassent large : « La réutilisation commerciale de ces contenus est payante et fait l’objet d’une licence. Est entendue par réutilisation commerciale la revente de contenus sous forme de produits élaborés ou de fourniture de service.» Elles ne s’appliquent pas seulement à des œuvres mais à l’ensemble des contenus (données, images, etc.). La réutilisation commerciale ne porte pas seulement sur la revente effective mais aussi sur la fourniture de service. Il n’est pas exclu que je sois payé par un projet de recherche pour faire du data mining sur Gallica : ce cas de figure s’apparenterait pleinement à une fourniture de service.
Ces contraintes légales sont renforcées et prolongées par des contraintes techniques. Gallica n’offre aucun service pour récupérer automatiquement les documents ou leur transcription OCR. Les fichiers PDF ne sont pas disponibles sur le web : l’on doit les « commander » via un protocole FTP. Cette contrainte technique vise à empêcher le moissonnage. La direction de la BNF redoute une absorption par un géant du web (Google en l’occurrence) : tout ce qui prévient la reprise automatisée du corpus bibliographique est bon à prendre, même si cela limite forcément les usages (tout téléchargement prend une à deux minutes, le temps de sélectionner les boutons, de cocher les cases et de cibler le document à enregistrer dans le bon dossier).
Le site paraît ainsi un peu inhospitalier. Pas suffisamment toutefois pour décourager un chercheur un peu hacker… Il existe des trappes secrètes et des chemins de traverses : les documents sur Gallica sont accessibles sous plusieurs modes. Deux modes en particulier se prêtent à une extraction automatisée, le mode texte et le mode zoom.
Extraction des textes : l’application Pyllica et ses limites…
Comme son nom l’indique, le mode texte publie une version textuelle du fichier. L’OCR de Gallica génère des résultats convenables. Il reconnaît les colonnes de texte (ce qui est impératif pour travailler sur la presse). Lorsque la copie est bonne, le taux d’erreur demeure convenable (en général un mot mal lu sur vingt). Comme nous aspirons à faire du data mining à grande échelle, cette petite part d’inexactitude n’a pratiquement aucune incidence.
À cette fin, j’ai écrit une petite application en python disponible sur Github, Pyllica (eh oui, je le concède, mon branding n’a rien de bien original).
Pyllica, donc, aspire les versions textuelles des document de Gallica et les transforme en fichiers bien proprets et proprement nommés. Il existe une fonction générique pour les documents standards, textbook. Je vais plutôt m’appesantir ici sur la fonction dédiée à la récupération des journaux, textpress. Elle intègre plusieurs paramètres permettant d’obtenir des séries d’exemplaires personnalisées de n’importe quel titre.
Les fonctions temporelles s’appuient sur la navigation par calendrier mise en place par Gallica. Elles définissent une date de départ, l’écart en nombre de jours entre chaque exemplaire recherché, et le nombre d’exemplaires au total. Cet écart est tout particulièrement utile lorsque l’on s’intéresse à des rubriques, des chroniques ou des séries d’articles publiant sur une base temporelle prédéterminées. En l’occurrence, je m’intéresse à la chronique boursière hebdomadaire du Journal des débats. Il me suffit maintenant de définir un écart de 7 pour obtenir l’ensemble des exemplaires du lundi, date de parution de la chronique.
Les fonctions éditoriales intègrent notamment l’échantillon de pages de recherchées (par exemple, de la page 3 à la page 4) et des séparateurs. Les rubriques ne sont en effet pas distinguées dans la version textuelles : nous n’obtenons qu’un long filet de texte. Sauf à étudier une page entière, aucune analyse quantitative ne serait envisageable dans ce cadre. L’un de mes projets à terme consisterait à compiler les principaux séparateurs des principales rubriques des principaux quotidiens français : par exemple “REVUE DE LA SEMAINE.” constitue le meilleur séparateur possible pour distinguer le début de la chronique boursière dans le Journal des débats au milieu du XIXe siècle (je n’ai jamais eu un seul faux positif). Pour la fin de la rubrique j’ai opté pour le nom de la rubrique disposées juste après (le “BULLETIN AGRICOLE”) : le nom du chroniqueur « Jules Paton », ne survit pas très bien à la transcription OCR. Parmi les fonctions éditoriales, j’ai aussi ajouté quelques expressions régulières, destinés à clarifier le texte (retraits des traits d’union disposés à la fin d’une ligne).
Bref, tout est pour le mieux… sauf que non. La version textuelle ne reconnaît pas l’un des composants fondamentaux de la presse française du XIXe siècle : le feuilleton. Le feuilleton apparaît pendant le directoire, comme un moyen de contourner une nouvelle taxe sur les suppléments de presse (en fait une forme de censure plus ou moins déguisée). Il s’agit d’un supplément greffé à la surface du journal et disposant de sa propre structure rédactionnelle. Le feuilleton constitue un laboratoire éditorial où émergent de nombreuses formes journalistiques : le roman-feuilleton, les publicités, la critique littéraire, les cours de la bourse…
Le feuilleton est bien dessiné sur les journaux : une épaisse bande noire le sépare de la partie haute. L’objet est facilement lisible pour un humain, mais aussi par une machine. On aurait pu espérer que l’OCR de Gallica spécifie le début et la fin du feuilleton par un signe quelconque. On ne trouve rien de tel. Ma chronique boursière en vient ainsi à intégrer une masse textuelle qui ne devrait pas s’y trouver.
À ma connaissance, il n’y a aucun moyen de discriminer ces indésirables en recourant à des expressions régulières ou à des analyses probabilistes de vocabulaire : le texte présent dans le feuilleton est trop proche de la chronique (il comprend notamment des publicités pour des émissions boursières).
Extraction des images : l’art du temps long
Nous voici donc ramené à notre point de départ : pour faire du bon data mining des documents journalistiques de Gallica, nous devons disposer des fichiers originels, et non simplement de la version OCRisée. Le téléchargement par des voies usuelles est exclu. J’avais tenté il y a quelques mois de truquer le processus de « commande » personnalisé des PDFs, en créant une série de requêtes automatisée pour actionner les boutons et cocher les cases. Le trucage s’est avéré finalement trop complexe pour mes compétences de programmeur amateur…
Un wikipédien m’avait mis sur une autre piste il y a quelques années. Gallica comporte un mode zoom qui permet de consulter un texte avec la plus haute résolution possible (ce qui est tout bonnement indispensable pour un corpus de presse). Pour d’évidentes raisons d’ergonomie, la version zoomée ne constitue pas une image unique, mais une collection d’images. Ainsi lorsque le lecteur consulte une portion du texte, le serveur n’est pas contraint d’afficher un scan bien lourd (il faut compter 20 à 40 millions de pixels pour une page de journal). Il se contente d’afficher suffisamment d’images au format 256×256 pour remplir la fenêtre d’un navigateur.
Curieusement, alors que les pdf sont bien cachés derrière un protocole FTP, les images composant la version affichées en ligne sont directement accessibles en ligne. L’url est, de plus, assez commode : elle agrège toutes les informations indispensables à connaître (coordonnées de l’image, niveau de zoom…).
Un combo de quelques bibliothèques python (urllib pour le téléchargement, PIL pour la gestion des images) permet de télécharger l’ensemble des images et de les recoller dans un document unique. La réalisation de ce puzzle nécessite de connaître les coordonnées finales du fichier : la presse au XIXe siècle évoluait vers des pages d’ampleur croissante et des textes de plus en plus condensés, ce qui amène Gallica à créer des fichiers de plus en plus lourds. Par exemple, la résolution du Journal des débats est de 3840/2304 px en 1815. En 1845, l’aire couverte a quadruplé en passant à 6400/4864 px.
Cette contrainte peut être contournée en créant une base de données des coordonnées finales, voire en récupérant directement cette information avec un scraper (il suffit de repérer la dernière balise img, quelque chose tout à fait à la portée de beautiful soup…).
Il y a encore un souci de taille : le temps. Urllib n’est pas performant : le téléchargement d’une seule page d’un exemplaire des débats de 1845 prend près de 10 minutes. J’ai tenté de recourir à une bibliothèque mieux réputée, Requests, sans beaucoup de succès. Requests s’en sort peut-être mieux avec l’ouverture des pages web, mais il peine avec les images.
Pour deux pages l’ensemble du processus (qui comprend aussi la transcription OCR avec pytesser et diverses opérations de clarifications avec expressions régulières) dure jusqu’à une demi-heure, ce qui est franchement déraisonnable. L’image mining redevient praticable si l’on se focalise sur de petites portions du texte journalistique. Certains rubriques reviennent à une place récurrente : il est possible de délimiter leurs coordonnées dans le référentiel de 256/256 images. J’ai ainsi pu extraire l’image suivante en moins de 30 secondes :
La piste de l’image mining reste ainsi envisageable pour de courtes rubriques solidement amarrées à un lieu précis du journal. Ce n’est pas le cas de ma chronique boursière qui passe son temps à gigoter entre la page trois et la page quatre : dans le jargon de l’époque, on dirait qu’elle appartient au « ventre mou » du journal, cette partie insaisissable qui évolue au gré de la matière disponible ou des opportunités du jour (scoop, etc.).
Expérimentations, conclusions, évaluations…
Fort de toutes ces expérimentations… je me suis résigné à retirer manuellement les morceaux de feuilletons qui s’étaient glissés au milieu de mes chroniques boursières. Dans son ensemble, le processus reste rentable. Il me faut environ une heure pour récupérer une année de chroniques bien formatées, ce qui comprend dix minutes d’extraction automatisée… et 50 minutes de corrections manuelles.
J’en retire également une conviction : la numérisation n’est qu’un début. En l’absence d’applications permettant l’extraction et la sémantisation, les images ou les textes n’offrent qu’un intérêt limité pour la recherche. Tant que les bibliothèques digitales verront l’extraction automatisée au mieux comme un phénomène marginal, au pire comme une menace, leurs corpus, souvent immenses, resteront sous-exploités.
Notons tout de même Gallica n’est pas le plus mauvais élève en la matière. Les éditeurs scientifiques font bien pire (Elsevier au premier chef, qui va jusqu’à définir sa propre loi sur le data mining au mépris des usages et des règles déjà existantes). Et Google Books ne perd sans doute rien pour attendre.
Et pour finir, voici une petite tentative d’évaluation en mode jeuxvideo.com (en bon chercheur hacker j’ai un petit penchant pour les références geeks…).
Accessibilité des fichiers : 3/20. Les fichiers PDF sont uniquement accessibles depuis un protocole FTP et en peuvent être récupérés automatiquement (sauf peut-être pour un programmeur expérimenté…). Les textes sont faciles à reprendre avec un petit script de scraping élémentaires. Les images peuvent être reconstituées en compilant les morceaux de 256/256 pixels. Bref, en faisant un peu de bidouille on parvient à quelque chose, mais rien n’est fait pour faciliter la vie.
Lisibilité des urls : 17/20. Les urls sont très précises et comportent presque toutes les informations souhaitées (date des journaux, pages, mode de lecture, etc.)
Sémantisation des documents : 1/20 : L’OCR reconnaît les colonnes. Et voilà tout… Europeana Newspaper promet de faire bien mieux, mais cela ne devrait porter que sur un corpus assez limité (18 titres au total sur les centaines de Gallica).
Métadonnées et données associées : 18/20. Les documents sont très bien renseignées. Et Gallica a récemment ouvert l’ensemble de ces riches métadonnées.
Statut légal : 1/20. Toute réutilisation implique une licence non commerciale, même si Gallica ne se démène pas pour l’appliquer. WIkisource ne se soucie aucunement de ces contraintes légales byzantines. Une institution scientifique n’aura sans doute pas la même audace.
Note globale : 8. Quelques aspects positifs (les urls, les métadonnées) ne parviennent pas à compenser des déficiences fondamentales (pas d’accès simple aux fichiers, ni de sémantisation préalable) ou un statut légal inapproprié.
OpenEdition vous propose de citer ce billet de la manière suivante :
Pierre-Carl Langlais (20 avril 2014). Peut-on faire du data mining sur Gallica ? Sciences communes. Consulté le 7 octobre 2024 à l’adresse https://doi.org/10.58079/twwh
Tu peux afficher dans Gallica jusqu’à 2236/2236 pixels maximum.
Tu n’as qu’à changer les deux derniers chiffres qui correspondent à la taille de l’image.