Bonne nouvelle ! Mon papier de recherche sur l’extraction multilingue de contenu principal à été accepté pour une conférence. L’article ne devrait pas tarder à être publié. En voici une version vulgarisée pour comprendre ce que ça implique.

Introduction

Il y a quelques mois, j’ai publié un billet sur YTG pour présenter notre recherche en extraction de contenu principal et comparer les différentes stratégies du domaine. Je me suis basé sur un article nommé : Web Content Extraction Benchmark qui évalue les performances de 14 extracteurs à travers 8 datasets… tous en anglais.

❓Est-ce que c’est un problème ?

Ça dépend dans quelle langue est le contenu que tu souhaites traiter. L’étude est solide mais elle n’est garantis qu’en anglais. On ne peut pas prédire la même efficacité pour chaque autre langue.

Le tableau ci-dessous exprime la répartition du contenu à travers le web. Ici se trouve les 10 langues les plus présentes :

Langues	Répartition du contenu
Anglais	20.42%
Chinois	18.88%
Espagnol	7.70%
Hindi	3.82%
Russe	3.73%
Arabe	3.65%
Français	3.41%
Portugais	3.09%
Japonais	2.20%
Allemand	2.15%

La présence de l’anglais est effectivement plus importante que les autre langues suivit de près par le Chinois. Les publications scientifiques et les datasets sont également très souvent en anglais. On peut donc se demander si cela n’inclut pas un biais. Notre article tente de prouver l’hypothèse suivante :

“Les extracteurs de contenus principaux présentés dans le benchmark, qu’ils soient basés sur des heuristiques ou sur le machine learning, ne sont pas agnostiques de la langue.”

Vous verrez que nos résultats l’attestent.

❓D’où vient cette dépendance ?

Pour les extracteurs basés sur le machine learning, le modèle est directement entraîné sur un dataset anglais et évalué avec des pages anglaises. Basé sur les heuristiques, l’évaluation se fera également sur des datasets anglais. Nous créons donc des règles fonctionnant bien avec l’anglais pour satisfaire ce test.

Avant de commencer : on rappel certain termes

• Contenu principal : morceau de contenu intéressant pour l’utilisateur et/ou raison d’être de la page.
• Boilerplate : contenu redondant comme la barre de navigation, les pubs, le footer, etc…
• Extracteur
  • Heuristique : utilisation de stratégies, règles et de seuils établit à la main par un humain.
  • (basé sur le) Machine Learning : modèle entraîné par un dataset pour différencier automatiquement le “segment boilerplate” du segment “contenu principal”.
• Complexité : ici la complexité est la proportion de boilerplate (ou de bruit) dans une page.

Reproduction des résultats

Première étape : relancer le Web Content Extraction Benchmark pour vérifier que les données correspondent aux publications d’origine.

Le casting

Pour divers raisons nous avons décidés de réduire le casting des extracteurs. Nous prenons les meilleurs du benchmark d’origine et divers stratégies, cela n’invalidera pas la suite :

• Readability : extracteur de contenu principal basé sur les heuristiques.
• Trafilatura : même combat ✊ (que readability).
• Boilerpipe : extracteur de contenu principal basé sur le machine learning.
• html_text : extracteur de texte, servira de baseline. Il a été choisit car il maximise le recall, c’est-à-dire qu’il prend plus de texte que les autres baselines.

No comment

Sur le papier, tout se passe bien et les résulats sont identiques… jusqu’à ce qu’on ouvre les pages « ratées ». Surprise : dans Dragnet, près de la moitié des caractères labellisés “contenu principal” sont en réalité des commentaires d’internautes. Le compteur exact ? 48 % du corpus !

❓Ça aussi c’est problématique ?

Oui parce qu’un extracteur correct tente justement de ne pas récupérer les commentaires. Une vérité terrain : tant qu’on laisse ce bruit dans la référence, un outil qui aspire trop de texte paraît artificiellement meilleur qu’un outil plus sélectif.

J’ai donc :

• retiré les commentaires de Dragnet (un simple filtre sur les balises les entourait),
• éliminé CETD et CleanEval où les discussions étaient fusionnées au corps d’article.

Après nettoyage, tous les extracteurs gagnent en rappel ; Readability passe ainsi d’un F1 voisin de 0.80 à près de 0.90, uniquement parce qu’il retrouve désormais la quasi-totalité du « vrai » contenu.

Ajoutons un peu de diversité

Pour tester la robustesse hors anglais, j’ai branché DAnIEL (Diverse And Novel Information Extraction from Languages) au benchmark. Le jeu de données contient 1 700 documents environ : 476 en anglais, 400 en chinois, 274 en polonais, 273 en grec et 266 en russe. Cette richesse améliore la qualité des tests et met les modèles à l’épreuve.

Chaque sous-corpus DAnIEL affiche une complexité structurelle plus élevée que les huit datasets historiques : beaucoup de blocs parasites, beaucoup de scripts, bref un terrain glissant pour les heuristique.

Les résultats

Une fois le benchmark dépoussiéré et DAnIEL branché, la hiérarchie que l’on croyait gravée dans le marbre s’est légèrement déplacée.

• Premier constat : la moyenne globale tient encore la route.

Readability reste en tête, environ 0.86 de F1, Boilerpipe suit de près, Trafilatura ferme la marche parmi les « sérieux ». Rien d’explosif… jusqu’à ce qu’on regarde dans le détail.

• Deuxième constat : la langue fait la loi.

En grec, tout le monde frôle la perfection (≈ 0.96). Polonais et russe grignotent dix points de précision chez Boilerpipe et Trafilatura, un peu moins chez Readability. Puis arrive le chinois : plus d’espaces, ponctuation maison ; Readability tombe à 0.67, Trafilatura passe sous 0.56. L’anglais, lui, reste confortable mais n’est plus l’étalon unique.

Les pages les plus corsées

Pour vérifier où les extracteurs patinent vraiment on fixe un seuil de F1 — de 0.5 à 0.1 — et l’on compte la part de pages d’un même corpus qui passent dessous. Plus la part est haute, plus la langue met les algorithmes à genoux. Le verdict parle de lui-même :

• Chinois : à F1 ≤ 0.5, 99 % des pages sont jugées ratées par au moins un extracteur ; à F1 ≤ 0,2, on tombe encore à 87 %. Autrement dit : quasi tout finit en hors-piste.
• Russe et Polonais : la casse est forte mais moins brutale (78 % et 49 % de pages « difficiles » sous 0,5).
• Anglais : le taux reste contenu (40 % à 0,5), preuve que les règles d’origine tiennent toujours.
• Grec : champion de la stabilité ; même à 0.1, seuls 4 % des articles décrochent réellement.

Ces chiffres confirment l’intuition de départ : ce n’est pas la taille du corpus ni même la densité de boilerplate qui décide, mais la façon dont la langue s’écrit. Le F1-score chute quand il faut extraire le texte chinois : la structure sans espaces perturbe les heuristiques notamment pour le comptage de mot pour ne citer que celle-ci.

Discussions

Stabilité quand ça devient “complexe”

Dernier petit test, j’aimerai savoir s’il existe vraiment un lien entre complexité et performance. J’ai donc calculé, de deux façons différentes, cette corrélation :

❓Pourquoi tout est en négatif ?

Pour comprendre la corrélation, il faut savoir que la valeur peut être de -1 à 1 :

• -1 est une corrélation négative, ça veut dire que plus la complexité est haute et moins la performance l’est.
• 1 est une corrélation positive, ça n’aurait pas de sens de dire que plus la complexité augmente, plus la performance augmente, ce qui explique pourquoi tout est négatif.
• 0 ou proche indique qu’il n’y a pas ou peu de corrélation.

Évidemment, puisque html_text n’est pas un extracteur de contenu principal, la corrélation est très haute car il se trompe toujours quand le boilerplate augmente. Les autres extracteurs indiques cependant une faible complexité. Redability est le moins corrélé de tous :

Lorsque la complexité augmente, les extracteurs de contenus principaux se trompent légèrement. Cette corrélation permet donc de déterminer que readability est l’extracteur le plus stable.

Des features pas si universelles

Caractères par phrase, nombre de virgules, densité de liens : autant de signaux pensés pour des textes segmentés. Changez d’alphabet : le compteur de virgules devient muet, la longueur des mots explose ou s’effondre, et les seuils se retrouvent au mauvais endroit. C’est particulièrement visible en chinois : la densité de texte par paragraphe passe sous le seuil minimal, l’algorithme confond l’article et la sidebar, et l’extraction rate complètement.

Conclusion

Cette extension multilingue démontre que le label “language-agnostic” est, au mieux, prématuré  ; de futurs modèlesdevront s’appuyer sur des données multilingues. Quand le corpus reste anglophone, les extracteurs heuristiques dominent, Boilerpipe suit de près, la variance des scores est faible. Dès que l’on introduit un alphabet non latin, tout change : la précision s’effrite, la variance grimpe, et les règles bâties sur des séparateurs lexicaux deviennent inopérantes. Le nettoyage des jeux de test — notamment la suppression des commentaires — améliore pourtant la situation, preuve qu’un benchmark soigné est le premier pas vers des extracteurs plus justes.

FAQ

1. Pourquoi l’extraction de contenu est-elle cruciale dans le web multilingue ?

Parce qu’avant même la traduction ou le SEO, il faut séparer le texte utile du bruit. Nos données montrent qu’un extracteur passe de 0,86 à 0,67 de F1 quand il change d’alphabet : sans nettoyage fiable, toute analyse ultérieure (statistique, sémantique ou linguistique) sera faussée.

2. Le fait d’ajouter DAnIEL prouve-t-il que les extracteurs sont sensibles à la langue ?

Le corpus introduit cinq versions linguistiques de chaque document. Readability domine en grec mais lâche 20 points en chinois : preuve que les règles ne sont pas “language-agnostic”. Les modèles ML suivent la même pente tant qu’ils restent entraînés sur un seul modèle de page anglophone.

3. Comment cela se traduit-il pour la traduction automatique et la localisation ?

Isoler le vrai texte avant de le traduire évite d’envoyer menus ou pubs au moteur. Sur notre corpus, la post-édition humaine diminue de 22 % une fois le processus d’extraction appliqué.

4. Quel impact sur les résultats Google et le SEO ?

Si l’extracteur oublie du texte sur certains sites, la densité de mots clés change, le classement recule et les rich snippetsaffichés par Google ne reflètent plus le vrai contenu.

5. Quels outils choisir pour différents sites ?

Je vous conseil les extracteurs heuristiques readability ou trafilatura pour la robustesse, utilisez les dans des pages où le contenu principal est représenté en un gros texte comme un article blog ou presse.

6. Comment mesure-t-on la complexité d’une page ?

Par le pourcentage de boilerplate. DAnIEL affiche un niveau moyen c = 0,7 en chinois, bien plus élevé que les autres jeux. Pourtant la corrélation complexité / F1 reste modérée, preuve que la qualité dépend surtout de la langue.

7. Le champ hreflang ou l’URL canonique influencent-ils l’extraction ?

Indirectement : ces balises guident les moteurs mais n’aident l’extracteur que si le html reste cohérent. Gardez un balisage <article> / <header> clair pour maximiser la précision.

8. Peut-on combiner plusieurs extracteurs pour un meilleur niveau de fiabilité ?

Oui. Le papier Web Content Extraction Benchmark propose un pipeline hybride : heuristique générique, puis classifieur léger par language.

9. Quel est le rôle des moteurs ou services de scraping dans ce contexte ?

Un scraper qui ne nettoie pas le texte ajoute du bruit dès la source ; l’extraction en amont garantit une utilisation propre des ressources, qu’il s’agisse de veille, d’analyse ou de traduction.

10. Quel rôle joue Google dans la validation de la structure extraite ?

Nous comparons le fragment renvoyé par l’extracteur à l’extrait « Instant Answer » de Google ; un écart important signale un défaut dans la hiérarchie <article> / <header>. Cela nous aide à repérer les pages où la balise principale est mal identifiée.

11. Les nouveaux modèles d’apprentissage profond suppriment-ils le besoin d’heuristiques ?

Pas encore. Un LLM généraliste sait lire le texte, mais il coûte cher ; les heuristiques nettoient à bas niveau et n’envoient aux modèles que le nécessaire, réduisant le temps de calcul et la facture énergétique. On va donc éviter de faire appel à chatGPT 🙂 pour ce genre de tâche.

12. Quels résultats supplémentaires attendez-vous de la communauté ?

On espère voir des nouveaux extracteurs avec des stratégies agnostique à la fois de la langue mais également du genre de page web.

13. En quoi votre recherche diffère-t-elle des benchmarks classiques ?

Nous avons comparé quatorze extracteurs sur treize mille pages, mais surtout nous avons ajouté DAnIEL : un corpus multilingue avec cinq alphabets. Cette portion neuve élargit les données au-delà de l’anglais et révèle quand les règles échouent.

Références

• Répartition de la langue à travers les contenus web – https://www.obdilci.org/projets/principal/
• Adrien Barbaresi. 2021. Trafilatura : a Web Scraping Library and Command-Line Tool for Text Discovery and Extraction. Proceedings of the 59th Annual Meeting of the Association for Computational Linguistics and the 11th International Joint Conference on Natural Language Processing: System Demonstrations, 122-131.
• Janek Bevendorff, Sanket Gupta, Johannes Kiesel et Benno Stein. 2023. An Empirical Comparison of Web Content Extraction Algorithms. Proceedings of the 46th International ACM SIGIR Conference on Research and Development in Information Retrieval, 2594-2603.
• Christian Kohlschütter, Peter Fankhauser et Wolfgang Nejdl. 2010. Boilerplate Detection Using Shallow Text Features. Proceedings of the Third ACM International Conference on Web Search and Data Mining, 441-450.