Le parseur basé sur les sélecteurs CSS se casse lorsque le site change de mise en page. Le parseur basé sur LLM ne se casse pas, mais facture pour chaque page. En 2026, le choix entre les deux a cessé d'être une question de goût : les prix des modèles ont divergé de plusieurs dizaines de fois, et la même page peut coûter 3 000 ou 20 000 tokens selon ce que vous avez envoyé au modèle. Ci-dessous se trouve une comparaison de trois approches en termes de coûts, de fiabilité et de trafic proxy, calculée pour 1 000 et un million de pages.
En bref : que choisir
- Sélecteurs (CSS/XPath) — un modèle de page, de gros volumes, mise en page stable. Le coût d'extraction est proche de zéro, mais le support incombe au développeur.
- Extraction LLM — de nombreux sites différents, mise en page instable, tâches ponctuelles. Vous payez pour les tokens sur chaque page et devez valider la réponse.
- Hybride — LLM écrit une fois les sélecteurs, ensuite les sélecteurs fonctionnent, et le modèle est appelé uniquement lorsque la vérification des données échoue. Pour la plupart des parseurs permanents, c'est l'option optimale.
Critères de comparaison
Nous comparons selon cinq points qui influencent réellement le coût final et la qualité des données :
- coût d'extraction pour 1 000 pages ;
- comportement lors du changement de mise en page ;
- précision et risque de valeurs inventées ;
- rapidité et latence ;
- consommation de trafic proxy — comme vous le verrez, cela dépend peu du choix de la méthode.
Combien coûte l'extraction LLM : calculons selon les prix d'octobre 2026
Les prix officiels pour un million de tokens (entrée / sortie) au tarif standard :
- Gemini 2.5 Flash-Lite — 0,10 $ / 0,40 $ ;
- Gemini 3.1 Flash-Lite — 0,25 $ / 1,50 $ ;
- Claude Haiku 4.5 — 1 $ / 5 $ ;
- Gemini 3.5 Flash — 1,50 $ / 9 $.
Google et Anthropic ont un Batch API avec une réduction de 50 % sur l'entrée et la sortie — pour le parsing où la réponse n'est pas nécessaire immédiatement, c'est le premier levier d'économie.
La principale variable — ce que vous envoyez au modèle
Une page HTML brute envoyée au modèle prend généralement entre 10 000 et 40 000 tokens. Cloudflare, en lançant la fonction Markdown for Agents, a donné un exemple : le même article de blog pèse 16 180 tokens en HTML et 3 150 tokens en Markdown — soit une réduction de 80 %. D'autres mesures sur les actualités, la documentation et les fiches produits montrent une réduction allant de 67 à 94 %.
Pour le calcul, prenons les hypothèses suivantes : une page brute — 20 000 tokens, nettoyée en Markdown — 3 000, plus 500 tokens pour l'instruction et le schéma, avec 300 tokens de sortie en JSON. Pour 1 000 pages, nous obtenons :
| Modèle | HTML brut (20,5 millions d'entrée) | Markdown (3,5 millions d'entrée) |
|---|---|---|
| Gemini 2.5 Flash-Lite | ≈ 2,17 $ | ≈ 0,47 $ |
| Gemini 3.1 Flash-Lite | ≈ 5,58 $ | ≈ 1,33 $ |
| Claude Haiku 4.5 | ≈ 22,00 $ | ≈ 5,00 $ |
| Gemini 3.5 Flash | ≈ 33,45 $ | ≈ 7,95 $ |
La différence est de 70 fois entre la pire et la meilleure option pour un résultat identique. Deux tiers de cette différence proviennent du nettoyage de l'entrée, et non du choix du modèle. Pour un million de pages par mois, cela représente soit environ 470 $, soit plus de 33 000 $.
Un autre détail : les modèles Claude à partir de la version 4.7 utilisent un nouveau tokeniseur qui, selon les données d'Anthropic, donne environ 30 % de tokens supplémentaires pour le même texte. En comparant les factures de différents générations de modèles, tenez-en compte — Haiku 4.5 fonctionne avec l'ancien tokeniseur.
Sélecteurs : presque gratuits, tant que le site ne change pas
Exécuter un sélecteur CSS ou XPath sur une page déjà téléchargée coûte une fraction de milliseconde de processeur. Dans le guide de ScrapingBee, l'évaluation est la suivante : sur une mise en page stable, un sélecteur est environ 10 fois moins cher et plus rapide que l'extraction LLM. En pratique, la différence est encore plus grande, car le sélecteur n'a pas de requête réseau vers l'API du modèle.
Le coût des sélecteurs réside dans le support :
- le site a renommé une classe ou a enveloppé un bloc dans un nouveau div — le parseur renvoie silencieusement des champs vides ;
- les tests A/B montrent différents modèles à différents visiteurs, et certaines pages ne sont pas analysées ;
- sur 50 sites différents, vous maintenez 50 ensembles de sélecteurs.
Le scénario le plus dangereux n'est pas l'échec, mais la corruption silencieuse des données : le sélecteur attrape un élément voisin, et une ancienne prix est écrite dans la base de données pendant des semaines au lieu de la actuelle.
LLM : résistant à la mise en page, mais capable d'inventer
Les modèles n'ont pas besoin d'un chemin exact vers l'élément — ils recherchent le « prix » par sens. Cela élimine le problème des classes renommées et des différents modèles. Mais trois types d'échecs typiques apparaissent, décrits par tous ceux qui ont lancé de tels parseurs en production :
- valeurs inventées — le modèle « devine » un prix ou un article qui n'est pas sur la page ;
- champs manquants — certaines données ne sont pas extraites ;
- derapage de structure — une chaîne au lieu d'un nombre, un autre nom de clé.
La protection est obligatoire : un schéma de réponse strict, validation (par exemple, Pydantic), temperature = 0 et répétition en cas d'erreur. Une température de zéro réduit la dispersion, mais n'élimine pas complètement les hallucinations. Pour les prix et les stocks, il est raisonnable d'ajouter une vérification « la valeur apparaît réellement dans le texte de la page ».
La latence est également plus élevée : au temps de chargement de la page via le proxy s'ajoute la réponse du modèle — de fractions de seconde à plusieurs secondes. Pour une surveillance une fois par jour, cela n'a pas d'importance, mais pour suivre les baisses, c'est critique.
Hybride : LLM écrit des sélecteurs, pas d'extraction de données
La troisième voie est directement soutenue par des bibliothèques populaires. Dans Crawl4AI, il existe une fonction de génération de schéma : le modèle regarde une fois des échantillons HTML et renvoie un ensemble de sélecteurs CSS/XPath, après quoi l'extraction se fait sans appels à LLM. La documentation souligne qu'il s'agit d'un coût unique, et le schéma peut être réutilisé sans restrictions ; avec plusieurs échantillons, le modèle choisit souvent des sélecteurs plus robustes basés sur des attributs plutôt que sur des positions fragiles comme nth-child.
Le schéma de travail de l'hybride :
- LLM génère des sélecteurs à partir de 3 à 5 échantillons de pages d'un même modèle.
- Le parseur fonctionne sur les sélecteurs, chaque enregistrement est vérifié par un validateur : les champs sont en place, les types sont corrects, le prix est dans une fourchette raisonnable.
- Si la proportion d'enregistrements non valides dépasse le seuil (disons, 2 à 5 %), la page passe à l'extraction LLM, et le schéma est régénéré.
- Le nouveau schéma est testé sur un échantillon de contrôle et ne remplace l'ancien qu'ensuite.
Ainsi, vous ne payez pour le modèle que lors des changements de mise en page, et non pour chacune des millions de pages.
Tableau récapitulatif
| Critère | Sélecteurs | Extraction LLM | Hybride |
|---|---|---|---|
| Coût d'extraction | près de zéro | 0,5 $–33 pour 1 000 pages. | près de zéro + appels ponctuels |
| Changement de mise en page | se casse, souvent silencieusement | survit généralement | répare automatiquement |
| Risque de données inventées | aucun (mais il y a « pas le bon élément ») | présent, validation nécessaire | minime |
| Vitesse | maximale | + réponse du modèle sur chaque page | comme pour les sélecteurs |
| Beaucoup de sites différents | coûteux à maintenir | point fort | bon, schéma pour chaque modèle |
| Trafic proxy | identique — le modèle ne réduit pas les octets téléchargés | ||
À propos des proxies : LLM ne fait pas économiser de trafic
Une erreur fréquente dans les calculs est de penser qu'un parseur « intelligent » est moins cher en réseau. Non : la conversion HTML en Markdown se fait après le téléchargement, donc la page complète passe par le proxy quelle que soit la méthode d'extraction. L'exception concerne les sites où le propriétaire a lui-même activé la livraison de Markdown via l'en-tête Accept : text/markdown (comme dans la fonction Cloudflare), mais c'est une solution du site, pas la vôtre.
Pour donner une idée : avec un poids HTML de 200 Ko sans images, 1 000 pages représentent environ 0,2 Go, soit environ 0,54 $ sur des proxies résidentiels à 2,70 $ par Go. Comparez avec le tableau ci-dessus : en envoyant du HTML brut à Claude Haiku 4.5, la facture pour le modèle sera 40 fois plus élevée que celle du proxy, tandis qu'en Markdown et Flash-Lite, elles sont comparables. Si vous rendez les pages avec un navigateur sans tête, le trafic augmentera considérablement — des mesures sont disponibles dans notre comparaison de la consommation de trafic de Playwright, Puppeteer et requests sur 1 000 pages.
Ce qui influence réellement le trafic, quelle que soit la méthode :
- ne pas télécharger d'images, de polices et d'analytique si ce n'est pas nécessaire ;
- chercher une API JSON interne au lieu de HTML ;
- ne pas faire de répétitions inutiles : chaque bannissement et réessai représente des octets payés. Pour en savoir plus sur pourquoi le prix par Go est trompeur, consultez l'analyse du coût réel d'un enregistrement réussi.
Pour des catalogues simples sans protection anti-bot stricte, des proxies de centre de données à 1,50 $ par Go suffisent ; des résidents sont nécessaires là où les IP d'hébergement sont coupées à l'entrée.
Recommandations par scénarios
- Surveillance des prix d'un à trois marketplaces, des centaines de milliers de fiches. Hybride ou sélecteurs purs avec validateur. LLM à connecter uniquement pour la régénération du schéma.
- Collecte de données à partir de centaines de sites hétérogènes (leads, offres d'emploi, contacts). Extraction LLM en Markdown via un modèle bon marché en mode batch. Ne pas lancer sans schéma strict et validation.
- Recherche ponctuelle sur plusieurs milliers de pages. LLM : pour quelques dollars, vous économisez des jours d'écriture de sélecteurs.
- Données où une erreur coûte de l'argent (prix pour le repricing, stocks). Sélecteurs ou hybride plus vérification de la valeur avec le texte source de la page.
- RAG et bases de connaissances. Ici, la structure n'est pas nécessaire, mais le texte brut : conversion en Markdown sans extraction de champs, modèle — uniquement au stade de la réponse.
Conclusion
L'extraction LLM n'a pas remplacé les sélecteurs, mais a déplacé le point de choix. Le moins cher est l'hybride : le modèle écrit et répare les sélecteurs, au lieu de lire chaque page. Si vous ne pouvez pas vous passer du modèle sur chaque page, commencez par nettoyer l'entrée en Markdown et utilisez le mode batch : ces deux étapes réduisent la facture de 5 à 10 fois avant que vous ne commenciez à choisir le modèle. Et rappelez-vous que le trafic proxy ne dépend pas de la méthode d'extraction : il faut économiser sur ce que vous téléchargez, et non sur la façon dont vous le parsez.