Quand l'extraction par LLM cesse d'être rentable

Firecrawl facture 1 crédit pour scraper une page et 5 crédits pour en extraire des champs structurés (Firecrawl pricing, 2026). C'est une majoration de 5x pour le même HTML, envoyé à travers un modèle.

La promesse est réelle : décrivez ce que vous voulez, obtenez du JSON en retour, aucun sélecteur à maintenir. Pour les mises en page instables et les cibles uniques, cela justifie la majoration. Mais pour le pipeline de production qui extrait 500 000 pages produits par jour des cinq mêmes sites marchands, ce n'est pas le cas.

Nous avons vu des équipes déployer l'extraction par LLM par défaut, recevoir la facture mensuelle, puis chercher une issue. La solution n'est généralement pas d'abandonner les LLM. Il s'agit de les placer au bon endroit dans le pipeline.

L'équation devient vite intenable

Prenons Firecrawl comme option d'entrée de gamme. Le scrape plus l'extraction par IA coûte 6 crédits par page sans crawl, 7 crédits avec crawl (ScrapeGraphAI breakdown, 2026). 100 000 pages par jour sur leur forfait "growth" reviennent à environ 21 000 $ par mois avant les tentatives de rejeu, et avant même d'avoir payé le moindre proxy.

Gérez votre propre pipeline de LLM et les chiffres changent, mais ne deviennent pas dérisoires pour autant. GPT-4o coûte 2,50 $ par million de tokens d'entrée et 10 $ par million de tokens de sortie (PricePerToken, 2026). Une page produit après conversion en markdown compte entre 4 000 et 8 000 tokens d'entrée. Disons 6 000 en entrée et 200 en sortie pour un bloc JSON. À 100 000 pages par jour, cela représente 360 $ par jour, soit 11 000 $ par mois pour une tâche que des sélecteurs CSS accomplissent gratuitement après une seule configuration.

Et cela concerne le modèle économique. Passez à Claude Sonnet 4.6 (3 $ en entrée, 15 $ en sortie) et la facture double (PE Collective, 2026). Passez à un modèle de raisonnement et ajoutez une pénalité de 3 à 10 fois selon le temps de réflexion avant de répondre.

Rien de tout cela ne prend en compte les échecs. Un taux d'hallucination de 3 à 5 % semble inoffensif jusqu'à ce que vous fassiez le calcul. Sur 100 000 pages par jour, cela représente 3 000 à 5 000 enregistrements erronés qui alimentent votre entrepôt de données, ressemblant à s'y méprendre aux bons parce que le modèle les a renvoyés avec assurance. Comme l'a formulé DataHen : "Le problème n'est pas que l'IA se trompe parfois. C'est qu'elle se trompe avec assurance." (DataHen, 2026).

Ce que font réellement les équipes expérimentées

Lisez la documentation des fournisseurs qui exploitent réellement des scrapers en production et la tendance est constante : l'approche hybride. Utilisez le LLM pour analyser la page une fois, puis exécutez un code déterministe peu coûteux pour tout le reste.

Zyte l'explique clairement dans sa propre documentation : "Au lieu d'utiliser un LLM par page, utilisez votre LLM pour générer des sélecteurs CSS pour les champs souhaités à partir du HTML brut d'une première page, et utilisez ces sélecteurs pour analyser toutes les autres pages." (Zyte LLM guide, 2026). Apify recommande le même flux dans son guide 2026 : essayez d'abord les sélecteurs CSS, puis rabattez-vous sur le LLM en cas d'échec (Apify 2026 guide). Un article de la communauté DEV décrivant un déploiement en production résume parfaitement cette architecture : le chemin du sélecteur mis en cache ne coûte rien, le LLM ne s'active que lorsque la validation échoue (DEV.to, 2026).

La répartition en production ressemble donc à ceci :

Le LLM initialise le sélecteur (un appel par cible, des fractions de centime)
Le sélecteur s'exécute sur chaque page (gratuit)
Un validateur (généralement une regex ou une vérification de présence) détecte les dérives
La dérive déclenche une réinitialisation, des semaines ou des mois plus tard

Le coût par page s'effondre, passant d'environ 0,005 $ à bien moins de 0,0001 $. La qualité s'améliore car l'analyse déterministe n'hallucine pas. Et vous dépensez des tokens pour le travail dans lequel les LLM excellent réellement : lire une structure inédite, et non répéter bêtement une structure que vous avez déjà cartographiée.

Là où les LLM justifient tout de même leur coût

Cet article n'est pas un plaidoyer contre les LLM. De nombreuses tâches d'extraction correspondent exactement aux cas où le modèle est le bon outil et où le calcul des crédits est rentable :

Des mises en page instables qui changent chaque semaine. Des sélecteurs qui cassent tous les mardis coûtent plus cher en temps d'ingénierie que l'extraction par LLM en tokens. Utilisez le modèle.
Des cibles de longue traîne que vous ne visiterez jamais deux fois. Aucun intérêt à écrire un sélecteur. Utilisez le modèle.
Du contenu non structuré dont la sortie est elle-même un résumé. Des descriptions de poste vers des compétences, des articles vers des affirmations, des avis vers des sentiments. Les sélecteurs ne peuvent pas aider. Utilisez le modèle.
Des pages avec des champs optionnels dispersés dans différentes variantes de mise en page. Un modèle unique avec vingt rendus conditionnels est exactement le cas où les LLM surpassent les chaînes de regex.

Analysez votre pipeline. Triez les cibles par volume. Les premiers 20 % en nombre de requêtes ont presque toujours une structure stable (c'est pourquoi ils représentent les premiers 20 %, vous les avez intégrés délibérément). Ce sont des candidats parfaits pour les sélecteurs. La longue traîne est l'endroit où le modèle a toute sa place.

Ce que cela signifie pour votre stack

Le discours des fournisseurs en 2026 vous incite à choisir l'extraction par LLM par défaut. La tarification au crédit rend cela raisonnable pour les petits projets. Cela cesse de l'être lorsque vous passez à l'échelle, de la même manière que la taille du pool de proxys a cessé de prédire le succès réel une fois que le signal sous-jacent s'est dégradé.

Trois points clés pour les équipes qui construisent de vrais pipelines :

Séparez la récupération de l'analyse. Si votre fournisseur de scraping ne renvoie que du JSON extrait par LLM, vous ne pourrez pas vous rabattre sur des sélecteurs lorsque la facture arrivera. Choisissez une infrastructure qui vous fournit du HTML et vous laisse choisir la méthode d'extraction.
Mettez en cache de manière agressive au niveau du sélecteur. Les sélecteurs générés sont réutilisables sur des milliers de pages. L'appel coûteux est la génération, pas l'utilisation.
Mesurez le coût par enregistrement, pas par page. Un pipeline qui coûte 0,001 $/page mais livre 5 % de données erronées coûte plus cher qu'un pipeline à 0,005 $/page qui livre des données propres. Le stockage, les requêtes en aval et le nettoyage final ont tous un coût.

Choisissez la partie ennuyeuse

L'extraction par LLM par défaut est idéale pour une démo, mais inadaptée pour la production. Les équipes qui réussissent sont celles qui traitent les LLM comme un outil pour comprendre une page, et non comme un outil pour lire une page. Le code déterministe ennuyeux gagne toujours le match du volume en 2026 ; le modèle gagne celui de la nouveauté. Les deux ont leur place dans la stack.

Chez FourA, Single et Browser renvoient la réponse brute (HTML, DOM rendu, headers, body) et s'arrêtent là. Que vous choisissiez d'analyser avec des sélecteurs, d'envoyer le tout à un modèle, ou de faire les deux, c'est votre choix. Nous n'appliquons pas de multiplicateur de crédit pour une extraction que nous n'avons pas effectuée.