Le vrai prix du bruit sur le web : pourquoi extraire le contenu utile n'a jamais été aussi crucial

Chaque modèle de langage avale le web deux fois. D'abord pendant le pré-entraînement, quand il digère les patterns de la connaissance humaine. Ensuite au moment de l'inférence, quand il récupère le contexte pertinent pour vous répondre. Les deux étapes partagent un secret gênant : la majeure partie de ce qu'elles ingèrent est du bruit inutile.

D'après des recherches récentes, environ 70% du HTML d'une page web classique est du remplissage — menus de navigation, publicités, barres latérales, banners de cookies, pieds de page. Le contenu qui vous intéresse vraiment ? C'est à peine 30% de la page. Et cerise sur le gâteau : ce 30%决定了 tout.

La qualité des données, le vrai avantage compétitif

La communauté du machine learning s'est longtemps focalisée sur l'architecture des modèles, le nombre de paramètres, les régimes d'entraînement. Mais un nombre croissant de recherches suggère que le travail ingrat de préparation des données pourrait être le véritable différenciateur.

Une étude de 2025 par Ma et al. (AICC) a mené une expérience révélatrice. L'équipe a créé deux corpus d'entraînement à partir d'instantanés Common Crawl identiques. La seule variable modifiée était la méthode d'extraction — l'une utilisait des heuristiques traditionnelles, l'autre une approche par modèle. Tout le reste était égal.

Le modèle entraîné sur des données plus propres, extraites par modèle, a surpassé son pendant de 1,08 point de pourcentage sur 13 benchmarks. Plus impressionnant encore : ce simple changement leur a permis de surpasser des modèles entraînés sur FineWeb et RefinedWeb — deux datasets reconnus pour leurs pipelines de filtrage élaborés.

Ce résultat devrait faire réfléchir toutes les équipes ML. Pendant que tout le monde se précipite pour entraîner des modèles plus gros ou expérimenter des architectures novatrices, les gains les plus importants pourraient venir d'un geste simple : supprimer les ordures.

Le problème au moment de l'inférence

La qualité des données compte aussi au-delà de l'entraînement. Des recherches de Shi et al. (ICML 2023) ont démontré qu'un seul passage non pertinent peut faire dérailler complètement la réponse d'un modèle. Quand votre système de retrieval récupère du contexte bruité, vous ne faites pas que gaspiller du compute — vous dégradez activement la qualité de la réponse.

Cela crée une dynamique préoccupante pour les systèmes en production. Les pipelines RAG (Retrieval-Augmented Generation) promettent d'ancrer les réponses dans des informations pertinentes, mais si ce retrieval inclut des publicités latérales et des notices de cookies, vous injectez du poison dans votre fenêtre de contexte.

Les chiffres sont éloquents quand on regarde comment différents extracteurs préservent le contenu structuré. Les méthodes basées sur des heuristiques comme Trafilatura affichent des scores de similarité de seulement 0,13 pour les blocs de code et 0,61 pour les formules mathématiques, contre respectivement 0,91 et 0,94 pour les approches par modèle. Quand votre documentation contient des exemples de code ou des notations techniques, ces erreurs d'extraction deviennent de la corruption d'entraînement.

La question de l'architecture : Encoder contre Decoder

Les méthodes d'extraction actuelles se divisent en deux catégories : structurelles et par lecture.

Les extracteurs structurels (Trafilatura, Readability, Boilerpipe) analysent le HTML via des signaux de surface — position dans le DOM, types de balises, densité du texte. Ils sont rapides et ne nécessitent pas d'overhead ML, mais ils confondent des éléments qui se ressemblent. Une table de navigation et une table de données ont des signatures structurelles identiques, donc ces méthodes classifient inévitablement mal.

Les extracteurs par lecture envoient le contenu réel à des modèles transformer. Dripper, le leader actuel, utilise une architecture decoder qui génère les labels token par token. Cette approche atteint une excellente précision mais souffre d'un problème fondamental d'efficacité : chaque token nécessite de lire le modèle entier depuis la mémoire. La vitesse devient limitée par la bande passante mémoire plutôt que par le compute.

C'est là qu'une nouvelle approche appelée Pulpie fait un pari architectural intéressant. Au lieu d'un decoder qui génère les labels séquentiellement, Pulpie utilise un encoder qui étiquette chaque bloc HTML en un seul forward pass. Cela déplace le goulot d'étranglement de la bande passante mémoire vers le compute pur — un problème beaucoup plus scalable.

Les résultats sont convaincants. Sur un GPU NVIDIA L4, le petit modèle Pulpie traite 13,7 pages par seconde contre 0,68 pages par seconde pour Dripper. C'est une amélioration du throughput de 20x. Pour traduire en coûts réels : nettoyer un milliard de pages coûte environ 7 900 $ avec Pulpie contre 159 000 $ avec Dripper.

Ce que ça signifie pour votre stack IA

Pour les startups et développeurs qui construisent des applications IA, cette recherche porte des implications pratiques :

D'abord, auditez votre pipeline d'extraction. Si vous utilisez encore des extracteurs heuristiques pour vos données d'entraînement ou vos pipelines RAG, vous laissez de la performance mesurable sur la table. Le coût marginal d'une meilleure extraction n'est plus qu'une fraction de ce qu'il était il y a même un an.

Ensuite, réfléchissez à la place de l'extraction dans votre architecture. Beaucoup d'équipes considèrent le contenu web comme un problème résolu — récupère la page, strip le HTML, terminé. Mais plus les modèles deviennent sophistiqués, plus la qualité de leurs entrées compte. Votre système de retrieval est seulement aussi bon que sa couche d'extraction.

Troisièmement, considérez les options open-source. Pulpie rejoint un écosystème grandissant de modèles d'extraction open-source. Les jours où vous aviez besoin d'APIs propriétaires coûteuses pour une extraction de qualité sont en train de disparaître.

Le tableau d'ensemble

Nous assistons à un changement discret dans la façon dont la communauté ML pense la qualité des données. Pendant des années, l'hypothèse était que plus de données primait sur des données plus propres. Scalez votre corpus, appliquez un filtrage basique, entraînez plus longtemps — eventually le signal submerge le bruit.

Mais à mesure que les modèles atteignent des niveaux de capacité plus élevés, cette hypothèse s'effondre. Quand vous vous entraînez sur des centaines de milliards de tokens, même des taux de corruption faibles se combinent en dommages significatifs. Et quand les contextes d'inférence sont bornés, chaque token bruité en est un de moins qui est utile.

L'ironie, c'est que l'extraction web — ce travail ingrat d'identifier le contenu principal du HTML — pourrait être l'une des interventions à plus fort effet de levier dans tout votre pipeline ML. La prochaine percée dans les performances de votre modèle ne viendra peut-être pas d'une nouvelle architecture. Elle viendra peut-être tout simplement d'une lecture plus attentive du web.

Des données propres, c'est pas glam. Mais c'est ce qui sépare un bon modèle d'un excellent.