trafilatura : extraire le texte utile d'une page web sans base de données

Le problème : le HTML brut n'est pas un corpus

Une page d'actualité contient le texte de l'article, mais aussi un menu, un bandeau de cookies, une liste d'articles liés, une signature, des appels à s'abonner. Si vous alimentez un index de recherche, un jeu de données d'entraînement ou une base documentaire avec le HTML complet, vous stockez surtout du bruit. trafilatura vise précisément ce nettoyage : le README indique que l'outil se concentre sur le contenu réel, évite les éléments récurrents comme les en-têtes et les pieds de page, et cherche un équilibre entre précision (limiter le bruit) et rappel (conserver toutes les parties valides).

Le public visé n'est pas le développeur qui écrit un scraper unique pour un site. C'est plutôt celui qui traite des dizaines de milliers de pages hétérogènes : équipes NLP, constitution de corpus, alimentation de chaînes de recherche augmentée. Le README mentionne d'ailleurs les mots-clés corpus-builder, text-mining et rag. Le projet est né d'un travail de thèse en linguistique et en traitement automatique des langues, à l'origine pour créer des bases de textes pour la recherche à l'Académie des sciences de Berlin-Brandebourg.

Découverte, téléchargement, extraction : trois étages distincts

L'architecture se lit dans la liste des fonctionnalités. Un premier étage découvre les URL : prise en charge des sitemaps au format TXT et XML, et des flux ATOM, JSON et RSS. Un deuxième étage gère le téléchargement, avec ce que le README appelle un traitement efficace et courtois des files d'attente, plus un filtrage et une déduplication des URL. Un troisième étage extrait le contenu.

Ce découpage est important en pratique : chaque étage est utilisable seul. On peut fournir à l'extracteur des fichiers HTML déjà téléchargés ou des arbres HTML déjà analysés, sans passer par le module de récupération réseau. Le traitement parallèle est annoncé pour les entrées en ligne comme hors ligne.

L'extraction du texte principal repose sur un extracteur maison à base de règles, avec jusText et readability-lxml comme solutions de repli. Les métadonnées récupérées couvrent le titre, l'auteur, la date, le nom du site, les catégories et les étiquettes. La structure est conservée sous forme de paragraphes, titres, listes, citations, blocs de code et sauts de ligne. Les commentaires, liens, images et tableaux sont optionnels, ce qui suppose des options d'activation dans l'interface, même si le README ne détaille pas leurs noms exacts.

Installation et premières commandes

Le paquet est publié sur PyPI et s'installe donc par pip. Le README ne donne pas de ligne de commande d'installation explicite, il renvoie à la page Installation de la documentation ; je ne peux donc pas citer ici une commande que je n'ai pas sous les yeux. Le seul extrait de code vérifiable est l'exemple Python du README :

from trafilatura import fetch_url, extract downloaded = fetch_url("https://github.blog/2019-03-29-leader-spotlight-erin-spiceland/") extract(downloaded)

La sortie par défaut est du texte brut. Avec output_format="json" et with_metadata=True, la même page produit une chaîne JSON contenant les clés title, author et text. Les formats de sortie annoncés dans les fonctionnalités sont TXT, Markdown, CSV, JSON, HTML, XML et XML-TEI.

Le README indique aussi qu'il existe une interface en ligne de commande, une utilisation depuis R, et un notebook d'introduction dans le dépôt sous docs/Trafilatura_Overview.ipynb. Les noms exacts des options de la CLI ne figurent pas dans le matériel fourni ; il faut consulter la page usage-cli de la documentation pour les obtenir.

Ce que l'outil n'ira pas chercher à votre place

Le point faible le plus net concerne le contenu produit par JavaScript. Rien dans le matériel fourni n'indique un moteur de rendu de navigateur. Le parcours décrit part du HTML téléchargé ou d'un arbre HTML déjà analysé, ce qui suppose que le texte soit présent dans la réponse du serveur. Sur un site qui construit son article côté client, l'extracteur travaillera sur une coquille vide. C'est une limite de conception, pas un défaut d'implémentation, mais elle décide du choix d'outil.

Deuxième réserve : la documentation publique citée dans le README est abondante, mais le README lui-même reste au niveau des fonctionnalités. Il annonce un extracteur robuste et raisonnablement rapide, sans chiffres. Les performances revendiquées renvoient à une section d'évaluation et à un fichier tests/README.rst permettant de relancer l'évaluation avec les données et les paquets courants. C'est une bonne pratique : la mesure est reproductible plutôt qu'affirmée. Cela signifie aussi que le chiffre qui compte pour vous est celui que vous obtiendrez sur vos pages, pas un classement général.

Troisième réserve, plus structurelle : le projet est maintenu par une personne, avec un appel explicite au sponsoring dans le README. Le rythme de publication récent montre des versions 2.1.0 et 2.2.0 en 2026, mais la version 2.0.0 datait de décembre 2024. Un intervalle de plus d'un an entre une majeure et la suivante n'est pas un signal d'abandon, c'est un rythme à intégrer dans votre planification si vous dépendez de correctifs rapides.

readability-lxml, BeautifulSoup, ou une API payante

L'alternative la plus directe est readability-lxml, qui porte en Python l'algorithme de lecture d'article. La différence d'approche est réelle : readability-lxml est un extracteur, point. Il ne fait pas de découverte de sitemaps ni de flux, ne gère pas de file de téléchargement, ne produit pas de XML-TEI et ne sérialise pas en CSV. trafilatura l'utilise d'ailleurs comme solution de repli, ce qui indique que l'auteur considère cette approche comme utile mais insuffisante seule.

BeautifulSoup est d'une autre nature : c'est un analyseur et un navigateur d'arbre HTML. Il vous donne les outils pour écrire vos règles, pas les règles. Si votre cible est un seul site stable avec une structure connue, quelques sélecteurs CSS suffisent et l'ajout d'une couche d'extraction générique n'apporte rien.

Face aux API d'extraction commerciales, l'écart tient à trois choses : le coût par page, la dépendance à un service tiers, et la reproductibilité. Un outil local vous laisse relancer la même version sur le même corpus des mois plus tard, ce qui compte pour un travail de recherche. En échange, vous héritez de la maintenance des sélecteurs et de la gestion réseau.

Licence et coût de maintenance

Le paquet est distribué sous Apache-2.0. Le README précise une exception notable : les versions antérieures à la v1.8.0 étaient sous GPLv3+. Ce changement de licence selon la version n'est pas anecdotique. Si vous intégrez trafilatura dans un produit distribué et que votre verrou de dépendance pointe vers une version ancienne, la question du respect de la GPLv3+ se pose à vous, pas à la bibliothèque. Je ne donne pas d'avis juridique : faites vérifier votre situation par qui de droit, en gardant en tête la frontière v1.8.0.

Sur le coût de maintenance, le matériel disponible ne permet pas de chiffrer la fréquence des mises à jour de compatibilité. Ce qu'on peut dire : les formats de sortie sont nombreux, donc une montée de version majeure peut toucher la sérialisation. Les versions 2.x ont suivi la 2.0.0 avec des incréments 2.1.0 et 2.2.0, ce qui suggère des évolutions continues plutôt qu'une réécriture. Le README encourage par ailleurs le parrainage, ce qui est un indicateur honnête de la charge qui pèse sur le mainteneur.

Évaluation : ce que le projet revendique et comment le vérifier

Le README affirme que trafilatura surpasse régulièrement les autres bibliothèques open source dans les benchmarks d'extraction de texte, et renvoie à trois évaluations externes : le benchmark d'extraction d'articles de ScrapingHub, où il est présenté comme la bibliothèque open source la plus efficace ; un travail de Lejeune et Barbaresi daté de 2020 ; et une comparaison de Bevendorff et al. (2023), où il obtient le meilleur score F1 ROUGE-LSum parmi les outils isolés. Ces références sont datées et portent sur des corpus précis. Elles ne préjugent pas de votre domaine.

Le point utile est ailleurs : le dépôt contient un fichier tests/README.rst qui décrit comment relancer l'évaluation avec les données et les paquets les plus récents. C'est la seule voie sérieuse pour trancher. Constituez un échantillon d'une dizaine de pages représentatives, passez-les dans extract() avec les options qui vous intéressent, et regardez ce qui manque et ce qui reste. Le compromis précision/rappel annoncé dans le README se manifeste différemment selon que vos pages sont des articles de presse, des billets de blog ou des fiches produit.

Conclusion éditoriale

Adoptez trafilatura si vous constituez un corpus de pages rédactionnelles en Python ou en ligne de commande et que vous voulez du texte propre sans infrastructure de stockage. Ne l'adoptez pas si votre cible est une application à composants, un document PDF ou un site dont le contenu n'existe qu'après exécution de JavaScript. Avant de vous engager, vérifiez deux choses concrètement : la version exacte que vous installez, car les versions antérieures à v1.8.0 relèvent de la GPLv3+ et non d'Apache-2.0, et la sortie de l'extracteur sur une dizaine de pages représentatives de votre domaine, en comparant le résultat par défaut avec extract(..., output_format="json", with_metadata=True).

Sources officielles

1. adbar/trafilatura on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases