Depuis vingt ans, extraire des données de pages web signifiait écrire des sélecteurs : trouver l’élément, récupérer le texte, le corriger quand le site change. Les grands modèles de langage offrent un marché différent. Donnez au modèle la page, décrivez les champs voulus, et récupérez des données structurées, sans sélecteurs à écrire ni à casser lors d’une refonte.
Le marché est réel, mais il a un prix, une vitesse et un mode de défaillance, et les trois méritent d’être mesurés avant de reconstruire un pipeline autour de cela. Nous les avons donc mesurés. Cet article rapporte un test modeste et honnête sur des pages en ligne, ce que les erreurs ont révélé, ce que cela coûte à grande échelle, et où un modèle a sa place dans un pipeline d’extraction.
Points clés
- Sur 18 articles de presse en ligne, un grand modèle Claude a extrait tous les titres exactement, 17 dates sur 18 et 14 listes d’auteurs sur 18, évalué par rapport aux données structurées propres à chaque page.
- La plupart des « erreurs » n’étaient pas des erreurs du modèle. Sur chaque page où les auteurs divergeaient, les données structurées contenaient un espace réservé générique ; sur deux d’entre elles, le modèle a rapporté la signature que la page visible affichait réellement.
- Le modèle n’a rien inventé : chaque titre et auteur qu’il a renvoyé apparaît dans le texte de la page. Il a néanmoins commis une véritable erreur, en désignant un photographe comme auteur.
- Cela a coûté environ 1,9 cents par page au prix catalogue et a pris une médiane de 2,4 secondes. L’analyse des données structurées ne coûte presque rien et prend des millisecondes.
- Utilisez les modèles là où les sélecteurs sont coûteux à maintenir, par exemple pour de nombreux modèles de site différents ou des champs sans source structurée, et validez tout ce qu’ils renvoient.
Ce que nous avons testé
| Paramètre | Valeur |
|---|---|
| Pages | 18 articles en ligne provenant des pages de section d’un grand éditeur d’actualités, collectés le 28 septembre 2026 |
| Entrée du modèle | Le texte visible de la page, y compris la navigation et autres éléments d’habillage de page, soit environ 8 700 caractères en moyenne |
| Champs | Titre, date de publication telle qu’affichée sur la page, et noms des auteurs |
| Modèle | Claude Opus 5, à effort faible, avec un schéma JSON contraignant la sortie |
| Référence | Les propres données structurées JSON-LD de la même page |
| Notation | Le titre et la date doivent correspondre exactement ; les listes d’auteurs doivent correspondre en tant qu’ensembles |
La référence est délibérément le type de données couvert dans arrêtez de parser le HTML : les données structurées que les éditeurs intègrent pour les moteurs de recherche. Elles sont généralement exactes. Il s’est avéré que ce n’est pas toujours le cas.
Résultats
| Mesure | Résultat |
|---|---|
| Titre correct | 18 sur 18 |
| Date correcte | 17 sur 18 |
| Auteurs corrects | 14 sur 18 |
| Valeurs extraites trouvées dans le texte de la page | 18 titres sur 18, 18 listes d’auteurs sur 18 |
| Tokens par page | environ 3 380 en entrée, 66 en sortie |
| Latence | médiane 2,4 s, plage 1,8 à 10,6 s |
| Coût pour l’exécution | 0,33 $ au prix catalogue, environ 1,9 cents par page |
Les erreurs étaient la partie intéressante
Les chiffres de titres sous-estiment le modèle et surestiment la référence. En examinant chaque désaccord :
- Un article d’opinion. Les données structurées indiquaient l’auteur comme un espace réservé générique de journaliste du personnel. La signature visible nommait le véritable chroniqueur. Le modèle a renvoyé le chroniqueur.
- Une dépêche. Les données structurées donnaient à nouveau l’espace réservé générique ; la signature visible indiquait « Staff and agencies ». Le modèle a renvoyé ce que la page montrait.
- Une page d’inscription à une newsletter qui s’était glissée dans l’ensemble. Elle ne montrait ni auteur ni date. Les données structurées fournissaient tout de même un auteur générique et une date ; le modèle a laissé les deux champs vides plutôt que d’inventer.
- Un reportage photo. Les données structurées donnaient le même espace réservé générique. La page créditait les photographies à un photographe nommé, et le modèle a renvoyé le photographe comme auteur. Il s’agit là d’une véritable erreur.
Ainsi, sur les quatre pages présentant un désaccord, deux reflétaient une référence moins précise que la page visible, une correspondait au modèle refusant à juste titre de deviner, et une était une véritable erreur. Cela change la question qu’il vaut la peine de poser. Les données structurées constituent une valeur par défaut solide, mais ce n’est pas la vérité de terrain, et un modèle lisant la page visible peut relever où elle se trompe, tout comme il peut occasionnellement mal lire ce qu’il voit.
Ce que cela coûte à grande échelle
Le test a coûté 0,33 $ pour 18 pages au prix catalogue de Claude Opus 5, soit 5 $ par million de tokens en entrée et 25 $ par million de tokens en sortie. Cela représente environ 1,9 cents par page, soit environ 18 600 $ par million de pages. L’API Batch d’Anthropic réduit de moitié ces prix par token pour les tâches qui peuvent attendre. Les modèles plus petits sont encore moins chers par token, Claude Haiku 4.5 est affiché à 1 $ et 5 $, mais nous ne les avons pas testés ici, et leur précision sur vos pages est une chose à mesurer, pas à supposer.
La latence compte aussi. Une médiane de 2,4 secondes par page, avec quelques valeurs aberrantes occasionnelles, convient pour la surveillance et l’enrichissement, mais constitue une contrainte réelle pour le crawling à haut volume. L’analyse du JSON-LD ou l’exécution de sélecteurs prend des millisecondes et ne coûte pratiquement rien au-delà de la récupération. Ces coûts d’extraction s’ajoutent aux coûts de collecte, c’est pourquoi le coût par enregistrement propre devrait inclure les deux.
Quand utiliser quoi
| Situation | Meilleure approche |
|---|---|
| La page publie les champs en JSON-LD ou en JSON intégré | Analyser les données structurées |
| Volume élevé provenant d’un ou quelques modèles de site | Sélecteurs ou données structurées, avec validation |
| De nombreux sites différents, chacun avec son propre modèle | Un modèle, validé, générant éventuellement des sélecteurs que vous réutilisez ensuite |
| Champs qui n’existent que dans le texte, comme les conditions, l’éligibilité ou les spécifications | Un modèle |
| Les données structurées échouent à la validation sur une page | Un modèle en solution de repli |
| Faible volume, forte valeur, changement fréquent de mise en page | Un modèle |
Les pipelines les plus solides combinent les deux. Analysez d’abord les données structurées, basculez vers un modèle lorsqu’un champ requis manque ou échoue à la validation, et enregistrez quelle méthode a produit chaque enregistrement, le même schéma de repli en cascade décrit pour les données structurées. Là où un modèle de site couvre des milliers de pages, il peut aussi valoir la peine de faire proposer des sélecteurs par un modèle une seule fois, puis d’exécuter ces sélecteurs à faible coût sur chaque page, avec le modèle en attente pour quand ils se cassent.
Utiliser un modèle en toute sécurité
Quatre pratiques transforment l’extraction par modèle d’impressionnante à fiable.
Contraignez la sortie. Un schéma JSON fait en sorte que le modèle renvoie les champs et types demandés ; vérifiez tout de même la raison d’arrêt, car une réponse refusée ou tronquée n’a rien à analyser. Dites au modèle de laisser un champ vide quand la page ne l’affiche pas ; dans notre test, c’est exactement ce qu’il a fait.
Vérifiez l’ancrage. Chaque chaîne extraite qui devrait apparaître sur la page, comme un nom, un titre ou un nom de produit, devrait être trouvée dans le texte de la page. C’est une vérification peu coûteuse qui capte les valeurs inventées. Elle ne captera pas un nom réel attaché au mauvais champ, comme le montre le cas du photographe, c’est donc un filtre, pas une preuve.
Échantillonnez pour une révision humaine. Notez un petit échantillon aléatoire chaque semaine par rapport à la lecture de la page par une personne, et suivez la précision par champ et par site dans le temps.
Traitez le texte de la page comme une entrée non fiable. Une page est écrite par quelqu’un d’autre. Utilisez les modèles sur le contenu web uniquement pour l’extraction, ne laissez jamais le contenu de la page déclencher des actions, et gardez les instructions du modèle séparées du contenu de la page.
Voici l’appel d’extraction que nous avons utilisé, suivi de la vérification d’ancrage :
import Anthropic from "@anthropic-ai/sdk";
const client = new Anthropic();
const SCHEMA = {
type: "object",
properties: {
headline: { type: "string" },
date_published: { type: "string", description: "YYYY-MM-DD, as shown on the page" },
authors: { type: "array", items: { type: "string" } },
},
required: ["headline", "date_published", "authors"],
additionalProperties: false,
};
export async function extractArticle(pageText) {
const response = await client.beta.messages.create({
model: "claude-opus-5",
max_tokens: 2000,
betas: ["server-side-fallback-2026-07-01"],
fallbacks: "default",
output_config: { effort: "low", format: { type: "json_schema", schema: SCHEMA } },
messages: [{
role: "user",
content:
"Below is the visible text of a news article web page, including navigation and other page furniture. " +
"Extract the article's headline exactly as written, its publication date as shown on the page (YYYY-MM-DD), " +
"and the author names. Leave a field empty if the page does not show it.\n\n<page>\n" + pageText + "\n</page>",
}],
});
if (response.stop_reason === "refusal") return null;
const text = response.content.filter((b) => b.type === "text").map((b) => b.text).join("");
return { record: JSON.parse(text), usage: response.usage };
}
// Grounding check: every extracted string must actually appear in the page text.
export function grounded(record, pageText) {
const norm = (s) => s.replace(/[‘’]/g, "'").replace(/[“”]/g, '"').replace(/\s+/g, " ").toLowerCase();
const page = norm(pageText);
return {
headline: page.includes(norm(record.headline)),
authors: record.authors.every((a) => page.includes(norm(a))),
};
}L’entrée compte autant que le modèle. Un modèle ne peut extraire que ce que la page contient réellement, donc une page de blocage, un mur de consentement ou une coquille vide produit une extraction confiante du mauvais contenu. Validez ce que vous avez récupéré avant d’en extraire, comme évoqué dans le taux d’échec silencieux, et récupérez depuis le marché dont vous avez besoin de la version de la page.
Les limites de ce test
Dix-huit pages d’un seul éditeur constituent un échantillon modeste, choisi pour être honnête plutôt que définitif. Les articles de presse sont aussi un cas facile : titres clairs, signatures visibles, dates bien étiquetées. Les pages produit avec variantes, prix et disponibilité, ou les pages dans d’autres langues, se comporteront différemment. Nous avons testé un modèle à un seul niveau d’effort. La méthode est simple à reproduire sur vos propres pages, et vos propres pages sont le seul benchmark qui compte.
En résumé
Un modèle lisant la page a obtenu tous les titres corrects, n’a rien inventé, et dans plusieurs cas a rapporté la page plus fidèlement que les propres données structurées de la page. Il a aussi mal attribué un auteur une fois, coûté des cents plutôt que des fractions de cent, et pris des secondes plutôt que des millisecondes.
Cela en fait un outil solide pour les parties de l’extraction que les sélecteurs gèrent mal : de nombreux modèles, des champs uniquement en texte et des solutions de repli quand les données structurées échouent. Ce n’est pas un remplacement des données structurées là où elles existent. Analysez ce que la page publie, recourez à un modèle là où elle ne le fait pas, validez les deux, et enregistrez lequel vous avez utilisé.
Sources et références
- Anthropic, Tarification. Prix du modèle et de l’API Batch au moment du test.
- Schema.org, NewsArticle.
- Test réalisé par Shifter le 28 septembre 2026 sur 18 articles de presse accessibles publiquement, à l’aide du code ci-dessus.