ScrapeGraphAI : décrire une extraction en langage naturel plutôt que d'écrire des sélecteurs

Le problème : écrire des sélecteurs pour un site qui change

Un scraper classique encode une hypothèse sur le HTML. On choisit un chemin CSS ou XPath, on écrit une fonction de nettoyage, et on la maintient jusqu'à ce que le site change de gabarit. ScrapeGraphAI inverse cette contrainte. Le README résume la promesse en une phrase : il suffit d'indiquer quelle information on veut extraire, et la bibliothèque s'en charge. L'unité de travail n'est plus le sélecteur mais le prompt. Pour une équipe qui collecte des profils d'entreprise, des offres d'emploi ou des fiches produit sur des dizaines de domaines différents, cela déplace le coût de la maintenance : au lieu de réparer du code après chaque refonte, on ajuste une consigne en langage naturel. Le public visé est donc précis : développeurs Python qui connaissent déjà les limites du scraping par sélecteurs et qui veulent un prototype fonctionnel sans cartographier le DOM. Ce n'est pas un outil pour quelqu'un qui n'a jamais écrit de Python, ni pour un cas où le format de sortie doit être garanti au champ près.

Ce que la bibliothèque fait réellement entre le prompt et le dictionnaire

Le README décrit l'architecture en une ligne : des pipelines de scraping construits avec un LLM et une logique de graphes. Le nom du paquet, scrapegraphai, et les classes exposées dans scrapegraphai.graphs reprennent ce vocabulaire. Concrètement, une instance comme SmartScraperGraph reçoit trois éléments : un prompt, une source, et un dictionnaire de configuration. Le pipeline récupère le contenu de la source, le fait passer par le modèle déclaré, et renvoie un dictionnaire Python. Le README donne un exemple de sortie avec des clés comme description, founders et social_media_links, où founders est une liste d'objets contenant name, role et linkedin. Cette structure n'est pas déclarée à l'avance dans le code de l'appelant : elle émerge de la consigne et du schéma imposé au modèle. C'est le point de conception central, et aussi la source de la plupart des surprises. La documentation ne détaille pas, dans l'extrait fourni, comment le contenu de la page est découpé avant l'appel au modèle, ni comment les chunks sont recombinés. Cette partie du mécanisme reste à vérifier dans le code source.

Installer et lancer un premier pipeline

L'installation tient en deux commandes, telles que le README les donne : pip install scrapegraphai, puis playwright install, cette seconde étape étant marquée comme importante pour la récupération du contenu des sites. Le README recommande un environnement virtuel pour éviter les conflits entre bibliothèques. Le premier script importe SmartScraperGraph depuis scrapegraphai.graphs, construit un dictionnaire graph_config, instancie la classe avec les arguments prompt, source et config, puis appelle .run() sur l'objet obtenu. Le résultat est un dictionnaire, que l'exemple affiche via json.dumps(result, indent=4). La configuration mérite qu'on s'y arrête, car c'est là que se jouent les choix qui coûtent. Dans l'exemple local, la clé llm contient model à ollama/llama3.2, model_tokens à 8192 et format à json. Deux autres clés de premier niveau apparaissent : verbose et headless. Pour un modèle hébergé, le README indique qu'il suffit de changer la configuration llm, en remplaçant model par openai/gpt-4o-mini et en ajoutant api_key. Autrement dit, passer d'un modèle local à un service distant ne demande aucune modification du pipeline, seulement du dictionnaire. C'est pratique, et c'est aussi ce qui rend le coût par page difficile à prévoir depuis le code seul.

Les pipelines au-delà de la page unique

Le README liste plusieurs pipelines en plus de SmartScraperGraph. SearchGraph traite plusieurs pages en extrayant l'information depuis les n premiers résultats d'un moteur de recherche. SpeechGraph part d'une page et produit un fichier audio. ScriptCreatorGraph est décrit comme un scraper mono-page dont la description est tronquée dans l'extrait fourni. Cette liste est la partie la plus fragile de la documentation : les descriptions sont courtes, et rien n'indique dans le matériel disponible comment SearchGraph choisit son moteur de recherche, combien de résultats il interroge par défaut, ni comment il déduplique les pages. SpeechGraph introduit une dépendance à une chaîne de synthèse vocale qui n'apparaît pas dans les commandes d'installation citées plus haut. Si votre cas d'usage repose sur l'un de ces pipelines plutôt que sur SmartScraperGraph, lisez le code avant de vous engager : le README ne suffit pas à en prédire le comportement.

Là où l'approche par LLM coince

Le point faible structurel est le déterminisme. Un sélecteur CSS renvoie la même valeur pour la même page. Un modèle de langage, non, même avec format réglé sur json. Le README ne promet d'ailleurs aucune stabilité de schéma : l'exemple de sortie contient un objet founder dont le champ name est une chaîne vide, ce qui montre que le modèle peut produire une structure correcte avec des valeurs manquantes. Sur un volume important, cela signifie qu'il faut prévoir une validation en aval, et que le coût par page dépend du modèle choisi et de la taille du contenu envoyé. Le second point est la confidentialité : avec un modèle hébergé, le contenu des pages transite par un service tiers. Pour des pages derrière authentification, des intranets ou des documents locaux sensibles, c'est un obstacle réel. La clé headless de la configuration rappelle par ailleurs que le rendu passe par un navigateur, avec la consommation de ressources que cela implique. Enfin, la bibliothèque est le projet open source d'un éditeur qui commercialise une offre hébergée, mise en avant dès la première ligne du README. Ce n'est pas un défaut en soi, mais cela signifie que la feuille de route open source peut suivre des priorités commerciales.

Face à un scraper classique ou à un service hébergé

L'alternative directe est un scraper à sélecteurs, avec requests et BeautifulSoup, ou un framework de navigation comme Playwright piloté par du code. La différence n'est pas la performance, c'est la nature de l'artefact à maintenir. Avec des sélecteurs, vous écrivez une spécification exécutable et déterministe, que vous versionnez et testez ; le coût est nul par page, mais chaque changement de gabarit casse le script. Avec ScrapeGraphAI, vous écrivez une intention, le coût par page est celui d'un appel de modèle, et la casse se manifeste plutôt comme une dérive silencieuse des valeurs extraites. Le choix dépend donc de la variabilité des sources, pas de leur nombre. Une autre voie consiste à utiliser l'API hébergée du même éditeur, présentée dans le README comme une façon de scraper à grande échelle en cinq lignes de code. Le compromis est inverse : moins de code à maintenir, mais le traitement quitte votre infrastructure. Entre les deux, la version locale garde la main sur le pipeline et sur le choix du modèle, y compris un modèle servi localement via Ollama.

Licence, mises à jour et coût de suivi

Le dépôt est publié sous licence MIT, ce qui autorise l'usage commercial et la modification, à condition de conserver l'avis de licence. Rien dans le matériel fourni n'indique de clause additionnelle, mais je ne donne pas d'avis juridique : faites relire le fichier LICENSE du dépôt si votre contexte l'exige. Le rythme de publication est soutenu. Les releases listées montrent v2.2.3, v2.2.4-beta.1 et v2.2.4 toutes datées du 7 septembre 2026, avec des écarts de quelques minutes entre certaines d'entre elles. Cette densité implique de figer une version dans vos dépendances plutôt que de suivre la branche principale, et de lire les notes de version avant de monter de version. Le coût de maintenance ne vient pas seulement du code : il vient aussi du modèle. Changer de modèle change la qualité d'extraction, et rien dans le README ne suggère une procédure de test pour mesurer cet écart. C'est à vous de constituer un jeu de pages de référence et de comparer les sorties avant de basculer.

Conclusion éditoriale

ScrapeGraphAI convient aux développeurs Python qui doivent extraire des champs depuis des pages dont la structure change souvent, et qui acceptent de payer cette souplesse en appels LLM. Ceux qui scrapent des milliers de pages au même format stable, ou qui ne peuvent pas envoyer le contenu des pages à un fournisseur de modèle, devraient s'abstenir. Avant d'adopter, vérifier deux points dans le dépôt : quels pipelines existent réellement dans le paquet installé, et si le parseur HTML utilisé par défaut correspond au type de page visé.

Sources officielles

1. License: MIT
2. Project website
3. README
4. Releases
5. ScrapeGraphAI/Scrapegraph-ai on GitHub