CyberScraper 2077 : extraire des données avec un LLM dans la boucle

Le problème que ce projet attaque vraiment

Extraire des données d'une page web se heurte toujours au même mur : il faut écrire un parseur. Sélecteurs CSS, XPath, structure HTML qui change sans prévenir, champs dont le libellé varie d'une page à l'autre. Le README de CyberScraper 2077 ne formule pas le problème en ces termes, mais la promesse est claire : laisser un modèle de langage lire le contenu et produire la structure à votre place. Vous décrivez ce que vous voulez, le modèle s'occupe du reste.

Le public visé est explicite dans le README : analyste, développeur curieux, ou toute personne qui veut sortir de l'information d'une page sans maintenir un parseur. Le projet propose aussi le scraping de sites .onion via Tor et un mode furtif, ce qui élargit le champ au-delà de la simple extraction de tableaux. C'est un outil d'exploration et de prototypage, pas un moteur d'ingestion. La nuance compte, parce que le coût par page et le non-déterminisme du modèle pèsent lourd dès qu'on passe à l'échelle.

Ce qui se passe entre l'URL et le fichier Excel

Le dépôt est en Python, l'interface en Streamlit. Le flux est celui d'une application locale : vous lancez Streamlit, vous saisissez une URL et une consigne, le navigateur piloté par Playwright charge la page, le contenu est envoyé au modèle choisi, et le résultat structuré revient dans l'interface avant export.

Deux mécanismes méritent l'attention. D'abord le cache : le README décrit une mise en cache basée sur le contenu et sur la requête, via LRU cache et un dictionnaire maison, pour réduire les appels API redondants. C'est la bonne réponse au coût par appel, et cela veut dire qu'une même paire URL plus consigne ne sera pas refacturée. Ensuite les modes de navigation : le mode furtif ajuste des paramètres pour éviter la détection, le mode current browser utilise votre navigateur local et permettrait selon le README de contourner la majorité des détections de bot, et le contournement de captcha s'active en ajoutant -captcha à la fin de l'URL. Ce dernier point est signalé comme fonctionnel nativement mais pas sous Docker, ce qui est une contrainte de déploiement réelle et non un détail.

La fonction de navigation entre les pages est marquée BETA dans le README. À traiter comme telle.

Mise en route : commandes et clés

Le README impose Python 3.10 ou supérieur. Le parcours de base tient en cinq commandes :

git clone https://github.com/itsOwen/CyberScraper-2077.git cd CyberScraper-2077 virtualenv venv pip install -r requirements.txt playwright install

L'étape playwright install est celle qu'on oublie, et sans elle le navigateur ne se lance pas. Les clés se passent par variables d'environnement : export OPENAI_API_KEY et export GOOGLE_API_KEY. Pour un proxy LiteLLM, le README documente trois variables : LITELLM_API_KEY, LITELLM_BASE_URL (valeur par défaut http://localhost:4000/v1) et LITELLM_MODELS, une liste séparée par des virgules. Les modèles ainsi exposés apparaissent dans la barre latérale sous la forme litellm:<model>. C'est le chemin le plus intéressant pour qui veut garder la main sur le routage des modèles.

Côté Ollama, la procédure est donnée directement dans le README : pip install ollama, installer Ollama depuis le site officiel, puis ollama pull llama3.1. L'auteur ajoute une recommandation nette : privilégier OpenAI et Gemini, ces modèles suivant mieux les instructions. Il prévient aussi que la vitesse dépend de la machine et qu'il faudra peut-être ajuster le prompt et ajouter des filtres. En Docker, le parcours est docker build -t cyberscraper-2077 . puis docker run -p 8501:8501 avec les clés passées en -e. Les exports couvrent JSON, CSV, HTML, SQL et Excel, avec un envoi vers Google Sheets depuis l'interface.

Là où l'outil vous lâche

Le point faible est structurel : le modèle de langage est le parseur. Un parseur écrit à la main donne le même résultat deux fois de suite. Un LLM, non. Sur des pages au format stable, vous payez un appel par page pour un travail qu'un sélecteur CSS aurait fait gratuitement et de façon reproductible. Le README reconnaît le problème à sa manière en conseillant OpenAI ou Gemini plutôt que les modèles ouverts, ce qui revient à dire que la qualité de l'extraction dépend du modèle bien plus que du code.

Vient ensuite la question du coût. Le cache réduit les appels redondants, mais il ne supprime pas le coût du premier passage sur chaque URL. Sur un catalogue de plusieurs milliers de pages, l'addition devient le facteur limitant, pas la vitesse de scraping. Le README met d'ailleurs en avant des sponsors de proxys résidentiels, ce qui suggère que le projet est pensé pour des volumes où la rotation d'IP compte. Or un proxy résidentiel se facture au gigaoctet : le budget se déplace du calcul vers le réseau et vers l'API.

Ajoutez les aspérités d'exploitation. Le contournement de captcha ne fonctionne pas sous Docker. La navigation multi-pages est en BETA. Aucune release n'apparaît dans les informations du dépôt, donc pas de version taguée à épingler : vous suivez la branche main. Pour un script personnel, c'est acceptable. Pour une dépendance de production, c'est un risque de mise à jour silencieuse. Enfin, le README précise que les utilisateurs Windows doivent passer par Docker, l'auteur indiquant qu'il ne maintiendra pas une version dédiée. C'est une décision honnête, mais elle ferme la voie native à tout un pan d'utilisateurs.

Scrapy ou Crawl4AI : deux réponses différentes au même besoin

Scrapy reste la référence du scraping déterministe. Vous écrivez des sélecteurs, vous obtenez les mêmes colonnes à chaque exécution, et le coût marginal d'une page supplémentaire est proche de zéro. Le prix à payer est le travail de maintenance : chaque refonte du site cible casse vos sélecteurs. CyberScraper 2077 déplace ce coût du développeur vers le fournisseur de modèle, en échange d'argent et d'une variabilité de sortie.

Crawl4AI attaque le même problème avec une approche différente : produire du contenu propre et structuré pour les chaînes de traitement par LLM, en s'appuyant sur des heuristiques de nettoyage et de conversion, sans imposer une interface graphique. La différence de posture est nette. CyberScraper 2077 est une application que l'on ouvre et que l'on pilote à la main, avec un résultat exportable en un clic. Crawl4AI est une brique que l'on appelle depuis du code. Si votre besoin est un pipeline automatisé et testable, l'interface Streamlit devient un détour, pas un atout. Si votre besoin est d'explorer une page inconnue cet après-midi, l'inverse est vrai.

Reste le cas Tor et .onion, que le README présente comme un routage automatique avec fonctions de sécurité. C'est un usage de niche, mais il est peu couvert par les alternatives généralistes, ce qui donne au projet un argument propre.

Maintenance, licence et coût de mise à jour

La licence est MIT. Concrètement, cela autorise la réutilisation, la modification et la redistribution, y compris dans un produit propriétaire, à condition de conserver l'avis de copyright et le texte de la licence. Aucune garantie n'est fournie. Ce paragraphe décrit la licence, il ne constitue pas un conseil juridique : si vous intégrez le code dans un produit distribué, faites relire la notice par qui de droit.

Le coût de maintenance se répartit sur trois fronts. Les dépendances Python d'abord, dont le contenu exact n'est connu qu'en lisant requirements.txt sur votre clone. Playwright ensuite, qui embarque ses propres navigateurs et demande un playwright install à jour après certaines mises à niveau. Les fournisseurs de modèles enfin : noms de modèles, tarifs et formats d'API changent, et rien dans les informations du dépôt n'indique un cycle de publication tagué. La dernière activité visible sur la branche principale est datée de septembre 2026, mais l'absence de release signifie qu'un git pull peut modifier le comportement sans changer de numéro de version. Pour maîtriser cela, épinglez un commit précis plutôt que de suivre main.

Faut-il l'installer

Adoptez-le si vous extrayez ponctuellement des données de pages dont la structure varie, si vous disposez déjà d'une clé OpenAI ou Gemini, et si l'idée de décrire en français ce que vous voulez récupérer vous fait gagner du temps par rapport à l'écriture d'un parseur. Adoptez-le aussi si vous voulez tester plusieurs modèles côte à côte : la configuration LiteLLM avec LITELLM_MODELS rend cette comparaison triviale, et c'est probablement l'usage le plus solide du projet.

Passez votre chemin si vous devez traiter des dizaines de milliers d'URL de façon reproductible, si votre budget API est contraint, ou si vous avez besoin d'une version taguée et d'un support Windows natif. Dans ces cas, Scrapy ou Crawl4AI répondent mieux, et le README lui-même oriente vers OpenAI ou Gemini plutôt que vers des modèles locaux, ce qui indique assez où se situe la dépendance critique.

Avant de vous engager, vérifiez trois choses dans votre clone : la version de Python installée, face à l'exigence de 3.10 minimum ; le contenu de requirements.txt, pour mesurer le poids réel des dépendances ; et le comportement du contournement de captcha dans votre mode de déploiement, puisque le README indique qu'il ne fonctionne pas sous Docker. Si vous prévoyez Tor ou le mode current browser, testez-les sur une cible sans conséquence avant de bâtir quoi que ce soit dessus.

Conclusion éditoriale

CyberScraper 2077 convient à qui veut extraire quelques pages, avec un modèle fort et une clé API, sans écrire de parseur. Ce n'est pas l'outil d'un pipeline de masse : coût par page, non-déterminisme et absence de release publiée sont trois choses à vérifier avant de s'engager, à commencer par le fichier requirements.txt et la version de Python sur votre machine.

Sources officielles

1. Issues
2. itsOwen/CyberScraper-2077 on GitHub
3. License: MIT
4. README